Table of Contents

Next Page

IT Auditing: Using Controls to Protect Information Assets
IT Auditing: Using Controls to Protect Information Assets
byChris Davis, Mike SchillerandKevin Wheeler
McGraw-Hill 2007 (387 pages)
ISBN:9780072263435

Packed with real-world examples, ready-to-use checklists, and valuable templates, this comprehensive guide will help you to build and maintain an IT audit function with maximum effectiveness and value.

Table of Contents
 | IT Auditing-Using Controls to Protect Information Assets
 | Foreword
 | Introduction
 | Part I - Audit Overview
 | Chapter 1 | - | Building an Effective Internal IT Audit Function
 | Chapter 2 | - | The Audit Process
 | Part II - Auditing Techniques
 | Chapter 3 | - | Auditing Entity-Level Controls
 | Chapter 4 | - | Auditing Data Centers and Disaster Recovery
 | Chapter 5 | - | Auditing Switches, Routers, and Firewalls
 | Chapter 6 | - | Auditing Windows Operating Systems
 | Chapter 7 | - | Auditing Unix and Linux Operating Systems
 | Chapter 8 | - | Auditing Web Servers
 | Chapter 9 | - | Auditing Databases
 | Chapter 10 | - | Auditing Applications
 | Chapter 11 | - | Auditing WLAN and Mobile Devices
 | Chapter 12 | - | Auditing Company Projects
 | Part III - Frameworks, Standards, and Regulations
 | Chapter 13 | - | Frameworks and Standards
 | Chapter 14 | - | Regulations
 | Chapter 15 | - | Risk Management
 | Index
 | List of Figures
 | List of Tables

Next Page


Back Cover

Previous Page
Next Page

Back Cover

Plan for and manage an effective IT audit program using the in-depth information contained in this comprehensive resource. Written by experienced IT audit and security professionals, IT Auditing: Using Controls to Protect Information Assets covers the latest auditing tools alongside real-world examples, ready-to-use checklists, and valuable templates. Inside, you'll learn how to analyze Windows, UNIX, and Linux systems; secure databases; examine wireless networks and devices; and audit applications. Plus, you'll get up-to-date information on legal standards and practices, privacy and ethical issues, and the CobiT standard.

Build and maintain an IT audit function with maximum effectiveness and value

  • Implement best practice IT audit processes and controls
  • Analyze UNIX-, Linux-, and Windows-based operating systems
  • Audit network routers, switches, firewalls, WLANs, and mobile devices
  • Evaluate entity-level controls, data centers, and disaster recovery plans
  • Examine Web servers, platforms, and applications for vulnerabilities
  • Review databases for critical controls
  • Use the COSO, CobiT, ITIL, ISO, and NSA INFOSEC methodologies
  • Implement sound risk analysis and risk management practices
  • Drill down into applications to find potential control weaknesses

About the Authors

Chris Davis, CISA, CISSP, leverages his experience auditing IT systems for Texas Instruments. Mr. Davis has trained and presented in information security, advanced computer forensic analysis, and hardware security design. He actively teaches auditing and certification curriculum for Southern Methodist University and is the author and contributor to several books and publications. His contributions include projects and presentations for SANS, Gartner, Harvard, BlackHat, and 3GSM. He has enjoyed positions at Texas Instruments, Austin Microsoft Technology Center, and Cisco Systems. He holds a bachelor's degree in nuclear engineering technologies from Thomas Edison, and a master's in business from the University of Texas at Austin. Chris was a U.S. Navy submariner, and served on the deep dive Submarine NR-1 and the ballistic missile OHIO class USS Nebraska, SSBN 739, Blue Crew.

Mike Schiller, CISA, has 14 years of experience in the IT audit field, most recently as the worldwide IT audit manager at Texas Instruments(TI). Prior to that, Mike served as the IT audit manager at The Sabre Group, where he served as the company's first-ever IT audit manager, creating the IT audit function, team, and processes from the ground up. Mike also has several years of experience as a senior IT auditor, programmer/analyst, and manager of IT support teams. He is involved in multiple industry IT audit organizations and has been a presenter at IT conferences such as ASUG. In addition to his years of experience in corporate management, Mike is also heavily 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.

Kevin Wheeler, CISA, CISSP, NSA IAM/IEM, is the founder and CEO of InfoDefense, an information security consultancy. Mr. Wheeler'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.

Previous Page


IT Auditing-Using Controls to Protect Information Assets

Chris Davis
Mike Schiller
Kevin Wheeler

The McGraw-Hill Companies

McGraw-Hill books are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please write to the Director of Special Sales, Professional Publishing, McGraw-Hill, Two Penn Plaza, New York, NY 10121-2298. Or contact your local bookstore.

© 2007 The McGraw-Hill Companies.

1234567890 FGR FGR 019876

ISBN-13: 978-0-07-226343-5

ISBN-10:

0-07-226343-1

Sponsoring Editor Jane Brownlow
Editorial Supervisor Janet Walden
Project Manager Madhu Bhardwaj
Acquisitions Coordinator Jennifer Housh
Technical Editors Barbara Anderson, Tim Breeding, Michael Cox, Subesh Ghose and Keith Loyd
Copy Editor Jim Madru
Proofreader Ragini Pandey
Indexer Kevin Broccoli
Production Supervisor George Anderson
Composition International Typesetting and Composition
Illustration International Typesetting and Composition
Art Director, Cover Jeff Weeks

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.

To my unbelievably awesome wife Sarah and son Joshua Michael,

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

To my wife Sandra; the love of my life, whose tireless encouragement and patience have sustained me through this process, to our beautiful child Heather, and to my lord who made all of this possible through His blessings.

-Kevin

About the Authors

Chris Davis, CISA, CISSP, leverages his experience auditing IT systems for Texas Instruments. Mr. Davis has trained and presented in information security, advanced computer forensic analysis, and hardware security design. He actively teaches auditing and certification curriculum for Southern Methodist University and is the author and contributor to several books and publications. His contributions include projects and presentations for SANS, Gartner, Harvard, BlackHat, and 3GSM. He has enjoyed positions at Texas Instruments, Austin Microsoft Technology Center, and Cisco Systems. He holds a bachelor's degree in nuclear engineering technologies from Thomas Edison, and a master's in business from the University of Texas at Austin. Chris was a U.S. Navy submariner, and served on the deep dive Submarine NR-1 and the ballistic missile OHIO class USS Nebraska, SSBN 739, Blue Crew. Go Big Red!

Mike Schiller, CISA, has 14 years of experience in the IT audit field, most recently as the worldwide IT audit manager at Texas Instruments(TI). Prior to that, Mike served as the IT audit manager at The Sabre Group, where he served as the company's first-ever IT audit manager, creating the IT audit function, team, and processes from the ground up. Mike also has several years of experience as a senior IT auditor, programmer/analyst, and manager of IT support teams. He is involved in multiple industry IT audit organizations and has been a presenter at IT conferences such as ASUG (Americass' SAP Userss' Group). In addition to his years of experience in corporate management, Mike is also heavily 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://www.texasrangerstrades.blogspot.com) and was named 2005 Texas Rangers Fan of the Year.

Kevin Wheeler, CISA, CISSP, NSA IAM/IEM, is the founder and CEO of InfoDefense, an information security consultancy. Mr. Wheeler'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 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. Ms. Hamaker 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. Ms. Hamaker'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.

About the Technical Reviewers

Barbara Anderson, CCSP, CCNP, has extensive experience in network and security planning, design, implementation, and operations. She currently serves as a senior network security engineer who provides consulting and support for LAN, WAN, and security design, including information security consulting, product implementation and training. Ms. Anderson proudly served her country for four and a half years in the U.S. Air Force. She has enjoyed positions at EDS, SMU, Fujitsu, ACS, and Fishnet Security.

Tim Breeding, CISA, currently serves as the director of Information Systems Audit at Wal-Mart Stores, Inc. His responsibilities include 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 Information Systems Audit Manager for six and a half years. While there, Tim presided over substantial growth of the IS audit function. Before joining Southwest Airlines, Tim served over 13 years in several capacities at Texas Instruments. His responsibilities included computer operations, software development, software quality assurance, and IS audit.

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.

Subesh Ghose worked for eight years in the IT audit industry for a Fortune 500 semi-conductor manufacturing company, where 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 life cycle. He is currently a manager in IT Security where he oversees the architecture/process development for securing external collaborative engagements and development of security controls in enterprise projects. In addition, he is responsible for disaster recovery processes for the enterprise data center. Subesh has an M.S. in computer science from Southern University.

Keith Loyd, CISSP, CISA, worked for seven years in the banking industry where he developed technology solutions for stringent legislative business requirements. As part of his role, he was responsible for implementing and testing networking solutions, applications, hardened external-facing platforms, databases, and layered mechanisms for detecting intrusion. Now in the manufacturing industry, Keith primarily deals with vulnerability and quality testing new applications and projects, worldwide incident response, and civil investigations. He has a B.S. in information technology from Cappella University and an M.S. in information assurance from Norwich University.

The excitement of learning separates youth from old age.

As long as you're learning you're not old.

-Rosalyn S. Yalow

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 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/Osborne is simply outstanding. We sincerely appreciate your dedication, coaching, and long hours during the course of this project. Jane Brownlow, this book is a result of your tireless dedication to the completion of this project. We congratulate you on your new baby and wish you the best. We look forward to working with you again in the future. We would also like to extend a big round of thanks to Jennifer Housh, 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 manager Madhu Bhardwaj; copy editor Jim Madru; proofreader Ragini Pandey; indexer Kevin Broccoli; editorial supervisor Janet Walden; production supervisor George Anderson; art director, cover, Jeff Weeks; and compositor and illustrator, International Typesetting and Composition.

A special thank you goes to Barbara Anderson, Tim Breeding, Michael Cox, Subesh Ghose, Donna Hutcheson, Austin Hutton, and Keith Loyd for their contributing works and deep reviews. Your involvement truly made the difference. Your reviews were wonderful, detailed, and significant in providing a useful product for the readers. Additionally, thank you Michael Cangemi for taking the time to deliver an incredible introduction to this work. Your words are thoughtful, kind, relevant, and illustrate the experience you have in this industry. And Doug Dexter-thank you for coming through at the last minute. We appreciate your quick turn-around and very kind review.

In particular, Keith Loyd-you went way above and beyond, and came to the table with excellent contributions and reviews. Michael Cox and Subesh Ghose, with all that you have going on, thank you for taking the time on this project. We know the readers will appreciate your expertise. Tim Breeding, you did an outstanding job contributing to the project auditing chapter. Barbara Anderson, you juggled multiple responsibilities including your home life and extensive work responsibilities to work on this book in the last hours. We thank you for that time and know the readers will appreciate the effort you put into this project.

There are two organizations that allowed us to borrow content to which we are truly grateful. 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 website. Thank you.

-The Authors

From Chris:

Thank you Sarah. This book would not exist without you. You've sacrificed so many late evenings for me to finish this. I'm thankful to have you as my wife and look forward to the many wonderful years we have left. I love you! Little Joshua, as your mom and I call you, we love you so much and can't wait to share this life with you. Not a day goes by that I 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.

Mike and Kevin, thank you for sharing the load, and investing your time into this work. You are good friends, and I appreciate the opportunity to learn from you. Through all of this project's challenges, between the three of us, we pulled it off. Barbara Anderson, Tim Breeding, Michael Cox, Subesh Ghose, and Keith Loyd-thank 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.

To the crew at McGraw-Hill/Osborne, especially Jane Brownlow and Jennifer Housh, you're a wonderful group to work with. I am grateful for the outstanding guidance and continual support. You're an amazing team, and I'm blessed for having worked with you.

A special thank you goes to my family for their love and support. Rob, David, and Jon, you are excellent examples of work ethic and wisdom. I'm grateful to have you as brothers and mentors. Thank each of you for your wisdom, love, support, and guidance.

Thank you Alan Bain, Michael Landewe, and Gord Boyce at ForeScout Technologies for allowing me to work on this project while getting up to speed on a new product in a hot field.

Finally, a special thank you goes to friends who convinced us to move forward with the project in the beginning stages. Thank you to all the friends and influences along the way, the Texas Instruments security and audit teams for your wealth of knowledge and opportunities to learn, Chris McAbee of Dallas, Texas for always being there for anything, and many, many others. I sincerely appreciate you all.

From Mike:

I would like to thank my good friends Tim Breeding, Michael Cox, and Subesh Ghose for helping with this book and making it better than we could have made it on our own. You're each not only outstanding auditors but also outstanding friends.

I would also like to thank my coauthors, Chris Davis and Kevin Wheeler, for their excellent work. Thanks especially to Chris for involving me in this book and for all of his hard work in coordinating this project. Thanks also go to Chris for helping me with visuals and being an excellent overall sounding board and reviewer. Extra thanks go to Kevin for the healthy debates and insight that helped us enhance the overall quality of the book.

Thanks to Mike Curry for his help in writing some of the audit steps in Chapters 3 and 4. Thanks also to Jane Brownlow and Jennifer Housh of McGraw-Hill/Osborne 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 (especially Table 7-3).

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. To Shawn Irving for your continued friendship throughout the years. 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.

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. 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 new energy and happiness you've brought into our lives. 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. 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. I couldn't have done this without you.

From Kevin:

I would like to thank Jane Brownlow and Jennifer Housh for being so patient with me, Chris Davis for including me in this project, his authoring guidance and encouragement, and my other coauthor Mike Schiller for the many hours of work that he put into this project. I would also like to thank contributing author Stacey Hamaker for providing a tremendous amount of expertise on Chapters 13 and 14, and technical editor Keith Loyd for the insight and depth of experience that he utilized while editing my chapters.

Next, I would like to thank my former employers and clients who provided opportunities for me to gain the IT audit experience required to write this book.

I would like to thank my Lord and Savior Jesus Christ for the many blessings including the opportunity to write this book.

Lastly, I would like to thank my wife Sandra for her continual support, encouragement, and incredible proofreading abilities; my mother and late father who have encouraged me throughout the years; and my sisters and brother-in-law who have graciously and unconditionally offered their support to me when I needed it most.


Foreword

The first books I read about IT auditing had no mention of databases, networks, or personal computers. They were not invented yet! Later I studied IT auditing books with no mention of routers, switches, firewalls, LANs, or web servers, which all came later. It would be very hard to find an industry that ever evolved at the speed of the information technology advances of the past three decades!

Prophets, song writers, and poets often advise us not to look backwards. However, as auditors, we spend a lot of our time looking backwards! Historically auditing was a look backwards. But "the times they are a changin"-inventions in information technology advanced the automation of recordkeeping and then the computerization of business itself. These IT advances transformed auditing to a real time and forward looking profession. As noted above, there is a constant need for books that keep the IT auditing profession more in step with the advances in information technology. After my initial review of IT Auditing: Using Controls to Protect Information Assets, I was excited about the invitation to contribute a foreward since I considered this book a quintessential transitional work for the IT auditing profession in the new millennium.

The pundits' question, who could get excited about auditing? Auditing has been a part of my life since the late 1960s when I began my career at Merrill Lynch, while in high school. Wall Street was in transition to the use of computers that enabled the massive expansion of the capital markets, which contributed considerably to the economic growth we have all enjoyed since the end of World War II. The need for IT auditors followed and I answered the call. These developments exemplify the aforementioned changes that make this book so timely and valuable.

I am a capitalist and a business management devotee. My career started in audit and followed the management path through IT audit director, chief audit executive, CIO, CFO, board member, CEO, and onto chairman of an audit committee. The theme of my recent book, Managing the Audit Function, is about managing people and particularly the audit function. I believe quality auditors utilizing tested and proven procedures, in a proactive way, will produce excellent audit results. My book provides a very detailed methodology for creating a management structure and procedures to perform audits effectively and efficiently. IT Auditing: Using Controls to Protect Information Assets addresses the state of the art technologies IT audit needs to be addressing today.

The book provides a quick overview of auditing in Part I, which is an excellent primer. It then proceeds to 10 core chapters on auditing techniques for information technology audits in Part II. This part makes the book a transitory work that bridges the long established basics of audit management, with the required technological guidance necessary to address auditing in the information age we live in now.

As noted, IT audit is always playing catch up. IT Auditing: Using Controls to Protect Information Assets provides the in-depth background and detailed auditing components and procedures necessary to audit core IT areas such as data centers, applications, databases, and also emerging audit areas like Linux, routers, switches, web servers, WLAN, and mobile devices.

These are still the early days of IT auditing. As the saying goes, "If you don't know where you are going any road will lead you there." As IT progresses so has the need for IT auditing methodology advances. When companies first installed data centers, few had the foresight to see the need for IT governance frameworks. As sophisticated IT enabled, not just the automation of recording keeping functions, but new IT-based businesses to evolve, there grew the need for formal IT planning, performance measurements, approvals, monitoring, policies, procedures, and return on investment measurements. We have come to refer to these as IT governance frameworks.

Organization managers are very busy individuals, trying to achieve the purpose of their business, to satisfy their customers and stakeholders. Among their many obligations are the requirements to control the business and ensure adequate returns. These are facilitated by the use of enterprise-wide control frameworks. IT Auditing: Using Controls to Protect Information Assets, Part III, provides a comprehensive overview of the widely used and generally accepted internal control framework COSO, the IT Governance Institute's IT governance framework CoBIT, which stands for Control Objectives for Information Technology, and others.

I have devoted a good portion of my professional career to auditing. Auditing is a window into a business that enables auditors to learn and continue their development. Careful consideration of how key IT control frameworks fit into the control structure of your organization will provide a deliverable to management, connect audit to a core business management issue, and ensure success.

-Michael P Cangemi, CPA, CISA

Editor-in-chief, IS CONTROL Journal

ISACA

September 7, 2006

Michael P Cangemi, CPA, CISA, is an author, speaker, and business consultant. He is president of Cangemi Company LLC (CanCo.us), a media and consulting firm centered on management, IT, and financial governance. Michael is the former president, chief executive officer, and director of Etienne Aigner Group, Inc. He is the author of Managing the Audit Function, now in a third edition, as well as in a Chinese translation, and long-time columnist and editor-in-chief of the IS Control Journal. Michael started his career at Ernst & Young and founded the Internal Audit Services practice at BDO Seidman after serving as CAE at Phelps Dodge Corporation. Michael is past international president of ISACA and past trustee of the IIA Research Foundation.


Introduction

Overview

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 item or how exactly to accomplish the step. Our goal was 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 was to demystify risk assessment and management, which is required by most regulations.

There is a wealth of knowledge and resources for hardening systems and performing detailed penetration tests in other texts. That is not the focus of this book. In our experience as auditors, we found that we were 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 hackerss' 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.


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, "Audit 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, "Standards, Frameworks, and Regulations," covers the standards, frameworks, 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 quickly help you 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.

Getting Around

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, providing the details on what the auditor should look for, why they should do so (i.e., what risk is being addressed), and how the step can be performed.

This is the audit step that should be performed This is the text immediately following the step stating why this step is important. This part states the reason, 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 looking more closely at 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.

Knowledge Base

This is a list of URLs and books where readers can find more information about the topic 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. 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 over-whelmed and overlook something. In addition, it is very 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 did writing it. Good luck in all your audits.


Part I: Audit Overview

Chapter List

Chapter 1: Building an Effective Internal IT Audit Function
Chapter 2: The Audit Process


Chapter 1: Building an Effective Internal IT Audit Function

The philosophies and guidance provided in this chapter form a foundation on which the rest of the book is built. It should be noted that while this first chapter is written from an internal auditor's perspective, the concepts and philosophies 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 we can develop an effective internal audit department, we must first come to an understanding of the department's purpose. Why does the internal audit department exist? What's the end goal?

Is our purpose to issue reports? To raise issues? To make people look bad? To show how smart we are and how dishonest, incompetent, and corrupt the rest of the company is? To flex our muscles and show that we can do anything and tell on anyone because we report to the board of directors? Hopefully, it's obvious that none of these are the right answer. Sadly, though, you will find that many (perhaps most) internal audit departments function as if one or more of these items are the answer. 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 and failing to realize the potential benefits that they could be providing to their companies.

Most audit departments were formed by the company's audit committee (a subset of the board of directors) for the purpose of providing them with independent assurance that internal controls are in place and functioning effectively. In other words, the audit committee wants a group that it can trust to be objective enough to tell it if there is anything the committee should be worried about. The committee wants to have someone it can trust to tell it what's "really going on" in the company. The committee wants someone it can trust to turn in all the evildoers in the company who refuse to implement internal controls. Internal audit departments usually report directly to the chairman of the audit committee, so they feel protected from blowing the whistle on the hordes of dishonest managers who surely have infested the company.

We cannot lose sight of this very important function. Despite the levity in the preceding paragraph, it is absolutely essential that the audit committee have eyes and ears within the company that can tell it what, if anything, it needs to be worried about. This is critical for the committee's ability to function and serve the company's shareholders. It also should be noted that most companies' audit departments dual report to an executive within the company, such as the chief executive officer (CEO) or the chief financial officer (CFO). We'll discuss later some implications of this reporting relationship, but for now, let's agree that this indicates that senior management is interested in the state of the company's internal controls, just like the audit committee. Therefore, I think we can comfortably establish that one of the internal audit department's key functions is to provide an objective body that the audit committee and senior management can go to, to find out if there's anything bad going on in the company from an internal control perspective. From an IT perspective, this means that audit committee and senior management want to be able to ask 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?" and believe that they will get an honest answer.

Therefore, can we say that the function of the internal audit department is to report internal control issues to the audit committee and senior management (or provide them with assurance that there are no issues)? The answer is, "Sort of." This is certainly an important role for the audit department to play. However, if we stop there, we are not getting the whole picture. We haven't totally missed the boat-it's more like we showed up as the boat was pulling away from the dock, jumped to catch it, and currently are hanging from the outside railing, holding on for dear life.

But why are we really here? What's the value of reporting issues? Merely reporting issues accomplishes nothing, except to make people look bad, get them fired, and create additional 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 is to improve the state of internal controls at the company. Reporting them provides a mechanism by which the issues are brought to light and 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, meaning that the company is still at risk. It's only when the hole is patched that I've actually done something that adds value to the company (and that's 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 we must remember that these acts provide no value in and of themselves. They only provide value when the internal control issues are resolved. This is an important distinction to remember as we develop our approach to auditing and, most important, to dealing with the people who are the "targets" of our 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.

In summary, the internal audit department's mission is twofold:

  • To provide independent assurance to the audit committee (and senior management) that internal controls are in place at the company and are functioning effectively.

  • To improve the state of internal controls at the company by promoting internal controls and by helping the company to 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

You will see that the term internal controls is used frequently throughout this chapter. Internal controls, stated in the simplest terms, are mechanisms that ensure the proper functioning of processes within the company. Every system and process within the company exists for some specific business purpose. The auditor must look for risks to that purpose being accomplished and then ensure that there are internal controls in place that mitigate those risks. We will dedicate some time in Chapter 2 to delving into the real 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. It is what they reference as 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 very much 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 feel that they are therefore not influenced or controlled by others. But let's examine this a little closer.

Yes, the audit department does indeed report to a member of the board of directors. However, in almost every company, the audit director also reports to the company's CFO or CEO (Figure 1-1). In most cases, the budget for the audit department is controlled by this executive, and more important, so is the compensation of the 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.

Image from book
Figure 1-1: Audit committee board of directors
Note

The bottom line is this: You work for the company and report to its management; therefore, you are not independent.

More important, as will be discussed later in this chapter, the most successful audit departments will have at least some people who have rotated into 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 he or she is an arrogant, know-nothing idiot.

It therefore seems apparent that internal audit departments are not truly independent. However, the core concept behind the independent auditor idea is valid and very important. An auditor must not feel undue pressure to bury issues and must feel that he or she has the avenues necessary 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. However, this should be a tool used only as a last resort because ultimately it is not healthy if the auditors constantly have to go over management's head.

It seems that objective is perhaps a more appropriate word to describe an internal auditor than independent. Webster says that someone who is objective is "not influenced by personal feelings or prejudice; unbiased." Although the internal auditor, by definition, is not really independent, it is fair to expect him or her to be objective. If the right sorts of auditors are hired, they will have the ability and willingness to put their personal feelings aside during an audit and view things in an unbiased fashion.

In order 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 things, 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 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 to be outsourced.

Note

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 show them that having your group of employees as their internal auditors is a competitive advantage for the company. Otherwise, you're just a bottomline cost, and if your 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

The cost of correcting issues and adding controls postimplementation is significantly higher than the cost of doing it right the first time. There is no difference regarding independence between providing an assessment of a system or solution prior to implementation and providing an assessment after implementation. There is a difference, though, 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 to not add value and to not 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 does not 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.

Many auditors are frozen with fear when asked for a preimplementation 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. Thus, how does providing such input this week damage your independence, whereas providing it next week (after implementation) doesn't? There's no logic to it.

Is there a chance that you might miss something or give bad advice with this upfront involvement? Of course. Just as there's a chance during any traditional audit that you might miss something or give bad advice. It's always a risk, and you just need to get over it and do your best.

Note

A key question that often comes up relates to the future independence (or objectivity) of the auditor who performed the upfront consulting work. Can he or she be allowed to audit the system in the future? Or is he or she compromised by the fact that he or she already has signed off on the controls and won't want to make himself or herself look bad by admitting that he or she missed something? This is certainly something worth considering. However, 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 preimplementation. The auditor who was involved before implementation is going to be your most knowledgeable resource for a postimplementation audit. It seems a shame to not use this resource. As mentioned earlier, the point of the audit is to improve internal controls. Who is better suited to perform a detailed audit than the person who was involved with the project team in the first place? If there continues to be a concern about that auditor's objectivity, then you might consider making him or her a team member but not the team leader. This will provide an extra layer of review over his or her work to ensure that he or she is not being unduly influenced by his or her prior work.

Are there lines that shouldn't be crossed when it comes to working with teams before implementation? Absolutely. The auditor generally should be involved with the team in an advisory capacity. This 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 roll up his or her sleeves and help to think through how the controls should work. However, this should not include actually executing the control, writing the code for implementing it, or configuring the system. We can't both own the control and audit it, but we should feel comfortable providing as much input as possible as to what the control should look like. To do less is just limiting your ability to do what you are really paid to do, which is to improve the quality of the company's internal controls.


Four Methods for Consulting and Early Involvement-Your Toolkit

Now that we've established that it's okay to actually 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 your formal audits:

  • Early involvement

  • Informal audits

  • Knowledge sharing

  • Self-assessments

Early Involvement

We've already discussed this a bit. The most cost-effective way to create internal controls is to build them in up front. 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 have done it right the first time. Also, as an auditor, you're much more likely to run into 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).

If we can agree that building in controls up front is our most efficient and cost-effective method, let's talk about how to accomplish this. Unfortunately, it's going to differ by company. However, 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 have a weekly or monthly meeting? Try to get yourself invited to it. Even better, does the company have 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 actually 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. Sure, there's a chance that you might mess up and sign off even though there's an internal control weakness in the system, but this is a chance you have to take. This is a risk we all 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 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. It may take some time, and your first step may need to be to begin the process of developing good relationships. However, given that the relationship is such that the IT groups will consider your request, be sure to let them know that your motive isn't to slow anything down or stop anything, but instead that you are expressing a willingness to step up to the plate and help them out. Your tone shouldn't be that you think they need your approval but that you'd like to be part of the solution, not part of the problem. Let them know that you might be auditing them someday 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 the controls in up front.

Again, this may take time, and you may need to be persistent, but the end result is worth it.

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 early? 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 by 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 with it and determine what sorts of controls you expect to see in order 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 system, technology, or process being implemented. You need to think through the potential risks involved with it that might affect its security, integrity, or reliability. You then can provide input to the teams regarding what controls you would be looking for if you were auditing it after the fact. Basically, you're planning the audit and sharing the key points of your audit plan with the auditee as the system is being developed (Note: The chapters in Part II of this book will serve as an excellent guide in performing this planning). From your standpoint, you are sharing your audit plan. From their standpoint, you are giving them a set of internal control requirements. If this is all you can do, you've already provided an excellent service. However, if you're in a position to get the project team to confirm with you how it has implemented those control requirements so that you can ensure the controls appropriately mitigate the risks, then you've really arrived.

Is the auditor required actually to perform independent testing and validation to ensure that the controls are working as described? In other words, does the auditor really have to perform an audit of the system before implementation in order to be willing to sign off on it? This certainly would be nice and is probably a good idea for major enterprise application implementations and things of that magnitude, but it is not realistic from a resource standpoint to do this for every project that comes along. It is perfectly acceptable to make it clear to all that your sign-off is based on the assumption that the information that you've been given is accurate. If you audit the system later and it turns out that the controls weren't implemented as described, it's not a failure on your part.

It is also important to understand that not all of these early involvement opportunities will be time-consuming. Some projects have a significant internal control impact. For example, implementation of new tools that provide the ability for external business partners to access the internal network needs to be scrutinized heavily and will take some time. On the other hand, implementation of a new conference room scheduling system has almost no internal control impact and should be dispositioned by the auditor quickly. This does not mean that the auditor declines to get involved by saying that internal controls are not applicable to the system. What it does mean is that the auditor can provide some high-level guidance and be done with the project for all intents and purposes. There's a big difference image-wise between saying that a system doesn't matter to you and saying that you want to provide sign-off as usual but that you don't have many concerns. One is a negative message, and the other is positive.

Note

Remember that for every project you're involved with, no matter how insignificant it is from an audit standpoint, you have a unique opportunity to educate your fellow employees on internal controls and their importance.

Informal Audits

One of the issues facing almost every department in almost every company is resource constraints. There's never enough time to do all the things you wish. For audit departments, there are always risks out there that we don't have time to address. There are always requests for audits that we can't fulfill. If our audits are to be thorough, we'll have time to audit only a handful of areas every year. In fact, if your audit scheduling process is purely risk-based (as opposed to having everything on a set rotation), there are some areas that will never make the cut. You'll likely never go to the audit committee and tell it that one of the top 15 risks that you need to review for the year is a tiny data center in a remote location supporting a small handful of people performing a less-than-critical business process. But does this mean that we should never work with those employees to help them understand the state of their internal controls? Does this mean that we should never understand what the risks at that site are? There has to be some way to perform reviews of such areas without turning them into unnecessarily large efforts. The informal audit is the mechanism to use.

In Chapter 2 we'll discuss potential processes for forming your audit plan. For now, let's take it as a given that you have some sort of risk evaluation process that helps you to form your audit plan each year. The problem is that there are two major gaps in what you'll be able to cover:

  • As mentioned earlier, if the process is risk-based, there are some areas that you'll never get to.

  • There are times when management requests an audit (once you've developed the right sort of relationship with them), but that audit just doesn't make the cut once you perform a risk ranking.

It is important that formal audits be performed in a disciplined and thorough manner. We will discuss the audit process in Chapter 2, but for now, let's just accept the fact that, to do them right, they need to be thoroughly documented and tested, including taking representative samples of data before making conclusions. Although all this is important and necessary, it is also time-consuming. But what if you had the flexibility to perform some audits in a more on-the-fly manner? If you've built a strong IT audit team, with good depth of knowledge and experience, you should be able to let them loose to perform a "quick and dirty" review of a system, site, or technology. Remove the constraints of documenting their work in detailed work papers. Forget about taking large representative samples. Let the auditors act as consultants. Give an auditor a couple of weeks to review the controls of the area, and tell him or her that all he or she needs to produce at the end of the project is a memo summarizing the results. You'll be amazed both at the quality of the results and the appreciation shown by the people you audited. You'll also be amazed at how much the auditors are able to accomplish in a short time when released from the shackles of the normal audit process (which are important for formal audits and, again, will be discussed in Chapter 2).

Of course, it's also important to put caveats on the work and the results. Make sure that the people you are informally auditing understand that this will not be as thorough as a formal audit, that you are not claiming that you will find all the issues, and that you are not testing statistical samples. Even though auditors like to shy away from the word consultant, you should make it clear that this is exactly what you are in this case. You are loaning them your control expertise. If you are of a particularly paranoid nature, you might even want to state these caveats in your final memo so that the review doesn't come back to haunt you later if more issues are found.

A common question with these sorts of informal reviews is whether the auditors are required to track the issues to completion. There is no right answer to this question, but in general, "No" is the best answer. This is an informal audit, and the issues have not been substantiated as thoroughly as in a formal audit. Therefore, you are on a little shakier ground when it comes to turning around and requiring that the issues you raised be fixed. Also, since this was an area that wasn't risky enough to make the formal audit plan, it's likely that the risks are relatively minor from a company perspective. Forcing and tracking their mitigation may be unnecessary overhead. Also, it may make others less likely to request your services in the future. If they invite you in as a consultant and then you turn around and beat them up and tell them they need to fix all the issues or be reported to the audit committee, they're highly unlikely to ask for your help again.

But what if you uncover a major issue that is creating a significant risk for the company? Clearly, in such a case, you have an obligation to make the appropriate level of management aware of the issue and ensure that the risks are mitigated. Therefore, a happy medium for these engagements is to tell the people you're auditing that you don't intend to track the issues coming out of the review but that if you find a major issue, you'll have to make an exception. Most people will be understanding and accepting of this obligation.

What does the audit process look like for an informal audit? It should be simple and straightforward, consisting of the following basic steps:

  1. The audit department should agree on the timing and scope of the informal review with the people they will be auditing.

  2. The auditor who will be performing the review should make a basic checklist of areas he or she plans to review during the project (the checklists throughout this book provide a good starting point).

  3. The auditor executes those steps, keeping notes as needed but not creating work papers for review. The notes do not need to be kept once the audit is completed. Remember, speed is of the essence, and this is a consulting engagement, not a formal audit review. If you can't get comfortable with this, you'll bog yourself down with documentation and process, losing the flexibility to perform this sort of review effectively.

  4. At the end of the project, the auditor compiles all concerns from his or her review.

  5. The auditor has a debriefing meeting with the people he or she has been auditing to discuss the issues and consult on how serious the issues are and potential means for addressing them.

  6. The auditor documents the final list of concerns, along with relevant thoughts on resolving them, in a memo. This memo does not need to include due dates and can include the caveats mentioned earlier (this is not a formal audit, we will not be tracking issues, etc.). The memo also should indicate the auditor's willingness to continue consulting with the team as it addresses these items.

  7. The auditor issues the memo and archives it electronically for future reference.

This list of steps may seem overly simplistic, and this is intentional. You need to avoid overengineering the process. The idea is that you're the department with internal control expertise, and you're consulting with other departments in this regard. Send knowledgeable, experienced auditors in, and let them "do their thing." Informal consulting engagements are another tool in your toolkit that you can use to promote internal controls at your company. They are yet another way that you can add value to your company.

Note

You have the internal control expertise, and you need to use it in every way imaginable. Informal audits are a way for you to do a lot quickly. They greatly increase your coverage of the company's risks and your ability to accomplish your mission of promoting internal controls.

Knowledge Sharing

As internal auditors, you have a unique blend of knowledge of the company and expertise in internal controls. As we have established, the true mission of an internal audit department is to help the company improve the state of its internal controls. In order to do this, it is vital that the internal audit department be creative in finding new ways to share its unique knowledge with the rest of the company. Of course, much of the knowledge sharing should occur as you perform audits, as you perform consulting reviews, and as you provide input as part of your early involvement activities. However, this still leaves some gaps. In this section we'll discuss how to close some of the remaining gaps.

One of the easiest communication vehicles should be the company's intranet. The internal audit department should have its own website. Unfortunately, for many companies, this website simply contains the audit department's organization chart, a description of its mission and processes, and its audit schedule. While these are certainly useful elements of the website, they don't realize the site's potential as a vehicle for communication. Listed below are three key opportunities for obtaining additional value from the audit department's website.

1 Control Guidelines

As you prepare for audits, one of the most frequent questions you'll receive is, "What do you people look for?" Wouldn't it be nice if you could just tell them to go to your website for the answer? Obviously, for some one-time audits, where you've never reviewed the area before and it will be years before you review it again, this wouldn't be practical. For common technologies and topics, though, it can be extremely helpful to provide control guidelines describing the sorts of things that you usually review during audits. The areas covered in Part II of this book are good candidates for this sort of thing. Why not let people know what sorts of things you look for when auditing Unix? Why not let them know the basic sorts of controls you look for when auditing an application? Not only will this help people prepare for your audits, but it also will provide excellent information for anyone else at the company who may be interested but whom you have no plans to audit. If you have checklists of things you look for in an audit, it's trivial to turn those checklists into control guidelines that can be used throughout the company. For example, perhaps you have a Unix test step that says, "Ensure that a shadow password file is used to prevent users from viewing the encrypted passwords." The control guideline could say, "A shadow password file should be used to prevent users from viewing the encrypted passwords." It is as easy as this. Turn your audit programs into control guidelines, stick them on your website, and you've helped reach your goal of open communication and promotion of controls.

Note

Posting control guidelines on your website empowers groups expecting an audit. Some groups actually will spend time up front finding weaknesses and implementing appropriate controls. This effort benefits the company and the group being audited.

2 Common Issues, Best Practices, and Innovative Solutions

Auditors are in a unique position in that they are able to review the processes and technologies that exist all across the company, giving them the ability to note trends and to compare and contrast various organizations. Unfortunately, they rarely take time to consider how the results of an audit might be useful to other similar organizations at the company. Now, there are many audits where the results are not applicable to any other organization. On the other hand, in most companies, there are some functions that are performed by multiple decentralized organizations. For example, perhaps Unix administration is performed at each company site by the site IT folks. In such a case, the results of a Unix security audit at one site could be very useful if shared with the Unix administrators at all other sites. These results could help them to analyze their own controls to ensure that they don't have the same problems. This is a way that your one audit can have an impact on other organizations months or years before you actually get around to auditing them. It's usually not healthy to air an organization's "dirty laundry" unnecessarily, but results usually can be "sanitized" so that they do not directly indicate the organization that was audited. Even better, if an area such as Unix security is going to be audited at multiple sites, wait until you have three or four of the audits under your belt, and then compile the results to determine what issues are surfacing commonly. This can be the basis of a common issues communication sent to all personnel with similar responsibilities. This sort of message should be communicated both on the website and also as an e-mail that is sent to all relevant personnel. This provides both a push and a pull delivery mechanism for your message.

Use the auditor's company-wide perspective to compile best practices and innovative solutions from past audits. As you perform your audits, you sometimes will see that a group has implemented a control particularly well. Or you might find instances where a group has developed an innovative solution for an issue found commonly in other sites or groups. This information also should be compiled and shared via the website and e-mail. This will help others to improve their controls and resolve issues that they may have in their own environments.

3 Tools

Do you have audit tools that you use in performing your audits? Why not make those tools available to the rest of the company so that people can assess themselves if desired? For example, if you use a vulnerability scanning tool for reviewing the security of various devices at the company, consider making that tool available via your website, along with some basic "how to" documentation. Of course, licensing issues must be taken into consideration, but it's something worth investigating. Again, this is another way that you can promote internal controls, allowing people to assess themselves. If you're using open-source tools, consider providing links to the websites where those tools can be retrieved. It's all part of sharing your knowledge and expertise.

Note

Sharing the tools auditors use with others enables groups to self-assess their controls. This is an excellent enabler, but it is important that you carefully package the tools inside strong policy stating who can use the tools, on what systems, at what times, and with whose permission. Other things to consider are controlled areas of the website open only to the IT organization and how to regulate the use of hacking tools such as password crackers and spoofing utilities. Inappropriate use of these tools can compromise personal information or violate the integrity of critical data.

Also, as mentioned in the immediately preceding section, you may know of instances where a group has developed an innovative solution to a common problem. If the solution involved developing a tool, ask the group if you can have a copy and post it on your website for others to use. For example, if a group has developed a script to enforce password aging in a Unix NIS (Network Information Service) environment, get a copy of it and place it on your website. In this way, other organizations running NIS can get it and improve their control environments too.

If you use the website for this purpose, it will be important to place a caveat on your site stating that you don't support the tools. You don't want to get in a position where people are calling you at all hours expecting you to help them debug the tools. Of course, you should be willing to help where you're able, but you don't want to set an expectation that turns you into a software support organization. Also, you should check with your IT security organization prior to making these tools available on your website to ensure that distribution and use outside the IT security and IT audit teams is not a violation of policy. Finally, you should include a disclaimer stating that there are no guarantees regarding the compatibility of the tools with any specific system and suggesting that they first be executed in a test environment. There is always the risk that a tool will interact oddly with "buggy" software, and you don't want to be held responsible should something unfortunate occur.

Self-Assessments

Another concept for promoting controls outside a formal audit is the self-assessment. Entire books have been written on this concept, and it is up to each audit department to determine whether it wants to formally implement a control self-assessment (CSA) model. We will not get into the details of this process here. However, conceptually, facilitating an organization in assessing itself is another potential tool for your toolkit. This could be as simple as walking through your control guidelines (described earlier in this chapter) and asking the organization whether or not it has implemented each control. This can lead to healthy dialogue around the purpose of each control and what level of mitigation is truly necessary. Earlier in this chapter we described the informal audit, which is something less than a formal audit but provides an organization with good input on the state of their internal controls. The self-assessment exercise is something less than an informal audit, in that it provides absolutely no independent validation of the controls in the environment, but it also can be a useful vehicle for promoting controls. Once again, a knowledgeable and experienced auditor is critical for making this tool work.

Consulting and Early-Involvement Toolkit-Final Thoughts

As can be seen, there are many methods of reviewing and promoting internal controls at a company besides formal audits. Of course, one of your barriers will be getting company management and the audit committee to approve use of your resources in this way. They may be resistant to using resources for anything except formal audits. Your best ammunition is to get the focus away from counting how many audit reports are issued and toward looking at how the department is helping to improve internal controls at the company. If you convince them to let you try it, even on a test basis, the results will speak for themselves.

Note

If the audit department focuses solely on formal audits, it severely limits its coverage and ability to fulfill its mission successfully.


Relationship Building-Partnering versus Policing

One of the biggest mistakes made by internal audit departments is distancing themselves from the rest of the company under the auspices of independence. Again, the question comes back to one of mission. If the department's mission is to promote and improve the state of internal controls at the company, then the more informed you are about what's going on, the more effective you'll be. Unfortunately, too many companies take the approach of doing "drive by" audits. They decide what they want to audit with little input from management. They decide when they want to perform the audit and inform the auditees, sometimes with very little notice. They then swoop in, perform the audit, throw the issues over the wall to be fixed, tell senior management how screwed up the area is, and disappear. They are then only seen again when they are beating people up for not addressing the issues by the due dates (which often were dictated by the auditors).

How receptive and open do you think people are going to be to the auditors under this approach? The answer is, "Not very." When audits are conducted in this way, it's a painful and unpleasant experience, and people are just trying to get it over with. They're likely to take the "just answer their questions and don't volunteer any information" approach. After the auditors leave, the people they have been auditing laugh about all the big, gaping internal control holes that the auditor missed. Was that audit effective? Absolutely not. It was an adversarial exercise in which the auditors had to fight their way through to the end, usually missing important issues.

Note

An effective internal audit department considers the audit to be a partnership with fellow employees and not a policing function. An effective audit department is involved year round with key functions and does not just swoop in and out when performing audits. The audit should be just an occasional event in an ongoing relationship.

By combining your internal controls expertise with the auditee's expertise in their business and day-to-day operations, together you can best determine what risks exist that are worth addressing. When you are having success in this area, the people you are auditing begin volunteering information about potential audit issues in their area. They go beyond just answering the questions you've posed and are brainstorming with you regarding where they might have exposures. You have credibility, and when you raise potential issues, their first reaction is not to fight you on them but instead to accept them and try to understand the reasons behind your concern.

At the end of an audit, the people you've been auditing should look back and realize that it was a helpful experience and was not unpleasant. Of course, there will be exceptions. On rare occasions you actually will find people who are uninterested and unwilling to implement the internal controls necessary for their area. There still will be occasional conflicts, but they should be extremely rare if the auditors know what they're doing and bring a customer-oriented approach to the job.

It is important to point out that advocating positive relationships does not abdicate the auditor of his or her responsibility to be objective. The auditors still must bring healthy skepticism to the job. However, this can be done in a negative way or in a positive way. You can choose to give the customer the impression that you don't believe anything he or she says and therefore must verify it, putting him or her on the defensive. Or you can bring an attitude to the table that says, “Look, I trust and believe what you're saying, but the standards of my profession require me to independently validate it-can you help me get access to the information I need to do so?' Very few people will be offended or defensive about the latter approach (unless, of course, they're among the small percentage of truly dishonest employees).

Note

Adversarial relationships get in the way of the core objective of the audit department, which is to improve the state of internal controls at the company. It is the responsibility of the audit department to do everything it can to minimize those negative relationships and foster positive ones.

Learning to Build Partnerships

In order to arrive at these results, the relationship between the IT auditors and the IT organization must be a cooperative, collaborative one. The auditors must have credibility and trust within the IT organization. This requires an investment of time and some patience as the relationship develops. Below are some basic steps that can be taken to start the journey:

  • Be intentional about regular updates and meetings with IT management.

  • Establish formal audit liaisons with different IT organizations.

  • Get yourself invited to key meetings.

  • Cultivate an attitude of collaboration and cooperation.

Be Intentional about Regular Updates and Meetings with IT Management

Select the IT managers over key areas, and get on their calendars. During those meetings, get their input on the audits they want you to perform. Get an understanding of upcoming activities in their area, and see if there are opportunities for you to help and consult on internal control needs for those activities. This information will aid in identification of the early-involvement opportunities discussed earlier in this chapter.

Establish Formal Audit Liaisons with Different IT Organizations

Assign an auditor (or the IT audit manager) to be the relationship manager for each significant IT organization. These relationship managers will have the responsibility of maintaining contact and relations with the management and key contributors of their assigned organization. This could involve regular (e.g., monthly, bimonthly, or quarterly) meetings with those contacts in order to keep up with their activities and understand their concerns. It could involve attending department meetings. It could involve getting their input as each year's audit plan is developed in order to obtain their recommendations for formal or informal audit activities.

Get Yourself Invited to Key Meetings

Get yourself invited to key meetings, such as project reviews, strategy sessions, and IT communications meetings. They are a great way to keep up with what's going on and are also excellent networking opportunities. As people get used to seeing you as part of their normal routine, they become more comfortable with you and much more likely to call you when they have internal control concerns or questions. Maintain a presence in the IT community. There are IT groups that support the network and some that support business applications. You're the IT group that provides internal control assurance. You're part of the overall team and have a unique and important function, just like they do. When invited to key meetings, don't take the "fly on the wall" approach that many auditors do, where you feel that your role is to just observe. Be vocal, join in the discussion, and provide your perspective as an auditor to the proceedings. This is a more value-added approach than just sitting against the wall. Similarly, look for opportunities to present at staff and department meetings on relevant internal control concepts. This is an excellent vehicle for spreading the word.

Cultivate an Attitude of Collaboration and Cooperation

Cultivate an attitude of collaboration and cooperation among the IT audit team. Do not allow team members to take the old-fashioned heavy-handed approach to auditing, where the audit department is the police department coming in to beat people into submission for not following the rules. Small things such as calling people customers instead of auditees can do wonders for altering the mind-set of team members and fostering the right attitude. The audit team should avoid "gotcha" tactics and language in its communications, instead presenting its concerns in an open way that shows respect and fosters discussion. The ability to work well with customers should be a part of each auditor's performance evaluation.


The Role of the IT Audit Team

So isn't this a book about IT auditing? So far, most of what you've read in this chapter is pretty much applicable to any sort of auditing. While this is true, the concepts we've discussed thus far are foundational to building an effective internal audit team, whether it's focused on IT auditing or another sort.

So let's talk about IT auditing. What is it? The obvious answer is that it's the auditing of information technology, computer systems, and the like. We'll assume that if you're reading this book, you understand the basic difference between an IT auditor and a financial or operational auditor, so let's not belabor the point by coming up with a technical definition of IT auditing. However, there are a number of variations and interpretations as to the role of an IT audit group within the overall audit function. We'll look at a few models:

  1. Information systems auditors

  2. Support for the financial auditors

  3. IT auditors

Before exploring what these mean, let's define a greatly simplified basic stack of potential technical subject areas that an IT audit group might be called on to review (Figure 1-2):

Image from book
Figure 1-2: Potential auditing subject areas.

  1. Entity-level controls. These are controls that are pervasive across the organization and provide the basic foundation for the control environment at the company. Examples of standard entity-level controls are company policies and mechanisms for complying with regulations such as Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPPA).

  2. Physical facility. This, quite simply, is the physical building and data center housing the computer equipment on which the system in question resides.

  3. Networking and communications infrastructure. This is what allows other systems and users to communicate with the system in question when they do not have physical access to it. This layer includes basic networking devices such as firewalls, switches, and routers.

  4. Operating system. This is what provides the basic operating environment on which the higher-level application runs. Examples are Unix, Linux, and Windows.

  5. Middleware. This is software that provides additional integration between two separate "programs" that were not originally designed to communicate with each other (e.g., between a database system and a web server or between an application and a database that it was not originally designed to access).

  6. Database. This is the tool that organizes and provides access to the data being run by the end application.

  7. Application. This is the end application, which actually is seen and accessed by the end user. This could be an enterprise resource planning (ERP) application providing basic business functions, an e-mail application, or a system that allows conference rooms to be scheduled.

Some element of all these generally will be relevant to all systems reviewed. The majority of this book is dedicated to detailing exactly how to audit these areas (and others), so we won't spend time on that here. However, it is important to understand that these layers work together and that each forms a foundation for the next layer.

Note

This is not intended to be an exhaustive list of potential subject areas and technologies that could be reviewed by an IT auditor. It is instead intended to illustrate some of the more common layers that might be reviewed during an audit. The stack of potential auditing subject areas could be made significantly more complex and granular if desired, spiking out topics such as storage and web servers. However, this simplified version will help illustrate the following discussion regarding types of IT auditors.

With this as a background, let's look again at those models of IT auditing mentioned earlier that describe the role of an IT audit group within the overall audit function.

Information Systems Auditors

There are an amazing number of IT audit groups that really aren't IT audit groups at all. These groups generally contain no true IT auditors but instead are made up of business or financial folks who know how to use business application systems. These audit teams focus almost solely on the application layer. They do a very thorough job of ensuring that access is properly controlled and that segregation of duties issues does not exist. They likely will do a good job of ensuring that unauthorized changes to the application cannot occur and that good controls are in place to ensure the integrity of data being entered into the system. However, they miss most or all of the other layers, meaning that they are only seeing part of the picture. They are not reviewing the foundational controls on which all systems rely, such as the security of the network and of the operating system environment. If those areas are not controlled properly, it's like locking the door but leaving the windows open. There are multiple ways for people to exploit security weaknesses at those other layers to disrupt the integrity, reliability, and security of the application systems. IT audit groups usually take this approach when they have not hired people with the appropriate technical skill sets that would allow them to understand and review the other layers of the stack. They focus on the application layer because that is all they understand.

Support for Financial Auditors

Still other IT audit groups spend the majority of their time pulling data for the financial auditors and helping them analyze it. They are likely to be experts at data extraction and analysis tools, such as Audit Command Language (ACL), but are not truly auditors. They receive requirements from the financial auditors and execute those requirements. For example, the financial audit team may be reviewing an accounts receivable process and asks the IT auditors to pull a list of all invoices greater than 90 days past due. These types of auditors can be a valuable part of an audit department, but if they constitute your entire IT audit function, you're missing a lot of the risk.

IT Auditors

Other departments have IT auditors that spend the majority of their time focusing on areas beneath the application layer in the stack. They ensure that the core infrastructure supporting the company's systems has the proper security and controls. These audit teams generally consist of IT professionals, as opposed to business folks who understand how to use application systems. The database layer and below constitute the domain of these IT auditors, and application audits are driven by the financial auditors with support provided by the IT auditors as needed. For example, the IT auditors might look at the database layer and below as they apply to that specific application (assuming that those items haven't been covered previously in larger-scale audits of the IT environment). In addition, the IT auditors might help to review some of the general application controls, such as change controls and overall system access administration. However, the financial auditors should have the knowledge and be in a better position to understand what sorts of data integrity controls and segregation of duties are necessary for that particular business application.

Note

The third model (IT auditors) seems to be the most thorough and effective because it ensures that all layers are being covered and that they are being covered by the people with the highest level of subject matter knowledge.

Some companies have developed a mix of the three models, and that also can be very successful. The key is that companies need some IT auditing that goes beyond the application layer in order to truly perform the function successfully.


Forming and Maintaining an Effective IT Audit Team

In this chapter we have discussed the real purpose of auditing, ways to add value outside of formal audits, how to build relationships, and what the IT audit function should do. However, none of these things is possible without an effective team in place to execute them. In this section we'll discuss how to build and maintain an effective IT audit team.

In the preceding section we discussed different models of the function of the IT audit team. The model you choose will greatly influence how you build your team. As mentioned in that section, some companies really look for their IT audit team to focus their efforts at the application layer. In such cases, people with knowledge of the company's principal applications and the business functions that those applications support are critical. Likewise, if the intent is for the IT audit team to spend its time pulling data for the financial auditors, it will be critical to hire IT auditors with detailed knowledge of data extraction and analysis tools.

However, let's assume that the intent is for the IT audit team to perform comprehensive IT auditing, performing work at all layers of the stack but relying on the financial auditors to be involved in reviewing the finer points of the business application controls. How should this team be staffed? Let's look at the two basic profiles of IT auditors and the pros and cons of each. After this discussion, we'll also look at the option of cosourcing the IT audit function.

Career IT Auditors

These are the people whose entire background basically consists of performing IT audit work at various companies. They generally will have Certified Information Systems Auditor (CISA) and/or Certified Information Systems Security Professional (CISSP) certifications and lots of experience at performing general controls reviews and Sarbanes-Oxley compliance reviews.

Note

It is essential to have some career IT auditors on your team because they are well versed in audit theory and in internal controls at a conceptual level. They understand how the audit process works and the important concepts of testing and substantiation.

However, you don't want to have an entire team made up of career IT auditors. They tend to understand IT in theory, but they usually never have been responsible for day-to-day operations of an IT environment. Their depth of technical understanding is therefore often fairly light, limiting your team's ability to perform in-depth technical reviews. These auditors often stay at the surface general controls review level when performing reviews. Their lack of operations experience can lead to credibility problems with your audit customers because they sometimes can be fooled and often don't have the ability to keep up with their customers when having indepth conversations about issues. When the customers state that implementing a control is technically impossible, these auditors often won't have the knowledge to either refute or validate the claim and won't know of potential alternate mitigating technical controls to suggest. This also sometimes leads to customer complaints because they have to spend too much time training the auditor on the basics of the environment.

These are obviously generalities, and there are plenty of career IT auditors who have extreme technical depth of knowledge. But even then, these auditors are prone to live in a fantasy world where they feel that every control must be fully mitigated, without consideration for the operational impact and the need to perform cost/benefit analyses. Again, it is critical to have some career IT auditors on your team because they form your foundation. However, creating an entire team of these types of auditors likely will lead to your team having a reputation of not really understanding how things work.

Sources for Career IT Auditors

Except in rare cases, these auditors will be coming from outside your company (it's highly unlikely that you'll find someone with audit experience already working in your IT organization). There are three basic sources for these auditors.

People with internal IT audit experience at other companies These people are the most likely to come in and quickly contribute. It will be important to ensure that their IT audit shops had the same focus as yours (e.g., if you plan to be a comprehensive IT audit shop, you might not want to bring in someone from an IT audit shop that only reviewed things at the application layer). They are the most likely to have performed in-depth technical reviews and understand the importance of positive relationships with audit customers.

People with external IT audit experience These people can provide a valuable asset to the team, bringing a deep understanding of audit theory. Unfortunately, most of the "Big 4" external auditing companies do not perform in-depth technical reviews. During their IT audits, they tend to skim the surface and focus on generic general controls. It is often difficult to find someone from an external audit firm that really understands the technology he or she is reviewing. These folks are the most likely to hurt your credibility with your audit customers and give you a reputation of not really understanding how things work. They are also the most likely to live in a fantasy land, where they push for all controls to be 100 percent mitigated instead of bringing some perspective to the table that not all issues are created equal.

College hires There are some universities with good IT audit programs. It is possible to hire people from these programs that have a good theoretical understanding of auditing and also have played around with lots of different technologies. The key is to find the truly technical folks, the ones who enjoy learning new things and have an aptitude for it. Obviously, college hires will require more guidance, and you wouldn't want to build a whole team around them, but they can provide a lot of energy to your team and also can bring knowledge of the latest technologies.


IT Professionals

These are people who are subject matter experts on technology but have no experience with auditing. These auditors can bring incredible maturity of understanding to your team in their specific field of expertise, allowing you to enhance your audit approach and audit tools for reviewing those technologies. However, it is tough to find the right personality fit. There are some common pitfalls of which to be aware.

Note

These auditors can do wonders for your ability to perform in-depth value-added audits and to really speak the language of your customers. They bring credibility to your organization because they've done what your customers have done.

Many IT professionals get their job satisfaction from touching and supporting the technology day to day. When they join an IT audit team, it is a shock to their system, and they find that they've lost the part of their job that they enjoy the most. Although they are working with technology, they are not responsible for operations and are instead looking at other people's environments. When recruiting IT professionals, it is important to be up front with them about this aspect of the job so that they are coming in with their eyes open.

It is also important to find someone who has shown that he or she can learn new things quickly. Maybe in the old job, all he or she did was support Unix. In the auditing job, however, such a person will audit Unix sometimes and also every other significant technology that exists at the company. You want people who are quick learners and also enjoy learning new things.

Another downfall of these sorts of auditors is that sometimes IT professionals never really "get it." They never really develop the ability to perform complex risk assessment, especially when it comes to examining processes (as opposed to looking at technical settings within a technology). They need to be able to examine a beginning-to-end process and determine where the holes are, and this is a skill that often does not come easily to people who have been supporting a specific technology day to day. During the interview process, it will be important to gauge the potential auditor's ability to "think like an auditor" by posing some scenarios and examining how his or her mind works.

It is also important to find technical professionals with the appropriate communication skills, both oral and written. They must have the ability to explain technical concepts and issues at all levels. They must be able to explain their concerns in a way that convinces the most technical person and also in a way that will allow senior management to understand the concern to the extent that they can understand the need for action. During the interview process, get these prospective auditors to explain a technical concept to you in order to see if the basic communication skills are there.

You also will find that a common weakness of this type of auditor is documentation skills. They're not used to the process of documenting their work in the orderly fashion required for audit workpapers. You'll have to spend time coaching them on how to get what's in their head into the workpapers.

Sources for IT Professionals as Auditors

These auditors also generally come from three sources.

Technical professionals from within your company This profile is the ideal. Not only do such auditors provide you with detailed knowledge of the technology they've been supporting, but they also understand how the company's specific processes work. In addition, they're likely to have many relationships throughout the company and bring instant credibility to the IT audit team. This name recognition can be invaluable. Of course, you'll need to be careful not to assign them to directly audit the area they just came from, at least for a while. Another benefit is that it increases the integration, from a career development standpoint, of the IT audit team with the rest of IT. It is encouraging for the IT audit team to see movement back and forth between IT audit and the rest of IT. Although it is possible that an IT professional could rotate to IT audit and decide to make a career of it, it is more likely that he or she will rotate back to IT after a while. This helps your company's goal of retaining top talent because the IT audit team becomes more likely to look within the company when it is ready to move. As you move people in and out of the IT audit department, it becomes more and more natural, and the IT audit team becomes an area that people in IT consider while planning their careers.

Technical professionals from outside your company These people can bring excellent depth of technical understanding with them, along with some knowledge of how other companies have implemented internal controls. However, you will have to teach them how your company's IT environment works, along with teaching them how to audit.

College hires It will be rare to find someone who obtained a nonaudit technical degree but wants his or her first job to be in auditing. However, it can happen, and there can be some benefits to bringing in the right people who fit this profile. Look for someone who will bring fresh energy to the team, along with "book knowledge" of the latest technologies.


Career IT Auditors versus IT Professionals-Final Thoughts

Of course, it is very possible for people to move back and forth between these two categories. You may bring someone in from IT, and he or she may decide to become a career auditor. Or you may have a career auditor who, after joining your company, decides that he or she wants to move into IT. You should be supportive of people making these transitions. The most successful IT audit shops have a mixture of these types of auditors and provide flexibility to people in managing their careers. There are some companies that have a forced rotation, where the audit department is basically a training ground for the rest of the company. In these companies, people are forced to leave the audit department after a set amount of time (usually two or three years). While this is a good way to train people on the company's processes and technologies, it is not the way to build an effective IT audit team. If the team is experiencing constant turnover, it harms the ability of the department to form a mature foundation to provide for continuous improvement in how the team's mission is accomplished. The team instead is always focused on bringing the new folks up to speed. A great alternative is to have a mix of career and rotational auditors so that you maintain a firm foundation of long-term auditors and also are providing movement back and forth with IT.

Key Traits of a Successful IT Auditor

As you begin your search to build out your audit team, here are some of the key traits of a successful IT auditor:

  • Ability to dig into technical details without getting lost in those details.

  • Analytical skills. It is critical for the auditor not only to understand technologies but also to be able to use that knowledge to uncover risk to the business and apply judgment regarding degrees of risk. This often is not a black-and-white job-you need people who can really think through a process or technology and frame up the risk to the company.

  • Communication skills (both written and oral). This is a huge emphasis for this job. An auditor must be able to help all levels (from the most detailed technical person to the highest level of management) understand exactly why he or she has a concern with something. This means that he or she must be able to lay it out logically in layperson's terms for management but also explain all the technical details of his or her concern to the people who work in the area day to day.

  • The ability to quickly learn the key concepts of new technologies and identify key risk points within those technologies.

  • Willingness not to be touching a specific technology daily. It's important for people to understand that while there is a lot of hands-on work when performing audit analyses, they won't be acting as the administrator of a production Unix box, managing routers, etc.

Selling Points for Recruiting IT Professionals into IT Audit

As you attempt to recruit people out of your company's IT organization, keep in mind the following benefits of the job as selling points:

  • Exposure to a wide variety of technologies. The audit department will perform hands-on audit work of just about any technology used at the company.

  • Opportunity to work with many levels of management. Auditors get a chance to work with and present to all levels of IT management in all IT organizations.

  • Broad view of the company and other IT groups. There are very few jobs that provide an opportunity to work with so many different IT groups. The IT audit job provides an unparalleled opportunity to network and build your career via the development of relationships across the company's IT landscape.

  • Opportunity to lead projects. Most IT audit groups rotate project leader assignments (after a period of training, of course), giving everyone a chance to direct resources, set project milestones, work closely with management of areas being audited, etc.

Cosourcing

Some companies cosource the audit function, bringing in auditors from external companies as supplemental labor. This is a fine thing to do if you have a need for extra resources to meet your audit plan, but it is best to not rely heavily on this approach. The rapport your internally sourced auditor has with the customer creates trust. The ability to build relationships and credibility in the IT organization depends on your internal employees performing the IT audit function and on those employees staying around long enough to build a reputation. Having different contractors and consultants constantly moving in and out is not conducive to the relationship-building goal. However, it does have its place and can be useful in a pinch. It also can be useful when you are auditing technologies that your team doesn't know well and that you don't plan to audit very often. For example, if you have a mainframe operating system and only plan to audit it once every few years, it may not make sense to spend time getting the IT audit team trained on the technology. It may be more effective to just bring someone in who has that expertise to help you out. On the other hand, if you're auditing a technology that's core to the company and that you'll be looking at over and over again, it's worth the investment to get your own team up to speed rather than bringing in someone from outside (or you might look into bringing in someone from the outside once with the understanding that part of his or her assignment will be to provide training and develop repeatable audit steps). If you do bring in cosourcing partners, it is critical that you emphasize to them your customer-oriented approach to performing audits so that they don't mess up the hard work you've put into building positive relationships.


Maintaining Expertise

If you want to have an effective IT audit team, you must invest time and money into keeping their skill sets up to date. Training is essential for IT auditors because technologies and techniques change constantly. Your auditors won't be supporting the technologies day to day (which necessitates keeping up with changes), so if you're not intentional about maintaining your expertise, your team's knowledge will quickly become outdated. It's never fun when you take your department's expert with you to a meeting and you find out that he or she has become a "dinosaur" because he or she doesn't know the latest developments.

Sources of Learning

Fortunately for the auditor, a wealth of training exists to keep skills sharp and up to date. The time away from formal audits and the cost involved in the training pay dividends in building a knowledgeable and effective team of auditors. Consider the following as sources for keeping the team's expertise up to date.

Formal Training

Each auditor generally should be given the opportunity to attend one of two outside training classes or conferences each year. If chosen wisely, they're a great way for the auditor to have a week of concentrated focus on learning something new. Common vendors in this space include SysAdmin, Audit, Network, Security (SANS), the MIS Training Institute, and the Information Systems Audit and Control Association (ISACA). It is important to pick the training classes wisely. Look for technical training classes that provide hands-on activities because they are much more likely to be teaching real technical skills. Too many technical training classes are focused at a high level and consist solely of looking at slides. It's very difficult to learn a technical skill without touching the technology. Shy away from classes that are purely theoretical in nature or focus solely on soft skills unless they meet one of your specific objectives. Look instead for classes that deal with how to audit and secure specific technologies and that provide hands-on illustrations of how to do so. Also look for training classes related to technologies that you actually will be auditing in the near future. Training that is not used quickly is lost quickly. Even though training classes are an important component of maintaining expertise, it is not realistic to think that it will be the only source of knowledge. It is simply cost prohibitive to send someone to a class every time you need to learn something. Therefore, the options below are as important as (if not more so than) formal training classes and conferences.

Research Time

Consider providing dedicated time for your IT auditors to perform research and learning activities. Give them a week here and there where the only objective is for them to perform self-study activities. Make sure that they have the leeway they need to purchase books to aid in this effort. This time also can be used to create or enhance standard audit programs/tools for auditing common technologies at the company.

Specialization

Closely related to research time, you might consider having one or two auditors specialize in each of the core technologies that the IT audit team will be auditing. These people become your resident experts, and they are responsible for keeping up with the technologies and maintaining the department's tools related to auditing those technologies (using dedicated research time, as mentioned earlier). They also would be responsible for providing assistance to other IT auditors who are performing audits dealing with those technologies. These specialists would be the primary points of contact for others within the company who might have questions regarding controls in those areas. They are also your top candidates for establishing liaison relationships (as discussed earlier in this chapter) with management of teams supporting those technologies.

Knowledge Sharing after Training

We talked about training earlier. Training is a high-dollar method of maintaining expertise, and you need to make sure that you fully leverage that investment. Too often people come back from training, stick their training books on the shelf, and never think about the class again. People should be held accountable for making full use of the knowledge they receive at a training class. Consider implementing a requirement that each person must do some sort of knowledge sharing on return from a class. The method of delivery should be flexible in order to allow the auditor to apply judgment. Potential delivery methods include holding a short training session for the rest of the department, creating or enhancing a standard audit approach for the topic, creating or enhancing tools to automate and/or analyze the technology, and creating a knowledge-sharing document that highlights key learning from the training. The key is that there should be an expectation and accountability that the auditor will bring something back to the department once training is complete.

Certifications

There are a number of certifications that are relevant to the IT audit profession, the most prevalent of these being the CISA. Another one that is becoming more popular among auditors is the CISSP. Certifications are a good way to ensure that auditors have a basic level of understanding, as well as to enhance the pedigree of the department (lots of audit directors like to brag to the audit committee about how many certifications the audit department has). There's wisdom in encouraging auditors to receive these certifications because undoubtedly they will enhance their knowledge in the process of examination preparation.

As you can see, there are a number of options for ensuring that the IT audit team has the appropriate level of knowledge or expertise. In an ideal world, it is best to implement a combination of all these things. However, the important thing is to be deliberate about establishing the methods that will be used. If you take your eye off the ball on these, you'll find that the world quickly passes you by and you lose the expertise and credibility necessary to accomplish your mission of promoting internal controls at the company effectively.

In addition to maintaining technical skills, it is critical for auditors to develop and maintain key soft skills such as communication, presentation, and writing skills. While dedicated training classes often can be useful in strengthening these skills, they are not always necessary. However, it is important for audit management and team leaders to constantly emphasize the importance of these skills and coach the audit team in identifying opportunities to strengthen them.


Relationship with External Auditors

Finally, as we wrap up this chapter about building an effective internal IT audit function, we'll briefly discuss external auditors and their impact on the internal audit team. Your company's external auditors also will have a need to review IT controls, especially as they relate to Sarbanes-Oxley compliance. They will need to review the internal audit team's work and also perform their own independent testing in certain areas. It is easy to see this as an intrusion and an annoyance. No one likes having their work reviewed and questioned, but really, the external auditors are just giving the internal auditors a taste of their own medicine. If we can't take it, we shouldn't dish it out. Accept the fact that the external auditors are there for a legitimate reason. A healthy working relationship between the internal and external auditors, where information is shared freely, is how to make the best of the situation. It also important for each group to keep the other informed of their activities. This will allow you to notify your audit customers about situations in which it may appear that they are being asked duplicate questions. Do your best to smooth over those situations such that the customers at least understand the reasons for them. Also, you should encourage the external auditors to review the internal auditors' work prior to speaking with your customers. This at least will give them a baseline of knowledge and minimize the amount of time the customer has to spend explaining the basics of the environment. Again, the external auditors are there for a reason, so do your best to work together and minimize the impact for your customers.


Summary

In this chapter we learned that

  • The real mission of the internal audit department is to help improve the state of internal controls at the company.

  • Internal auditors are not truly independent, but they should be objective.

  • It is important to find ways to accomplish the department's mission outside formal audits. Early involvement, informal audits, knowledge sharing, and self-assessments are four important tools in this regard.

  • Building and maintaining good relationships with the IT organization are critical elements of the IT audit team's success.

  • The most effective IT audit teams ensure that every layer of the stack is covered, not just the application layer.

  • Successful IT audit teams generally will consist of a combination of career auditors and IT professionals.

  • It is critical to develop methods for maintaining the technical expertise of the IT audit team.

  • A healthy relationship should be developed with external IT auditors.

Note

If you'ue interested in more information on the overall management of the audit function, an excellent resource is 'Managing the Audit Function: A Corporate Audit Department Procedures Guide' by Michael P. Cangemi and Tommie Singleton.


Chapter 2: The Audit Process

This chapter is not intended to be an Auditing 101 course because entire volumes have been written on that topic. Nor is it intended to be a recitation of auditing standards and guidelines, which also are subjects of other books. However, this chapter will provide some guidance on how to best execute the audit process so as to ensure that your information technology (IT) audit team is as effective as possible.

After this chapter, we will have concluded our overview discussions and will be ready to move on to Part II, where we will discuss the specifics on how to audit various technologies and processes.

Internal Controls

Before beginning our discussion of the audit process, it is important to ensure that we all have an understanding of one of the most basic concepts by auditing. All through Chapter 1 we discussed the fact that the real mission of the internal audit department is to help improve the state of internal controls at the company. But what are internal controls? If you don't know the answer to this question, then it will obviously be difficult to accomplish the department's mission. We won't spend much time on this, for fear of turning this book into the aforementioned Auditing 101 course, but the topic does warrant a few paragraphs.

Note

Internal controls, stated in the simplest terms, are those mechanisms that ensure the proper functioning of processes within the company.

Every system and process within a company exists for some specific business purpose. The auditor must look for the existence of risks to those purposes and then ensure that internal controls are in place to mitigate those risks.

Types of Internal Controls

Controls can be preventive, detective, or reactive and have administrative, technical, and physical implementations. Examples of administrative implementations are items such as policies and processes. Technical implementations are the tools and software that logically enforce control (such as passwords). Physical implementations include controls such as guards and locked doors (Figure 2-1).

Image from book
Figure 2-1: Types of internal controls and their implementation.

Preventive Controls

Preventive controls stop a bad thing from happening. For example, requiring a user ID and password for access to a system is a preventive control. It prevents (theoretically) unauthorized people from accessing the system. From a theoretical standpoint, preventive controls are always preferred, for obvious reasons. However, when performing audits, it is important to understand that preventive controls are not always the cost-effective solution. There are times when another type of control will make the most sense from a cost/benefit standpoint.

Detective Controls

Detective controls record a bad thing after it has happened. For example, logging all activities performed on a system will provide the ability to go back and look for inappropriate activities after the fact.

Reactive Controls (Also Known as Corrective Controls)

Reactive controls fall between preventive and detective controls. They do not prevent a bad thing from happening, but they provide a systematic way for detecting when those bad things have happened and correcting the situation. This is why these are sometimes called corrective controls. For example, you might have a central antivirus system that detects whether each user's PC has the latest signature files. Ideally, it would be nice to disallow network access to anyone who is not in compliance. However, this might not be practical from a business standpoint. Therefore, an alternative might be to log those in noncompliance and perform some regimented follow-up activities to either get the PC in compliance or remove its ability to access the network.

Internal Control Examples

Let's say that you're looking at your company's accounts receivable system. That system exists for the purpose of ensuring that you're tracking who owes you money so that you can nag the deadbeats who don't pay you and so that you properly record payments from those who do. The financial auditors will worry about risks within the accounts receivable process itself, but the IT auditors need to think about the risks to the system accomplishing its business purpose. Some examples are cited below.

Software Change Controls

If changes to the system code itself are not approved and tested properly, then we might find that the logic being executed by the code is erroneous. This might mean that we lose our confidence in the integrity of the data within the system, resulting in an inability to know for sure who has paid us and who hasn't. So what are some internal controls that would mitigate this risk?

  • One internal control might be that the programmers don't have logical access to update the production code.

  • Another internal control might be that the people who do have logical access to update the production code will not do so without evidence of testing and approval.

Access Controls

If access to the system is given to people who do not have a need for that access, then system data might be changed, added, or deleted inappropriately. What are some internal controls that would mitigate this risk?

  • Requiring a user ID and password to access the system is an internal control.

  • Having a limited number of application security administrators who control the ability to add new user accounts to the system is another internal control. Ensuring that those application security administrators are knowledgeable individuals who know which users really need access to the system is yet another internal control.

Backups and Disaster-Recovery Plans

If the system or its data were lost, then system functionality would be unavailable, resulting in a loss of your ability to track outstanding receivables or post new payments. What are some internal controls that would mitigate this risk?

  • Backing up the system and its data periodically is an internal control.

  • Shipping those backup tapes offsite is another internal control.

  • Documenting a disaster recovery plan is a third internal control.

These are just a few rudimentary examples and are intended to illustrate the concept. The auditor must understand the business purpose of what he or she is auditing, think through the risks to that purpose being accomplished, and then identify any existing internal controls that mitigate those risks. The chapters in Part II of this book provide detailed guidance on internal controls to look for within various topic areas.

Hopefully, this discussion has put us all on a level playing field regarding what we mean by internal controls, a term used frequently in this book. The concept of internal controls is absolutely fundamental to the auditing profession.


Determining What to Audit

One of the most important tasks the internal audit department will perform is determining what to audit. In Chapter 1 we discussed such things as early involvement, informal audits, and self-assessments. This is not the sort of thing we're talking about now. Now we're referring to traditional, formal audits-the kinds that have teams of auditors working on them, producing workpapers, audit reports, lists of issues, and action plans for resolving those issues.

It is important that your audit plan focuses your auditors on the areas that have the most risk and on areas where you can add the most value. You have limited resources, and you have to be efficient and effective in how you use them. You have to spend your IT audit hours looking at the areas of most importance. This should not be done by arbitrarily pulling potential audits out of the air but instead should be a logical and methodical process that ensures that all potential audits have been considered.

Creating the Audit Universe

One of the first steps to ensure an effective planning process is to create your IT audit universe. You must be aware of what audits you potentially might perform before you can rank them. There are multiple ways to slice the IT universe, and none of these is right or wrong. What is important is to figure out a way to slice the environment that will allow for the most effective audits.

The Audit Universe-Centralized IT Functions

It is advisable to determine what IT functions are centralized and place each of those centralized functions on your list of potential IT audits (Table 2-1). For example, if you have a central function that manages your Unix and Linux server environment, then one of your potential audits might be a review of the management of that environment. This could include administrative processes such as account management, change management, problem management, patch management, security monitoring, and other such processes that would apply to the whole environment.

Table 2-1: Potential Opportunities for Auditing Centralized Activities
Unix and Linux server administration | Central help desk
Windows server administration | Database management
Wireless network security | Telephony and voice over IP
Internal router and switch management | Mobile services
Firewall/DMZ management | IT security policy
 | Mainframe operations

One example might include a review of the security of the baseline the centralized Unix and Linux function uses for deploying new servers. This audit could cover all those processes that apply to the whole Unix and Linux server environment. Then, if the financial auditors' audit plan calls for an audit of a particular financial application that resides on a Unix server, your participation in that audit could consist solely of auditing the security of that specific server without having to spend time understanding the processes for managing that server (which were covered already in your centralized audit).

Of course, each company will centralize these sorts of core IT functions to differing degrees. It is important to understand the environment well enough to determine what functions are centralized and add those functions into your audit universe. Audits of those sorts of functions form a baseline that will speed up the rest of your audits. As you perform other audits, you can scope out those centralized functions that have already been audited. For example, let's say that you perform audits of the IT environment at each site, but the network configuration and support are centralized. It would be very inefficient to talk to the remote group about their processes during each and every site audit. Instead, you should perform one audit covering their processes and then scope that area out of your site audits.

The Audit Universe-Decentralized IT Functions

After creating a list of all the company's centralized IT processes, you can determine the rest of your audit universe. One potential way to slice the rest of the universe is to have one potential audit per company site. These audits could consist of reviewing the decentralized IT controls that are owned by each site, such as data center physical security and environmental controls. Server and PC support also may be decentralized at your company. The key would be to understand what IT controls are owned at the site level and review those. It may be necessary to get more granular than this and have numerous potential audits at each site. It all depends on the complexity of the environment, the breakup of the organization, and your staffing levels. You will have to determine what is most effective in your environment.

Note

Getting your hands wrapped around what potential audits are in your universe is critical to being effective. Perhaps the best way to scope the breadth of possible audits is to meet with the company's IT managers to understand how IT responsibilities are divided and determine what IT functions are centralized and decentralized in your company.

The Audit Universe- Business Applications

You also might have a potential audit for each business application. You will have to determine if it is more effective to have these audits in the IT audit universe or in the financial audit universe. In many ways, it makes the most sense to have these audits be driven by the financial auditors. For example, they are probably in the best position to determine that it is time to perform an audit of the procurement process. If they do make that decision, then they can approach you and have you determine the relevant system aspects that should be included in the procurement audit (such as a reviews of the server on which the procurement application resides, the system's software change controls, the systems disaster recovery plan, etc.).

The Audit Universe- Regulatory Compliance

Depending on the services or goods your business provides, you might be responsible for ensuring compliance with certain regulations. Common examples include auditing compliance with Sarbanes-Oxley, Health Insurance Portability and Accountability Act (HIPPA), and Payment Card Industry (PCI) regulations and standards. You might have a separate audit in your audit universe for testing compliance with each relevant regulation.

Note

A good source for ensuring that you have considered all significant areas of IT governance is to reference the control objectives for information and related technology (CoBIT) framework. This framework defines the high-level control objectives for IT, and although your planning always should be tailored to the specifics of your company's environment, CoBIT can be a good reference in creating your audit universe. We will discuss CoBIT in more detail in Chapter 13. You also can learn more about CoBIT online at http://www.isaca.org.

Ranking the Audit Universe

Once you've created your IT audit universe, you must develop a methodology for ranking those potential audits (Figure 2-2) in order to determine your plan for the year (or quarter or month or whatever your schedule is). There are all kinds of factors you can include in this methodology, but following are some of the essential ones:

Image from book
Figure 2-2: Example audit ranking table.

  • Known issues in the area. If you know there are problems in the area, it should be more likely that you perform an audit there.

  • Inherent risk in the area. Maybe you don't know of any specific problems in the area, but your experience tells you that the area is one that is prone to problems. If so, it should be more likely that you perform an audit there. For example, maybe you consistently find significant issues when auditing site-level IT controls supporting a particular manufacturing activity. This experience would lead you to feel that there's higher inherent risk in that area, steering you to perform similar audits at other sites, even if you're not aware of any specific problems at those sites.

  • Benefit of performing an audit in the area. This is a critical factor that is not always taken into account. You should consider the likelihood that performing an audit in the area will add value to the company. This provides an offset of sorts to the first item in this list. For example, there might be an area where you know there are issues. However, maybe management is already aware of and is addressing those issues. If this is the case, it adds no value for you to go in there and tell management about all the problems they're already in the process of fixing. Instead of auditing it, consider being part of the team that is developing solutions to fix the problem (as discussed in Chapter 1). You also have to consider the importance of an area to the company. For example, maybe you know that there are problems with the system used to order meals for internal meetings. Your ranking model needs to take into account the fact that this system just isn't very important to the overall success of the company.

  • Management input. In Chapter 1 we discussed the importance of developing and maintaining good relationships with IT management. When those relationships are healthy, the input of IT management should be a large factor in your decisions as to what to audit. If your chief information officer (CIO) and/or key members of his or her leadership team have a concern in an area and want you to audit it, then that input should weigh heavily in your decision process. In fact, if those relationships are healthy and you're doing a good job of maintaining contact throughout the year, then your audit plan almost should create itself. You'll already be aware of major changes in the environment and of significant concerns, meaning that your planning process can just be a confirmation of the discussions you've been having throughout the year. Note that this factor might influence the others. For example, if management is encouraging you to perform an audit, it is likely because managers know of problems in the area, which might lead you to increase your rating of the first factor (known issues in the area). It also might lead you to believe that you can add value by performing the audit, leading you to potentially increase your rating of the third factor (benefit of performing an audit in the area).

Other factors can be included in an audit ranking model, but these are the four that are absolutely essential. Other factors can be added based on the environment at your company. Also, the environment at your company may lead you to weight some of those factors more heavily than others. As an example of how the ranking model would work, you might decide to rank each factor from 1 to 10. If the CIO and the entire leadership team are encouraging you to do an audit, then the management input factor might get a 10. However, if it's an area where you do not feel there is much inherent risk, you might give that factor a 5. And so on until you have assigned a point value to each factor for each potential audit in your audit universe. You also might decide that, for example, the "known issues" factor needs a higher weighting than the others, so you might count that factor double. The key is to have your universe of potential audits defined and then some process that helps you rank the relative importance of performing each of those potential audits.

Note

See Chapter 15 for information covering detailed risk analysis techniques.

There are some companies that place a large emphasis on rotating audits, where each audit is on a specific schedule. This can be a valid way to ensure that all critical systems and sites are audited regularly; however, rotation schedules always should be a guideline and not a firm rule. You always should consider what is the most important area for you to audit today based on factors such as those just mentioned. A rotation schedule should not serve as an excuse for you to turn your brain off and ignore known problems and the input of IT management. It is critical to reserve the right to ignore the rotation schedule in order to ensure that you are hitting the areas where you can add the most value to the company. If rotations are a big part of how your audits are scheduled, you might consider adding rotation schedule as a factor in your audit ranking model. In this way, if an audit is due in the rotation (or past due), it is more likely to make the plan.

Of course, there may be some audits that you are required to perform on an annual basis per regulatory requirements (such as Sarbanes-Oxley compliance). Such audits obviously do not need to be ranked.

Determining What to Audit-Final Thoughts

Once you have performed your ranking, you will need to estimate the resource requirements for each potential audit. This will allow you to determine the cut line for your audit plan (since you should already know what resources are available to you). It also will allow you to show management which audits you will not have time to get to, which can lead to healthy discussions about the appropriateness of audit staffing levels and/or the need to consider cosourcing options.

In summary, before you can feel comfortable that you're auditing the right things, you must determine your universe of potential audits and then develop a methodology for ranking those audits. Once you have determined what you will be auditing, you then obviously need to execute each audit in the plan. The rest of this chapter is devoted to discussing the methodologies for doing so.


The Stages of an Audit

Now that we understand the process of selecting what to audit, let's discuss the various stages for performing each of the audits in the audit plan. We will divide our audits into six major phases (Figure 2-3):

Image from book
Figure 2-3: Audit process overview.

  • Planning

  • Fieldwork and documentation

  • Issue discovery and validation

  • Solution development

  • Report drafting and issuance

  • Issue tracking

Over the next few pages we will discuss how to perform each of these stages most effectively. However, as already mentioned twice in this chapter, we do not intend for this to be an Auditing 101 course, so we will not exhaust these topics. Instead, we will focus on key points that will then allow us to move on to the meat of our book.

Planning

Before beginning work on any audit, it is obviously important to determine what you plan to review (Figure 2-4). If this planning process is executed effectively, it will set the audit team up for success. Conversely, if it is performed poorly, then the audit team will be set up for failure, beginning work without a plan and without clear direction.

Image from book
Figure 2-4: Audit process overview-planning stage.

The goal of the planning process is to determine the objectives and scope of the audit. You need to determine just what it is you're trying to accomplish with the review. As part of this process, you should develop a set of steps that need to be executed in order to accomplish the audit's objectives. This planning process will require careful research, thought, and consideration for each audit; however, following are some basic sources that should be referenced as part of each audit's planning process:

  • Hand-off from the audit manager

  • Preliminary survey

  • Customer requests

  • Standard checklists

  • Research

Hand-off from the Audit Manager If the audit is in the audit plan, there must be some reason. The audit manager should relay to the audit team the information that led to the audit being scheduled. This might include comments from IT management and/or known concerns in the area. The factors that led to the audit being scheduled need to be encompassed in the audit plan. In addition, the audit manager should be able to provide the audit team with the key contacts for the audit.

Preliminary Survey The audit team should spend some time before each audit performing a preliminary survey of the area to be audited in order to understand just what it is they're getting into. This likely will include interviews with the audit customers to understand the function of the system or processes being reviewed, as well as review of any pertinent documentation. The goal is to obtain a basic background and understanding of the area to be reviewed. This will be needed to perform the preliminary assessment of risks in the area.

Customer Requests In Chapter 1 we discussed the importance of making the audit a collaborative, cooperative process. As part of accomplishing this goal, the audit customers should feel that they have some ownership in the audit. The audit team should not just come in and say, "This is what we're reviewing," and leave it at that. Instead, the team should ask the customers what areas they think should be reviewed and what areas they have concerns with. This input then should be meshed with the results of the auditors' objective risk assessment to determine the scope of the audit. Of course, there will be times when the auditors don't use the customers' input. For example, sometimes the audit customers will be concerned about areas that are more operational in nature and have no internal control impact. In those cases, it is perfectly legitimate for the audit team to scope those areas out, with an explanation to the customer as to why the audit team is not positioned to execute that request. It is also important not to allow the customer to steer the auditors away from reviewing important areas. The auditors still ultimately have to apply their judgment. However, obtaining the customers' input and incorporating it into the audit plan where possible will give the customers a feeling of ownership in the audit project and increase the chances of there being open and honest communication.

Standard Checklists Often there are already standard audit checklists for the area being reviewed. The checklists in Part II of this book can be an excellent starting point for many audits. In addition, the audit department might have its own checklists for systems and processes that are standard at the company. Having standard, repeat-able audit checklists for common areas can provide a very useful head start for many audits. However, those checklists still should be evaluated and altered as necessary for each specific audit. Having a standard checklist does not remove the requirement for the auditor to perform risk assessment prior to each audit.

Research Finally, the Internet, books, and training materials should be referenced and used as appropriate for each audit in order to obtain additional information about the area being audited.

Once these resources have been referenced, the auditor must perform an assessment of the risks in the area being reviewed in order to identify the steps that must be accomplished during the audit. This concept is illustrated in the "Internal Controls" section earlier in this chapter. As mentioned there, the auditor must understand the business purpose of what he or she is auditing, think through the risks to that purpose being accomplished, and then identify any existing internal controls that mitigate those risks. If it's a process being reviewed, then the auditor needs to lay out that process end to end and think about where it could break down. If it's a system or technology being reviewed, then the auditor needs to think through the risks to that system or technology functioning as intended.

The result of the preceding exercise, as mentioned, should be a determination of the scope of the audit, including specifically determining and communicating what is out of scope and compiling a list of steps to be performed in order to accomplish that scope.

Toward the end of the planning process, it is important to hold some sort of kick-off meeting with the audit customers so that you can communicate what is in and out of scope for the audit project and also receive their final input. During this meeting, you should continue to be open to the customers' input and flexible regarding making changes to the audit scope. Again, if the customers feel ownership in the audit, they are much more likely to be open when working with the auditors. The kick-off meeting is also a great time to solicit primary points of contact for each audit step and to determine a schedule and methodology (e.g., meetings, e-mails) for keeping the customers informed as to the audit's status.

Once the kick-off meeting is completed, the audit's steps should be split up among the audit team members, and the next stage of the audit can begin.

Fieldwork and Documentation

The bulk of the audit occurs during this phase. This is the point in the process where the audit steps created during the preceding stage are executed by the audit team. During this stage, the team is acquiring data and performing interviews that will help team members to analyze the potential risks and determine which risks have not been mitigated appropriately (Figure 2-5).

Image from book
Figure 2-5: Audit process overview-fieldwork and documentation stage.

Part II of this book provides detailed guidance for performing fieldwork for standard topics and technologies. In addition, Chapter 15 provides detailed guidance on performing risk analysis. Therefore, we will not spend much time on this topic here. However, it is important to understand the value of healthy skepticism. Wherever possible, the auditors should look for ways to independently validate the information given to them and the effectiveness of the control environment. There are times when this is not possible, and the audit team will need to take the information given to it at face value. However, the auditor always should be putting thought into how he or she can test things. For example, if the audit customer describes a process for approving new user account requests, the auditor should attempt to pull a sample of recently added users to see if they did indeed receive the proper approval. This will provide much more compelling evidence that a process is being followed than an interview.

It is also worth taking a moment to point out the importance of workpaper documentation. During fieldwork, it is critical for the auditors to do an adequate job of documenting their work so that the conclusions can be substantiated. The goal should be to document the work in sufficient detail that a reasonably informed person can understand what was done and arrive at the same conclusions as the auditor. The auditor basically should be telling a story, saying, "Here's what I did, here's what I found, here's my conclusion, and here's why I reached that conclusion." If a process was reviewed, the process should be described, and the key control points within that process should be highlighted. If a system or technology was reviewed, the specific settings and data reviewed should be described (along with how that information was obtained) and interpreted.

The documentation process seems tedious, but it is important. First, it is needed to meet the standards of the profession. Second, it is very possible that in the future the findings of the audit may be questioned or challenged, and the auditor who performed the work may have left the company or department by that time (or have just forgotten the details of what he or she did). It will be critical to have some documentation explaining what was done and substantiating the conclusions. Third, if the audit is performed again someday, retaining detailed documentation will allow the next audit team to learn from the experience of the previous audit team, thereby allowing for continuous improvement and efficiency.

One final note on fieldwork: During the planning phase, you will develop checklists as to what you plan to review during the audit. Do not fall into the trap of allowing those checklists to cause audit team members to turn off their judgment. The team needs to remain flexible during the audit and be prepared to explore avenues that were not considered during the planning. Team members always need to keep in mind the overall objective of the audit and not just become automatons following a canned script. It is also critical that each team member understand the purpose behind the audit steps he or she has been assigned. The steps assigned to each team member should be a guideline for accomplishing that purpose, and each auditor needs to remain creative in how this is done. If the step is performed, but it didn't really address the risk being investigated, then the auditor has failed.

Note

The end purpose of the audit is not to execute the audit steps but instead to evaluate the state of internal controls in the area being reviewed.

Issue Discovery and Validation

During the course of executing fieldwork, the auditors will be developing a list of potential concerns (Figure 2-6). This is obviously one of the more important phases of the audit, and the auditor must take care to scrub the list of potential issues so that he or she can be sure that all the issues are valid and relevant. In the spirit of making the audit a collaborative experience with the audit customers, potential audit issues should be discussed as soon as possible. Nobody enjoys having the auditors wait until the audit is over and then show a laundry list of issues. Not only is it unpleasant for your customers, but it also can be unpleasant for you because you may find that not all your information is accurate and not all your issues are valid. Instead of making a federal case out of each potential issue, take the tactic of approaching the customer and saying, "Hey, I think I uncovered something of concern. Can I discuss it with you to be sure I have my facts straight and am understanding the risk properly?" This allows the customer to work with you in validating the issue and also helps the customer take ownership of the issue.

Image from book
Figure 2-6: Audit process overview-issue discovery and validation stage.

In addition to validating that you have your facts straight, it is also important to validate that the risk presented by the issue is of enough significance to be worth reporting and addressing. Don't raise issues for the sake of raising issues. Instead, raise issues that are presenting significant risk to the company. Consider mitigating controls and understand the whole picture before determining whether you have an issue worthy of being reported. Except in businesses that are highly regulated, take the same approach with compliance with internal policies. While it is obviously important for IT auditors to review systems for compliance with the company's internal IT security policies, the approach still should be risk-based. There are times when a system is technically in violation of policy, but that violation represents no real risk owing either to mitigating controls or to the nature of that particular system. In such cases, what is the value of raising an issue? Likewise, there should be many cases where the auditors raise a concern that has nothing to do with policy but instead has to do with risks to the specific environment being reviewed. Do not allow your audit team to become the policy compliance team. You should instead consider policies as well as all other relevant factors in evaluating the true risks to the environment being reviewed.

Note

If you work with your customers throughout the audit to validate issues and come to agreement on the risks those issues represent, then the conclusion of the audit will go much more smoothly and quickly. Instead of debating all the issues at the end, you can just focus on addressing the issues that you've been discussing throughout the audit and on which you've already agreed.

Solution Development

Once you have identified the potential issues in the area you're auditing and have validated the facts and risks, it is time to work with your customers to develop an action plan for addressing each issue (Figure 2-7). Obviously, just raising the issues does your company no good unless those issues are actually addressed. Three common approaches are used for developing and assigning action items for addressing audit issues:

Image from book
Figure 2-7: Audit process overview-solution development stage.

  • The recommendation approach

  • The management-response approach

  • The solution approach

The Recommendation Approach

Under this very common approach, the auditors raise issues and provide recommendations for addressing them. They then ask the customers whether they agree to the recommendations and, if so, when they'll get them done. The following is a very common scenario for this approach. Perhaps the audit team discovers that there is no process in place to ensure that users have the latest security patches on their PCs prior to connecting to the network. They present the issue to the customers, along with a recommendation that says something like, "We recommend that a process for ensuring that users have the latest security patches on their PCs be in place prior to their being allowed to connect to the network" or something equally brilliant and useful. The auditors then ask the customers when they can have it done. The customers throw out a date to get the auditors off their backs, generally without really thinking through what they're signing up for. The auditors go away happy because their recommendation was accepted, and they have a due date. Who cares that the customers have no ownership in the action plan and that they'll probably blow the due date? We'll worry about that in a few months when the point is due, right?

This example obviously is a bit exaggerated, but unfortunately, it is not all that far from the truth. The recommendation approach can work if handled very well by a knowledgeable audit team. However, it generally results in the customers feeling a lack of ownership in the action plan because they're just doing what the auditors told them to do. In addition, the customers being audited are bound to have more detailed knowledge of the area being audited than the auditors, meaning that they're in the best position to develop a solution to the problem. By sticking a recommendation in front of them and asking if they accept it, they are much less likely to think through the problem and develop a workable and realistic action plan. There is instead a tendency to "accept" the recommendation to get the auditors out of the way, only to discover the inevitable roadblocks and complexities down the line when the audit point is almost due and the auditors are following up. This leads inevitably to the audit point going overdue and/or being extended. It is not an efficient process.

If this is the approach used by your company, it is important to do it the right way and engage the customers in brainstorming how to fix the problem prior to documenting your recommendation. Then the recommendation just becomes documentation of what has already been agreed to by all involved parties. This doesn't mean that the auditors can't bring ideas to the table. They can, and they should. However, the customers ultimately need to feel ownership of the action plan.

The Management-Response Approach

With the recommendation approach, the auditors develop a recommendation and ask the customers if they'll do it. With the management-response approach, the auditors develop a list of issues and then throw them to the customers for their response and action plans. Sometimes the auditors send their recommendation for resolution along with the issue, and sometimes they just send the issue with no recommendation. Either way, the customers are supposed to send back their response, which is included in the audit report. This lends itself to very polite finger pointing and name calling. The auditor writes, in effect, 'There's a problem. We recommend that they fix it.' Management then writes back, in effect, "We think this is stupid, but we'll go ahead and implement a half-baked solution that we feel adds no value in order to get the auditors off our backs." Or even worse, management's response may be more like, "We think this is stupid and are going to do nothing about it. The auditors can go jump in a lake." In such cases, the auditors may include their counterresponse, saying something like, "Can you believe these people? They obviously don't care about controls. We're going to tell the CEO and get them in trouble."

Again, this is an exaggerated example but not far off the mark. The management-response approach does not lend itself to reaching consensus but instead allows the auditors basically to wash their hands of the responsibility of getting buy-in on the issues and their resolutions. Instead of developing a mutually agreed-on solution, they just say what they want and then allow the audit customers to say what they want, with the auditors then getting the last word in the report.

If this is the approach used by your company, try to get it changed. If you can't, try to work around the system. Prior to sending the issues and your recommendations to the customers, work out a solution with them with which you all feel comfortable. Your recommendation then can reflect what you're already agreed on, allowing the management response to be something like, "We agree and will implement it by the end of the year." Just because you have a management-response approach doesn't prevent you from going ahead and collaborating with your customers on mutually acceptable solutions.

The Solution Approach

Under this approach, the auditors work with the customers to develop a solution. This solution represents a mutually developed and agreed-on action plan for addressing the issues raised during the audit. It is a combination of the two preceding approaches, bringing in the best of each. As with the recommendation approach, the auditors are providing ideas for resolution based on their control knowledge. As with the management-response approach, the customers are providing ideas for resolutions based on their real-life operational knowledge. The result is a solution that the customers "own" and that is satisfying to the auditors. Because they have ownership of the issues, the customers are much more likely actually to follow through.

Under this approach, the audit report subtly reflects the shift in ownership. With the recommendation approach, the auditors might write something like, "We recommend that audit logs be enabled" or "Audit logs should be enabled." These statements emphasize the auditors' wishes and often are interpreted by customers as heavy handed and bossy (and often clueless). With the solution approach, the auditors instead would write, "The support team will enable audit logs." This statement is a crisp, clean statement of the customers' intentions and reflects something they have developed and agreed to with the auditors' help.

With this approach, it is important that the development of the solution be truly collaborative. Although the auditors should try to allow the customers to develop some initial ideas, they should have some potential solutions ready in their "back pockets" in case the customers are not coming up with acceptable answers. In addition, the auditors should have some sort of idea as to the minimum amount of mitigation with which they will be comfortable. They need to be prepared to let the customers know if the solutions proposed do not meet the minimum risk mitigation needs.

Guidance on Solution Development

Regardless of the approach used, it will be important to establish who is responsible for executing the action plans and the due dates by which they will be completed. This provides accountability and a basis for the auditors' follow-up. As these action plans are addressed, the auditors should be flexible regarding how finalized the action plan must be in the audit report. There are some issues that lend themselves to very straightforward solutions, such as changing a system setting or locking down file permissions. In these instances, you would expect the customers to be able to say exactly when the solution will be implemented. However, there are other issues that require very complex solutions and will involve engaging multiple organizations and developing complex processes or acquiring new technology. In these instances, it is not realistic to expect the audit customers to know exactly what they will do and when they will do at the time of report issuance. Instead, there needs to be an evaluation period in which the alternatives are examined and a detailed timeline is developed. Instead of pushing the customers to provide information when it is not realistic to expect them to do so, set an interim date. Establish a date by which they will have chosen a solution and developed a timeline. Once that date is reached, if they have indeed developed a detailed action plan, establish a new due date based on that plan.

Note

When developing solutions, the auditor should keep in mind that it is not always practical for 100 percent of the risk to be mitigated. There are many occasions where mitigating 100 percent of the risk would be cost-prohibitive, but 80 percent of the risk may be mitigated for a reasonable cost. This is the Pareto concept, where the first 80 percent of the risk can be addressed for 20 percent of the cost. If the auditor digs his or her heels in and insists on a 100 percent solution, he or she will lose credibility, damage relationships, and cause the customers to do nothing. Having 80 percent of the risk addressed is better than having 0 percent of the risk addressed. The auditor must remember that he or she is an employee of the company and should be pushing for solutions that are reasonable and cost-beneficial. Of course, the auditor must be objective and ensure that the unmitigated risk is not unreasonable. However, auditors who always insist on 100 percent solutions become auditors who are avoided and who are viewed as having no business sense.

As discussed previously, the auditors should work diligently to reach agreement with the customers on the issues and solutions from the audit. If this is done well, there should be very few instances where agreement cannot be reached. However, inevitably there will be times where you just don't see eye to eye and cannot reach consensus. These cases should be few and far between, but they do happen. In addition, there are times when the customers agree with you but do not feel that they have the resources to address the issue. So how do you approach these instances? Do you get in a yelling and screaming match? Do you threaten your customers, reminding them that you report to the audit committee and that you can get them in trouble for not addressing the issue? Absolutely not! There is no reason that these situations can't be handled respectfully and cooperatively.

Remember, the concept of audit requirements is a misnomer. The audit department is not a requirements-setting body and therefore should not be in the business of trying to force action. Instead, auditors are there to identify risks and to ensure that the appropriate level of management is made aware of those risks so that decisions can be made as to whether or not to mitigate them. It is always an option that a risk may be accepted. However, the auditor must use his or her judgment to determine what level of management needs to be informed of the risk. There are some audit issues that represent a small amount of risk. In such cases, if a lower-level manager indicates that he or she understands and accepts the risk, then the auditor can just document this and move on. There will be other instances where the risk is more severe, and the auditor feels that the CIO needs to be made aware of the risk. However, if the CIO understands the risk and decides to accept it, once again, the auditor has done his or her job, and no further action is necessary. Still other issues represent such a severe risk that the auditor will be comfortable only with sign-off by the CEO or even the audit committee.

Note

There is always some level of management that can sign off on accepting the risk for any given issue. The auditors must use their judgment to determine what that level is.

Even in cases where you feel that you must go above someone's head to make the appropriate level of management aware of a given risk, there is no reason for this to be an adversarial event. You can calmly explain to your audit customers that you understand their reasons for declining to address the issue and that your job requires you to inform higher levels of management about the risk to ensure that they are also comfortable with accepting it. You can even invite them to participate in any meetings to discuss the risk and/or keep them copied on any e-mail traffic. This should not turn into a "he said/she said" match but instead can remain very open and respectful, with the auditors explaining the customers' viewpoint as well as their own during management communications. Escalating an issue often will result in a positive outcome for the customers, such as additional resources being allocated to allow for the issue to be addressed, so the escalation process does not have to be a contentious one. There even will be times when the customers want the auditors to escalate an issue in order to provide additional backing to address a known issue that perhaps has not received proper attention prior to the audit.

Report Drafting and Issuance

Once you've discovered the issues in the environment being audited, validated them with the customers, and developed solutions for addressing them, it is time to draft the audit report (Figure 2-8). The audit report is the vehicle by which you document the results of the audit. It serves two main functions:

Image from book
Figure 2-8: Audit process overview-report drafting and issuance stage.

  • For you and the audit customers, it serves as a record of the audit, its results, and the resulting action plans.

  • For senior management and the audit committee, it serves as a "report card" on the area that was audited.

Essential Elements of an Audit Report

There are as many audit report formats as there are internal audit departments. However, following are the essential elements of an audit report:

  • Statement of the audit scope

  • Executive summary

  • List of issues, along with action plans for resolving them

Statement of the Audit Scope It is important to make it clear for the reader what was included in the audit and, if necessary, what was not included in the audit. If an area or topic was specifically scoped out of the audit, it is important to state as much in the report so that there are no misunderstandings.

Executive Summary In addition to listing all the detailed issues and action plans, you need to have an executive summary so that someone who does not have the time or inclination to read all the details can understand the overall state of controls in the environment. This summary should be written so that it can stand alone, even if it were removed from the rest of the report. It should not list or discuss every issue, only the most significant ones. It should not be a tedious listing of the results of each area reviewed. Instead, it should reflect what you would really want someone to know about the results of the audit, assuming that they read no other part of the report. It also should not just be a bunch of mealy-mouthed platitudes and vague statements. Don't just say, "The area generally was well controlled, but there are opportunities for improvement." What does this mean? Be bold, and actually state an opinion. Say

Strong controls were in place over account administration, but a number of control concerns were found related to software change controls. The most significant of these issues is the fact that developers have direct access to update production code. This means that these programmers can alter production code functionality without going through proper testing and approval. The development team has developed an action plan for addressing this concern, which will result in their access being removed from the production environment. Further details are found in the "Issues" section below.

This is obviously just an example, and most of your executive summary sections should be longer than this. The point is that you need to provide some actual information so that management can understand what it should be concerned about.

List of Issues and Action Plans This is the meat of the report because it provides details on all the significant issues uncovered during the audit and what is going to be done to fix them. Quality and clarity of writing are essential because each issue must be documented in such a way that multiple levels can understand it. It should be written so that the people who deal with the area day to day understand exactly what you're talking about, but it also needs to be written so that senior management can understand enough about it to grasp the risk and why it needs to be mitigated. Be sure to explain concepts in layperson's terms and to spell out the risk. For example, if you have a concern about the default umask setting on a server, you could write an issue that says

The default umask on the server is set to 000.

Although the Unix administrators will understand your concern immediately on reading it, this statement is completely meaningless to anyone else who reads it. Alternatively, you could write the issue this way:

File permissions on the server need improving.

The lay reader will understand this, but the Unix administrator could interpret this in many ways and needs more detail about exactly what aspect of file permissions you're referring to. Instead, you might write the issue like this:

The default umask on the server is set to 000. This means that, by default, when a new file is created, its file permissions are set such that anyone with access to the server will be able to read and write to the file. As this server contains critical financial data files, this could result in inappropriate access to data and/or unauthorized changes to the data.

All levels can understand this third example. The technical person understands exactly what system setting you're referring to, and the layperson can understand the business risk being addressed.

Note

If you have certain systems or subject areas that you audit frequently, it may be useful to develop a database of standard wording for common issues. This database (which could be as simple as a spreadsheet) would contain standard wording for issues that are raised frequently during your audits. This prevents each audit team from spending time struggling with how to document the issue when writing the report and also provides consistency between your reports. For example, if you frequently audit Unix security at various company sites, it would be helpful to document standard wording for common issues such as, for example, the absence of password aging, easily guessed passwords, poor file security, etc. Of course, the audit team always should alter these as necessary to fit the circumstances of the specific audit, but the standard wording will provide an excellent starting point.

Many audit departments use a rating system in their audit reports. This rating system could provide a an overall rating for the audit, such as rating each audited area as "unsatisfactory," "needs improvement," or "adequate," or could provide a number rating, with, for example, a 1 being the worst and a 10 being the best. The rating system also could involve rating the severity of each specific audit issue. While your company's environment may require this sort of thing, it is best to avoid it if possible. Rating systems lead to lots of wasted time and energy spent on debating with the customers what the exact rating should be. Instead of spending energy on debating whether the report should be a 5 or a 6, spend that time reaching agreement on the need to do something and on developing an action plan. The end goal is to improve the controls in the environment. Debating over a rating does not contribute to this goal.

Following is a simplified example of an audit report, using the elements described in the preceding section.

Audit Scope

During this audit, we reviewed the internal controls within the corporate accounts receivable (AR) system. This included a review of controls within the application and its related database and operating system. Physical security of the AR system server was not included in the scope of the review because those controls were tested during a recent audit of the data center.

Executive Summary

Strong controls were in place over account administration, but a number of control concerns were found related to software change controls. The most significant of these issues is the fact that developers have direct access to production code. This means that these programmers can alter production code functionality without going through proper testing and approval. The development team has developed an action plan for addressing this concern, which will result in their access being removed from the production environment. Further details are found in the "Issues" section below.

Audit Issues

  1. Developers have direct access to update production code.

    There are no technical or procedural controls to prevent application support personnel from making unauthorized changes to the system.

    Risk Without proper software change controls, changes could be made to the application, either unintentionally or maliciously, that have not been approved and/or that have not been tested properly. These code changes could result in inaccurate system processing, the ability of an employee to execute fraudulent transactions, or system unavailability.

    Solution The AR system team will implement a baseline tool for protecting the production code. The ability to check new code into this tool will be limited to the group's manager and a backup, neither of whom has responsibility for performing code changes. Once this tool is implemented, the team will document procedures requiring approval and testing prior to submitting new production code for check-in.

    Responsible: Clark Kent

    Completion Date: xx/xx/xx

  2. The default umask on the server is set to 000.

    Risk This means that, by default, when a new file is created, its file permissions are set such that anyone with access to the server will be able to read and write to the file. Since this server contains critical financial data files, this could result in inappropriate access to data and/or unauthorized changes to the data.

    Solution Janet Richardson from the Unix infrastructure team will reset the default umask to 027 on the affected servers in the environment. Additionally, the Unix baseline documentation will be updated to include checking the default umask value prior to placing new systems into production.

    Responsible: Janet Richardson

    Completion Date: xx/xx/xx

Additional Elements of an Audit Report

In addition to the three basic sections just mentioned, there are other elements that you might consider adding to your reports.

Key Controls In addition to the issues you found, there undoubtedly were some good things that were already being done. There were likely some important controls already in place that you relied on during your assessment. If these controls were not in place or changed, it would change your overall assessment of the environment. Isn't it as important for your customers to know what they're doing right as it is for them to know what they need to improved? If you don't tell them that you considered a particular control to be important, then they could very well make a decision to stop performing that control. For example, if you relied on the fact that they disabled all unnecessary network services on their servers and that they regularly run Tripwire to detect changes in the environment, then state as much in the audit report. In this way, they'll know that they should not make changes to those controls.

Closed Items If your audit customers resolve issues during the course of the audit, give them credit for it. List the issues that have already been resolved in a separate section. This keeps closed items from clogging up the "Issues" section, gives your customers credit for being proactive, and yet also ensures that the audit report reflects a complete picture of the problems in place at the time of the review.

Minor Issues Sometimes you find minor issues during the project that do not represent a great risk. You have no interest in tracking their resolution because you really don't care whether the customers address them or not. Yet you would like to make the customers aware of your observations so that they can take action if they would like. These sorts of minor issues can be listed in their own section, where you make it clear that they are being communicated purely for informational purposes and that you won't be requiring action plans or tracking resolution.

Once you have drafted the report, you should let your customers review it and comment on it before it is issued. Be willing to make minor wording changes as long as they don't change the message of what you're saying. The goal should be for the customers to be comfortable with and in agreement with what's in the report.

Distributing the Audit Report

Finally, once the report has been drafted and reviewed by the customers, it is time to issue it. Most audit departments issue all audit reports to senior management (including the CIO, CFO, and CEO) and sometimes even to the audit committee. This certainly fits with the department's goal of providing senior management with independent assurance on the state of internal controls at the company. However, it can damage your goal of partnering with management to assess and improve the state of internal controls.

Note

If people know that everything you find is going to be sent all the way up the management chain, they'll likely be much less willing to share information and will be doing all they can to minimize what's in the report.

Consider seeking permission from senior management to allow you to issue reports only to the lower-level management of the group being audited. Senior managers likely will be concerned that this will result in significant issues going unad-dressed without their knowledge. You can compensate for this concern with a few additions to the process:

  • Send the executive summary section of each audit to senior management. This possibly could be compiled and sent on a quarterly basis. In this way, senior management stays in the loop on what's being audited and on the overall results without being sent every detailed issue and action plan.

  • Assure senior managers that if any issue is not resolved in a timely manner, you will escalate it to them. In this way, they will be bothered only with the issues that are not being addressed.

  • Assure senior managers that you will go ahead and let them know about any particularly material or pervasive issues. If you find these sorts of issues on an audit, you can consider going ahead and sending just those issues to senior management in an abbreviated audit report.

As you consider how to document and distribute your reports, keep in mind that your objective is to see the issues addressed, the risks mitigated, and the controls improved. Your objective is not to report things for the sake of reporting them or to show off all the things you did. Tailor your reporting process in such a way that it maximizes your chance of achieving your true objective.

Issue Tracking

It is common for auditors to feel like the audit is "done" once the audit report is issued. However, as we've discussed earlier in this book, issuing an audit report adds no value to the company unless it results in action being taken. The audit is not truly complete until the issues raised in the audit are resolved, either by being fixed (the preferred resolution) or by being accepted by the appropriate level of management (Figure 2-9). The audit department must develop a process whereby its members are able to track and follow up on issues until they are resolved. This likely will involve maintaining a database containing all audit points and their due dates, along with a mechanism for marking them as closed, overdue, etc.

Image from book
Figure 2-9: Audit process overview-issue-tracking stage.

It is usually wise for the auditor who performed or led an audit to be responsible for following up on the points from that audit. That auditor is responsible for following up regularly with the responsible customers as the due date for each point approaches. The auditor shouldn't wait until the point is due or past due before contacting the customer but instead should be in regular contact regarding the status of the issue. This serves a number of purposes. First, it allows the auditor to consult with the customers as decisions are being made. Second, it allows the auditor to be alerted early if the solution being implemented isn't matching expectations. In this way, the auditor can try to redirect activities before things are finalized. Third, if the issue is not being worked, it allows the audit department to try to address the problem prior to the point becoming overdue.

If it turns out that an issue is not being addressed as agreed, the auditors are responsible for initiating escalation procedures where needed. In the preceding section on solution development, we discussed the concepts of escalation and risk acceptance and how they can best be executed. We will not repeat that material here except to provide a reminder that not every issue has to be escalated to the audit committee if it's not being worked. The auditors must determine how important the risk is and make a decision as to what level of management needs to be aware of that risk and make a decision about whether to mitigate it. This is the level of management that an issue should be escalated to if necessary. Every little issue does not need to be escalated to the audit committee because the risks associated with some issues just don't warrant it. You don't need to go tell the audit committee about a user having a bad password.

Escalation should be a last resort and should not be a mechanical process. Judgment should be retained during the issue-tracking process. If a point is overdue, the first step should be to spend time with the responsible customers understanding why. If they are working on the issue, but other priorities have gotten in the way, resulting in a delay, or if it has turned out that implementing the solution is more complicated than initially thought, there is no need to escalate the point. Instead, consider extending the due date while setting an expectation that you cannot extend it endlessly. Escalation should occur only in cases where work is truly not progressing on addressing the issue either because the customers are choosing to not take action or because the customers do not have the resources or authority to make it happen.

Note

The escalation process should be a tool to enable the fulfillment of the audit department's goal of improving internal controls, not a mechanical process devoid of common sense.

Finally, a decision needs to be made regarding the validation of solutions put in place to address audit issues. How much emphasis needs to be placed on retesting the area to ensure that the new controls are working effectively? Although it would be nice to retest everything, it's probably not practical from a resource standpoint. In some cases it would require a complete reaudit of the area to truly validate the solution. The practical answer is usually to perform a "best effort" attempt to validate that the control was indeed implemented. If the solution was to modify a system setting, the auditor certainly can check the setting. If the solution was to create a disaster recovery plan, the auditor certainly can view the plan. However, there are other cases where the practical answer is to get the customer to explain and walk through the process or system that has been implemented without really testing its effectiveness. This is another area where judgment and common sense need to be applied.


Standards

As we conclude this chapter about the audit process, it is important to note that there are standards for the audit profession that should be adhered to as each company develops its audit process. On the website for the Institute for Internal Auditors (IIA) (http://www.theiia.org), you can find the International Standards for the Professional Practice of Internal Auditing. These standards should be reviewed and incorporated into your audit process. In addition, on the same website you will find the Code of Ethics for the auditing profession, which explains the requirements for integrity, objectivity, confidentiality, and competency as they apply to auditing.


Summary

In this chapter we learned that

  • Internal controls, stated in the simplest terms, are mechanisms that ensure the proper functioning of processes within a company. Controls can be preventive, detective, or reactive and have administrative, technical, and physical implementations.

  • It is important that your audit plan focus your auditors on the areas that have the most risk and on areas where you can add the most value. A comprehensive audit universe and effective ranking model are important elements to achieving this goal.

  • There are six key stages to an audit: planning, fieldwork and documentation, issue discovery and validation, solution development, report drafting and issuance, and issue tracking.

  • Some basic sources that should be referenced as part of each audit's planning process include handoff from the audit manager, preliminary survey, customer requests, standard checklists, and research.

  • During fieldwork and documentation, wherever possible, the auditors should look for ways to independently validate the information given to them and the effectiveness of the control environment.

  • If you work with your customers throughout the audit to validate issues and come to agreement on the risks those issues represent, then the conclusion of the audit will go much more smoothly and quickly.

  • Three common approaches are used for developing and assigning action items for addressing audit issues: the recommendation approach, the management-response approach, and the solution approach.

  • The essential elements of an audit report are the statement of the audit scope, list of issues along with action plans for resolving them, and the executive summary.

  • The audit is not truly complete until the issues raised in the audit are resolved.

In these first two chapters we have formed the foundation that will allow us to move on to Part II, which will provide details on how to audit specific processes and technologies.

Note

If you're interested in further information on the audit process, 'Managing the Audit Function: A Corporate Audit Department Procedures Guide' by Michael P. Cangemi and Tommie Singleton is an excellent resource.


Part II: Auditing Techniques

Chapter List

Chapter 3: Auditing Entity-Level Controls
Chapter 4: Auditing Data Centers and Disaster Recovery
Chapter 5: Auditing Switches, Routers, and Firewalls
Chapter 6: Auditing Windows Operating Systems
Chapter 7: Auditing Unix and Linux Operating Systems
Chapter 8: Auditing Web Servers
Chapter 9: Auditing Databases
Chapter 10: Auditing Applications
Chapter 11: Auditing WLAN and Mobile Devices
Chapter 12: Auditing Company Projects


Chapter 3: Auditing Entity-Level Controls

Background

As mentioned earlier, entity-level controls are controls that are pervasive across an organization. In other words, they are the areas that you can audit once and feel confident that you have covered the topic for the whole company. This chapter covers the areas that the auditor generally should expect to see centralized. If the topics covered in this chapter are not centralized or at least centrally coordinated at your company, it should lead to questions as to their overall effectiveness. Most of these topics set the "tone at the top" for the IT organization and provide overall governance of the IT environment. If they are not centralized and/or standardized, it should cause the auditor to question the ability of the overall IT environment to be well controlled.

The problem is that there is no set definition of what is and is not an entity-level control, and it will vary by company, depending on how the IT environment is defined. An area that is an entity-level process at one company will not necessarily be an entity-level process at another company. However, there's really no mystery to it-it all comes down to what's centralized and pervasive at your company. If a critical IT process is centralized at your company, it is a good candidate for being covered in an entity-level controls review.

For example, in Chapter 4 we cover the topic of auditing data centers and disaster-recovery plans (DRPs). In that chapter we will discuss auditing areas such as physical security, environmental controls, system monitoring, etc. Many companies have multiple decentralized data centers, meaning that these controls are not centralized for those companies. However, there are also many companies that have one data center and one set of processes for executing the areas just mentioned. In those companies, areas such as physical security, environmental controls, and system monitoring would qualify as entity-level controls because they are centralized and pervasive. However, we will not cover those areas in this chapter because they are covered in Chapter 4. The point is that auditors must use judgment and knowledge of the company to determine what is and is not an entity-level control.

However, as mentioned earlier, the topics mentioned in this chapter generally should be centralized to a large degree because they provide for the core principles of IT governance. If these areas have been decentralized with no central coordination, the auditor should dig deep before signing off as to their effectiveness.

Put another way, the areas covered in this chapter should be considered the minimum for an entity-level controls review. Other areas (such as data center operations) might be added based on the environment at your company.

Note

Strong IT entity-level controls form a foundation for the IT control environment within a company. They demonstrate that IT management is taking internal controls, risk management, and governance seriously. A strong overall control environment and attitude coming from the top tends to trickle down throughout the organization and lead to strong controls over decentralized processes and functions. Conversely, weak entity-level controls increase the likelihood that controls will be weak throughout the organization because upper management has not demonstrated and communicated to the organization that internal controls are valued. This generally leads to inconsistency at the lower levels because the personalities and values of lower-level managers will be the sole determining factors in how seriously internal controls are taken within the organization.

It is critical for upper management to communicate and set the tone that internal controls, risk management, and governance are valued and will be rewarded. Without this message, departments are more likely to focus on cutting costs, managing their budgets, and meeting their schedules, with no consideration given to internal controls.


Test Steps

1 Review the overall IT organization structure to ensure that it provides for clear assignment of authority and responsibility over IT operations and that it provides for adequate segregation of duties.

A poorly defined IT organization structure can lead to confusion regarding responsibilities, causing IT support functions to be performed inefficiently or ineffectively. For example, critical functions either may be neglected or may be performed redundantly. Also, if lines of authority are not clearly established, it can lead to disagreement as to who has the ultimate ability to make a final decision. Finally, if IT duties are not segregated appropriately, it could lead to fraudulent activities and affect the integrity of the company's information and processes.

How

A "one size fits all" model for an IT organization doesn't exist, and the auditor can't mechanically use a checklist to determine whether his or her company's IT organization is adequate. Instead, the auditor must view the overall organization and apply judgment in determining whether it adequately addresses the most essential elements. With this in mind, we will discuss below some key areas to consider during this review.

Review IT organization charts and ensure that they clearly indicate reporting structures. The organization charts should provide an indication as to where in the company the various IT organizations meet. For example, in most companies, all IT organizations eventually report to the chief information officer (CIO) so that there is one ultimate authority that is able to set rules for the overall IT environment. Ensure that your company has IT organization reporting structures that eventually report to a single source that is "close enough" to day-to-day IT operations to allow for effective governance and direction setting. If the IT organizations report to multiple CIOs or only consolidate to a high-level executive such as the chief executive officer (CEO), additional processes likely will be needed to develop an effective method for establishing overall policies, priorities, and governance for IT at the company. Otherwise, it is likely that fiefdoms will exist within IT, preventing the establishment of true entity-level IT controls.

Review IT organization charts and charters and ensure that they clearly delineate areas of responsibility. Determine whether it is clear how responsibilities are divided between organizations, or evaluate whether there is significant opportunity for confusion and overlap. In addition to reviewing documented organization charts and charters, consider interviewing a sample of IT employees and customers to determine whether there is a consistent understanding of the division of responsibility.

Evaluate the division of responsibilities within the IT organization to ensure that duties are segregated appropriately. Following are some basic general guidelines that can be considered during the review. Again, this should not be used as a mechanical checklist, and the auditor should review for compensating controls when investigating potential exceptions. The auditor also should consider criticality in making judgments. It is more important that separation of duties be in place over critical financial systems than over systems providing support for minor convenience functions (e.g., the company's internal training system).

Note

The specifics of which duties should be segregated from others will vary by company; however, the general idea is that the responsibilities for initiating, authorizing, inputting, processing, and checking data should be segregated so that one person does not have the ability to create a fraudulent transaction, authorize it, and hide the evidence. In other words, you're attempting to prevent one person from being able to subvert a critical process.

  • IT personnel should not perform data entry. Keep in mind that IT organizations differ in their composition across companies, so there may be data-entry personnel who are classified as IT in their companies. Here, we're referring to IT personnel who are performing true systems support.

  • Programmers and those performing run/maintain support for systems should not have the ability to directly modify production code, production data, or the job-scheduling structure. As with all these statements, in cases where there appears to be segregation-of-duties issue, the auditor should look for compensating controls before determining whether there is a true issue. Access to production data and code may not be a large risk if there are strict accountability and change-control procedures in support of that access.

  • Programmers and those performing run/maintain support for systems should be separate from those performing IT operations support (e.g., support for networks, data centers, operating systems, etc.).

  • An IT security organization should exist that is responsible for setting policies and monitoring for compliance with those policies. This IT security organization should not have any operational responsibilities outside those related to IT security.

2 Review the IT strategic planning process and ensure that it aligns with business strategies. Evaluate the IT organization's processes for monitoring progress against the strategic plan.

In order to provide for long-term effectiveness, the IT organization must have some sort of strategy regarding where it plans to go, as opposed to always being in reactive mode, where day-to-day issues and crises are the only things considered. The IT organization must be aware of upcoming business needs and changes in the environment so that they can plan and react accordingly. It is important that IT priorities align with business priorities. Too many IT organizations lose sight of the fact that their only reason for existence is to support the company in meeting its business objectives. Instead, these IT organizations focus on becoming a "world-class IT shop," even in cases where this goal doesn't directly support the overall company objectives. It is critical for IT organizations to stay grounded by tying their objectives to the company's objectives.

How

Look for evidence of a strategic planning process within IT, and understand how that planning is performed. Determine how company strategies and priorities were used in developing the IT strategies and priorities. Review documented short- and long-term IT priorities. Evaluate processes in place for periodically monitoring for progress against those priorities and for reevaluating and updating those priorities.

3 Determine whether technology and application strategies and roadmaps exist, and evaluate processes for long-range technical planning.

IT is a rapidly changing environment, and it is important that IT organizations understand and plan for change. Otherwise, the company's IT environment runs the risk of becoming obsolete and/or not fully leveraging technology to benefit the company.

How

Look for evidence that long-term technical planning is being performed. For purchased applications and technologies, determine whether there is an understanding of the vendor's support roadmap for those products. The IT organization should understand when their versions of the products will cease to be supported and have plans for either upgrading or replacing the products. Determine whether there are processes in place to monitor for changes in relevant technologies, consider how those changes will impact the company, and look for opportunities to use new technologies to help the company.

4 Review performance indicators and measurements for IT. Ensure that there are processes and metrics in place (and approved by key stakeholders) for measuring performance of day-to-day activities and for tracking performance against service-level agreements (SLAs), budgets, and other operational requirements.

The IT organization exists in order to support the business and its day-to-day operations. If minimum standards of performance are not established and measured, it is difficult for the business to determine whether the IT organization's services are being performed at an acceptable level.

How

Obtain a copy of any metrics being captured for the IT organization's routine activities (e.g., system uptime and response time). Determine what the goals for those metrics are, and ensure that the appropriate stakeholders have approved those goals. If actual performance is significantly inferior to goals, determine whether root-cause analyses have been performed to understand the problem and whether plans are in place to solve the problem.

Review any SLAs that have been established for supporting IT's key stakeholders. Ensure that there are processes in place for measuring actual performance against the requirements of the SLA and for correcting any deviations.

Ensure that processes are in place for establishing budgets and for holding the IT organization accountable for meeting its budget. Obtain copies of the IT budget for the current and preceding years, as well as copies of any "budget versus actual" analyses. Determine how any significant variances were reported and resolved.

5 Review the IT organization's process for approving and prioritizing new projects. Determine whether this process is adequate for ensuring that system acquisition and development projects cannot commence without approval. Ensure that management and key stakeholders review project status, schedule, and budget periodically throughout the life of significant projects.

Without a structured process for approving and prioritizing new IT projects, it is likely that IT resources will not be deployed efficiently. Instead, they will be assigned on an ad hoc basis to whatever potential project comes up next. Also, IT projects may commence that do not meet the needs of the business and/or that are not as important as other potential projects to which those resources could be deployed. Without a structured process whereby management and key stakeholders periodically review the project's progress, it is more likely that the project will get off track and fail to meet key goals and milestones.

How

Review any available documentation regarding the project proposal and approval process. Evaluate the process for potential holes that might allow a project to commence without approval. Look for evidence that proposed projects have been prioritized prior to approval and that there is some discipline and commonality within this approval process. Consider selecting a sample of active IT projects and obtaining evidence that those projects went through an appropriate process of proposal, prioritization, and approval. Review evidence that management and key stakeholders are periodically reviewing the status, schedule, and budget for active IT projects.

6 Evaluate standards for governing the execution of IT projects and for ensuring the quality of products developed or acquired by the IT organization. Determine how these standards are communicated and enforced.

If standards are not in place and enforced in the IT environment, it is more likely that projects will be executed in an undisciplined fashion, quality issues will exist in developed or purchased products, and the IT environment will be unnecessarily diverse (leading to increased support costs and potential interface issues).

How

Determine whether there are documented standards governing areas such as the following. If so, review those standards and ensure that they are adequate.

  • Project management. See Chapter 12 for guidelines regarding key elements that should exist within project management standards.

  • Software development. Standards should exist governing the development of code, including standards for naming, revision history, comments, and calls to other programs. Without such standards, the time and effort required for one person to support and troubleshoot another person's code increase significantly. Note that depending on the size of the IT organization, it may be acceptable for programming standards to be decentralized to a degree. However, each significant development organization should have a set of standards. See Chapter 12 for guidelines regarding key elements that should exist within these standards.

  • System configuration. This would include standard configuration for laptops, desktops, servers, and common user software packages. Common configuration will help to ensure that the systems are supportable and that they have the appropriate security settings.

  • Hardware and software. Standards should exist governing the hardware and software that is approved and supported for use in the company. This should include the specific versions that are supported. Otherwise, the IT environment likely will consist of a multitude of products performing similar functions, driving up IT support costs and leading to problems with the ability of the various products to interface with each other.

  • Quality assurance standards. Standards should exist that ensure that the development process includes the evaluation of security risks and internal control requirements.

Look for evidence that these standards are communicated to all relevant IT employees, and determine how these standards are enforced.

Note

Consider reviewing a sample of recent and active IT projects for evidence that the standards were followed. Consider reviewing a sample of systems for deviations from configuration, hardware, and software standards.

7 Ensure that IT security policies exist and provide adequate requirements for the security of the environment. Determine how those policies are communicated and how compliance is monitored and enforced.

IT security policy sets a baseline of expectations for employees of the company. If policies don't exist or provide adequate coverage, employees are forced to make up their own rules regarding security-related decisions. The same concept extends to computer systems, which require a standard by which system security can be evaluated. If IT security policies are too lenient, they will not provide adequate protection of the company's information assets. If they are too strict, they either will be ignored or will place unnecessary overhead and costs on the business.

If the IT security policies aren't communicated to employees, then they won't be followed. Additionally, if compliance with those policies is not monitored and enforced, employees will learn quickly that the policies can be ignored with no consequence, causing the policies to become "suggestions" rather than requirements.

How

Verify Adequate Policy Coverage Obtain a copy of your company's IT security policies. Ensure that they adequately cover your company's IT environment. At a minimum, the policies should include coverage of the following areas:

  • Acceptable usage of the company's information assets by employees (e.g., whether employees can use their computers, the Internet, and e-mail for personal reasons)

  • Data classification, retention, and destruction

  • Remote connectivity (e.g., overall network security and security requirements for virtual private network (VPN), dial-up, and other forms of connection to external parties)

  • Passwords

  • Server security (e.g., security requirements for Unix and Windows servers)

  • Client security (e.g., security requirements for desktops and laptops)

  • Logical access (e.g., requirements for obtaining and granting access to systems)

Review the policies for adequacy based on industry standards and the specific needs of your company. The audit steps in the other chapters of this section can be used as guidelines.

Specifically review the company's password policy. It should provide adequate guidelines dictating requirements for the composition of company passwords (e.g., minimum of eight characters, combination of letters and numbers, difficult to guess, etc.), for aging company passwords (e.g., requiring that they be changed every 90 days), for locking accounts after a certain number of unsuccessful logon attempts, for timing out login sessions after a period of inactivity, and for retaining a password history so that previous passwords cannot be reused for a certain period of time.

Specifically review the company's logical access policy. It should provide adequate guidelines dictating requirements for every user to have a unique ID, for accounts to be suspended on employee termination or job change, and for users to be granted the minimum access necessary to perform their jobs.

Verify Stakeholder Buy-in Ensure that key stakeholders were included during policy creation. Obtain a list of employees involved in the creation and approval of the IT security policies, such as IT organizations that are expected to comply with the policy. If IT security policies are created in a vacuum by the IT security organization without involving others, they are likely to be viewed as unrealistic and ignored. Involvement from those who provide the day-to-day support of the IT environment will bring an important perspective to the policies and also will ensure buy-in from those who need to enforce and comply with the policies. Ensure that the IT security policies were approved by an executive, such as the CIO or CEO. This will provide the IT organization with the authority and backing necessary to enforce the policies.

Verify Processes around the Policies Review processes for periodically reviewing and updating the policies to ensure that they keep up with the ever-changing IT environment. Look for evidence that these processes have been executed.

Review processes for periodically evaluating changes in the environment that might necessitate the development of new policies. Look for evidence that these processes have been executed.

Ensure that provisions have been made for obtaining approved exemptions from the policy. There inevitably will be occasions when people do not feel that they can comply with the policy. There should be a defined process whereby those people can formally request an exemption from the policy. They should be required to state why they need an exemption and define the compensating controls that will be put in place. The IT security organization should facilitate the exception process, including providing a recommendation and an opinion on the risk presented by the request, but usually should avoid making the final decision as to whether or not to accept the risk. Instead, it usually should be a business decision. Review the escalation policy for the exemption process and ensure that business (as opposed to IT) management is involved at some point, at least for the acceptance of significant risks. Ensure that the final decisions are documented and retained.

Note

Look for evidence that the IT security policies are communicated adequately to all company employees. Potential vectors include referencing the policies during new-hire orientation and/or having all employees periodically sign a statement that they have read and agree to the policies.

Review processes implemented by IT security and other IT organizations for monitoring compliance with the policies. Ensure that enforcement and escalation processes are in place that result in the correction of noncompliant situations. Review a sample of recent applicable compliance-monitoring reports, and ensure that significant issues were tracked to resolution.

Ensure that a mechanism exists for employees to report security incidents or concerns and that those reports are followed up on and tracked to resolution. Review a sample of recently reported incidents, and determine whether they were resolved adequately.

8 Review and evaluate risk-assessment processes in place for the IT organization.

Without these processes, the IT organization will be unaware of risks to the achievement of its objectives and therefore will not have the ability to consciously make decisions regarding whether to accept or mitigate those risks.

How

There is some overlap between this step and some of the other steps mentioned in this chapter, many of which are designed to determine how the IT organization is evaluating its own risks. It is possible that the auditor will consider this step to be covered adequately without explicitly performing it. However, the auditor should look for evidence that the IT organization is periodically considering the risks to the IT environment and making conscious decisions as to whether to accept, mitigate, or avoid those risks. Risk-assessment mechanisms could include

  • Monitoring internal controls in the IT environment, including internal audits and self-assessments

  • Performing formal threat and risk assessments of critical data centers and systems

  • Performing periodic reviews of the strategic IT plans and technical roadmaps and assessing risks to the achievement of those plans.

  • Monitoring compliance with IT security policies and other relevant IT policies

9 Review and evaluate processes for ensuring that IT employees at the company have the skills and knowledge necessary for performing their jobs.

If employees in the IT organization are not qualified to perform their jobs, the quality of IT services obviously will be poor. If mechanisms are not in place for maintaining and enhancing the knowledge and skills of IT employees, their knowledge can become outdated and obsolete.

How

Review human resources (HR) policies and processes as they relate to IT employees. Look for mechanisms that ensure that qualified people are hired and that provide for continuous enhancements of employee skills and knowledge. Review evidence that these policies and processes are followed. For example,

  • Ensure that job descriptions exist for all IT positions and that the job descriptions specifically state the knowledge and skills required for each job. Review evidence that these job descriptions are referenced during the hiring process. Review processes for keeping the job descriptions up to date.

  • Review the IT organization's training policies and ensure that they provide the opportunity for employees to attend training classes and seminars for enhancing and updating their skills and knowledge. Look for evidence that IT employees have taken training over the past year.

  • Review performance-review processes. Look for evidence that IT employees are receiving regular feedback on their performance. Ensure that processes exist for identifying poor performers, coaching them, and moving them out of the organization if performance does not improve. Conversely, ensure that processes exist for identifying top performers, rewarding them, and providing them with incentives to remain at the company.

10 Review and evaluate policies and processes for assigning ownership of company data, classifying the data, protecting the data in accordance with their classification, and defining the data's life cycle.

Although IT is responsible for providing the technology and mechanisms for protecting company data, there must be a framework for making decisions as to what level of protection is necessary for any given data element (based on the criticality of the data). Without such a framework, there will be inconsistency in how data are protected, likely resulting in some data being underprotected (thereby placing critical information assets at risk) or overprotected (leading to unnecessary costs). If the life cycle of data is not defined, it will lead to data being retained longer than necessary (resulting in additional storage costs and possible legal liabilities) or being destroyed prematurely (leading to potential operational, legal, or tax issues).

How

Review the company's data classification policy. It should have provisions for identifying owners for all critical company data. It also should provide a framework for classifying those data based on their criticality (e.g., confidential, internal data, public data). This framework should provide specific definitions of each classification level, along with specific requirements for how data at each level should be protected (e.g., encryption).

Review evidence that the data classification policy has been implemented. Look for a list of data owners and documentation indicating that those owners have classified their data. For a sample of these data, review evidence that protection has been implemented in alignment with the classification.

Determine whether life-cycle information has been created for company data. For a sample of major data elements, review documentation of the data's life-cycle requirements, including retention, archive, and destruction requirements. Ideally, requirements will be identified for how long the data should be active (e.g., online, easily accessible, modifiable if appropriate, and backed up periodically), when and for how long they should be archived (e.g., possibly offline, not necessarily easy to access, no longer modifiable, and no longer backed up periodically), and when they should be destroyed.

Review evidence that life-cycle requirements have been implemented.

11 Ensure that effective processes exist for complying with applicable laws and regulations that affect IT (e.g., Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley) and for maintaining awareness of changes in the regulatory environment.

If your company is found to be in violation of applicable laws and regulations, it can lead to stiff penalties and fines, a damaged reputation, lawsuits, and possibly cessation of the company. If a robust process is not in place for monitoring the regulatory environment, the company may be unaware of new laws and regulations, resulting in noncompliance.

How

Look for a single point of contact that is responsible for monitoring the regulatory environment and its impact on IT. This person or organization should be responsible for identifying laws and regulations that apply to the company's IT environment, ensuring that the responsibility for complying with those rules has been explicitly assigned to the appropriate organization(s), and monitoring the regulatory environment for additions and changes that will affect the company. If there is not a single person or organization responsible for this (or a small subset of people, each with a specific regulatory domain to cover), it likely will be done on an ad hoc basis, providing no assurance of full coverage. Review the processes used to monitor the regulatory environment, and evaluate their effectiveness. Obtain a list of IT-applicable regulations that have been identified, and look for evidence that responsibility for compliance with those regulations has been assigned and is being monitored. See Chapter 14 for more information on laws and regulations that may be applicable to your company.

12 Review and evaluate processes for ensuring that end users of the IT environment have the ability to report problems, have appropriate involvement in IT decisions, and are satisfied with the services provided by IT.

Because the IT environment exists in order to support the company's employees in performing their jobs, it is critical that processes exist whereby those employees can provide input into the quality of service they are receiving. Otherwise, the IT organization may be misaligned with its users and not be aware of it.

How

Ensure that there is a help desk function that provides end users with the ability to report problems. Review and evaluate processes for capturing problems and ensuring that they are tracked to resolution. Obtain a list of recent tickets, and select a sample, ensuring that all tickets were resolved and that no tickets were closed without the consent of the user who entered the ticket.

Ensure that a process exists for obtaining end-user feedback after tickets are closed. Look for evidence that user-satisfaction metrics are kept and that management follows up on end-user feedback.

In order to ensure that the help desk does not seek customer satisfaction at the expense of security, review policies and processes for obtaining proper approvals prior to responding to user requests for having passwords reset and for obtaining system access. Review a sample of these sorts of tickets, and ensure that proper processes were followed and approvals obtained.

Review for the existence of customer steering teams to provide input and prioritization of IT projects and enhancements. For significant areas of the business, key stakeholders should be identified to provide guidance to the IT organization regarding projects and decisions that affect them. Otherwise, the IT organization will be making decisions in a vacuum and likely will work on projects or enhancements that do not provide the greatest value for the business.

Review any SLAs that have been established for supporting IT's key stakeholders. Ensure that there are processes in place for measuring actual performance against the requirements of the SLA and for correcting any deviations.

13 Review and evaluate processes for managing third-party services, ensuring that their roles and responsibilities are clearly defined and monitoring their performance.

Many companies outsource some or all of their IT support process, including areas such as PC support, web server hosting, system support, programming, etc. If these vendors are not managed appropriately, it can lead to poor service and unacceptable quality in the IT environment. Depending on what portion of the IT environment has been outsourced, it could have a significant impact on the company's operations.

How

Review the process for selecting vendors. Ensure that the process requires soliciting multiple competitive bids, the comparison of each vendor against predefined criteria, involvement of knowledgeable procurement personnel to help negotiate the contract, and investigation of each vendor's qualifications and financial health. For a sample of recent vendor selections, review evidence that the process was followed.

Ensure that contracts with third-party service providers specifically define the roles and responsibilities of the vendor and include defined SLAs. Review a sample of contracts for evidence that expectations have been specifically defined.

Ensure that contracts include nondisclosure clauses, preventing the vendor from disclosing company information. Also ensure that contracts include right-to-audit clauses allowing you to audit vendor activities that are critical to your company. Review a sample of contracts for evidence that these clauses are in place where applicable.

Review processes for monitoring the performance and providing oversight of existing third-party service providers. For a sample of existing vendors, look for evidence that they are being monitored for compliance with SLAs and that they are performing the responsibilities defined in the contract.

14 Review and evaluate processes for controlling nonemployee logical access.

Most companies employ some level of outsourcing and contract labor to supplement their internal workforce. Also, some companies allow third-party vendors to have a degree of logical access to purchased systems for troubleshooting and support purposes. Because these personnel are not employees of the company, they are less likely to have a personal investment in the company's success or an awareness of the company's policies and culture. If their access to company information assets is not governed, and if expectations regarding their use of that access are not communicated, it is more likely that company information assets will be exposed unnecessarily or misused.

How

Ensure that policies require approval and sponsorship from an employee prior to a nonemployee obtaining logical access to company systems. If feasible, obtain a sample of nonemployee accounts, and validate that they have appropriate approval and sponsorship.

Review and evaluate processes for communicating company policies (including IT security policies) to nonemployees prior to granting them system access. Look for evidence that this communication has taken place. For example, if all nonemployees are required to sign a statement that they have read and agree to the policies, pull a sample of nonemployees and obtain copies of these agreements.

Review and evaluate processes for removing logical access from nonemployees when they have ceased to work with your company or otherwise no longer need access. Consider obtaining a sample of current nonemployee accounts and validating that those nonemployees are still working with your company and still have a need for their current level of access.

Ensure that nondisclosure agreements (NDAs) are signed by nonemployees in order to legally protect your company from inappropriate use of company data. Pull a sample of nonemployee accounts, and obtain a copy of the NDAs for those accounts.

Ensure that consideration has been given to identifying data that should not be accessed by nonemployees and activities that should not be performed by nonemployees. For example, your company may decide that access to certain levels of financial data never should be granted to nonemployees. Or it may decide that nonemployees never should be granted system administration duties. The answer will depend on your company's industry and philosophies; however, an evaluation process should take place, and the results of that evaluation should be documented in company policy and enforced. This evaluation should be part of the data classification effort described in step 10. This evaluation should drive the restrictions on nonemployee logical access.

15 Review and evaluate processes for ensuring that the company is in compliance with applicable software licenses.

Using software illegally can lead to penalties, fines, and lawsuits. It is increasingly easy for company employees to download software from the Internet. If companies do not develop processes for preventing or tracking this activity (as well as tracking the use of company licenses for purchased software), they can find themselves subject to software vendor audits without the ability to properly account for the company's use of the vendor's software.

How

Look for evidence that the company maintains a list of enterprise software licenses (e.g., Microsoft Office, ERP application accounts, etc.) and has developed a process for monitoring use of those licenses and complying with the terms of agreement. Determine how decentralized (nonenterprise) licenses are monitored and tracked. This would include software purchased by employees and placed on their company computers, as well as software downloaded from the Internet. Test the effectiveness of the method used at your company either by performing your own scans on a sample of computers or by reviewing evidence from the company's processes.

16 Review and evaluate controls over remote access into the company's network (e.g., dial-up, VPN, dedicated external connections).

Allowing remote access to a network basically results in that network being extended beyond its normal confines, bypassing normal perimeter controls such as firewalls. If strong controls are not implemented over this access, it can result in inappropriate access to the network and to the network being compromised.

How

Ensure that a user ID and strong password are required for remote access and that these credentials are transmitted over secure (e.g., encrypted) communication channels.

Determine whether approval processes are in place for granting remote access, especially for nonemployees. Pull a sample of users with remote access, and look for evidence of approval. Also evaluate processes for removing dial-up and VPN remote access accounts when employees leave the company. Pull a sample of users with remote access, and ensure that they are still active employees.

Evaluate controls for ensuring that dedicated external connections to business partners are removed when no longer needed. Pull a sample of current connections, and by means of interviews and review of documentation, determine whether they are still legitimately necessary.

Evaluate controls for ensuring that unauthorized connections cannot be made to the network and/or for detecting them if they are. Evaluate controls for ensuring that unauthorized modems or VPN connection points cannot be placed on the network and/or for detecting them if they are.

Ensure that policies provide minimum security requirements that should be met by all machines accessing the network remotely. This should include requirements for operating system patch level and antivirus protection. Look for preventive or detective controls that enforce these requirements.

Ensure that machines that are remotely accessing the network are not permitted to be dual-homed, which would bridge networks. This should be enforced technically where possible and by explicit agreement otherwise.

17 Ensure that hiring and termination procedures are clear and comprehensive.

Hiring procedures ensure that employees are submitted to drug screens and background checks, where local laws permit, prior to beginning work within an organization. Termination procedures ensure that access to company systems and facilities is revoked before a disgruntled employee can cause damage and that company property is returned. Inadequate hiring or termination procedures would expose the company to sabotage or abuse of privileges that could result in an information security compromise.

How

Review HR policies and procedures for the hiring and termination of employees. Ensure that hiring procedures include background checks, drug screens, and confidentiality agreements. Ensure that termination procedures include physical and logical access revocation, return of company-owned equipment, and where appropriate, supervision while the former employee collects his or her belongings.

18 Review and evaluate policies and procedures for controlling the procurement and movement of hardware.

Asset management is the controlling, tracking, and reporting of organizational assets to facilitate accounting for the assets. Without effective asset management, the company will be subject to the increased expense of duplicate equipment in situations where equipment is available but unaccounted for. Additionally, theft of equipment that is not tracked likely would go unnoticed. In the context of this step, the assets being referred to are computer hardware, such as desktops, laptops, servers, etc.

How

Review and evaluate the company's asset management policies and procedures, and ensure that they encompass the following:

  • Asset procurement process. Ensure that this process requires appropriate approvals prior to the purchase of hardware.

  • Asset tracking. Ensure that the company is using asset tags and has an asset management database.

  • Current inventory of all equipment. Ensure that there is an inventory containing the asset number and location of all hardware. Ensure that there is an effective mechanism for keeping this inventory up to date. A sample of asset tags also should be inspected visibly and tied back to the inventory.

  • Asset move and disposal procedures. Ensure that unused equipment is stored in a secure manner. Also ensure that data are erased properly from equipment prior to its disposal.

19 Ensure that system configurations are controlled with change management to avoid unnecessary system outages.

Configuration change management ensures that system changes are controlled and tracked in order to reduce the risk of system outages. It includes planning, scheduling, applying, and tracking changes to systems for the purpose of reducing the risk of those changes to the environment.

How

Change activities can fall into two areas: hardware and software (including operating-system-level changes). Ensure that the configuration-management procedures include processes for the following:

  • Requesting changes (including processes for end users to request changes)

  • Determining the specifics of what should change

  • Prioritizing and approving proposed changes

  • Scheduling approved changes

  • Testing and approving changes prior to implementation

  • Communicating planned changes prior to implementation

  • Implementing changes

  • Rolling back (removing) changes that don't work as expected after implementation

Also review change-control documentation to verify that changes are fully documented, approved, and tracked. Approvals should incorporate a risk assessment and typically are given by a committee made up of stakeholders. You should be able to obtain a sample of change-control requests, as well as other configuration management documentation, from IT management.

20 Ensure that media transportation, storage, reuse, and disposal are addressed adequately by company-wide policies and procedures.

Media controls ensure that information stored on data-storage media remains confidential and is protected from premature deterioration or destruction. Inadequate media transportation, storage, reuse, and disposal policies and procedures expose organizations to possible unauthorized disclosure or destruction of critical information. One increasingly common type of security incident is the loss of backup media in transit by third-party carriers. A number of high-profile companies have fallen victim to this threat in recent years, having incurred losses owing to legal actions, reputation damage, and incident response costs.

How

Computer media, including, but not limited to, backup tapes, CDs and DVDs, hard disks, USB jump drives, and floppy disks, must be strictly controlled to ensure data privacy. Since backup operators, computer technicians, system administrators, third-party carriers, and even end users handle storage media, media policies and procedures should address these disparate roles. When auditing media control policies and procedures, you should look for the following:

  • Requirements for sensitive information to be encrypted prior to transporting it through a third-party carrier

  • Requirements for magnetic media to be digitally shredded or degaussed prior to reuse or disposal

  • Requirements for optical and paper media to be physically shredded prior to disposal

  • Requirements for users to be trained adequately on how to store and dispose of computer media, including jump drives

  • Requirements for computer media to be stored in a physically secure, temperature-controlled, and dry location to prevent damage to the media

You can obtain this information through the review IT policies, procedures, and security awareness training documents, as well as user interviews.

21 Verify that capacity monitoring and planning are addressed adequately by company policies and procedures.

Anticipating and monitoring the capacity of data center facilities, computer systems, and applications are critical parts of ensuring system availability. When companies neglect these controls, they often experience system outages and data loss.

How

Capacity management is a core IT operations function. When auditing this area, review for the following:

  • Selected architecture documents to ensure that systems and facilities are designed to anticipated capacity requirements

  • Systems monitoring procedures, paying particular attention to capacity thresholds

  • System monitoring logs to determine the percentage of systems that are approaching or exceeding capacity thresholds

  • System availability reports to ensure that system capacity issues are not causing undue downtime.

Since capacity management is addressed most often by the groups responsible for data centers, applications, or system management, specific procedures should be addressed within these areas.

22 Based on the structure of your company's IT organization and processes, identify and audit other entity-level IT processes.

Note

If a critical IT process at your company is centralized, it is a good candidate for being reviewed during an entity-level controls audit. By auditing it once at the company level, you will be able to rely on the results of that audit when performing audits of other IT systems and processes.

By identifying those baseline IT controls, you should be able to reduce testing during other audits and avoid repetition. For example, if your company has only one production data center, you can test the physical security and environmental controls of that data center once. Then, as you perform audits of individual systems that are housed in that data center, instead of auditing the physical security and environmental controls for each of those systems (which would be very repetitive because they're all in the same place), you can just reference your entity-level audit of those topics and move on. Also, by performing audits of centralized processes, you will have an understanding of potential compensating controls in the overall IT environment that may mitigate concerns you have with lower-level controls.

How

Review the topics covered in the other chapters in Part II of this book, and consider whether any of those areas are centralized at your company. Those topics are candidates for an entity-level controls review. Below are some likely candidates:

  • Data center physical security and environmental controls (see Chapter 4)

  • System monitoring (e.g., performance and availability) and incident reporting (see Chapter 4)

  • Disaster-recovery planning (see Chapter 4)

  • Backup processes (see Chapter 4)

  • Network security and management (see Chapter 5)

  • Windows system administration processes (e.g., account management, security monitoring) (see Chapter 6)

  • Security of baselines used for deployment of new Windows systems (see Chapter 6)

  • Virus protection (e.g., antivirus, patching, compliance checking) (see Chapter 6)

  • Unix/Linux system administration processes (e.g., account management, security monitoring, security patching) (see Chapter 7)

  • Security of baselines used for deployment of new Unix and Linux systems (see Chapter 7)

  • Software change controls for internally developed code (see Chapter 10)

  • Enterprise password and account management practices (see step 7 above for guidance)


Knowledge Base

As mentioned throughout this chapter, the specifics of entity-level controls will vary from company to company. However, the best general sources of information on IT-specific entity-level controls can be found on the Information Systems Audit and Control Association (ISACA) website (http://www.isaca.org), where details on the control objectives for information and related technology (CoBIT) framework and guidelines for Sarbanes-Oxley IT compliance testing are available. In addition, general guidelines on entity-level controls (not specific to IT) and links to resources related to the popular Committee of Sponsoring Organizations (COSO) model of internal controls can be found on the website for the Institute of Internal Auditors (IIA) at http://www.theiia.org. Finally, your external auditors likely will have some published guidelines to share with you on this topic.


Master Checklist

Auditing Entity-Level Controls

Checklist for Auditing Entity-Level Controls

  1. qReview the overall IT organization structure to ensure that it provides for clear assignment of authority and responsibility over IT operations and that it provides for adequate segregation of duties.

  2. qReview the IT strategic planning process to ensure that it aligns with business strategies. Evaluate the IT organization's processes for monitoring progress against the strategic plan.

  3. qDetermine whether technology and application strategies and roadmaps exist, and evaluate processes for long-range technical planning.

  4. qReview performance indicators and measurements for IT. Ensure that processes and metrics are in place (and approved by key stakeholders) for measuring performance of day-to-day activities and for tracking performance against SLAs, budgets, and other operational requirements.

  5. qReview the IT organization's process for approving and prioritizing new projects. Determine whether this process is adequate for ensuring that system acquisition and development projects cannot commence without approval. Ensure that management and key stakeholders review project status, schedule, and budget periodically throughout the life of significant projects.

  6. qEvaluate standards for governing the execution of IT projects and for ensuring the quality of products developed or acquired by the IT organization. Determine how these standards are communicated and enforced.

  7. qEnsure that IT security policies exist and provide adequate requirements for the security of the environment. Determine how those policies are communicated and how compliance is monitored and enforced.

  8. qReview and evaluate risk-assessment processes in place for the IT organization.

  9. qReview and evaluate processes for ensuring that IT employees at the company have the skills and knowledge necessary for performing their jobs.

  10. qReview and evaluate policies and processes for assigning ownership of company data, classifying the data, protecting the data in accordance with their classification, and defining the data's life cycle.

  11. qEnsure that effective processes exist for complying with applicable laws and regulations that affect IT (e.g., HIPAA, Sarbanes-Oxley) and for maintaining awareness of changes in the regulatory environment.

  12. qReview and evaluate processes for ensuring that end users of the IT environment have the ability to report problems, have appropriate involvement in IT decisions, and are satisfied with the services provided by IT.

  13. qReview and evaluate processes for managing third-party services, ensuring that their roles and responsibilities are clearly defined and monitoring their performance.

  14. qReview and evaluate processes for controlling nonemployee logical access.

  15. qReview and evaluate processes for ensuring that the company is in compliance with applicable software licenses.

  16. qReview and evaluate controls over remote access into the company's network (e.g., dial-up, VPN, dedicated external connections).

  17. qEnsure that hiring and termination procedures are clear and comprehensive.

  18. qReview and evaluate policies and procedures for controlling the procurement and movement of hardware.

  19. qEnsure that system configurations are controlled with change management to avoid unnecessary system outages.

  20. qEnsure that media transportation, storage, reuse, and disposal are addressed adequately by company-wide policies and procedures.

  21. qVerify that capacity monitoring and planning are addressed adequately by company policies and procedures.

  22. qBased on the structure of your company's IT organization and processes, identify and audit other entity-level IT processes.


Chapter 4: Auditing Data Centers and Disaster Recovery

Background

Ever since the ENIAC was created in 1946, data center-class computer systems have had specific environmental, power, and physical security requirements. Beginning in the late 1950s, as mainframe computers became more widely available, purpose-built data centers were created to meet these requirements. Now, most organizations have their own data centers or collocate their systems in a shared facility.

Today's data centers provide the physical access control infrastructure, environmental control, resilient power and network connectivity, fire suppression systems, and several different types of alarm systems. The data center infrastructure is designed to maintain a constant optimal computing environment. The auditor's role is to verify and validate that all the necessary systems and procedures are present and working properly to protect the confidentiality, integrity, and availability of information.


Data Center Auditing Essentials

For those who have not worked in a data center environment, data centers can be a little overwhelming. As you enter the data center, you will notice that access is controlled strictly. You may pass through a "man trap" and have been authenticated by either a biometric or a card-key-based authentication system.

Once you pass into the computing environment, you will notice racks of computer systems, usually sitting on a raised floor. Most of the time, miles of power and network cables are run beneath a raised floor, although some data centers run cables through open conduits that hang from the ceiling. You also will notice that there are normally generators, large power conditioners, and UPS devices or rooms filled with batteries to ensure that clean, uninterrupted power is available at all times. Most data centers also have industrial-strength heating, ventilation, and air conditioning systems to maintain optimal temperature and humidity levels within the data center.

The brain of the data center facility is the data center control center. It usually consists of a series of consoles and computer monitors that are used to monitor temperature, humidity levels, power consumption, alarm, and critical system status. Most of the time, this is the only area consistently manned by data center personnel.

For the purpose data center audit, we will explore facility-based controls, as described earlier; system and site resiliency controls; as well as policies, plans, and procedures used in governing data center operations.

Facility-Based Controls

Data centers incorporate several types of facility-based controls, including access control systems, alarm systems, and fire suppression systems. These systems are designed to prevent unauthorized intrusion, detect problem conditions before they cause damage, and prevent the spread of fire.

Access Control Systems

Access control systems are used to provide physical protection of the information systems that reside within the data center. These systems include biometric devices that read fingerprints, hand geometry, and even retina characteristics to authenticate individuals who need to enter the facility. They also may include card-key systems or proximity badge systems.

Access control systems also include man traps. Man traps consist of two doors that are separated by a corridor. People entering the facility must authenticate to enter the corridor. The door closes behind them, and then they authenticate again to enter the data center facility. If someone is able to circumvent security to gain access to the corridor, they are effectively trapped when the access control system blocks their access to the data center itself.

Alarm Systems

Because fire, water, extreme heat and humidity levels, power fluctuations, and physical intrusion threaten data center operations, you will notice several different types of alarm systems. Specifically, you will want to look for the following types of alarms:

  • Burglar alarms (with magnetic door, window, or cabinet sensors; motion sensors; and sometimes audio sensors)

  • Fire alarms (usually smoke-activated sensors broken into zones that cover different parts of the facility)

  • Water alarms (usually with sensors beneath the raised floor, near bathrooms, or in water pipe ducts)

  • Humidity alarms (normally with sensors disbursed throughout the facility)

  • Power fluctuation alarms (with sensors near the logical point of entry)

  • Chemical or gas alarms (sometimes in battery rooms and near air intakes)

These alarms systems normally will feed into the data center operations center. During an alarm condition, the operator usually can drill down to specific sensors and reference a surveillance camera to isolate the cause of a problem.

Fire Suppression Systems

Because of the large amount of electrical equipment, fire is a major threat to data centers. Therefore, data centers normally are equipped with sophisticated fire-suppression systems and should have a sufficient number of fire extinguishers. Generally speaking, fire extinguishers come in two varieties: water-based systems and gas-based systems.

System and Site Resiliency

Since the computer systems that reside in a data center generally are leveraged to automate business functions, they must be available any time the business operates. Therefore, data centers incorporate various types of controls to ensure that systems remain available to perform critical business operations. These controls are designed to protect power, the computing environment, and wide area networks (WANs).

Power

Clean power is absolutely critical to maintain computer operations. Power fluctuations such as spikes, surges, sags, brown-outs, and black-outs can damage computer components or cause outages. In order to mitigate this risk, data centers provide power redundancy in several layers, including the following:

  • Redundant power feeds (connecting the data center to more than one power grid)

  • Ground to earth (to carry power away from critical components during fault conditions)

  • Power conditioning (to flatten out harmful spikes and sags in current)

  • Battery backup systems or UPSs (to provide uninterrupted power in the event of a power fluctuation, brown-outs, or black-outs)

  • Generators (to provide electrical power during prolonged power outages)

The auditor's responsibility is to verify that the power-related control method, capacity, and operating condition are adequate. We will explore power-related controls later in this chapter.

Heating, Ventilation, and Air Conditioning

Extreme temperature and humidity conditions can cause damage to computer systems. Since computers require specific environmental conditions to operate reliably, heating, ventilation, and air conditioning systems are required controls. Data centers typically provide sophisticated redundant systems to maintain constant temperature and humidity. Data centers often provide double the required capacity. The auditor's task is to evaluate capacity and the operational condition of these units.

Network Connectivity

Whether from internal networks or the Internet, users access information systems residing within data center facilities through network connections. Therefore, network connectivity is absolutely critical. More often than not, data center facilities have redundant Internet and WAN connections using multiple carriers. If one carrier experiences a network outage, service to the facilities can be provided by another carrier.

Data Center Operations

Although data centers are designed to be automated, they do require a staff to operate. As a result, data center operations should be governed by policies, plans, and procedures. The auditor should expect to find the following area covered by policies, plans, and procedures:

  • Physical access control

  • System and facility monitoring

  • Facility and equipment maintenance

  • Responding to outages, emergencies, and alarm conditions

We will explore data center operations in more detail later in this chapter.


Auditing Data Centers

A data center is a facility that is designed to house an organization's critical systems. These systems are made up of computer hardware, an operating system, and applications. Applications are leveraged to support specific operational functions such as order fulfillment, customer relationship management (CRM), and accounting. Figure 4-1 shows the relationships among data center facilities, system platforms, applications, and business processes.

Image from book
Figure 4-1: Data-processing hierarchy.

As you can see, data-processing facilities are at the foundation of the hierarchy, which is why it is so important that they have the necessary controls to mitigate risk. Major center threats include

  • Natural threats such as weather events, flooding, earthquakes, or fire

  • Man-made threats such as terrorist incidents, riots, theft, or sabotage

  • Environmental hazards such as extreme temperatures or humidity

  • Loss of utilities such as electrical power or telecommunications

You will notice that most of these threats are physical in nature. The remainder of this chapter will be spent on the various controls that mitigate these threats.


Neighborhood and Environment

When auditing a data center facility, the first thing an auditor should do is evaluate the environment in which the data center resides. The goal is to identify high-risk threats. For example, the data center we are auditing may be in the flight path of a regional airport, a FEMA flood zone, or a high-crime area. These types of environmental characteristics will reveal otherwise latent threats. In our audit, we will be looking for controls that reduce the likelihood of one of these threats being realized. Some of the things we will be evaluating include

  • Building orientation

  • Signage

  • Neighbors

  • Exterior lighting

  • Environmental hazards

  • The facility's proximity to emergency services

1 Review data center exterior lighting, building orientation, signage, and neighborhood characteristics to identify facility related risks.

Data center facilities should provide a physically secure environment for personnel and information systems. A breach of physical security, whether through a bomb, a physical intrusion, or a weather-related event, would compromise information and personnel security.

How

As we approach the facility, we will notice how far the building is set back from the curb and whether or not there are barriers to prevent cars from getting too close to the building. As we proceed into the facility, we also will determine which floor of the building the data center resides. These are important data security center characteristics. Specifically, we will look for controls such as building setback and physical barriers that reduce the risk of vehicle accidents or car bombs impacting the data center. I know, you're thinking, "Car bombs, vehicles crashing into buildings; is this really a risk?" The answer is yes. Prior to September 11, 2001, deliberately flying a plane into a skyscraper was considered an unthinkable scenario as well.

The floor in which the data center resides is important as well because below-ground and ground-level data centers are susceptible to flooding. Data centers on higher floors are more prone to lightning, wind, and tornado damage. The ideal is a single-story data center that is 5 ft or so above ground.

Signage Data centers also should be anonymous, away from main thoroughfares, and inconspicuously marked, if marked at all. In fact, most data centers employ what we call in the security industry security through obscurity. Maintaining relative anonymity will reduce the possibility of the facility becoming a target for espionage, theft, or sabotage.

Neighborhood The next question is, "Who are the neighbors of the data center facility?" Is it located in a multitenant building, or is it a stand-alone structure? If there are neighbors who are within a close proximity, what sort of business are they engaged in? A data center that is located next to a warehouse or manufacturing facility may have an increased risk of being affected by hazardous material spills or fires. The ideal is a stand-alone structure without any neighbors within close proximity.

Exterior Lighting Another control that we will evaluate is exterior lighting. Proper lighting deters crime and loitering around the facility. Critical facilities should have exterior walls and parking lots illuminated uniformly at an intensity level that allows for viewing at a reasonable distance.

2 Research the data center location for environmental hazards and to determine the distance to emergency services.

Environmental threats such as floods, severe weather, and transportation-related accidents can destroy or severely damage a data center. In the event of an emergency, rapid response from authorities is critical. Therefore, the proximity to fire stations, police stations, and hospitals is important.

How

Either before or after the on-site review is performed, the auditor should do some research to identify environmental hazards that may not be evident during the on-site visit. This research would entail either finding the following information in previous audit reports or compiling it from readily available sources:

  • Flood elevations

  • Weather and earth movement threats

  • Proximity to transportation-related hazards

  • Local crime rate

  • Proximity to industrial areas

Flood Elevations According to FEMA, floods are one of the most common hazards in the United States. After the 2005 hurricane season, it is apparent that this assessment is based in fact. Finding flood-zone information on the Internet is relatively easy.

Note

The following Internet resources are available to assist auditors in evaluating flood risks:

http://www.esri.com/hazards/makemap.html

http://www.hazards.fema.gov/

http://www.msc.fema.gov/

Weather and Earth Movement Threats Since different geographic zones are prone to different weather and earth movement hazards, it is also important for the auditor understand which of these threats are prevalent in the geographic area in which the data center resides. For example, if the data center we are auditing is in Dallas, the threats would be tornados, flooding, and extreme heat, whereas in northern California the threat would be earthquakes. The goal here is to understand the weather- and earth-related characteristics of the area in which the data center we are auditing resides.

Note

Some excellent weather-related Internet resources include

http://www.noaa.gov/

http://www.earthquake.usgs.gov/

http://www.hazards.fema.gov/

Proximity to Transportation-Related Hazards Planes, trains, and automobiles represent another risk to data center operations. Specifically, we will research whether or not the data center we are auditing is in an airport flight path or if there is a rail line next to the data center facility. Though rare, planes do crash and trains do derail and therefore pose a risk to nearby facilities. As auditors, it is our responsibility to inform management about risks to business. It is management's responsibility to decide where to spend limited resources in an effort to mitigate risk. Maps and observation are good methods for identifying nearby transportation-related hazards.

Local Crime Rate Obviously, if our data center is in a high-crime area, there is a higher risk of theft and other crimes. Therefore, another statistic we will research is the local crime rate. If the area in which the data center we are auditing resides has a high crime rate, we may recommend mitigating controls such as reinforced fences, an increased presence of security personnel, closed-circuit television (CCTV), and perimeter alarm systems.

Note

There are several excellent sources of online crime statistics. Below are a couple of the better websites: http://www.ojp.usdoj.gov/bjs/dtdata.htm http://www.cityrating.com/crimestatistics.asp

Proximity to Industrial Areas Many data center facilities are situated in industrial zones near factories and warehouses. These areas generally have a higher crime rate and a higher risk of hazardous materials spills affecting data center operations. Therefore, if the data center is situated in an industrial area, the auditor should evaluate the risks inherent to the area.

Proximity to Emergency Services When there is an emergency within a data center, each additional minute that it takes for authorities to respond can be very costly. Therefore, it is important to evaluate the distance to police stations, hospitals, and fire stations. This information can be obtained from the blue pages of the local phone book.


Physical Access Control

There have been several information security incidents in which thieves gained unauthorized access to sensitive information by defeating physical access control mechanisms. Therefore, restricting physical access is just as critical as restricting logical access. In a data center environment, physical access control mechanisms consist of the following:

  • Exterior doors and walls

  • Access control procedures

  • Physical authentication mechanisms

  • Security guards

  • Other mechanisms and procedures used to secure sensitive areas

3 Review exterior doors and walls to determine if they protect data centers facilities adequately.

A data center's first and most formidable line of defense should be the walls and doors used in its construction. As auditors, we will look closely at how well doors and walls protect against intrusion and other hazards such as projectiles or blasts.

How

Data center exterior walls should be reinforced with steel and concrete to protect the facility. If the data center resides within a building, the walls may be constructed of sheet-rock but should be reinforced with steel to prevent intrusion. Exterior doors also should be reinforced and should be able to withstand intrusion attempts. The auditor should obtain this information through interviews and observation. When auditing a data center, the auditor should verify that data center walls and doors are reinforced, identify all potential entry points, and validate that entry points are protected properly.

Raised Floors and Drop Ceilings Most data centers use either raised floors or drop ceilings to conceal ventilation ducts and power and network cables. Interior building walls sometimes are constructed with spaces below raised floor or spaces above drop ceilings left unwalled. Someone trying to gain unauthorized access to the secured area could remove either a tile or a section of the drop ceiling to crawl over or under the wall. During the building tour, the auditor should remove a section of raised floor and a ceiling tile at a data center wall to verify that walls extend from floor to ceiling.

Man Traps Man traps are an effective means of controlling access to critical facilities. They are used often in data center facilities to prevent unauthorized access. In auditing physical security, auditors should verify through observation that man traps exist where appropriate and that they are working properly. Man traps are equipped with two locking doors with a corridor in between. To ensure security, one door should be locked before the other is allowed to open. Obviously, the man trap should be constructed of reinforced walls and doors as well.

4 Evaluate physical authentication devices to determine if they are appropriate for the manner in which they are being used and are working properly.

Physical authentication devices such as card-key readers, biometric devices, and traditional key locks serve to allow access to authorized personnel and keep out unauthorized personnel. The failure or misuse of these devices can allow unauthorized persons access to the data center or prevent authorized personnel for entering at a time when intervention is required.

How

Data centers employ a few different types of authentication mechanisms, including card keys, proximity badges, biometric devices, and key locks in some areas. These devices also should incorporate PIN-code devices to provide two-factor authentication. When auditing the data center, the auditor should obtain a sample of data center authentication device logs and verify that the device is logging the following information:

  • User identification

  • Time and place of the access attempt

  • Success or failure of the access attempt

Card-Key and Proximity Devices Card-key devices use magnetic stripes or radio frequency identification (RFID) chips to authenticate users who possess the card. Because a stolen card can be used for unauthorized authentication, a PIN-code device normally is coupled with the card-key reader. The auditor should verify that all card-key readers are working properly and are logging access attempts.

Biometric Devices Biometric authentication devices have become more accurate and cost-effective over the past few years. As a result, more and more data centers are now employing the technology. Biometric devices are able to measure fingerprint, retina, and hand geometry. Since these biometric characteristics are unique to each individual, biometric authentication devices are difficult to defeat. The auditor should review the quality of the biometric system being used to determine if there are an inordinate number of false negatives or any observed false positives.

5 Review security guard building rounds logs and other documentation to evaluate the effectiveness of the security personnel function.

Security guards can be one of the most effective physical access controls. They act as a deterrent and also have the ability to control facility access and respond to incidents. If the security personnel function is ineffective, emergency response most likely would be slow and ineffective, doors could be left unlocked, and unauthorized personnel could have the opportunity to enter the data center facility.

How

When auditing a data center, the auditor should verify that documentation of building rounds, access logs, and incident logs/reports exist and that this information is recorded properly by obtaining samples from the security staff. Look for consistent entry and exit times, regular building tours, and comprehensive incident logs/reports. Visit the main security post to obtain this documentation.

6 Verify that sensitive areas are secured adequately.

Data centers typically have some areas that are more sensitive than others, such as equipment staging areas, generators, and computer systems that are processing sensitive information. If these areas are not secured adequately, information could be altered or disclosed to unauthorized personnel or destroyed due to a system failure caused by either sabotage or an accident.

How

Access to sensitive areas should be restricted further than access to the main facility. Computer systems that process sensitive information may be locked within a cage or locking cabinet, with only a select number of personnel given access. During interviews and tours of the data center, the auditor should verify that these areas are protected appropriately with proper access control mechanisms and, if appropriate, are monitored by CCTV cameras and/or alarm systems.


Environmental Controls

Computer systems require specific environmental conditions such as controlled temperature and humidity. Data centers are designed to provide this type of controlled environment. When auditing a data center, the auditor should verify that there is enough heating, ventilation, and air-conditioning capacity to service the data center even in the most extreme conditions.

7 Verify that heating, ventilation, and air-conditioning systems maintain constant temperatures within the data center.

Heating, ventilation, and air-conditioning systems are used to provide constant temperature and humidity levels within the data center. This is important because computer systems are damaged by extremes in either. High humidity levels can cause corrosion over time, and low humidity levels cause static electricity to occur.

How

Data center temperatures should range from 65 to 70°F. Temperatures above 85°F will damage computer equipment. Humidity levels should be between 45 and 55 percent. The auditor should review temperature and humidity logs to verify that each falls within acceptable ranges over a period of time. The auditor also should review the heating, ventilation, and air-conditioning design to verify that all areas of the data centers are covered appropriately. This information usually can be obtained from the facility manager during an interview.

8 Evaluate the data center's use of electronic shielding to verify that radio emissions do not affect computer systems or that system emissions cannot be used to gain unauthorized access to sensitive information.

Electronic equipment creates electronic emissions that, in theory, can be captured and disseminated to compromise the information that is being processed by the equipment. These are the same emissions that create crosstalk conditions in phone and network wires. The level of risk that electronic emissions creates is debatable, but nonetheless, many data centers provide electronic shielding to mitigate it as well as the risk of electronic interference from outside sources.

Note

There was a program that the National Security Agency (NSA) initiated in the 1960s called the TEMPEST project that was created to study the feasibility of using electronic emissions to gain access to otherwise protected information. The TEMPEST project still continues today. Although information about it is scarce, see http://www.cryptome.sabotage.org/tempest-time.htm for additional information about project history.

How

The auditor should review any shielding strategies that the data center employs to protect against interference or unauthorized access through emissions. Also determine whether there are any nearby sources of electronic interference. The data center facility manager usually can provide this information during an interview.


Power Continuity

Computer systems require uninterrupted, clean power to operate. Data centers typically employ several different types of controls to maintain clean power. These controls include

  • Redundant power feeds that provide power from two or more power stations

  • Ground to earth to carry excess power away from systems during electrical faults

  • Power conditioning systems to convert potentially dirty power to clean power

  • Battery backup systems (UPSs) that provide immediate power, typically for short periods of time

  • Generators to provide sustained power during extended power losses

When performing data center audits, the auditor should verify that adequate power continuity controls are present and working properly.

9 Determine whether the data center has redundant power feeds.

Some data centers are built in locations where they can connect to more than one power station. When the power supplied by one feed is lost, the other often will remain live. As a result, redundant power feeds can be used to maintain utility power continuity.

How

This control is not always present, but it is worth exploring with the data center facility manager during interviews.

10 Verify that ground to earth exists to protect computer systems.

Ungrounded electrical power can cause computer equipment damage, fire, injury, or death. These perils affect information systems, personnel, and the facility itself. Today, buildings that do not have grounded electrical outlets most likely will be in violation of building code.

How

Unlike redundant power feeds, the ground-to-earth control always should be present. Ground to earth is a basic feature of all electrical installations. It consists of a green wire that connects all electrical outlets to a rod that is sunk into the ground. When short circuits or electrical faults occur, excess voltage is passed through the ground wire safely into the ground rather than short-circuiting electrical equipment. This control should be present in any facility less than 30 years old or so, but it is definitely worth verifying. Older buildings that have not had electrical systems upgraded may not have an electrical ground, however. Electrical ground normally is required in building codes. This information can be obtained by interviewing the data center facility manager or through observation.

11 Ensure that power is conditioned to prevent data loss.

Power spikes and sags damage computer systems and destroy information. Power conditioning systems mitigate this risk by buffering the spikes and sags.

How

Clean power can be represented as a wave pattern with symmetric peaks and valleys. Normal utility power has a wave pattern with peaks and valleys that are far from symmetric, causing momentary spikes and sags. These spikes and sags shorten the life of electronic components and sometimes cause system faults. Power conditioning systems smooth out the wave pattern to make it symmetric. Through interviews and observation, the auditor should verify that power is being conditioned by either a power conditioning system or a battery backup system.

12 Verify that battery backup systems are providing continuous power during momentary black-outs and brown-outs.

Power failures can cause data loss through abrupt system shutdowns. UPS battery systems mitigate this risk by providing 20 to 30 minutes of power as well as power conditioning during normal utility power conditions.

How

Battery backup systems or UPSs offer immediate power in the event of a power loss. They are typically designed to provide somewhere between 20 minutes and 1 hour of computer run time. Basically, they provide enough time for the generator to turn on and begin generating electricity. They also perform a power conditioning function because they logically sit in between utility power and computer center equipment. As a result, the batteries are actually powering the data center all the time. When utility power is live, the batteries are charged constantly. Conversely, when power is lost, they begin to drain. The auditor should interview the data center facility manager and observe UPS battery backup systems to verify that the data center UPS system is protecting all critical computer systems and affords adequate run times.

13 Ensure that generators protect against prolonged power loss and are in good working condition.

Mission-critical data centers, by their nature, cannot withstand any power loss. Since it is impractical to install enough batteries to power the data center for more than an hour or two, generators allow the data center to generate its own power in the event of a prolonged loss of utility power.

How

Generators come in two common varieties: diesel-powered and natural gas- or propane-powered. Each has its benefits and drawbacks.

Diesel generators are most common but have a finite amount of fuel stored in their tanks. Diesel fuel is also a biohazard. If it is spilled, there could be significant cleanup expenses. Also, if the generator is in close proximity to the data center, there is a danger of a spill that reaches into the data center itself, which would be disastrous. These risks can be mitigated though fuel service contracts and spill barriers, however.

Natural gas generators run cleaner and theoretically have an infinite supply of fuel as long as the gas lines are intact. There is no danger of spills, but there is an increased danger of fire. Natural gas generators are employed rarely, however, because of the expense.

Propane generators are also expensive but have a limited supply of fuel. Again, this can be mitigated with service contracts.

All types of generators require frequent maintenance and testing. As a result, the auditor should review both maintenance and test logs during a data center audit. Additionally, auditors should obtain the sustained and peak power loads from the facility manager and compare them with current power generation capacity. Generators should be able to produce at least double the sustained power load.


Alarm Systems

Data centers normally have several different alarm systems that are designed to monitor for unauthorized access to the facility, fire, water, and excessively high or low humidity. These alarm systems typically feed into a console located in the data center operations center.

14 Ensure that a burglar alarm is protecting the data center from physical intrusion.

A burglar alarm failure would allow a physical intrusion to go undetected. Burglar alarms mitigate this risk.

How

Burglar alarms are designed to detect physical intrusions. They do this through a series of sensors that are placed in strategic locations such as doors and hallways. Burglar alarm systems employ the following common types of sensors:

  • Motion sensors that typically detect infrared motion

  • Contact sensors that are placed on windows and doors to detect when they are opened

  • Audio sensors to detect breaking glass or changes in normal ambient noise

When auditing a data center, the auditor should review sensor placement, verify that critical areas of the data center are covered adequately, and review maintenance logs to ensure that the system has been maintained and tested properly.

15 Verify that a fire alarm is protecting the data center from the risk of fire.

Because of all the electrical equipment, data centers are prone to fires. Fire alarms alert data center personnel of a developing fire condition so that they can evacuate the premise. A fire alarm failure would put human life at risk.

How

Data centers should have fire alarms to detect electrical fires before they can threaten human life. Data center fire alarm systems usually are multizone systems, which reduces the risk of false alarms due to a single malfunctioning sensor or zone. In a multizone system, sensors in two or more zones must detect the fire before an alarm sounds. There are three types of sensors:

  • Heat sensors activate when temperature reaches a predetermined threshold or when temperatures rise quickly.

  • Smoke sensors activate when they detect smoke.

  • Flame sensors activate when they sense the infrared energy or flickering of a flame.

Smoke actuated sensors and heat sensors are most common. When auditing a data center, the auditor should review fire alarm sensor type, placement, maintenance records, and testing procedures.

16 Ensure that a water alarm system is configured to detect water in high-risk areas of the data center.

Water and electronic equipment do not mix well. As a result, data centers normally employ water sensors in strategic locations such as near water sources or under raised floors. Water sensors detect the presence of water and are designed to alert data personnel prior to a major problem.

How

When performing a data center audit, the auditor should identify potential water sources such as drains, air-conditioning units, exterior doors, and water pipes to verify that water sensors are placed in locations where they will mitigate the most risk. The facility manager should be able to point out both water sources and sensors during a tour of the facility. The auditor also should review maintenance records to ensure that the alarm system is maintained periodically.

17 Ensure that a humidity alarm is configured to notify data center personnel of either high or low-humidity conditions.

Humidity levels above 60 percent or below 40 percent can cause computer equipment damage. High humidity can cause corrosion of computer components, and low humidity can cause static electricity discharges that can short-circuit system boards. As a result, data centers should be equipped with humidity alarm systems.

How

In a proper humidity alarm installation, humidity sensors are placed in all areas of the data center where electronic equipment is present. When reviewing the humidity alarm system, the auditor should ensure that sensors are placed in appropriate locations either by reviewing architecture diagrams or by touring the facility. The auditor also should review maintenance and testing documentation to verify that the system is in good working order.

18 Review the alarm monitoring console(s) and alarm reports to verify that alarms are monitored continually by data center personnel.

Alarm systems most often feed into a monitoring console that gives data center personnel the opportunity to respond to an alarm condition before calling authorities, evacuating the building, or shutting down equipment. The absence of a monitoring console would introduce the risk of an alarm condition going unnoticed.

How

The data center should have an alarm-monitoring console, where alarm systems are monitored by data center personnel. The auditor should review alarm reports and observe the data center alarm-monitoring console to verify that burglar, fire, water, humidity, and other alarm systems are monitored continually by data center personnel. Occasionally, the burglar alarm is monitored by data center security staff. The main objective here is to verify that alarms are being monitored.

There also should also be procedures that data center personnel adhere to for handling each alarm condition. See "Data Center Operations" section below for more information on auditing procedures.


Fire Suppression

Since data centers face a significant risk of fire, they typically have sophisticated fire suppression systems. There are basically two types of systems: gas-based systems and water-based systems. The data center relies on more than just fire suppression systems, however, as controls. Other fire suppression controls include

  • Building construction

  • Fire extinguishers

  • Proper handling and storage of hazardous materials

19 Ensure that data center building construction incorporates appropriate fire suppression features.

For over 30 years, building codes have required that building be constructed in such a way as to resist fire. Some fire suppression features include

  • Fire-rated walls and doors to prevent fire from moving from one area of a building to another

  • Firestops where fire-rated walls or floor assemblies are sealed to prevent the spread of fire

  • Standpipe fire hose systems to provide a ready supply of water for fire suppression

The absence of these features introduces the risk of a fire spreading more quickly and causing additional damage and possibly threatening life.

How

In auditing fire suppression, the auditor should review the available fire suppression features built into the facility. The facility manager or local fire marshal should be able to provide information about wall/door fire rating and firestops. Standpipe water systems will be visible and observed easily during a building tour.

20 Ensure that data center personnel are trained in hazardous materials handling and storage and that hazmat procedures are appropriate.

Hazardous and highly flammable materials are a common cause of fire. These materials include

  • Diesel and other fuels

  • Solvents and thinners

  • Propane or acetylene torches

  • Chlorine or ammonia-based chemicals

  • Glues and bonding compounds

These materials should be handled and stored in a proper manner to mitigate the risk of fire or spillage.

How

Data center employees should be trained in and there should be procedures that ensure the proper handling and storage of hazardous materials. In auditing hazmat procedures and training, the auditor should review hazmat incident reports, training materials, and procedures, as well as interview data center staff.

21 Verify that fire extinguishers are placed every 50 ft within data center isles and are maintained properly.

Fire extinguishers are often the first line of fire defense. In data centers, they should be placed in hallways and aisles every 50 ft or so. There are three common types of extinguishers: dry chemical-based, water-based, and inert gas-based. In most cases, data centers should use inert gas-based fire extinguishers, such as CO2 because water and dry chemicals damage electrical equipment. A lack of usable fire extinguishers could result in a small fire getting out of control.

How

During the course of the data center audit, the auditor should review the locations of fire extinguishers, as well as a sample of the attached service tags. The data center facility manager also should be able to supply maintenance records.

22 Ensure that fire suppression systems are protecting the data center from fire.

All data centers should have a fire suppression system to help contain fires. There are two common types of systems: gas-based systems and water-based systems. Modern fire suppression systems most often are multistage, where the first sensor (usually a smoke sensor) activates the system, and a second sensor (usually a heat sensor) causes a discharge of either water or gas.

Gas-Based Systems There are several varieties of gas-based fire suppression systems, including CO2 FM-200, CEA-410, and others. Gas-based systems are more expensive and often impractical, but they do not damage electronic equipment in the same manner as water-based systems.

Water-Based Systems Water-based systems are less expensive and more common but can cause damage to computer equipment. To mitigate the risk of damaging all the computer equipment in a data center or in the extended area of a fire, fire suppression systems are designed to only drop water from sprinkler heads at the location of the fire. There are four common types of fire suppression systems:

  • Wet pipe. Pipes are always filled with water.

  • Dry pipe. Pipes are filled with air and are filled with water at the time of a discharge.

  • Preaction. Pipes are filled at stage 1 activation, and water is discharged during stage 2.

  • Deluge. A type of dry pipe system that discharges a large amount of water to overwhelm a fire.

The absence of a fire suppression system would allow a fire to spread more quickly, causing a greater degree of equipment loss and possibly loss of life.

How

When auditing fire suppression systems, the auditor should review system design, maintenance, and test records. This information can be obtained through a combination of interviews, document review, and observation. The data center facility manager should be able to provide the design, maintenance, and test documentation.


Surveillance Systems

Most data centers employ either CCTV, audio surveillance systems, or a combination of the two. These systems typically feed into a guard station, where they are monitored by security personnel and recorded on either tape or a digital storage system.

23 Verify that surveillance systems are designed and operating properly.

Surveillance cameras are a detective control as well as a deterrent for would-be thieves. The absence of surveillance systems would increase the risk of theft and other criminal activities.

How

When auditing a data center, the auditor should review camera quality and placement as well as tape rotation or mass-storage archival schedules. This can be done through a combination of document review and observation. The data center security manager should be able to provide this information.


Data Center Operations

Effective data center operations require strict adherence to formally adopted policies, procedures, and plans. These documents should be used for determining who is granted access to the data center and what access they are granted, determining when facility-based systems are to be scheduled for maintenance, and determining which actions should be taken during an emergency. Some of the areas that should be covered by these policies, procedures, and plans include

  • Physical access control

  • Facility monitoring

  • Roles and responsibilities of data center personnel

  • Segregation of duties of data center personnel

  • Responding to emergencies and disasters

  • Facility and equipment maintenance

  • Data center capacity planning

  • Data center

One example of why documented policies, plans, and procedures are so important might include a scenario where a generator catches fire while being tested. Without clear procedures and proper training, we probably would witness employees running around in the heat of the moment responding in a way that they think is most appropriate but most likely not working together to solve the problem. With clear emergency response procedures, the decisions would have been thought out ahead of time, and employees would not be forced to make decisions in the heat of the moment. We most likely would witness a more coordinated response.

24 Ensure that physical access control procedures are comprehensive and being followed by security staff.

Physical access control procedures govern employee and guest access to the data center facility. If physical access control procedures are incomplete or not enforced consistently, data center physical access will be compromised.

How

When reviewing physical access control procedures, the auditor should do the following:

  • Ensure that access authorization requirements are clearly defined for both employees and guests.

  • Verify that guest access procedures include restrictions on taking pictures and outline conduct requirements within the data center.

  • Review a sample of both guest access and employee ID authorization requests to ensure that access control procedures are followed.

25 Review facility monitoring procedures to ensure that alarm conditions are addressed promptly.

Facility monitoring procedures ensure that all critical alarm conditions are captured and acted on promptly. They should include a description of the alarm systems that will be monitored, as well as the steps that are to be taken in the event of all reasonably foreseeable alarms, including fire, burglar, water, power outage, data circuit outage, system, and system component alarm conditions. The lack of system monitoring procedures could result in unnecessary risk to information systems and data center facilities.

How

When auditing facility monitoring procedures, the auditor should do the following:

  • Ensure that all critical systems and facility alarms are defined as "monitored systems" in the procedure.

  • Verify that alarm-condition response is clearly outlined for each type of alarm condition.

The auditor should be able to obtain the actual monitoring procedures as well as monitoring logs from data center facility management.

26 Verify that network, operating system, and application monitoring provides adequate information to identify potential problems.

System monitoring provides insight into potential problems resulting from capacity issues, misconfigurations, and system component failures. Inadequate system monitoring gives rise to the threat of security violations going undetected and system outages.

How

Although this function typically is managed by IT service groups rather than data center personnel, monitoring is a critical component of a sound IT strategy. System monitoring encompasses the monitoring of network devices, intrusion detection systems, operating systems, system hardware, and applications. Whereas intrusion detection system monitoring is focused primarily on monitoring for security violations, network device, operating system, system hardware, and application monitoring is focused primarily on items that can affect the availability of a system, such as hard-disk usage, number of concurrent connections, and so forth. Therefore, when auditing monitoring system procedure, it is important to understand the objective of the system.

The auditor should understand the criticality of specific system components and verify that monitoring systems provide near-real-time information to detect a problem with these system components. Additionally, the auditor should review monitoring logs and reports to identify instances where components being monitored exceed predetermined thresholds and then verify that actions have been taken to remediate the condition. Monitoring logs and reports typically can be obtained from system support groups, network support groups, and security and application monitoring teams.

27 Ensure that roles and responsibilities of data center personnel are clearly defined.

Well-defined employee roles and responsibilities ensure that responsibility and accountability for data center functions are clear. Inadequate roles and responsibilities would result in unclear job boundaries and data center functions going unaddressed, which could increase the risk of system outages.

How

When auditing data center roles and responsibilities, the auditor should ensure that all job functions are covered and that responsibilities associated with job functions are clearly defined. Data center facility management should be able to provide job descriptions, including roles and responsibilities.

28 Verify that duties and job functions of data center personnel are segregated appropriately.

Segregation of duties is a basic security precept of personnel management. The goal is to spread high-risk functions across two or more employees to reduce the risk of fraud or inadvertent errors. One example of segregation of duties is a check-payment procedure where one person is responsible to creating the check, another is responsible for posting the check to the accounting system, and a third is responsible for signing the check. If high-risk functions are not segregated, the data center will have a higher degree of fraud risk.

How

When reviewing the data center's segregation of duties, the auditor should verify that high-risk job functions, such as access authorization, are segregated across two or more employees. These processes should be tracked with logs and forms that can be reviewed to verify that duties are segregated effectively.

29 Ensure that emergency response procedures address reasonably anticipated threats.

When a fire breaks out or a data center floor begins to flood, data center personnel need a clear plan to address the condition and minimize losses. Although used only during the unlikely event of an emergency, emergency response plans are absolutely critical for reducing the risk of an emergency escalating owing to improper response from data center personnel.

How

Data centers are faced with various threats, including

  • Fire

  • Flood

  • Physical or logical intrusion

  • Power loss

  • System failure

  • Telecommunications outages

These and other identified threats should be addressed by emergency response plans. When auditing data centers, the auditor should verify that plans are present for all foreseeable threats and ensure that response procedures are comprehensive and well thought out. Data center operations staff should be able to provide these plans.

30 Verify that data center facility-based systems and equipment are maintained properly.

When not properly maintained, facility-based systems and equipment are prone to premature failure. These breakdowns can cause loss of information and system outages. As a result, maintenance is critical.

How

Critical systems and equipment should be maintained at least semiannually. The auditor should review maintenance logs for critical systems and equipment. The data center facility manager should be able to provide the maintenance logs.

31 Ensure that data center personnel are trained properly to perform their job functions.

Data center personnel cannot be expected to be proficient if they are not afforded job training. When not trained properly, data center personnel are more likely to cause data loss or system outages due to mistakes.

How

Auditors should review training history and schedules during data center audits. When reviewing training, the auditor should ensure that training is relevant to job functions and that all data center personnel are afforded training. Data center management should be able to provide access to training history and schedules. The auditor should review history for the past full year and schedules for the next 6 months.

32 Ensure that data center capacity is planned to avoid unnecessary outages.

Capacity planning ensures that procedures are in place to monitor and analyze factors that could impact the data center's current or future power, network, heating, ventilation, air-conditioning, and space requirements. Inadequate capacity planning could result in data loss, system outages, and/or delays in system deployments.

How

Capacity management is a broad topic that was covered in more detail in Chapter 3. A well-managed data center will be able to forecast how much rack space, network drops, network gear, electricity, and heating, ventilation, and air conditioning, just to name a few, are needed to support current and future operations.

When auditing capacity planning, the auditor should review monitoring thresholds and strategies that data center management uses to determine when facilities, equipment, or networks require upgrading. Data center management should be able to provide the capacity planning strategy, including thresholds for upgrading systems.

33 Verify that procedures are present to ensure secure storage and disposal of electronic media.

Electronic media often contain sensitive information that, if disclosed, would constitute a compromise of information security. As a result, media storage and disposal must be closely controlled. Additionally, improper storage of electronic media could result in accidental corruption of the information stored on the media.

How

The auditor should ensure that the following media storage and disposal controls exist within the data center:

  • Electronic media are stored in a dry, temperature-controlled, and secure environment.

  • Electronic media containing sensitive information are encrypted and tracked as they move from one location to another.

  • Electronic media are degaussed, overwritten with a Department of Defense (DOD)-compliant electronic shredding utility, or physically destroyed prior to disposal.

The auditor should be able to obtain media tracking, storage, and disposal records from data center management. Additionally, the auditor should tour electronic media storage facilities within the data center to verify that appropriate access control and environmental controls are in place. For more information regarding electronic media management audit, see Chapter 3.


Auditing Disaster Recovery

All data centers are susceptible to natural and man-made disasters. The preceding section focused on auditing controls that prevent disasters and system outages. This section will focus on auditing disaster recovery and will address the following:

  • System resiliency

  • Data backup and restore

  • Disaster recovery planning

From time to time, auditors are called on to review disaster recovery plan tests. As a result, we will address disaster-recovery plan testing at a high level as well.

Note

Disaster recovery is a very deep discipline; it is important to note that the scope of this book is to touch on best practices and provide high-level audit procedures. There are several resources that can be used by auditors for additional information, including the following:

http://www.drj.com/

http://www.fema.gov/

http://www.drii.org/


System Resiliency

Most information systems that reside within data centers process information that has a high requirement for system availability. Data center controls ensure high availability in relation to the facility, whereas redundant system components and sites are used to ensure high system availability in relation to the computer hardware.

1 Ensure that hardware redundancy is used to provide high availability where required.

When high system availability is required, systems should contain redundant system components such as redundant array of inexpensive drives (RAID) or redundant power supplies. Failure of system components will cause system outages and data loss.

How

When auditing redundant systems, the auditor should ensure that critical system components such as disk storage and power supplies are redundant wherever possible. Information about hardware redundancy can be found within system specification documents. Data custodians (administration personnel) should be able to provide this documentation.

2 Verify that redundant systems at separate sites are used where very high system availability is required.

In situations where there is no toleration for system downtime, redundant systems are placed at two or more separate locations. Information can be copied to alternate sites at set intervals such as daily or in real time. In cases where very high system availability is required, a system failure would cost an organization hundreds of thousands of dollars or more.

How

When reviewing system redundancy, it is important to review the manner in which data are copied from the main system to redundant systems. Since most systems with this level of criticality are database applications, we will focus on database redundancy. In general, there are three types of systems that provide database transaction redundancy:

  • Electronic vaulting-which provides periodic data copies through a batch process.

  • Remote journaling- which provides real-time parallel processing over a network connection.

  • Database shadowing-which provides real-time parallel processing over two or more network connections.

The auditor should ensure that the appropriate system is being used for the level of system availability that is required. System redundancy information usually can be obtained from system architecture documentation.


Data Backup and Restore

System backup is performed on most systems regularly. Often, however, restore is tested for the first time when it is required because of a system corruption of hard-disk failure. Sound backup and restore procedures are critical for reconstructing systems after a disruptive event.

3 Ensure that backup procedures are appropriate for respective systems.

Typically, backup procedures come in the form of backup schedules, tape rotations, and an off-site storage process. Depending on the maximum tolerable downtime, system backup schedules could be as frequent as real time or as infrequent as monthly. If systems are backed up less frequently than required on critical systems, data will be lost in the event of a system failure.

How

When auditing backup procedures, the auditor first should verify that backup procedures are in alignment with organizational backup practices and then ensure that more critical systems are backed up more frequently. Backup schedules generally are 1 week in duration, with full backups normally occurring on weekends and incremental or differential backups at intervals during the week. Tape rotations generally are 6 to 10 weeks in duration. Therefore, the organization will have the opportunity to retrieve a 6- or 8-week-old version of a file that was corrupted more than a week prior. System backup procedures and logs can be obtained from data center staff. The auditor also should consider retrieving and reviewing a sample of backup system logs.

4 Verify that systems can be restored from backup media.

There is no reason to back up information unless restore is possible, but unfortunately, organization rarely test backup media to ensure that system restore works properly. Backup media failure rates are high, especially with magnetic tapes. If it is not possible to restore from backup media, data will be lost.

How

When testing the restore function, the auditor should ask a system administrator to order backup media from off-site storage facilities and observe the restoration of data from the media to a test server. The auditor then should review the restore logs to verify that all files were restored.

5 Ensure that backup media can be retrieved promptly from off-site storage facilities.

Often, backup media cannot be retrieved from off-site storage facilities. This is due to backup media being marked improperly or placed in the wrong location. This situation can cause either undue delay in restoring systems or a complete loss of data.

How

When performing this audit step, the auditor should verify that backup media can be retrieved within the time frames set forth in the service-level agreement with the off-site storage vendor. Longer retrieval times would constitute a finding.


Disaster Recovery Planning

As a result of the 2005 hurricane season, disaster recovery planning has gained in awareness. The goal of disaster recovery planning is to efficiently reconstitute systems after a disaster such as a hurricane or flood strikes. In this section we will touch on auditing disaster recovery plans.

6 Ensure that a disaster recovery plan exists and is comprehensive and that key employees are aware of their roles in the event of a disaster.

If a disaster strikes your only data center and you don't have a disaster recovery plan, the overwhelming odds are that your organization will suffer a large enough loss to cause bankruptcy. Disaster recovery therefore is a serious matter.

How

Auditing disaster recovery plans can be difficult because of the complexity of successfully recovering data center operations. In auditing disaster recovery plans, the auditor should do the following:

  • Ensure that a disaster recovery plan exits.

  • Verify that the disaster recovery plan covers all systems and operational areas.

  • Review the last data center threat assessment to verify that the disaster recovery plan is still relevant and addresses the current risk to the data center.

  • Ensure that disaster recovery roles and responsibilities are clearly defined.

  • Verify that salvage, recovery, and reconstitution procedures are addressed.

  • Ensure that the emergency operations center has appropriate supplies, computers, and telecommunications connectivity.

  • Ensure that emergency communications is addressed in the plan.

  • Review the findings of the last disaster recovery exercise.

This information can be obtained from reviewing the actual disaster recovery plan or from interviewing the data center facility manager or disaster recovery planner.

7 Ensure that disaster recovery plans are updated and tested regularly.

Disaster recovery plans should be tested and updated at least annually, sometimes more frequently for organizations that are upgrading or procuring new systems, conducting mergers or acquisitions, or adding new lines of business. Failure to update or test disaster recovery plans will result in slower recovery times in the event of a disaster.

How

When auditing disaster recovery plans, the auditor should review the update or version history that usually is included in the front of the plan. Plans should be updated at least annually. Likewise, the auditor should review disaster recovery test documentation to verify that tests are performed at least annually. This information usually accompanies the plan in either electronic or paper form.

8 Verify that parts inventories and vendor agreements are accurate and current.

When disasters occur, organizations are faced with the task of recovering systems that often are completely destroyed from scratch. This requires hardware, software, and backup media. To speed up the process, data centers should keep certain parts at off-site facilities and enter into vendor agreements to get expedited parts in the event of a disaster.

How

The auditor should review both parts inventories and vendor agreements to ensure that both are current for existing systems. Vendor agreements should accompany the disaster recovery plan. Part inventories can be obtained from asset management or system personnel.

9 Ensure that emergency operations plans address various disaster scenarios adequately.

There are several different types of disasters that can occur at a data center. The common ones include fire, flood, and other weather-related events. Different types of events will require different salvage and recovery efforts. Emergency operations plans should reflect any reasonably anticipated scenario. Inaccurate emergency operations plans increase recovery times.

How

The auditor should verify that any reasonably anticipated scenario is covered by emergency operations plans and that plans accurately reflect specific needs relating to each scenario. This analysis can be performed by interviewing disaster recovery planners or simply by reviewing emergency operations plans.


Knowledge Base

We are only able to just touch on the concepts within this chapter. Below you will find additional resources where you can obtain additional information about data centers and disaster recovery.

  • http://www.esri.com/hazards/makemap.html

  • http://www.hazards.fema.gov/

  • http://www.msc.fema.gov/

  • http://www.fema.gov

  • http://www.noaa.gov/

  • http://www.isaca.org

  • http://www.earthquake.usgs.gov/

  • http://www.drj.com

  • http://www.drii.org

  • http://www.disasterrecoveryworld.com/

  • http://www.disaster recovery-guide.com/


Master Checklists

The following tables summarize the steps listed herein for auditing data centers and disaster recovery.

Auditing Data Centers

Checklist for Auditing Data Centers

  1. qReview data center exterior lighting, building orientation, signage, and neighborhood characteristics to identify facility related risks.

  2. qResearch the data center location for environmental hazards and to determine the distance to emergency services.

  3. qReview exterior doors and walls to determine if they protect data centers facilities adequately.

  4. qEvaluate physical authentication devices to determine if they are appropriate for the manner in which they are being used and are working properly.

  5. qReview security guard building rounds logs and other documentation to evaluate the effectiveness of the security personnel function.

  6. qVerify that sensitive areas are secured adequately.

  7. qVerify that heating, ventilation, and air-conditioning systems maintain constant temperatures within the data center.

  8. qEvaluate the data center's use of electronic shielding to verify that radio emissions do not affect computer systems or that system emissions cannot be used to gain unauthorized access to sensitive information.

  9. qDetermine whether the data center has redundant power feeds.

  10. qVerify that ground to earth exists to protect computer systems.

  11. qEnsure that power is conditioned to prevent data loss.

  12. qVerify that battery backup systems are providing continuous power during momentary black-outs and brown-outs.

  13. qEnsure that generators protect against prolonged power loss and are in good working condition.

  14. qEnsure that a burglar alarm is protecting the data center from physical intrusion.

  15. qVerify that a fire alarm is protecting the data center from the risk of fire.

  16. qEnsure that a water alarm system is configured to detect water in high-risk areas of the data center.

  17. qEnsure that a humidity alarm is configured to notify data center personnel of either high or low-humidity conditions.

  18. qReview the alarm monitoring console(s) and alarm reports to verify that alarms are monitored continually by data center personnel.

  19. qEnsure that data center building construction incorporates appropriate fire suppression features.

  20. qEnsure that data center personnel are trained in hazardous materials handling and storage and that hazmat procedures are appropriate.

  21. qVerify that fire extinguishers are placed every 50 ft within data center isles and are maintained properly.

  22. qEnsure that fire suppression systems are protecting the data center from fire.

  23. qVerify that surveillance systems are designed and operating properly.

  24. qEnsure that physical access control procedures are comprehensive and being followed by security staff.

  25. qReview facility monitoring procedures to ensure that alarm conditions are addressed promptly.

  26. qVerify that network, operating system, and application monitoring procedures provide adequate information to identify potential problems.

  27. qEnsure that roles and responsibilities of data center personnel are clearly defined.

  28. qVerify that duties and job functions of data center personnel are segregated appropriately.

  29. qEnsure that emergency response procedures address reasonably anticipated threats.

  30. qVerify that data center facility-based systems and equipment are maintained properly.

  31. qEnsure that data center personnel are trained properly to perform their job functions.

  32. qEnsure that data center capacity is planned to avoid unnecessary outages.

  33. qVerify that procedures are present to ensure secure storage and disposal of system media.

Auditing Disaster Recovery

Checklist for Auditing Disaster Recovery

  1. qEnsure that hardware redundancy is used to provide high availability where required.

  2. qVerify that redundant systems at separate sites are used where very high system availability is required.

  3. qEnsure that backup procedures are appropriate for respective systems.

  4. qVerify that systems can be restored from backup media.

  5. qEnsure that backup media can be retrieved promptly from off-site storage facilities.

  6. qEnsure that a disaster recovery plan exists and is comprehensive and that key employees are aware of their roles in the event of a disaster.

  7. qEnsure that disaster recovery plans are updated and tested regularly.

  8. qVerify that parts inventories and vendor agreements are accurate and current.

  9. qEnsure that emergency operations plans address various disaster scenarios adequately.


Chapter 5: Auditing Switches, Routers, and Firewalls

Background

Routers, switches, and firewalls join and protect out networks, but how did we end up with this interconnected network of devices?

It started way back in 1962 when Paul Baran of the RAND Corporation was commissioned by the U.S. Air Force to do a study on how to maintain control over its aircraft and nuclear weapons after a nuclear attack. This project was meant primarily to be a military network that would allow the armed forces to maintain communication with other commands throughout the United States in the event of a catastrophic event. This would allow the armed forces to maintain control of the nuclear weapons needed to launch a counterattack.

In 1968, ARPA (Advanced Research Projects Agency) awarded the ARPANET (Advanced Research Projects Agency Network) contract to BBN (Bolt, Beranek and Newman). The physical network was constructed in 1969, linking four nodes: the University of California at Los Angeles, SRI (Stanford Research Institute), the University of California at Santa Barbara, and the University of Utah. The network was wired together using only 50-kbps circuits. From there, the Internet was developed and flew into modern society, now running the backbone of every major company on the planet. In 1973, development began on the protocol later termed the Transmission Control Protocol/Internet Protocol (TCP/IP), but it was 1977 before it was demonstrated. This new protocol was created to allow diverse computer networks to interconnect and communicate with each other. Ten years later, in 1983, TCP/IP became the core Internet Protocol on ARPANET.

ARPANET was divided into two networks, MILNET and ARPANET. MILNET was to serve the needs of the military, and ARPANET was to support the advanced research component that later was to include commerce. Finally, in the early 1990s, you could now order pizza and take care of your bank account online. We've come a long way since the 1960s. In the next section we will uncover how these components work using simple explanations and analogies.


Network Auditing Essentials

We need to explore the International Standards Organization's (ISO) Open System Interconnection (OSI) model to understand routers, switches, and firewalls. The seven-layer OSI model will help you to understand the essentials so that you can comfortably audit your networking environment. We will do this using simple analogies and examples while avoiding overly complex issues.

Note

There is a reason that it takes several years for someone to take and pass their Cisco Certified Internetworking Expert (CCIE) certification. The purpose of this section is to help an auditor new to networking equipment quickly understand the differences between routers and switches and how firewalls work.

The layered model describes how to move data from your system to another system connected over a wire. This model helps to describe how to build applications, protocols, and equipment that allow moving data from your application to the physical wire, across hundreds or thousands of miles, and then finally to an application on the other side. Two common layered models are the ISO OSI model and the TCP/IP model. The TCP/IP model has five layers that loosely relate to the layers in the ISO OSI model. For the purposes of this chapter, we will discuss and stick with the ISO OSI seven-layer model (Table 5-1). Keep in mind that this is just a model and that real implementations of protocols do not always fit perfectly in the soup mix that follows.

Table 5-1: Simplified OSI Model Description
Layer | Common Name | Description
Layer 7 | Application | This layer represents the end-user application such as HTTP, FTP, SMTP, or Telnet.
Layer 6 | Presentation | This layer handles formatting, encryption, compression, and presentation of data to the application. Examples include SSL and TLS.
Layer 5 | Session | This layer deals with the setup and management of sessions between computer applications. Examples include named pipes, NetBIOS, and session establishment for TCP.
Layer 4 | Transport | This layer deals with transport issues, such as getting to the destination in one piece, and error control. TCP and UDP are perhaps the best-known examples in this layer.
Layer 3 | Network | This layer routes packets between networks. Examples include IP, ICMP, IPSec, and ARP. Routers operate at this layer typically using IP addresses.
Layer 2 | Data Link | This layer links data on hosts from one location to another, typically on the local-area network (LAN) but sometimes on the wide-area network (WAN) too. Examples include Ethernet, Token Ring, FDDI, Frame Relay, and ATM. Switches and bridges operate at this layer, typically using MAC addresses.
Layer 1 | Physical | This layer defines the physical link, cabling, and binary transmission. Modulation and flow control occur at this layer.

Switches and Routers

Two key hardware components of networks include routers and switches. Routers connect and route data between networks using IP addresses. Remember that routers typically represent OSI layer 3. Once data are routed to the destination network, they go to a switch where the destination host resides. The switch uses the destination host's MAC address to send the data the rest of the way to the host.

Switches

A switch is an extension of the idea of a hub. A hub takes a frame that it receives on any given port and repeats it out every port on the hub. A switch has a learning feature whereby it learns the MAC address for each host plugged into the switch ports. Once it knows this information, the switch will repeat a frame only out the port that contains the correct destination MAC address. Everything at the switch level typically is handled with the MAC address, represented by OSI layer 2.

Computer networks are composed of interconnected LANs, which are simply groups of computers, printers, and other equipment connected to the same switch. Hosts on the network have various applications and protocols that rely on broadcasts, which are a way of addressing all hosts that are in the same "broadcast domain," or layer 2 adjacent. If all hosts were layer 2 adjacent on a network of thousands, then you could saturate your network with broadcast traffic. While routers typically will separate broadcast traffic domains (broadcast domains), many switches also have a powerful capability of controlling broadcast domains. These switches essentially separate ports (and therefore hosts connected to those ports) into little groups. These groups form virtual networks, or virtual LANs (VLANs), which limit broadcast traffic to the VLAN.

VLANs can be used on most types of switches to further segment networks connected to the switch. Routing between these VLANs can be performed by routers separate from the switch or, in some cases, integrated into the switch. Switches that can switch packets between VLANs without the use of an external router are known as layer 3 switches.

This may sound confusing, but VLANs are extremely powerful. Think of VLANs as being used to separate a physical switch into multiple logical switches. VLANs allow network administrators to create segregated networks based on levels of trust or types of traffic. For example, you can keep an IP phone on a separate VLAN than the user's computer that uses the IP phone as data drop. Breaking the network up into smaller LANs also generally helps to reduce the number of broadcasts that individual hosts are required to process, and VLANs also allow network administrators to move a user with a logical change in the switch rather than a cable move.

Routers

We now need a way to route traffic between networks. Routers forward packets between different networks. Eventually, the packaged data, or packet, gets to the remote LAN and then finally to the host on the other side. Each router between you and the remote host simply looks at the IP address header information, layer 3, to see where to send it next.

Features specific to routers are those that enable them to communicate across the Internet or company WAN. Routers dynamically build routing tables using protocols such as Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP). These enable the routers to send packets in the direction they need to go to get to the other side as quickly as possible. Routers also may have access control lists and qualityof-service features. The association to remember is as shown in Table 5-2.

Table 5-2: Routers and Switches
Layer | Name | Equipment Used | Depends on | Example
Layer 3 | Network | Routers | IP Address-WAN | 198.133.219.25
Layer 2 | Data Link | Switches | MAC Address-LAN | 00-14-22-F5-04-16

You may hear people interchangeably use routers and layer 3 devices and likewise switches and layer 2 devices. Nowadays, people quite commonly will say, "That's a layer 2 device" or "That's a layer 3 device."

Despite some of the differences between them, switches and routers typically are managed in similar manners using similar syntax and have many of the same concerns from an audit perspective. Keep in mind the purpose of the device as you step through the audit, and this will help you to determine what additional steps, if any, that you might want to perform.

Firewalls

There are hundreds of firewalls on the market across several dozen vendors and several dozen applications. However, they are designed essentially to help segment networks and users into appropriate security zones. For example, the Internet is not trusted and falls into the lowest security zone. Also, your internal network might be further segmented into security zones using firewalls of several types depending on the data and resources you want to protect.

A correctly deployed firewall in key areas protects information assets from unnecessary risk. Network firewalls are essential in their role of protecting the network. Firewalls can be used for perimeter protection or for creating concentric rings of various levels of trust within a network. Firewalls also can help to establish a protected area of your network that is accessible to the public or only certain partners.

It's good to have a basic understanding of the different types of firewalls so that you know whether the firewall you are auditing is appropriate for the application for which it is being used.

Packet-Filtering Firewalls

Packet-filtering firewalls are essentially routers operating at layer 3 using set access control lists (ACLs). Decisions are made to allow and disallow traffic based on the source and destination IP address, protocol, and port number.

Stateful Packet Inspection Firewalls

Stateful packet inspection (SPI) firewalls, also called dynamic packet-filtering firewalls, operate at layers 3 and 4. Your linksys router at home allows you to establish and maintain a session externally with another address. The "state" in stateful refers to established sessions that occur in layers 4 and 5. The rules are changed dynamically when you establish an outbound connection to enable packets from the destination IP address to return back to you. All other traffic is stopped from reaching your computer, protecting you from the dangers of the Internet.

Application Proxies

Application proxies manage conversations between hosts, acting as an intermediary at the application level of the OSI model. Because proxies reestablish conversations to the destination, they effectively can hide the source of a conversation. This is often referred to as network address translation (NAT). Proxies might enforce authentication, logging, or content rules. They typically work in conjunction with a true firewall that controls traffic to the proxy because the proxy doesn't have built-in capabilities to deny traffic.

Application-Level Firewalls

Application-level firewalls, sometimes called gateways, combine the functionality of the typical firewall operating in the lower OSI layers with the power and deep inspection of a proxy. Now, based on information at the application level, decisions can be made to allow or disallow traffic. An example might be an appliance or host that screens web traffic before it hits your web server. Based on the behavior and content of the web traffic, decisions might be made dynamically to refuse access to the web server.


Auditing Switches, Routers, and Firewalls

The audit steps are divided into general steps and specific steps. The general networking audit steps are applicable to network equipment in general, followed by specific sections for routers, switches, and firewalls. You need to work through the first section of general controls regardless of your audit and then move to the specific section you need to complete the audit.

Note

The general networking audit steps need to be performed regardless of what networking device you audit. These steps apply to routers, switches, and firewalls regardless of what layer they operate on and regardless of where they are located in your network.
Note

Some of the examples below are for Cisco equipment. However, the concepts quite often are applicable regardless of your equipment.


General Network Equipment Audit Steps

Begin the audit by asking the network engineers for a copy of the configuration and the version of the device you intend to audit. For routers and switches, frequently, nearly all the information you will want is located in this file, and it prevents you from having to log onto the device repeatedly.

If you get a configuration file, sometimes it can be fairly long, and you may find it helpful to use command line tools such as grep and sort to move through the file and retrieve information for you. Windows version of these tools are readily available online from http://www.gnuwin32.sourceforge.net. You also could install Cygwin (http://www.cygwin.com) or other toolkits that provide similar functionality. It's possible to create scripts based on these binaries to quickly audit several configuration files at the same time.

Note

Many of the illustrations that follow are from the Cisco IOS. Your networking equipment may be different, but the concepts generally are the same. Your network engineers should know when there are differences and show you adequate supporting documentation so that you feel confident that your network is secure and operating as it should.

1 Review controls around developing and maintaining configurations.

This is a catch-all that addresses configuration management, the overarching concept of maintaining the secure configuration of the firewall. Failure to maintain a secure configuration subjects the firewall to lapses in technology or processes that affect the security of your network. Changes on the firewall should be reviewed immediately to ensure that the change did not unintentionally degrade the performance or otherwise hurt the security of the assets the firewall is protecting.

How

Discuss change-management practices with network administrators. Ensure that changes are planned, scheduled, documented (including the purpose of the change), and approved prior to implementation. Ensure that the company's configuration change-management policies and processes are followed. See Chapter 3 for more information.

Note that this step lightly covers routine patch cycles, which is specifically covered again in step 2. Discuss the following as applicable with the administrator to ensure that proper configuration management controls are in place:

  • Security mailing lists are monitored.

  • The latest patches are applied in a routine patch cycle under the guidance of written and agreed-on policies and procedures.

  • A configuration guideline exists for the equipment in the environment and is strictly followed. Exceptions are carefully documented and maintained.

  • Regular vulnerability scanning from both internal and external perspectives is conducted to discover new risks quickly and to test planned changes to the environment.

  • Regular internal reviews of the configuration are conducted to compare the existing infrastructure with the configuration guide.

  • Regular status reports are issued to upper management documenting the overall security posture of the network.

Having a strong configuration standard is critical to a secure network. Network equipment, including routers, switches, and firewalls, has many configuration options that affect security and are rarely secure out of the box. Taking the time to understand these options and how to configure them to your environment is fundamental to maintaining a sound and secure network.

2 Ensure appropriate controls are in place for any vulnerabilities associated with the current software version. These controls might include software updates, configuration changes, or other compensating controls.

This step goes beyond configuration changes and targets specifically software updates and any associated vulnerabilities. This step is where you as an auditor will research critical vulnerabilities associated with the software and ensure appropriate controls are in place, such as a software update, a configuration change, or other compensating control. Note that it isn't necessary to install each and every update, but you generally should keep your network equipment current. As vulnerabilities become known to the security community, they are documented in various online databases such as the National Vulnerability Database (NVD) located at http://www.nvd.nist.gov. These lists should be checked, and if the version of code being used is found to have some known vulnerabilities, the device should be patched or have other mitigating controls put in place to protect the network device and your network.

How

Discuss the software version information with the network administrator and the status of any pending patches or upgrades. Check the software and version against the National Vulnerability Database. Note and discuss any potential issues with the network administrator.

3 Verify that all unnecessary services are disabled.

Running unnecessary services can leave you susceptible to performance and security related risks. This is true of any host or device and adds to the attack surface available to potential attackers.

How

Discuss unnecessary services with the network administrator, and review the configuration of the device. If the device depends on another platform (e.g., some firewalls), then ensure the underlying platform also has all unnecessary services disabled.

Discuss any exceptions with the administrator, and determine what additional risk exposure might exist and whether exceptions are necessary. For any other services enabled, discuss with the administrator to verify that there is a legitimate business need for the service. Services should be enabled only when needed.

Table 5-3 presents an example for Cisco routers and switches. Note the presence or absence of these services, and be aware some of the ones included in the table may not be applicable. However, they should be disabled if they exist. For more documentation on these services, please consult the references section.

Table 5-3: Unnecessary Services
Service Name | Comments | Config File Entry
TCP Small Servers | RFC specified services for TCP (chargen, daytime, etc) | no service tcp-small-servers
UDP Small Servers | RFC specified services for UDP (chargen, daytime, etc) | no service udp-small-servers
Finger | Gives away information about the device and users; should be disabled or at least blocked from external networks | no service finger or no ip finger
HTTP Server | Used to manage the router via HTTP; disable if not in use; restrict access via ACLs if in use; typically not used at TI | no http server no ip http secure-server
Proxy ARP | Use only when absolutely necessary to support legacy architectures; not really a big deal unless the interface is an end-user subnet | no ip proxy-arp (on each interface)
DNS | Disable entirely or enable with specific server(s) | no ip domain-lookup (to disable) ip name-server addresses (for specific servers)
DHCP | Assumes you have other DHCP servers on your network | no ip dhcp-server
bootp | Bootstrap Protocol | no ip bootp server
identd | Identifies the user of a particular TCP connection | no ip identd
CDP | Cisco Discovery Protocol: Information sent through CDP is cleartext and unauthenticated | no cdp run (disables globally) no cdp enable <interface> (disables per interface)

4 Ensure good SNMP management practices are followed.

Simple Network Management Protocol (SNMP) represents an often-overlooked way to obtain full administrative access to a network device. This step may not be applicable to your equipment if the equipment doesn't support SNMP management or it is disabled.

How

Discuss SNMP management practices with your network administrator. In an ideal world, you would use SNMP Version 3 because the packets are authenticated and the password is encrypted on the wire. However, it's much more common to find SNMP Version 2 in most corporate environment. If SNMP Version 2 is used, then the community string should be difficult to guess. SNMP Versions 1 and 2 send the community string in cleartext, and packets are unauthenticated. These issues are resolved in SNMP Version 3.

SNMP community strings should follow standard password policies for strength and change frequency. Management with SNMP should be restricted with an access list, and no management should be allowed from an untrusted network.

5 Review and evaluate procedures for creating user accounts and ensuring that accounts are created only when there's a legitimate business need. Also review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

This is a large step with a wide scope, covering controls around account usage and management. Inappropriately managed or used accounts could provide easy access to the network device, bypassing other additional security controls to prevent malicious attacks. This step should cover policies and procedures that are essential to ensure that only authorized administrators can log in to a network device and that once logged in they have the proper privilege level. Login procedures should adhere to strong authentication, authorization, and accounting (AAA).

How

Discuss with the administrator and verify with the administrator's help that appropriate policies and procedures exist to add and remove account access to the device. The accounts should be controlled such that only those authorized to have access can log onto the device. Unused accounts, if applicable, should be removed from the configuration of the network device or completely disabled in accordance with your organization's account management policies.

Also review the process for removing accounts when access is no longer needed. The process could include a periodic review and validation of active accounts by system administrators and/or other knowledgeable managers. Obtain a sample of accounts, and verify that they are owned by active employees and that those employees' job positions have not changed since the account's creation.

In general, accounts should never be shared among administrators. This can present risk in that you lose accountability for actions taken on the system. Strong account policies always should be enforced by the network device. Additionally, discuss login procedures with the administrator to ensure that all users are managed appropriately using roles and that actions are logged appropriately. In general, individual IDs should be created for every person requiring access to the network device, or the network device should use a central authentication server for these accounts, sometimes called an AAA server. RADIUS and TACACS are examples of AAA servers.

Some network infrastructures may use TACACS for AAA on routers and switches. This system allows anyone with an RAS-enabled NT account to log onto the router in nonprivileged mode. An additional password, enable secret, is then required for privileged access. An example configuration file entry if TACACS servers are used might be

tacacs-server host <IP Address>

Individual IDs might look something like this in the configuration file:

username <name> password 7 <encrypted password>

These IDs should be created with a privilege level of 1, forcing enable secret to be required for additional access.

6 Ensure appropriate password controls are used.

Weak and unencrypted passwords allow attackers to easily guess or read passwords in plaintext. Strong password controls are essential to protecting network equipment.

How

Discuss password controls with the network administrator, and consult existing policies and procedures. Ensure complex passwords are used, stored with MD5 hashes where possible, and changed with appropriate periodicity (e.g., every 90 days). Passwords for privileged modes of operation never should be the same as any other password on the device.

Look for the command service password encryption on Cisco and other devices running IOS because this will encrypt most passwords displayed in the configuration. You may run across two types of encryption, type 5 and type 7. Type 5 is used for the enable secret only and is a strong encryption method using MD5 hash. Type 7 is a reversible algorithm. Type 7 encryption is decoded easily.

Note

Some passwords may not be able to be encrypted in the configuration file. These values often include SNMP community strings and RADIUS keys. It is imperative that these plaintext values are not the same as any other passwords on the system. Discuss this with the administrator.

Additionally, service password-encryption, if available on your router or switch, serves to provide a measure of security against shoulder-surfing attacks, where someone casually looks over your shoulder and sees the configuration file on your screen by storing and displaying your passwords in a scrambled format. Also for IOS devices, review the configuration file to ensure that the enable secret password is set and that it is not the same as any other password set on the system. Look in the configuration file for the line

enable secret 5 xxxxxxxxxxxxxxx.

Finally, ensure that appropriate controls exist such that the same password isn't shared on a large number of devices throughout your network. Passwords shared on the WAN should not be used on the LAN.

7 Verify that secure management protocols are used where possible.

Telnet sends all its information in cleartext. This allows passwords and other information to be viewed with a sniffer. SNMP Versions 1 and 2 are similar. Secure alternatives are SSH, Encrypted Kerberized Telnet, IPSec, and SNMPv3. While it is imperative that secure protocols be used from an untrusted network, it is very important on the inside as well.

How

Discuss management procedures with the network administrator, and review the configuration of the network device. Ensure that policies and procedures exist to manage routers, switches, and firewalls as securely as possible. Secure Shell (SSH) Protocol or another secure management protocol or an out-of-band management system should be used.

8 Ensure that current backups exist for configuration files if applicable.

It is critical to keep copies of the all network device configurations in a readily accessible, secure location. These files will contain any comments that can help to give perspective to the configuration settings and filters. Changes to the filters can be done with much more ease and accuracy when you can refer back to the old configuration files. These backups also can be invaluable for diagnosing suspected attacks and recovering from them.

How

Discuss policies and procedures with the network administrator, and ask to see where the current configurations are kept. Verify with the administrator that the backup repository contains the latest configurations kept on the routers and switches. The configuration files should be stored in a secure location to which only the network team has access.

9 Verify that logging is enabled and sent to a centralized system.

Logs should be collected for AAA and regular syslogging. They should be sent to a secure host to prevent tampering with the information. Additionally, SNMP traps may be used to send a subset of the information available with syslog.

How

Discuss logging with the network administrator, and review the configuration file. Ensure that appropriate log levels are used. Log levels range from 0 to 7 on Cisco equipment. Log level 0 would only log emergencies where the system was unusable, and log level 7 is debug-level logging. Logging is identified by

logging host <ip address>

AAA logging is identified in Cisco configuration files by

aaa accounting

SNMP traps are identified by

snmp-server host [log host] [version] [community string] [trap-type]
snmp-server enable traps [trap-type]

10 Evaluate use of Network Time Protocol (NTP).

Use of the NTP provides time synchronization for the timestamp on all logged events. The timestamps are invaluable in reporting and troubleshooting and enable acquisition of useful information about events in logfiles.

How

Discuss the use of NTP with the administrator, and review the configuration file. For ease of management, it is a good idea to standardize all clocks to a single time zone. The following indicates that NTP is enabled. Note that the key option is used with authentication.

ntp server <ip address> key <key>

11 Verify that a banner is configured to make all connecting users aware of the company's policy for use and monitoring.

A warning banner that clearly marks the router or switch as private property and disallowing unauthorized access is essential should a compromise ever result in legal action.

How

Verify with the administrator and a review of the device configuration that all connecting users are made aware of the company's policy for use and monitoring. Confirm that the motd or login banner does not disclose any information about the company or network device. This information should be reserved for the exec banner after a successful login.

For Cisco equipment, you would review the configuration file for either the banner motd or the banner login. These do basically the same thing with minor differences. The motd banner is displayed before the login banner, but both appear to the end user before the login prompt. The motd banner can be disabled on a per-line basis, whereas the login banner cannot.

12 Ensure that access controls are applied to the console port.

Logical access can be gained via the console port with poor physical access controls to the router or switch. Often the console port will be left with no password for convenience. Ensure that a password is used to provide an additional layer of defense beyond the physical controls. A password is imperative if the location is not physically secure.

How

Discuss access controls with the administrator, and verify that the console port is password-protected. Here is an example of a Cisco router or switch configuration:

line con 0
login (to use a password only)
login local (to use a locally defined username and password)
login tacacs (to use the TACACS+ servers)
password 7 xxxxxxxxxxxxxxxx

If AAA authentication is used, make sure that the line starts with aaa authentication login default. Failure to include default could mean that login on the console port is allowed without any password. Typically, TACACS will be tried first with local as a backup.

13 Ensure that all network equipment is stored in a secure location.

Anyone with physical access to a network device might be able to gain full logical access using well-documented password-recovery procedures. Someone also could unplug cables or otherwise disrupt service. Additionally, access should be limited to prevent nonmalicious accidents (e.g., tripping over a cable) from disrupting service.

How

Visually observe the location of the network equipment, and discuss physical access to the equipment with the network administrator.

14 Ensure that a standard naming convention is used for all devices.

Standard naming conventions make troubleshooting and finding issues easier. Standard naming conventions also help to make managing the environment easier as the organization grows.

How

Discuss the naming conventions used with the network administrator.

15 Verify that standard, documented processes exist for building network devices.

Documented processes provide repeatability of secure designs and higher-quality workmanship, helping to prevent common mistakes that might lead to a service disruption or network compromise.

How

Discuss documented policies and procedures for building network equipment with the network administrator. If possible, verify using a recent build that the process was followed.


Additional Switch Controls-Layer 2

The following are additional controls for switches, or layer 2 devices.

1 Verify that administrators avoid using VLAN 1.

By default, all ports on a Cisco switch are members of VLAN 1. Avoiding the use of VLAN 1 prevents network intruders from plugging into unused ports and communicating with the rest of the network.

How

Discuss this practice with the administrator, and review the configuration file for the existence of VLAN 1.

2 Evaluate the use of trunk autonegotiation.

A trunk on a switch joins two separate VLANs into an aggregate port, allowing traffic access to either VLAN. There are two trunking protocols, 802.1q, which is an open standard, and ISL, which was developed by Cisco. Some switch types and software versions are set to autotrunking mode, allowing a port to attempt automatically to convert the link into a trunk. Dynamic Trunking Protocol (DTP) might help to determine which trunking protocol it should use and how the protocol should operate. If this is the case, then generally speaking, all the VLANs on the switch become members of the new trunked port. Disabling trunk autonegotiation mitigates the risks associated with a VLAN-hopping attack, whereby someone in one VLAN is able to access resources in another VLAN.

How

Discuss with the network administrator, and review the configuration file. There are five best practices that may help you to decide if the trunk autonegotiation is set appropriately on the ports in your switch. The examples and practices come from the NSA Switch Configuration Guide.

  1. Do not use the Dynamic Trunking Protocol (DTP) if possible. Assign trunk interfaces to a native VLAN other than VLAN 1.

    Switch(config)# interface fastethernet 0/1

    Switch(config-if)# switchport mode trunk

    Switch(config-if)# switchport trunk native vlan 998

  2. Put nontrunking interfaces in permanent nontrunking mode without negotiation.

    Switch(config)# interface fastethernet 0/1

    Switch(config-if)# switchport mode access

    Switch(config-if)# switchport nonegotiate

  3. Put trunking interfaces in permanent trunking mode without negotiation.

    Switch(config)# interface fastethernet 0/1

    Switch(config-if)# switchport mode trunk

    Switch(config-if)# switchport nonegotiate

  4. Specifically list all VLANs that are part of the trunk.

    Switch(config)# interface fastethernet 0/1

    Switch(config-if)# switchport trunk allowed vlan 6, 10, 20, 101

  5. Use a unique native VLAN for each trunk on a switch.

    Switch(config)# interface fastethernet 0/1

    Switch(config-if)# switchport trunk native vlan 998

    Switch(config)# interface fastethernet 0/2

    Switch(config-if)# switchport trunk native vlan 997

3 Verify that Spanning-Tree Protocol attack mitigation is enabled (BPDU Guard, Root Guard).

Risks associated with this type of attack include giving an attacker the ability to use the Spanning-Tree Protocol to change the topology of a network. The Spanning-Tree Protocol is designed to prevent network loops from developing. The switch will learn the network topology and move a port through four stages from block, listen, learn, and forward as it ensures that an endless loop isn't developing in the network traffic patterns.

How

Discuss with the network administrator, and review the configuration file. For access ports, look for the following configuration:

spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable

For downlink ports to other switches, look for the following configuration:

spanning-tree guard root

4 Evaluate the use of VLANs on the network.

VLANs should be used to break up broadcast domains and, where necessary, to help divide resources with different security levels.

How

Discuss the application of VLANs with the network administrator. Devices at different security levels ideally should be isolated on separate switches or layer 2 devices. For example, if you have equipment that, for some reason, cannot be protected with the company's standard antivirus software and security patches, you could place that equipment on a separate VLAN.

5 Disable all unused ports and put them in an unused VLAN.

This setup prevents network intruders from plugging into unused ports and communicating with the rest of the network.

How

Discuss this practice with the network administrator.

6 Evaluate use of the VLAN Trunking Protocol (VTP) in the environment.

VTP is a layer 2 messaging protocol that distributes VLAN configuration information over trunks. VTP allows the addition, deletion, and renaming of VLANs on a network-wide basis. A network attacker could add or remove VLANs from the VTP domain as well as create Spanning-Tree Protocol loops. Both situations can lead to disastrous results that are very difficult to troubleshoot. This would not have to be a malicious event. A switch with a higher configuration version number in its VTP database has authority over other switches with a lower number. If you had a lab switch such as this one and placed it on the production network, you might accidently reconfigure your entire network.

How

Discuss use of the VTP with the network administrator to ensure that passwords are used if the VTP is necessary. VTP should be turned off if it's not used. The VTP mode of a switch can be server, client, or transparent. Use transparent mode unless client or server is required.

If VTP is necessary, then domains should be set up for different areas of the network, and passwords should be enabled. Look for these lines in the configuration file:

vtp domain domain_name
vtp password Some_strong_password

7 Verify that thresholds exist that limit broadcast/ multicast traffic on ports.

Configuring storm controls helps to mitigate the risk of a network outage in the event of a broadcast storm.

How

Discuss with the administrator and review the configuration file for the presence of storm-control [broadcast | multicast | unicast] level.


Additional Router Controls-Layer 3

The following are additional controls for routers, or layer 3 devices.

1 Verify that inactive interfaces on the router are disabled.

Interactive interfaces that should be disabled include LAN and WAN interfaces such as Ethernet, Serial, and Asynchronous Transfer Mode (ATM). Open interfaces are possible sources of attack should someone plug into the interface.

How

Discuss policies and procedures with the network administrator to ensure that this is a common practice. Ask the administrator for examples. The command shutdown is used to disable interfaces.

2 Ensure that the router is configured to save all core dumps.

Having a core dump (an image of the router's memory at the time of the crash) can be extremely useful to Cisco tech support in diagnosing a crash and possibly detecting that an attack was the root cause.

How

Discuss how the router handles core dumps with the network administrator. The core dumps should be located in a protected area that is accessible only to network administrator because disclosure of important information could occur. You might review the configuration file for something similar to the following. Note that TFTP and RCP also may be options here, but FTP is recommended.

exception protocol ftp
exception dump <ip address of server>
ftp username <username>
ftp password <password>
Note

Note that core dumps will cause the router to take longer to reboot after a crash because of the time it takes to dump the core file to the server.

3 Verify that all routing updates are authenticated.

Authentication ensures that the receiving router incorporates into its tables only the route information that the trusted sending router actually intended to send. It prevents a legitimate router from accepting and then employing unauthorized, malicious, or corrupted routing tables that would compromise the security or availability of the network. Such a compromise might lead to rerouting traffic, a denial of service, or simply giving access to certain packets of data to an unauthorized person.

How

The authentication of routing advertisements is available with RIPv2, OSPF, IS-IS, EIGRP, and BGP. Most allow the use of plaintext authentication or an MD5 hash. The MD5 method should be used to prevent passwords from being sniffed.

RIPv2 authentication is configured on a per-interface basis. Look in the configuration file for something like this:

router rip
version 2
key chain name_of_keychain
key 1
key-string string
interface ethernet 0
ip rip authentication key-chain name_of_keychain
ip rip authentication mode md5

OSPF authentication is configured on a per-area basis with keys additionally specified per interface. Look in the configuration file for something like this:

router ospf 1
area 0 authentication message-digest
interface ethernet 0
ip ospf message-digest-key 1 md5 authentication_key

BGP authentication is configured on a per-neighbor basis. Look in the configuration file for something like this (MD5 is the only option, so it does not need to be specified):

router bgp 1
neighbor ip_address or peer_group_name password password

4 Verify that IP source routing and IP directed broadcasts are disabled.

IP source routing allows the sender of an IP packet to control the route of the packet to the destination, and IP directed broadcasts allow the network to be used as an unwitting tool in a Smurf or Fraggle attack.

How

Discuss the router configuration with the network administrator. An example configuration for disabling IP source routing might look something like this for Cisco routers:

no ip source-route

You should see the following on each interface in the configuration file for Cisco routers to disable IP directed broadcasts:

no ip directed-broadcast


Additional Firewall Controls

The following are additional controls for firewalls. Note that some of these controls might be handled by a router in conjunction with a firewall, but a router by itself is a poor firewall for the perimeter of a corporate network.

1 Verify that all packets are denied by default.

All packets on a firewall should be denied except for packets coming from and headed to addresses and ports that are all explicitly defined. This is a much stronger defensive position than trying to keep track of what rules you have set up to block each specific address or service. For example, external SNMP queries from outside your network targeted to a router inside your network would be denied by default if the only traffic you allowed into your DMZ was to a web server.

How

Verify with the firewall administrator that all packets are denied by default. Ask the administrator to show you in the configuration how this is set up.

2 Ensure that inappropriate internal and external IP addresses are filtered.

Traffic coming from the internal address space should not have external addresses. Likewise, traffic coming from outside the network should not have as the source address your internal network.

How

Verify with the help of the firewall administrator that all packets entering from the exterior with source IP addresses set up for internal networks are denied. Likewise, all packets coming from the interior with source IP addresses not set up for the interior should be denied. Additionally, firewalls should hide internal Domain Naming Service (DNS) information from external networks.


Tools and Technologies-Auditing Networking Equipment

Note

Automated tools can be quite harmful to production environments. Exercise care, and design the test in a manner that will not affect production systems.

These tools can be quite helpful and guide you toward parts of your configuration file that might need further review. A strong case could be made that new configuration files should be tested with good peer reviews and tools such as those listed below. Many general vulnerability scanners also test commonly exploited vulnerabilities for networking platforms.

  • Router Audit Tool (RAT): http://www.cisecurity.org

  • Firemon: http://www.securepassage.com

  • Wireshark (formally Ethereal): http://www.wireshark.org

  • Nmap: http://www.insecure.org

  • TeraTerm Pro: http://www.hp.vector.co.jp/authors/VA002416/teraterm.html

  • Top 100 Security Tools: http://www.sectools.org


Knowledge Base

  • Cisco documentation: http://www.cisco.com/univercd/home/home.htm

  • Cisco conventions: http://www.cisco.com/warp/public/459/techtip_conventions.html

  • IETF: http://www.ietf.org/

  • National Vulnerability Database: http://www.nvd.nist.gov

  • NSA Switch Guide: http://www.nsa.gov/snac/os/switch-guide-version1_01.pdf

  • NSA Router Guide: http://www.nsa.gov/snac/routers/C4-040R-02.pdf

  • Assigned port numbers, essential for reading access lists: http://www.iana.org/assignments/port-numbers

  • Valid but unassigned IP blocks: http://www.iana.org/assignments/ipv4-address-space

  • Original ISO OSI Standard: http://www.standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498-1_1994(E).zip


Master Checklists

General Network Equipment Audit Steps

These controls should be evaluated in addition to performing the specific steps in the following checklists as they apply. For example, if you were to audit a switch, router, or firewall, you would perform the steps in the following checklist and then additionally perform the steps under the appropriate checklist for switches, routers, or firewalls.

Checklist for Auditing Network Equipment

  1. qReview controls around developing and maintaining configurations.

  2. qEnsure that appropriate controls are in place for any vulnerabilities associated with the current software version. These controls might include software updates, configuration changes, or other compensating controls.

  3. qVerify that all unnecessary services are disabled.

  4. qEnsure that good SNMP management practices are followed.

  5. qReview and evaluate procedures for creating user accounts and ensuring that accounts are created only when there's a legitimate business need. Also review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

  6. qEnsure that appropriate password controls are used.

  7. qVerify that secure management protocols are used where possible.

  8. qEnsure that current backups exist for configuration files if applicable.

  9. qVerify that logging is enabled and sent to a centralized system.

  10. qEvaluate use of the Network Time Protocol (NTP).

  11. qVerify that a banner is configured to make all connecting users aware of the company's policy for use and monitoring.

  12. qEnsure that access controls are applied to the console port.

  13. qEnsure that all network equipment is stored in a secure location.

  14. qEnsure that a standard naming convention is used for all devices.

  15. qVerify that standard, documented processes exist for building network devices.

Auditing Layer 2 Devices-Additional Controls for Switches

These controls should be evaluated in addition to performing the general steps for auditing network equipment.

Checklist for Auditing Layer 2 Devices: Additional Controls for Switches

  1. qVerify that administrators avoid using VLAN 1.

  2. qEvaluate the use of trunk autonegotiation.

  3. qVerify that Spanning-Tree Protocol attack mitigation is enabled (BPDU Guard, Root Guard).

  4. qEvaluate the use of VLANs on the network.

  5. qDisable all unused ports, and put them in an unused VLAN.

  6. qEvaluate use of the VLAN Trunking Protocol (VTP) in the environment.

  7. qVerify that thresholds exist that limit broadcast/multicast traffic on ports.

Auditing Layer 3 Devices-Additional Controls for Routers

These controls should be evaluated in addition to performing the general steps for auditing network equipment.

Checklist for Auditing Layer 3 Devices: Additional Controls for Routers

  1. qVerify that inactive interfaces on the router are disabled.

  2. qEnsure that the router is configured to save all core dumps.

  3. qVerify that all routing updates are authenticated.

  4. qVerify that IP source routing and IP directed broadcasts are disabled.

Auditing Firewalls-Additional Controls

These controls should be evaluated in addition to performing the general steps for auditing network equipment.

Checklist for Auditing Firewalls: Additional Controls

  1. qVerify that all packets are denied by default.

  2. qEnsure that inappropriate internal and external IP addresses are filtered.


Chapter 6: Auditing Windows Operating Systems

Background

In the early 1990s, Microsoft and IBM worked jointly to develop OS/2, but the relation-ship turned sour. Microsoft and IBM split up and went separate directions, with Microsoft later releasing Windows NT in July 1993. Microsoft's server line as we know it today finds it roots in these humble beginnings. Windows NT was the professional version of the operating system targeting company and government organizations.

Windows NT created the foundation for the desktop market with Windows XP Home and Windows XP Professional. Windows XP Professional contains superior networking and security features over the Home edition and now is used widely.

The server market went from Windows NT to Windows Server 2000 in February 2000. April 2003 saw the introduction of Windows Server 2003, which then was replaced with Windows Server 2003 Release 2 in December 2005. Windows Vista and Longhorn are under development and will replace Windows XP and Windows Server 2003.

What this means for the auditor is that there are many versions of operating systems in most large environments. It's highly recommended to find the time to familiarize yourself with the operating systems in your particular situation. Not all utilities will work on all systems. In some situations, hosts exist on your networks that are no longer supported by Microsoft. Additional controls should be in place to protect these systems, such as technologies that prevent network attacks or malware propagation.

Significant background information is documented online covering the development of the Microsoft platform. For example, check out any search engine and type "Micro-soft History" into the search box. Select "Search," and you will find an abundance of information about the current and future development of the Windows platform.


Windows Auditing Basics

There are some key things that you need to know about auditing Windows that will make you more accurate and efficient. Remember that Windows is just a platform, and you have to consider the overlying applications that make use of the platform before you can bless off a machine as passing an audit. Take a look at Figure 6-1, which we like to use when teaching classes to hammer home this concept. Notice the applications across the top. The more applications you add to the platform, the more potential trouble areas you have as an auditor. Consider the other chapters in this book as a supplement to get you started in considering the challenges the other applications bring to the table. This concept is true for any platform, including Unix, Solaris, Mac, and others. If you understand this concept, then you understand why an external security scanner cannot see everything you need to check for without logging onto the host.

Image from book
Figure 6-1: Auditing hosts model.

Most Windows hosts in a company are part of a domain. This automatically suggests there are other attack vectors that can be exploited, intentionally or not, to access or violate the integrity of your host. For example, if an employee doesn't have access to the payroll server but he or she has domain administrator rights for the domain that the payroll server belongs to-and he or she has a bad day-oops!

There are mitigating controls for situations like this. This is part of your responsibility as an auditor to ensure that mitigating controls are in place. In this situation, removing the Domain Administrators group from the local Administrators group and adding an application-specific group will mitigate these types of implicit/inherited security permissions.

The point is to carefully consider the trust relationships implicitly and explicitly (indirect and direct) that affect your host. The scope of your audit may be just one host. But you may miss vulnerable avenues of attack if you blind yourself too much.

Consider scheduling some time on your calendar to finally learn what the tools listed below actually do. There are many more than what we present here. You might be surprised at how easy most of them are to use and how much more efficient you become because you know the shortcuts to getting just the information you want. As auditors, it's easy to get tied down into "knowing what you gotta know" to get the job done. Most administrators of any caliber actually enjoy showing others the ropes. You can be assured that if you show up to an administrator's office asking about an obscure tool, you'll get his or her attention, and one of you will walk away a little wiser for the visit.

Command-Line Tips

For those of you who are comfortable with the command line on a Unix-flavored host, you will appreciate installing Unix functionality with GnuWin32 utilities from http://www.gnuwin32.sourceforge.net. The benefit is that several utilities you miss such as ls, sed, grep, more, and cat now will work from your command line in Windows. You could also install Cygwin or other toolkits that provide similar functionality. It's also possible to create scripts based on these binaries to manipulate the text output from standard Windows utilities.

Note

If you like the command line and enjoy scripting, make sure to take advantage of the resources located in Microsoft's scripting center website. It is located at http://www.microsoft.com/technet/scriptcenter/default.mspx

Essential Command-Line Tools

There are several tools that should be in every administrator's back pocket, even beyond the scope of the extensive adminpak (Administrator's Pack) and reskit (Resource Kit) tools that Microsoft makes available. Some of these are listed below. Keep in mind that with today's complex networks and firewalls, not all these will work the way they did a few years ago. Test every tool in a lab environment prior to running them on a production network.

Microsoft has an outstanding built-in command-line help file available by typing HH "ntcmds.chm" at the command line (with the quotes exactly as shown). Type help cmd for general information about using the command line in Windows. The company has more information on its website. Search for "Command-Line Reference" using Google, and visit the first Microsoft website that comes up: http://www.microsoft.com/ resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr=true.

Note

The various tools discussed below can be powerful. More than likely you are going to be just fine installing and running the tools on your own personal machine. However, follow best practices. You should learn how these tools work on another computer off the network in a test environment prior to using them on your production network and systems. Often you can use VMWare or Virtual PC to do this.

Resource Kit Tools

The Resource Kit contains more than 120 different tools for administering systems, troubleshooting systems, managing Active Directory, configuring security features, and much more. You can download the Resource Kit tools from Microsoft's website. The quickest way to find these is to go to Google and type in "Microsoft Resource Kit Tools." Select and download the Windows Server 2003 version of the tools. Given time, you may find some of the tools from the old NT or 2000 reskits useful that are no longer carried in the Windows 2003 reskit. These are beyond this chapter's scope and will not be discussed here.

SysInternals Tools

The SysInternals tools quickly dissect the inner workings of the operating system and produce meaningful results. These are essential to help administrators manage servers. Download SysInternals tools from the website http://www.sysinternals.com.

Several organizations make the decision to include some of the pstools as part of the standard build for servers and clients. You should think out this decision carefully because it's not appropriate for all situations. For example, your DMZ servers and other bastion hosts should be stripped of everything that isn't necessary.

For auditing purposes, you can always load the tools you need into a folder on the server, open a command prompt, and go to that folder to run the tools from the command line.

Other Tools

There are many, many other tools available. Some of these are listed below and discussed in the different audit steps. A free tool at the time of this writing is the Windows Forensic Toolchest (WFT), written by Monty McDougal. This tool serves as a wrapper for command-line tools listed below or others you may want to add. It is currently part of the SANS forensic track. Download and learn more about it at http://www.foolmoon.net/security.

Common Commands

Table 6-1 presents a list of command-line tools used throughout this chapter.

Table 6-1: List of Common Commands Used in This Chapter
Tool | Description | Where to Get It
psinfo | List system information, including installed service packs, patches, applications, and drive information | http://www.sysinternals.com
Systeminfo | List system information | Native command
Pslist | List running processes | http://www.sysinternals.com
psservice | List all installed services | http://www.sysinternals.com
wscui.cpl | Brings up the Windows Security Center | Native command
Netsh | Display or modify network configuration | Native command
netstat | Provides network information | Native command
ps service | List service information | http://www.sysinternals.com
sc | Tool for talking with service controller | Native command
DumpSec | GUI and command-line "Swiss army knife" of the security settings | http://www.somarsoft.com
tcpview | GUI view of processes mapped to ports | http://www.sysinternals.com
procexp | Very powerful GUI process explorer | http://www.sysinternals.com
Fport | Command line view of processes mapped to ports | http://www.foundstone.com/knowledge/ proddesc/fport.html
schtasks | Lists scheduled tasks at the command line | Native command
bootcfg | Lists boot partition information | Native command
pendmoves | Lists file move operations scheduled for the next reboot | http://www.sysinternals.com
autoruns | Lists everything scheduled to start when your computer starts up. This is the GUI version. | http://www.sysinternals.com
autorunsc | Lists everything scheduled to start when your computer starts up. This is the command line version. | http://www.sysinternals.com
rsop.msc | Opens the resulting set of security policies on your host when run from the Start | Run box or command line | Native command
secpol.msc | Opens just the local computer policy | Native command
pwdump | Dumps Windows password hashes into a format usable by nearly all free and commercial password crackers | http://www.openwall.com/passwords

Server Administrative Tools

The Windows Server 2003 administrative tools (adminpak.exe) installs on Windows XP and Windows Server 2003. Most of the tools in the Adminpak are used for AD domain-specific administration. If the subject of the audit is part of the AD infrastructure, then these tools may be of use. The Adminpak allows administrators to perform remote server management functions and includes several great tools that are otherwise difficult to duplicate in functionality.

Note

You can easily add the Microsoft Windows Server 2003 administrative tools to your desktop or laptop computer. Just visit Google, type "Microsoft adminpak," and follow the link to Microsoft's downloads page for the Windows Server 2003 Administration Tools Pack. After downloading the .msi package onto your computer, you need to run the file to install the tools onto your system.


Performing the Audit

The keys to a successful audit of Windows servers or clients is to thoroughly review the host by itself and in conjunction with the many other possible connections that pass data to and from the host.

The following audit steps focus only on the host and do not cover extensive reviews of overlying applications or trust relationships with outside systems. Also not covered are data input and data output methods or their validity. You would cover these on a per-host basis using techniques and tools covered elsewhere in this book. The steps here are typical of many server audits and represent a good tradeoff between the number of risks covered and the amount of time it takes to review the host.

Note

The test steps in this chapter focus on testing the logical security of Windows boxes, as well as processes for maintaining and monitoring that security. However, there are other internal controls that are critical to the overall operations of a computing environment, such as physical security, disaster-recovery planning, backup processes, change management, capacity planning, and system monitoring. These topics are covered in Chapter 4 and should be included in your audit if they have not already been covered effectively in a separate data center or entity-level information technology (IT) controls audit.


Windows Server Test Steps

In an ideal world, you would audit your host against a set of policies and procedures. However, we don't live in an ideal world. Here is a recommended list of items to evaluate. From experience, we know that there are debates around auditing Windows. Can a Windows server be secured? What makes your steps better than some else's steps? The truth is that these steps have worked for several companies, and any auditing program you implement is only going to catch most of the things you could possibly examine.


Setup and General Controls

The following represents a check of the overall system setup and other general controls to ensure overall system compliance with your organization's policy. These are mostly general, high-level controls, such as making certain that the system runs company-provisioned firewall and antivirus programs.

1 Obtain the system information and service pack version and compare with policy requirements.

Policies were written and agreed to in order to make your environment more secure, easily manageable, and auditable. Double-check the basic configuration information to ensure that the host is in compliance with policy. Older operating systems increase the difficulty in managing the server and increase the scope of administrator responsibilities as he or she attempts to maintain control over disparate operating system (OS) versions. Maintaining standard builds and patch levels greatly simplifies the process of managing the servers.

How

You could find this information using built-in command-line tools, hunting through the graphical user interface (GUI), and searching the registry. However, two efficient ways to pull up this information include the SysInternals tool psinfo and the native tool systeminfo. Go to http//www.sysinternals.com and download the pstool package. Use psinfo to pull up this information, and then compare the results with your organization's policies and requirements.

Note

Download pstools from http://www.sysinternals.com/Utilities/PsTools. html. The tool psinfo is part of this set of tools. There are several tools from SysInternals that you may want to use for auditing your servers.

2 Determine if the server is running the company-provisioned firewall.

Failure to have a firewall subjects the client to network attacks from malware, attackers, and curious people.

How

Most of the time, a check of the processes on the system shows that the company-provisioned firewall is installed and running on the system. An easy way to script this check is to run the SysInternals tool pslist. Do this by running pslist <process name> on the system, and search for the appropriate running process by specifying the process you want to find.

Depending on the nature of your audit, you also might want to check the configuration of the firewall on the host. For many organizations the firewall is centrally managed and the same across all hosts.

If you are using the Windows firewall, then learn the netsh command set, which allows scripted output and changes to the firewall. Try running netsh firewall show config to see the overall configuration of the firewall on the host and whether the firewall is configured for particular adapters. Use netsh firewall show to see other available options for the netsh firewall tool.

3 Determine if the server is running a company-provisioned antivirus program.

Running different software other than company provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have antivirus protection may allow harmful code or hacking tools to run on the computer that violate company policy.

How

A visual check of the system tray shows that an antivirus program is installed and running on the system. As mentioned earlier, an easy way to script this check is to run pslist from SysInternals on the system and search for the running process.

pslist rtvscan
PsList 1.26 - Process Information Lister
Copyright (C) 1999-2004 Mark Russinovich
SysInternals - http://www.SysInternals.com
Process information for CA-CDAVIS:
Name        Pid Pri Thd Hnd Priv    CPU Time  Elapsed Time Rtvscan      244 8 53 569 26212  0:07:16.640  85:27:32.223

Depending on the nature of your audit, you also might want to check the configuration of the antivirus program on the host. For many organizations, the antivirus program is managed centrally and is the same across all hosts. One thing to be careful about with antivirus programs is the ability to exclude certain files or folders from monitoring. This is an easy way to get around the antivirus program.

4 Ensure that all approved patches are installed per your server management policy.

If all the OS and software patches are not installed, then widely known security holes could exist on the server.

How

Use psinfo -s to pull this information up for you, and then compare the results against the policies and requirements of your organization. You can use the psinfo output to compare with existing sms, patchlink, and other patch-management data. You also could compare the psinfo output with data from a vulnerability scanner, two of which are discussed below.

5 Determine if the server is running a company-provisioned patch-management solution.

Again, running different software other than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have a company-provisioned patch-management solution may prevent the server from receiving the latest patches, allowing harmful code or hacking tools to run on the computer.

How

A visual check of the processes in the task manager usually shows that the company-provisioned patch-management system for servers is installed and running on the system. For example, this may be evidenced by the existence of the process in the task manager or pslist. Some organizations like to enable automatic updates, which is also easily checked by looking for "Automatic Updates" in the Control Panel.

6 Review and verify startup information.

Rogue partitions, processes, or programs in violation of your policies sometimes may be found during system startup. Additionally, sometimes malware will make use of the next reboot to install kits deeper into the OS.

How

There are several utilities that can help to dissect what the next reboot will do to the system. We recommend using bootcfg, pendmoves, and autoruns(c).

The output of bootcfg reveals the partitions set in the boot.ini file. There are several ways to get this information, including reading the file, but this allows you to easily script the result. Each bootable OS will have a separate boot entry ID like this:

Boot Entries
------------
Boot entry ID:  1
OS Friendly Name: Windows Server 2003, Standard
Path:      multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
OS Load Options: /noexecute=optout /fastdetect

Run pendmoves by itself without any switches to understand what file moves are planned for the next system restart.

Autoruns is the GUI version of autoruns (c). When you use autoruns (c) from the command line, it might be easier to output it to a csv file with the -c switch and view the results inside Excel. It might be hard to appreciate the power of autoruns (c) until you use the GUI autoruns version to see the information it's capable of uncovering for you.


Review Services, Installed Applications, and Scheduled Tasks

7 Determine what services are enabled on the system, and validate their necessity with the system administrator. For necessary services, review and evaluate procedures for assessing vulnerabilities associated with those services and keeping them patched.

Whenever remote access is allowed (i.e., whenever a network service is enabled), it creates a new potential vector of attack, therefore increasing the risk of unauthorized entry into the system. Therefore, network services should be enabled only when there is a legitimate business need for them.

New security holes are discovered and communicated frequently to the Windows community (including potential attackers). If the system administrator is not aware of these alerts, and if he or she does not install security patches, well-known security holes could exist on the system, providing a vector for compromising the system.

Note

This is one of the most critical steps you will perform. Unnecessary and unsecured network services are the number one vector of attack on Windows servers. They are what will allow someone who has no business being on the system to gain access to the system and/or to disrupt the system. These steps go hand in hand with the vulnerability scanning performed later in the audit.

How

The results of the tools shown in Table 6-2 reveal key pieces of the internal operations of the host to help you to view what's happening on the system. Netstat reveals the active sockets on your computer listening for external communications. Psservice, sc, and DumpSec list the running services. Next, you can map the running services to the open ports using fport or tcpvcon. The last utility mentioned, procexp, is also capable of showing you much of this information but cannot be scripted. It is mentioned here because of its powerful capabilities and because it is free. This may seem like a lot of utilities, but it's worth taking the time to look through them to decide what information you need for your audit.

Table 6-2: Tools for Viewing Service Information
Tool | Description | Where to Get It
netstat | Provides network information | Native Windows command
psservice | List service information | http://www.sysinternals.com
sc | Native tool for talking with service controller | Native Windows command
DumpSec | GUI and command-line "Swiss army knife" of the security settings | http://www.somarsoft.com
tcpvcon | CLI view of processes mapped to ports | http://www.sysinternals.com
tcpview | GUI view of processes mapped to ports | http://www.sysinternals.com
procexp | Very powerful GUI process explorer | http://www.sysinternals.com
Fport | CLI view of processes mapped to ports | http://www.foundstone.com

You can use the native netstat command by typing netstat -an at the command line. Look for lines containing LISTEN or LISTENING. The host is available for incoming connections on these TCP and UDP ports. You can find a list of services using such tools as psservice.

Other utilities that map processes to port numbers include the built-in sc (try sc query type= service) command, Fport from foundstone, and tcpvcon from SysInternals. We recommend tcpvcon from SysInternals. The "Tools and Technology" section below has information on where to find these tools and more. You can run tasklist /svc if you want to quickly map existing process IDs to running services. If you want to know absolutely everything about a process, then download and run the SysInternals Process Explorer.

Once you have obtained a list of enabled services, talk through the list with the system administrator to understand the need for each service. Many services are enabled by default and therefore were not enabled consciously by the system administrator.

For any services that are not needed, encourage the administrators to disable them. The Microsoft snap-in for the management console can be launched by typing services.msc from the Run option on the Start menu.

The services listed in Table 6-3 probably should not be running unless necessary for other applications or legitimate business reasons.

Table 6-3: Unnecessary Services
Alerter | Network DDE
Application Layer Gateway Service | Network DDE DSDM
Clipbook | Print Spooler
Error Reporting Service | Routing and Remote Access
Fax Service | Telephony
IMAPI CD-Burning COM Service | Telnet
Indexing Service Wireless | Upload Manager
Intersite Messaging | Windows Audio
Windows Messenger Service | Windows Image Acquisition (WIA) Configuration
NetMeeting Remote Desktop Sharing |

8 Ensure that only approved applications are installed on the system per your server management policy.

It is critical for administrators to manage the application set that gets installed on their hosts.

  • Not all applications play well together.

  • Applications may have a dependency that's not installed.

  • More applications means more areas of potential compromise.

Unmanaged or unknown applications also may have configuration or coding issues that makes the server vulnerable to compromise. For example, a poorly managed application could be missing patches, allow access to a privileged process, or inadvertently create a covert channel for an unprivileged user.

How

Use the results from the output of psinfo -s. This output has information about the installed applications. Compare this with organizational policy, and discuss your findings with the administrator.

9 Ensure that only approved scheduled tasks are running.

Scheduled tasks can stay hidden for weeks until an administrator takes the time to view the running scheduled tasks on the host. Scheduled tasks created by malicious or unknowing sources could damage host or network resources.

How

Note that reading scheduled tasks from the command line doesn't show you what the task is really going to do. The task can be called anything an attacker wants to call it while setting it up. This being said, there is a way to view tasks from the command line using schtasks.

The current directory is C:\>
schtasks
TaskName  Next Run Time    Status
------------------------------ ---------------------- -----------
Malicious Task  12:27:00 PM, 5/19/2006

Note that running the old AT on the command line on this server doesn't list Malicious Task. Get in the habit of using schtasks to view tasks. If you really want to understand in-depth exactly what each task does, you need to open the properties of each task independently. From there, you also can see the target file and review several other settings. Manually go to Start | Control Panel | Scheduled Tasks, right click each task, and click on "Properties" in the popup menu.


Account Management and Password Controls

10 Review and evaluate procedures for creating user accounts and ensuring that accounts are created only when there's a legitimate business need. Also review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

If effective controls are not in place for providing and removing access to the server, it could result in unnecessary access to system resources. This, in turn, places the integrity and availability of the server at risk.

How

Interview the system administrator, and review account-creation procedures. This process should include some form of verification that the user has a legitimate need for access. Take a sample of accounts from the password file, and review evidence that they were approved properly prior to being created. Alternatively, take a sample of accounts from the password file, and validate their legitimacy by investigating and understanding the job function of the account owners.

Also review the process for removing accounts when access is no longer needed. This process could include an automated feed from the company's human resources (HR) system providing information on terminations and job changes. Or the process could include a periodic review and validation of active accounts by the system administrator and/or other knowledgeable managers. Obtain a sample of accounts from the password file, and verify that they are owned by active employees and that those employees' job positions have not changed since the account's creation.

11 Ensure that all users are created at the domain level and clearly annotated in the active directory. Each user should trace to a specific employee or team.

Most user accounts should be administered centrally by a domain controller, with the possible exception of accounts created on isolated systems that are not a member of a domain (e.g., some DMZs). This increases network security because account provisioning and deprovisioning can be controlled.

How

You can view the accounts by opening compmgmt.msc from the command line or with DumpSec using the following syntax:

DumpSec.exe /rpt=users /saveas=fixed /outfile=users.txt
Note

Download DumpSec from http://www.somarsoft.com. The same executable that launches the GUI is the one used from the command line. You can include DumpSec in a script by including the binary with your script when you run the script. Learn about the different command-line options by going to the help file under Help | Contents and selecting Command-Line options.

Discuss your findings with the administrator, and pay close attention to accounts that should exist outside the domain. The only accounts that should exist outside the domain are the built-in guest and administrator accounts unless required by an application.

12 Review and evaluate the use of groups, and determine the restrictiveness of their use.

Groups can greatly simplify the provisioning and deprovisioning process for adding or removing user access to systems as users join and leave a team. However, old members sometimes hang around inside a group when they leave a team.

How

Review the contents of the groups on the system for appropriate membership while you're looking through the accounts using the method in the preceding step. Remember, in an active directory environment, groups can be nested, and you need to check the membership of the nested groups. In general, this is a good time to investigate the use of shared accounts. Such accounts present risk in that you loose accountability for actions taken on the system. However, there are certain situations in which this is unavoidable, such as with certain software on a manufacturing floor. Organizations dealing with PCI or HIPAA should examine their use of shared accounts closely.

Additionally, ensure that the IT security team, investigations team, and appropriate support personnel have administrative access to the server. This may not pertain to all organizations, and there may be some exceptions. These should be placed into a group and not added as individual users to the server.

Note

Although mentioned previously, it bears repeating that it's common to have exception requests that document exceptions to policy. This is fine as long as the requests are documented with the specific accepted risks and the appropriate management sign-off on the request. Many large organizations require the highest levels of management to sign off on such requests to discourage exceptions to policy.

13 Review and evaluate the strength of system passwords.

If passwords on the system are easy to guess, it is more likely that an attacker will be able to break into that account, obtaining unauthorized access to the system and its resources. A key mitigating control for many organizations is the use of two-factor authentication.

How

All accounts should have passwords. The methods used to test these controls depend on the password-provisioning process and controls enabled on the servers and active directory. At a minimum, you should review system settings that provide password controls such as those mentioned in the next step.

There are several ways to retrieve and test Windows password hashes. However, be careful and play it safe. Password dump, or pwdump, is one commonly used tool to dump password hashes from systems (download information below). It works well, and you should take a look at it. However, even the latest version may have problems on your server, crashing your system. This has happened to organizations that tweaked the internals of the server. Test everything in a nonproduction environment first!

Note

You can download pwdump6 directly from http://www.foofus.net/fizzgig/ pwdump or visit http://www.openwall.com/passwords/microsoft-windows-nt-2000-xp-2003 for this and many other cracking utilities.

Perhaps the easiest way to get your SAM and SYSTEM files is to copy them from the C:\WINDOWS\repair directory. Select the files with the CTRL key pressed, and then drag them to another folder or USB drive with the CTRL key still pressed.

As for cracking the passwords, once you have the hashes, you can attempt cracking the passwords with one of the password crackers listed un Table 6-4. Several of them also will take the SAM and SYSTEM files as direct inputs, dump the hashes, and perform the crack.

Table 6-4: Common Password Crackers
Cracker | Cost | Comments
John | Free | Get it from http://www.openwall.com. It's a fast brute-force cracker. John supports dictionaries and is command line.
rcrack | Free | Code is originally from Zhu Shuanglei at http://www.antsight.com/zsl/rainbowcrack. Now it's built into a lot of tools such as Cain and Abel (http://www.oxid.it). You must find, generate, or buy tables.
Ophcrack | Free | It's sometimes buggy, but it's free and very quick. Comes with rainbow tables. It's located at http://www.ophcrack.sourceforge.net.
plain-text.info | Free | Located online at http://www.plain-text.info.
Proactive Password Auditor | $300-$2500 | Cost depends on number of user accounts. It's located at http://www.elcomsoft.com/ppa.html.
SAMInside | $40 | Located at http://www.insidepro.com. You need your own rainbow tables, but the program supports them.

14 Evaluate the use of password controls on the server, such as password aging, length, complexity, history, and lockout policies.

Password controls are essential to enforcing password complexity, length, age, and other factors that keep unauthorized users out of a system.

How

you'll find the account policies as they affect your system by typing rsop.msc at the command line. When the window opens, select Computer Configuration | Windows Settings | Account Policies. In general, verify that the policies listed in Table 6-5 are set in accordance with your local policies. Some common settings have been listed.

Table 6-5: Account Policies
Policy | Setting
Minimum password age | 1 day
Maximum password age | 90 -180 days
Minimum password length | 8 characters
Password complexity | Enabled
Password history | 10-20 passwords remembered
Store passwords using reversible encryption | Disabled, if possible, but really understand and test this before making this decision
Account lockout duration | 10-30 minutes
Account lockout threshold | 10-20 attempts
Reset account lockout after | 10-30 minutes

You might try using DumpSec to pull account policies, but make sure that it pulls the specific settings you want. DumpSec doesn't gather everything in Table 6-5.


Review User Rights and Security Options

15 Review and evaluate the use of user rights and security options assigned to the elements in the security policy settings.

The default installation of Windows Server 2003 has 39 user rights settings and 70 security options. These settings and options allow broad, sweeping, and powerful changes to how the host will behave under many different situations.

Note

Be very careful here. It is possible to lock yourself out, disable critical internal processes, and limit necessary functionality. It's strongly recommended that you thoroughly test any changes you make here in a test environment with any applications that may even possibly depend on the settings running on the system.

How

you'll find the security policies as they affect your system by typing rsop.msc or secpol.msc at the command line. After the GUI opens, select Computer Configuration | Windows Settings | Local Policies. Remember that you can export these settings by right clicking the folder icon and selecting "Export."

Evaluate the settings you have here with the policies you have for your organization. There are several guides suggesting recommended settings, including Microsoft's website, the built-in security templates, the Center for Information Security guides (http://www.cisecurity.org), and of course, SANS (http://www.sans.org). The bottom line here is that you need to decide what your organization is looking to accomplish and audit against these settings. If your organization isn't using these settings at all, then you should take the initiative to spearhead a project to look into these settings. Here are some common settings for both.

Common security options include

  • Renaming guest and administrator accounts

  • Disabling the guest account

  • Choosing not to display the last logged on user

  • Prompting the user to change the password before expiration

  • Refusing enumeration of SAM accounts and shares by anonymous

  • Refusing to store network credentials (Be careful with this!)

  • Changing local-area network (LAN) manager responses (Be careful with this!)

Common user rights assignments include

  • Changing who can access the computer across the network

  • Defining who can log on locally

  • Denying access to the computer from the network

  • Denying logon through terminal services

  • Defining who can take ownership of file or other objects


Network Security and Controls

16 Review and evaluate the use and need for remote access, including RAS connections, FTP, Telnet, SSH, VPN, and other methods.

Not all remote access technologies are created equally, and until encrypted networks become the standard, cleartext protocols should be eliminated where possible. Although newer equipment and savvy network administrators can help mitigate the risk of eavesdropping on network traffic, the real risk of catching that traffic still exists, especially on the same broadcast domain for the networking types.

Certain protocols such as FTP and Telnet transmit all information in cleartext, including User ID and password. This could allow someone to obtain this information by eavesdropping on the network. Cleartext communications should be minimized or eliminated. Nonessential remote access connections should be limited or eliminated. These two are commonsense security practices today. Exceptions should be limited to business-driven cases where senior management is willing to sign off on and formally accept the risk of cleartext and remote access.

Modems in particular, or RAS access, bypass corporate perimeter security (e.g., firewalls) and allow direct access to the machine from outside the network. They present significant risk to the security of the machine on which they reside and also may allow the modem user to access the rest of the network. Allowing dial-in modems to be placed on a production machine is usually a bad idea. It is almost always preferable to have access to a machine channeled through standard corporate external access mechanisms such as a virtual private network (VPN) or remote access server (RAS).

How

View the output of the services and port-mapping tools, and discuss these with the administrator. Ask the administrator about the remote access policies and the different methods of access. Question the need for any cleartext communications that aren't driven by business needs. There are cases where cleartext communications exist and are hard to remove because of a legacy application or the traffic just isn't that important. However, where possible, an encrypted protocol should be used instead. For Microsoft hosts, encrypted protocols include the Remote Desktop Protocol (RDP), Citrix (ICA protocol), SSH, and SSL among many others.

On a Windows server, you can find information about remote access by going to Start | Administrative Tools | Routing and Remote Access.

Note

The use of secure protocols is particularly important in a DMZ and other high-risk environments. The auditor may determine that they are of less importance on the internal network. However, it is still advisable to use secure protocols even on internal networks in order to minimize attacks from within.

17 Ensure that a legal warning banner is displayed when connecting to the system.

A legal logon notice is a warning displayed whenever someone attempts to connect to the system. This warning should be displayed prior to actual login and basically should say, "you're not allowed to use this system unless you've been authorized to do so." Verbiage of this sort may be needed to prosecute attackers in court.

How

Log into your account using each available service that provides access, such as remote desktop, Telnet, and SSH. Determine whether a warning banner is displayed. Interview the system administrator to determine whether the verbiage for this warning banner has been developed in conjunction with the company's legal department.

18 Look for and evaluate the use of shares on the host.

Inappropriate or open shares may needlessly compromise personal or company data. You need to identify all shares, shared directories, and permissions. For example, it's not uncommon to find open shares on a network with personal, group ranking, or payroll information. These data never should be kept on an open share.

How

Use the Microsoft Management Console (MMC) snap-in under Start | Administrative Tools or by typing compmgmt.msc at the command line. When the MMC opens, go to Computer Management | System Tools | Shared Folders to view open shares, sessions, and files.

Alternatively, you can script this with DumpSec. The first command lists the shares, and the second lists the shared directories. You still should verify the share permissions manually, especially for manually created shares.

DumpSec.exe /rpt=shares /saveas=fixed /outfile=TempFile01 DumpSec.exe /rpt=allsharedirs /saveas=fixed /outfile=TempFile02

You also can view a list of shares by running the command net share. You can view remotely opened files by running psfile from SysInternals or use the command net file. If you have a large set of shares on a server and want to spot check it for inappropriate content, consider indexing the shared volume using a tool such as dtSearch. After the indexing is completed, you can run instant searches across the entire volume. This tool is familiar to forensic examiners and built into several products. You can find out more about it at http://www.dtsearch.com.

For each share you find, determine if the permissions are appropriate. Disallow public shares where the NT authenticated users group has full control permissions.

19 Ensure that the server has auditing enabled per your policies or organization's practices.

Auditing provides evidence in the aftermath of an event and helps with troubleshooting issues on the host. Ideally, an event-correlation engine would filter and produce meaningful data for the system administrator. Until that day comes, it is important to have auditing enabled to provide a record for what happens on the host.

How

You should view your audit settings manually with the MMC Group Policy snap-in. If you want, you can export the settings by right clicking the folder icon that says "Audit Policy" and selecting "Export List." Our recommended settings are shown in Table 6-6.

Table 6-6: Audit Policies
Audit Policy | Audit Settings |
Audit account logon events | Success | Failure
Audit account management | Success | Failure
Audit directory service access | Not defined |
Audit logon events | Success | Failure
Audit object access | Not defined or failure |
Audit policy change | Success | Failure
Audit privilege use |  | Failure
Audit process tracking | Not defined |
Audit system events | Success | Failure

Only enable object access auditing if you know how to use this feature. If you do, then we suggest monitoring only as much as is necessary to meet your needs. You can quickly fill your logs and tax your system with meaningless overhead if this is misused.

You would use the following syntax for DumpSec at the command line:

DumpSec.exe /rpt=policy /saveas=fixed /outfile=policies.txt

20 Review and evaluate system administrator procedures for monitoring the state of security on the system.

If the system administrator doesn't monitor his or her systems for changes or regularly attempt discovering issues in his or her systems, security holes could exist, and security incidents could occur without his or her knowledge. By monitoring, we mean actively watching for issues (detection) and actively searching them out (finding vulnerabilities).

Monitoring also provides a snapshot of the current security level of the system (from a network services standpoint). The world of network vulnerabilities is an ever-changing one, and it is unrealistic to create a static audit program that will provide an up-to-date portrait of vulnerabilities that should be checked. Therefore, a scanning tool that is updated frequently is the most realistic mechanism for understanding the current security state of the machine. In addition, if the system administrator has a security patching process in place, this scan will provide at least some validation as to the effectiveness of that process.

How

Interview the system administrator and review any relevant documentation to get an understanding of security monitoring practices. There are numerous levels and methods of security monitoring that can be performed. They don't all need to be performed, but they should have some level of monitoring. The level of monitoring required should be consistent with the criticality of the system and the inherent risk of the environment (e.g., a web server in the DMZ should have more robust security monitoring than a print server on the internal network). The system administrator is responsible for monitoring his or her hosts for issues such as those you have been auditing for throughout the other audit steps in this chapter.

If security monitoring is performed, assess the frequency of the monitoring and the quality with which it is performed. Look for evidence that the security monitoring tools are actually used and acted on. Review recent results, and determine whether they were investigated and acted on. Leverage the results of the rest of the audit in performing this assessment. For example, if you found significant issues in an area they were supposedly monitoring, it might lead to questions as to the effectiveness of that monitoring.

Listed below are a few types of security monitoring to consider. You might have others, including external sources such as network security appliances.

Intrusion Detection

This is monitoring in order to detect unauthorized entry (or attempts at unauthorized entry) into the system. Baseline monitoring tools (e.g., Tripwire) can be used to detect changes to critical files, and log-monitoring tools can be used to detect suspicious activities via the system logs.

Intrusion Prevention

This is a type of monitoring that detects an attempted attack and stops the attack before it compromises the system. Examples include host IPS tools and network-based IPS tools.

Network Vulnerability Scanning

This is probably the most important type of security discovery or monitoring in most environments. These vulnerabilities can be exploited by anyone on the network. There are several great scanners on the market such as eEyes Retina and Tenable Network Security's Nessus scanner. Auditing a host with a scan for vulnerabilities enables you to see the host from the network's perspective, validates your findings, and may show you things that you didn't find. This is true for both Windows and Unix systems. Many of these companies offer free trial versions of the scanner prior to purchase. The Nes-sus scanner is practically free depending on your needs, but you need a Linux host on which to install the scanner. The Retina scanner is particularly easy to use for Windows users (Figure 6-2). Both have received positive reviews from industry peers. There are also several others out there on the market.

Image from book
Figure 6-2: Retina scanner.

See the "Tools and Technology" section below for information on potential network vulnerability-scanning tools. Even though many of these tools are designed to be non-disruptive and to not require access to the system, you always should inform the appropriate IT personnel (e.g., the system administrator, the network team, and IT security) that you plan to run the tool, receive their approval, and schedule with them execution of the tool. There is always a chance that the scanning tool will interact in an unexpected fashion with a port and cause a disruption, so it is important that others be aware of your activities. These tools almost always should be run in a "safe" (nondisruptive) mode in a production environment such that the tools do not attempt to exploit any vulnerabilities discovered. There may be rare occasions when you will want to run an actual exploit to get more accurate results, but this should be done only with buy-in from and coordination with the system owner and administrator.

Host-Based Vulnerability Scanning

This is scanning for vulnerabilities that would allow someone who's already on the system to escalate his or her privileges (e.g., exploit the "root" account), obtain inappropriate access to sensitive data (e.g., owing to poorly set file permissions), or disrupt the system. This type of scanning generally is more important on systems where there are many nonadministrative end users.

21 If you are auditing a larger environment (as opposed to one or two isolated systems), determine whether there is a standard build for new systems and whether that baseline has adequate security settings. Consider auditing a system freshly created from the baseline.

One of the best ways to propagate security throughout an environment is to ensure that new systems are built correctly before moving into testing or production.

How

Through interviews with the system administrator, determine the methodology used for building and deploying new systems. If a standard build is used, consider auditing a newly created system using the steps in this chapter. At the very least, consider structuring an approval process for new standard builds in which an auditor would look over the changes and perform a full audit of new images. This is a great way for the audit team to create a working relationship with the Windows server team.

22 Perform the steps from Chapter 4-Auditing Data Centers and Disaster Recovery as they pertain to the system you are auditing.

In addition to auditing the logical security of the system, it is important to ensure that appropriate physical controls and operations are in place to provide for system protection and availability.

How

Reference the steps from Chapter 4, and perform those that are relevant to the system being audited. For example, the following topics are likely to be pertinent:

  • Asset inventory

  • Physical security

  • Environmental controls

  • Capacity planning

  • Change management

  • System monitoring

  • Backup processes

  • Disaster recovery planning

How to Perform a Simplified Audit of a Windows Client

The following steps provide a very quick way to verify the image used for provisioning new computers to the end user. This isn't designed to cover or catch everything, only to give the auditor a "warm, fuzzy feeling" that the clients are following policy properly. These checks lean heavily on the Microsoft Baseline Security Analyzer and your external scanner of choice. If you would like a more comprehensive view of the system, you can perform many of the steps in the preceding section pertaining to servers.

Determine the following steps using a freshly built computer and through interviews with a local technician responsible for provisioning new computers.

1 Determine if the client is running the company-provisioned firewall.

Running different software than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have a firewall subjects the client to network attacks from malware, attackers, and curious people.

How

Most of the time, a visual check of the processes in the task manager shows that the company-provisioned firewall is installed and running on the system. An easy way to script this check is to run pslist from SysInternals on the system and search for the service you're looking for. See the same step executed for servers in the preceding section for more information.

If you are using the Windows firewall, then learn the netsh command set, which allows scripted output and changes to the firewall. Try running netsh firewall show config to see the overall configuration of the firewall on the host and whether the firewall is configured for particular adapters. Use netsh firewall show to see other available options for the netsh firewall tool.

2 Determine if the client is running a company-provisioned antivirus program.

Running different software than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have anti-virus software may allow harmful code or hacking tools to run on the computer that violate company policy.

How

A visual check of the system tray shows that antivirus software is installed and running on the system. As mentioned earlier, an easy way to script this check is to run pslist from SysInternals on the system and search for the specific running process. Be wary of customized configurations such as excluding directories and files from normal protections offered by the antivirus software.

3 Determine if the client is running a company-provisioned patch-management solution.

Again, running different software than company-provisioned software may cause instabilities in the enterprise software environment on the laptop or desktop. Failure to have a company-provisioned patch-management solution may prevent the client from receiving the latest patches, allowing harmful code or hacking tools to run on the computer.

How

A visual check of the processes in the task manager usually shows that the company-provisioned patch-management system for client computers is installed and running on the system. For example, this may be evidenced by the existence of the process in the task manager or pslist. Some organizations like to enable automatic updates, which is also easily checked by looking for Automatic Updates in the Control Panel.

4 Determine if the client is equipped with the minimum recommended service pack, hotfixes, and software.

Failure to have the latest hotfixes and service pack as recommended by Microsoft or other software vendors you use in your environment may allow harmful code to run on the computer or prevent legitimate software from working properly.

How

Perhaps the easiest way to check this is with the utility psinfo. This utility has several powerful switches that allow for checking for installed software or hotfixes and then outputting the information into a comma-separated file that opens nicely in Excel. Keep in mind that the pstools, psinfo included, are designed to be run remotely to manage hosts across the network. The options allow for checking against all computers in the local domain, in a file, or on a single host. The following is a partial output of psinfo:

The current directory is C:\PERL> psinfo
PsInfo v1.73 - Local and remote system information viewer Copyright (C) 2001-2005 Mark Russinovich SysInternals - http://www.SysInternals.com
System information for \\CA-CDAVIS:
Uptime: 0 days 10 hours 42 minutes 25 seconds
Kernel version: Microsoft Windows XP, Multiprocessor Free
Product type: Professional
Product version: 5.1
Service pack: 2
Kernel build number: 2600
Registered organization:
Registered owner: Christopher Davis
Install date: 4/19/2006, 1:57:31 PM
IE version: 6.0000

5 Ensure that the client has all the following according to the Microsoft Baseline Security Analyzer (MBSA).

The MBSA does a great job auditing a single host quickly for some of the more grievous errors we commit as administrators. For example, we know that incomplete patch installations may cause instabilities in the enterprise software environment on the laptop or desktop. MBSA will check for this and many other common mistakes, such as

  • Active accounts with blank or weak passwords. Blank and weak passwords create easy targets for attackers.

  • Using file systems older than NTFS. Older file systems are easier to compromise because they don't support granular file permissions.

  • Autologin enabled. Autologin allows attackers to easily boot directly into the computer.

  • Guest accounts enabled. Guest accounts usually have weak passwords and are easily compromised.

  • Anonymous access. Anonymous access allows attackers to access and profile the computer without an audit trail.

  • Logon auditing. When enabled, logon auditing provides an audit trail of who has attempted to log onto the computer.

  • IIS enabled. IIS is complicated to correctly configure securely, and there are always some users who don't take the time to do this even if they know they should.

How

Consult the results of the MBSA scan for these and other common errors. You should get back results stating that

  • No incomplete software update installations were found.

  • No users have blank or simple passwords.

  • All hard drives are using the NTFS file system.

  • Autologin is not configured on the computer.

  • Guest account is disabled on the computer.

  • Computer is properly restricting anonymous access.

  • Logon success and logon failure auditing are both enabled.

  • IIS is not running on the computer.

6 Scan the system using a commercial-grade network scanner.

Remotely scanning the computer allows you to have a more complete picture of the computer's possible avenues of compromise than just checking everything locally to the host.

How

There are several great scanners on the market such as eEyes Retina and Tenable Network Security's Nessus scanner. You need to scan your hosts. Auditing a host with a scan for vulnerabilities

  • Enables you to see the host from the network's perspective

  • Validates your findings

  • May show you issues that you didn't find during the onbox audit

This is true for both Windows and Unix systems. Many of these companies offer free trial versions of the scanner prior to purchase. The Nessus scanner is practically free depending on your needs, but you need a Linux host on which to install the scanner. The Retina scanner is particularly easy to use for Windows users. Both have received positive reviews from industry peers. There are also several others out there on the market.

7 Evaluate physical security controls during a walk-through.

Physical security controls are required usually according to some company policy, and just as important, they help to protect computers from easy physical compromise. There are three common areas for improving physical security inside the building:

  • Cable locks should be used on laptops.

  • Users should be logged out of their workstations.

  • Passwords should not be written down anywhere.

How

Conduct a random walk-through of the work site once during working hours and once after working hours. During the walk-through, observe the use of cable locks, users logged out of their workstations, and whether or not passwords are written down in plain site.

Cable locks may not be an issue if you have other controls in place, but most companies can relate to the occasional laptop walking off the job site. Cable locks are cheap and a great deterrent to "honest thieves."

Users should show the company some love and log out of their workstations using [Windows] + [L]. This key combination quickly locks the computer and prevents others from walking behind you and using your privileges.

Users quite often write down passwords and place them in readily available or obvious locations. There are too many stories of people who never intended to be dishonest, but then they couldn't resist the "open password" and got into trouble. Consider the use of second-factor authentication tokens or free utilities such as keepass (http://www.keepass.sourceforge.net) that store passwords inside an encrypted vault.


Tools and Technology

Several of the tools mentioned earlier are free and easily accessible. You are encouraged to download them and play with them on your personal machine, but be careful. Some of them are powerful and should be tested in the bulletproof superman testing network prior to use in a production environment. The purpose of Table 6-7 is to list in a shortened format some of the tools you might want to consider as you look further into auditing Windows.

Table 6-7: Tools and Technology-Auditing Windows
Resource | Location
Administration Tools Pack (adminpak) | Search for "Administration Tools Pack" at http://www.microsoft.com
Resource Kit Tools | Search for "Resource Kit Tools" at http://www.microsoft.com
SysInternals Tools | http://www.sysinternals.com
Retina Scanner | http://www.eeye.com
Nessus Scanner | http://www.nessus.org
Fport | http://www.foundstone.com/knowledge/proddesc/fport.html


Knowledge Base

Here is where you can find more information. We can't discuss everything here, but we can point to other places where others discuss more than a reader could possibly want to know.

  • http://www.technet.com

  • http://www.cisecurity.org

  • http://www.csrc.nist.gov/

  • http://www.sysinternals.com/

  • http://www.ss64.com

  • Every auditor should read this concise rundown of important tips and tricks for Windows hosts: http://www.microsoft.com/technet/community/columns/profwin/ pw0902.mspx.

  • http://www.networkclue.com/os/Windows/commands/index.aspx

  • http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/ Admin/LaunchAdminToolsfromtheCommandLine.html

  • http://www.eeye.com

  • http://www.nessus.org

  • http://www.keepass.sourceforge.net

  • Learn about the Windows firewall: http://www.technet2.microsoft.com/WindowsServer/ en/Library/1033.mspx?mfr=true.


Master Checklists

The following tables summarize the steps listed earlier for auditing Windows servers and clients.

Auditing Windows Servers

Checklist for Auditing Windows Servers

  1. qObtain the system information and service pack version, and compare with policy requirements.

  2. qDetermine if the server is running the company-provisioned firewall.

  3. qDetermine if the server is running a company-provisioned antivirus program.

  4. qEnsure that all approved patches are installed per your server management policy.

  5. qDetermine if the server is running a company-provisioned patch-management solution.

  6. qReview and verify startup information.

  7. qDetermine what services are enabled on the system and validate their necessity with the system administrator. For necessary services, review and evaluate procedures for assessing vulnerabilities associated with those services and keeping them patched.

  8. qEnsure that only approved applications are installed on the system per your server management policy.

  9. qEnsure that only approved scheduled tasks are running.

  10. qReview and evaluate procedures for creating user accounts and ensuring that accounts are created only when there's a legitimate business need. Also review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

  11. qEnsure that all users are created at the domain level and clearly annotated in the active directory. Each user should trace to a specific employee or team.

  12. qReview and evaluate the use of groups, and determine the restrictiveness of their use.

  13. qReview and evaluate the strength of system passwords.

  14. qEvaluate the use of password controls on the server, such as password aging, length, complexity, history, and lockout policies.

  15. qReview and evaluate the use of user rights and security options assigned to the elements in the security policy settings.

  16. qReview and evaluate the use and need for remote access, including RAS connections, FTP, Telnet, SSH, VPN, and other methods.

  17. qEnsure that a legal warning banner is displayed when connecting to the system.

  18. qLook for and evaluate the use of shares on the host.

  19. qEnsure that the server has auditing enabled per your policies or organization's practices.

  20. qReview and evaluate system administrator procedures for monitoring the state of security on the system.

  21. qIf you are auditing a larger environment (as opposed to one or two isolated systems), determine whether there is a standard build for new systems and whether that baseline has adequate security settings. Consider auditing a system freshly created from the baseline.

  22. qPerform the steps from Chapter 4: Auditing Data Centers and Disaster Recovery as they pertain to the system you are auditing.

Auditing Windows Clients

Checklist for Auditing Windows Clients

  1. qDetermine if the client is running the company-provisioned firewall.

  2. qDetermine if the client is running a company-provisioned antivirus program.

  3. qDetermine if the client is running a company-provisioned patch-management solution.

  4. qDetermine if the client is equipped with the minimum recommended service pack, hotfixes, and software.

  5. qEnsure that the client has all the following according to the Microsoft Baseline Security Analyzer (MBSA).

  6. qScan the system using a commercial-grade network scanner.

  7. qEvaluate physical security controls during a walk-through.


Chapter 7: Auditing Unix and Linux Operating Systems

Background

Unix dates back to 1969, when it was developed by employees at AT&T for the purpose of providing a multiuser environment for running programs. Strong security was not one of the goals of its development.

In the late 1970s, students at Berkeley made extensive modifications to the AT&T Unix system, resulting in the Berkeley Software Distribution (BSD) Unix variant. This variant became very popular in academic circles. Around the same time, AT&T began a push to develop its Unix operating system into a legitimate commercial product, called AT&T System V (or often just System V).

During the 1980s, as commercial interest in the Unix operating system grew, companies faced the dilemma of deciding which of the two versions of Unix to adopt. Sun's SunOS and Digital Equipment Corporation's Ultrix were based on the Berkeley operating system. Other companies that tried to develop Unix, including Hewlett-Packard (HP), IBM, and Silicon Graphics, used System V as their standard. Microsoft developed a third version of Unix, called Xenix, and licensed it to Santa Cruz Operations (SCO). Xenix was based on a prior version of the AT&T Unix operating system.

All these versions of Unix obviously resulted in confusion in the industry and frustration for vendors who were attempting to develop software for use on Unix-based platforms. This resulted in the merging of some versions, beginning with Xenix and AT&T's System V in 1988. Next was a merger of AT&T and Sun's versions, called System V Release 4 (SVR4), which was to be compatible with programs written for either System V or BSD. Sun later named its proprietary version of this operating system Solaris. Not to be left out, a number of the other companies, such as IBM and HP, formed an organization called the Open Software Foundation (OSF), with the purpose of placing control of Unix in the hands of a not-for-profit group. The OSF operating system (OSF/1) was never adopted widely, and the individual companies continued to develop and use their own proprietary Unix variants, such as IBM's AIX, HP's HP-UX, SCO Unix, and IRIX.

Linux, a "Unix-like" operating system, came on the scene with a Usenet posting in 1991 by its author, Linus Torvalds. Strictly speaking, Linux is a kernel and not an operating system because what Torvalds developed was the piece that allows other programs to run. Most of these other programs that allow the system to be truly usable came from the GNU project. Hence many people prefer to refer to Linux as GNU/Linux when speaking of it as an entire operating system, but since this subject is a bit of a religious war, we won't go any further. From these humble, hobbyist beginnings in 1991, Linux grew to a 1.0 release in 1994 and then to the current stable branch (2.6) released in December 2003. Even before the 1.0 release, a number of Linux "distributions" were developed, combining the Linux kernel with applications and system utilities. Some examples of today's popular distributions are RedHat, Debian, Suse, and Gentoo. While many aspects of all Linux distributions will be identical or very similar, there will be some differences as well, such as package management and the init system. Support models differ as well, and when you pay for a Linux distribution, you're typically paying for the support because the software itself is free. This free software, combined with the ability to run on generic hardware, has made Linux a compelling choice for both business and personal computing needs.

Note

As can be seen from this history, there are many variations on the Unix and Linux operating systems. Although the information and concepts in this chapter are generic and applicable to all versions, it would take more space than is feasible to note the nuances for each *nix version. This chapter therefore focuses on Solaris (Unix) and RedHat (Linux), where version-specific commands and examples are required.


Getting Around

If you are new to the Unix world, it is helpful to obtain access to a Unix/Linux system while reading through this section. Try the commands out for yourself to become familiar with them.

Windows users can easily turn their machine into a Linux system without altering their Windows file system. Just download and burn one of the many bootable Linux CDs, such as the popular Knoppix (http://www.knoppix.org/), and boot into a full-featured Linux distribution. If you have a spare PC to work with, then consider visiting http://www.distrowatch.com and selecting "Major Distributions." you'll find a wealth of information about the various free distributions available there.

Note

When you're learning these commands, remember that you can access help at any time by typing man <command name> for comprehensive help or <commandname> --help for abbreviated help.

File System Layout, Navigation, and Permissions

The file system can be thought of as a tree, and the base of every tree is its root. So the root directory, designated "/," is the base from which other directories branch off. Every Unix system will have a root directory, but there will be some variance in what you find from there. Table 7-1 lists some common directories that you usually will find.

Table 7-1: Common Unix and Linux Directories
Directory | Description
/bin | Location of most of the system binaries (programs)
/sbin | Contains binaries that are reserved for use by privileged accounts
/etc | Contains system configuration files
/boot | Contains location of the kernel in many systems
/home | Typical location for user home directories
/var | Contains information that programs need to keep track of as they run (such as the process ID on the system); usually contains log files as well
/lib | System and application libraries; these aren't executed directly but are used by applications as they run.
/opt | Many add-on packages will be installed here.
/usr | Another place for user-added packages; often /usr will duplicate many of the top-level directories within itself, so you'll have /usr/etc, /usr/bin, etc. Documentation is often placed into /usr/share.
/root | The home directory for the root account is often here.
/tmp | Temporary directory that any user typically can access; often this is cleared when the system is booted.
/mnt | Remote file systems may be mounted under this directory.
/dev | Represents the concept that everything is a file; hence you will find device files in this directory representing the hardware in your system.
/proc | This pseudo-file system doesn't exist on a physical disk, but it contains memory-resident information about both the processes running on a system and the system itself.

There are some essential commands for navigating Linux and Unix file systems. These allow users at the command prompt to get their jobs done. The most essential commands are illustrated in Table 7-2 along with some common and helpful switches.

Table 7-2: Common Linux and Unix Navigation Commands
Command | Meaning | Description | Tips for Use
cd | Change directory | This command allows you to change your directory location like you would from the windows command prompt. | cd~ Change directory to user's home: . signifies current directory .. signifies parent directory
ls | List directory contents | Lists the contents of a directory along with information such as ownership, permissions, file size, etc. when used with the -l option. | ls -l uses long listing format for the files within the directory. ls -ld provides the long listing format for the directory itself. ls -a lists all directory contents including hidden files. ls -R provides a recursive directory listing.
pwd | Print working directory | This prints the current working directory to the screen. | Use this command when you copy screen output for an audit to show someone reviewing your work paper where you are on the system.
more cat less | List file contents | Lists the contents of a file. | cat displays all the file's contents at once. more displays the file's contents one page at a time. less displays the file's contents one page at a time and allows backward navigation.
ypcat | List NIS file contents | Lists the contents of a centralized NIS file. | Use this command if you're using NIS for centralized account management in order to display the contents of the NIS password and group files.
su | Switch user | Allows a user to switch to another user ID. | This only works if you have "root" access or if you know the password of the account to which you wish to switch.

Note that when navigating a *nix system, the presence or absence of the leading "/" in the path is very important and, if present, serves to anchor the path at the root directory. Thus, if you are currently in /usr, cd /bin and cd bin will take you to different places (/bin and /usr/bin, respectively). These are known as absolute or relative path names. The absolute path always starts with "/" and traces the entire path from the root directory. The relative path, with no leading "/," starts with the present directory.

File System Permissions

File and directory permissions are broken into separate user, group, and world permissions. Both files and directories have their own permission sets. You can see how this can get tricky, but remember that the most restrictive set of permissions wins every time. For example, if a file has world-read permissions but is restricted under its parent directory to disallow world-read permissions, then the world (meaning everyone) will not be able to read the file.

You will notice two ways these permissions are shown. Some places use three sets of rwx for read, write, and execute. The three sets are for the owner, group, and world. An example might be rwxr-xr--. This means that the file's owner has read, write, and execute permissions on the file, the owner's group has read and execute permissions, and everyone else has read permissions.

Other places use a three-digit number such as 754. This is identical to the rwxr-xr--and shown in Figure 7-1. For those who never studied binary numbers, just remember that read is worth 4 points, write is worth 2, and execute is worth 1. Add them up for each set (i.e., owner, group, and world), and you have your permissions. Thus 754 is a way to say, "I don't mind if other people read this file and if those in my group run this file, but only I should be able to modify it."

Image from book
Figure 7-1: Unix permissions.

Finally, it is important to note that file permissions are not completely independent of the permissions of the directory that contains the file. This interaction is illustrated in Table 7-3. For example, if you have rwx access to a file, but that file is sitting in a directory to which you have no access, then you will have no actual ability to do anything to the file.

Table 7-3: Interaction Between File and Directory Permissions
Directory Permissions (Across), File Permissions (Down)
 | - | r | x | wx
- | No access | No access | No access | Delete file
r | No access | No access | Read data | Delete file or read data
w | No access | No access | Add to or clear data | Delete file or add to or clear data
rw | No access | No access | Update data | Delete file or update data
x | Can't execute | Can't execute | Execute | Delete file or execute

Note that execute permissions on all parent directories back to "/" are required for operations on a file within that path. For example, permissions are 777 on a file in /home/andrew, but permissions in the andrew directory are 700. Nonroot users other than Andrew therefore will not be able to read or delete that file.

Users and Authentication

Access to a Unix system typically is controlled by means of a username and password. This authentication information may be kept on the local file system, or it may be kept in a central location on the network, where many systems can access the same information. In the simplest case, where all the information is local, we typically would consider three files, /etc/passwd, /etc/shadow, and /etc/group.

Unix Password File (Table 7-4)

Table 7-4: Components of a Unix Password File
Field | Use
Account | Represents the user to the system. It is the name that is used when logging in.
Password | Encrypted password, but note that it may be kept in /etc/shadow instead. This field may also contain an *, x, !, or other character.
UID | Numeric user ID.
GID | Numeric group ID for the user's primary group.
GECOS | Optional field used to store arbitrary additional information about the account. A typical use would be the real name and/or employee ID of the user.
Directory | Location of the user's home directory
Shell | User's default shell. The shell is the command-line environment that interprets commands and passes them to the kernel.

Lines in /etc/password have the format

account:password:UID:GID:GECOS:directory:shell

Unix Shadow File (Table 7-5)

Table 7-5: Components of a Unix Shadow File
Field | Use
Account | Name representing the user to the system.
Password | Encrypted password. *LK* indicates that the account is locked.
Lastchange | Number of days since the password was changed.
Min | Minimum number of days allowed between password changes.
Max | Maximum number of days allowed between password changes.
Warn | Number of days before Max, at which point the user will be warned that he or she needs to change his or her password
Inactive | Number of days of inactivity after which the user's account will be disabled.
Expired | Number of days since January 1, 1970. that the account has been disabled.
Reserved | An extra field that is not used.

Lines in /etc/shadow have the format

account:password:lastchange:min:max:warn:inactive:expired:reserved

Unix Group File (Table 7-6)

Table 7-6: Components of a Unix Group File
Field | Use
Name | Name of the group.
Password | Group password, if one is used.
GID | Numeric group ID.
Users | List of users who are members of the group, although members of the group who are assigned to it through their GID in /etc/password (see Table 7-4) won't necessarily be on this list.

Lines in /etc/group have the format

name:password:GID:users

LDAP, NIS, or NIS+

In more complicated cases, credentials can be checked against an authentication database located on the network; typically, this is LDAP, NIS, or NIS+. You may be able to determine if one of these is used in preliminary discussions with the system administra-tor, or you may wish to look at the systems yourself.

Determine whether NIS, NIS+, or LDAP is used by looking at the line beginning with passwd in /etc/nsswitch.conf. The presence of nis, nisplus, or ldap indicates use of those protocols. These typically will be present in addition to files, which is for the local password file. You also may see compat, which enables the use of "+" and "−" in the local password file for NIS/NIS+. If compat mode is used, then a "+" at the beginning of a line in /etc/passwd would indicate that NIS/NIS+ is being used. Review of the passwd_compat entry in /etc/nisswitch. conf should allow you to distinguish between the two. Note that local access only can show you everything you need to know about local Unix authentication. You may need more information to determine the effectiveness of a network authentication scheme such as NIS or LDAP. For these, you may wish to do a separate review of the given authentication infrastructure.

Network Services

To understand areas of potential risk in your environment, it is critical to know the avenues by which a system can be accessed. In order to do this, you need to be able to determine what network services are enabled on the system. Most systems will have the netstat command available to show you this information. The most generic usage would be netstat -an, and this will list a lot of information. Services running on Transmission Control Protocol (TCP) ports that are listening for external connections usually will say LISTEN in the output. Universal Data Ports (UDPs) may say IDLE on some systems such as Solaris. On Linux, look for UDP ports that have a listed Remote Address of 0.0.0.0. Once you have identified the open ports, you should determine what applications (often called a daemon) are running on them. You often can determine this by mapping the port to the list of well-known ports maintained by IANA at http://www.iana.org/assignments/port-numbers. However, you should be aware that just because TCP port 25 is supposed to be for SMTP, there's no reason you can't run a web server on that port instead. If there's any question, ask the system administrator. You also may wish to use some of the tools listed in the "Tools and Technology" section later in this chapter that can automate the process of identifying open ports and the applications running on them.


Test Steps

The following audit steps are divided into five sections:

  • Account management and password controls

  • File security and controls

  • Network security and controls

  • Audit logs

  • Security monitoring and other controls

Note

The test steps in this chapter focus on testing the logical security of Unix and Linux boxes, as well as processes for maintaining and monitoring that security. However, there are other internal controls that are critical to the overall operations of a Unix/Linux environment, such as physical security, disaster recovery planning, backup processes, change management, capacity planning, and system monitoring. These topics are covered in Chapter 4 and should be included in your audit of the Unix/Linux environment if they have not already been covered effectively in a separate data center or entity-level IT controls audit.

Account Management and Password Controls

Note

Most of the steps in this section require some form of testing over the system's password file. Prior to commencing work on these steps, the auditor should determine whether the system is using only its local password file (/etc/passwd) or it is also using some form of centralized account management such as NIS or LDAP. If the latter is true, then the auditor must execute the following steps on both the centralized password file and the local password file. The same concept applies for the steps that reference the group file.

In the "How" sections of the following steps, we will not attempt to specify the commands for every possible centralized account management system because there are a number of vendor-specific tools. We will include the details for pulling information from NIS, which is the most common of these systems, as an example. If your company uses a different tool, such as NIS+ or LDAP, you will need to work with your system administrator and review the documentation for these systems to determine the equivalent commands. However, the concepts described below for the local and NIS password and group files will apply.

1 Review and evaluate procedures for creating Unix or Linux user accounts and ensuring that accounts are created only when there's a legitimate business need. Also, review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

If effective controls are not in place for providing and removing access to the server, it could result in unnecessary access to system resources. This, in turn, places the integrity and the availability of the server at risk.

How

Interview the system administrators, and review account-creation procedures. This process should include some form of verification that the user has a legitimate need for access. Take a sample of accounts from the password file, and review evidence that they were approved properly prior to being created. Alternatively, take a sample of accounts from the password file, and validate their legitimacy by investigating and understanding the job function of the account owners.

Also review the process for removing accounts when access is no longer needed. This process could include an automated feed from the company's human resources (HR) system providing information on terminations and job changes. Or the process could include a periodic review and validation of active accounts by the system administrators and/or other knowledgeable managers. Obtain a sample of accounts from the password file, and verify that they are owned by active employees and that those employees' job positions have not changed since the account's creation.

2 Ensure that all userIDs in the password file(s) are unique.

If two users have the same userID (UID), they can fully access each other's files and can "kill" each other's processes. This is true even if they have different usernames. The UID is what the operating system uses to identify the user. It merely maps the username to the corresponding UID in the password file.

How

For local accounts, perform the command more /etc/passwd, and review the entries to ensure that there are no duplicate UIDs. If NIS is used, the command ypcat passwd also should be used so that NIS UIDs can be examined.

The following command will list any duplicate UIDs found in the local password file:

cat /etc/passwd | awk -F: ‘{print $3}’ | uniq -d

3 Ensure that passwords are shadowed and use strong hashes where possible.

In order for the system to function appropriately, the password file needs to be world readable. This means that if the encrypted passwords are contained within the file, every user on the system will have access to them. This, in turn, provides the ability for a user to copy the encrypted passwords and attempt to crack them via password-cracking tools that are freely available on the Internet. Given enough time, a brute-force cracking tool can guess even the most effective password. Consideration also should be given to the form of the passwords. The crypt routine traditionally used for Unix passwords is a relatively weak form of encryption by today's standards, and the maximum effective password length is eight characters. A better choice is to use MD5 hashes, which are harder to crack and allow more than eight characters for the password.

How

To determine whether a shadow password file is being used, perform a more /etc/ passwd command in order to view the file. Look within the password field for all accounts. If each account has an "*" or "x" or some other common character in it, the system uses a shadow password file. The shadow password file will be located at /etc/ shadow for most systems. Systems using NIS create some special problems that make the use of shadowed passwords more difficult, and older systems cannot shadow these passwords at all. If NIS is used in your environment, consult with the system administrator to discuss the possibilities of shadowing these passwords. If it is not possible to do so, then other password-related policies will need to be considered much more important.

MD5 is now the default hash on many Linux systems. The crypt form can be recognized because it is always 13 characters long; an MD5 hash in /etc/passwd or /etc/shadow will be prepended with the characters $1$ and is longer.

4 Evaluate the file permissions for the password and shadow password files.

If a user can alter the contents of these files, he or she will be able to add and delete users, change user passwords, or make himself or herself a superuser by changing his or her UID to 0. If a user can read the contents of the shadow password file, he or she will be able to copy the encrypted passwords and attempt to crack them.

How

View the file permissions for these files by performing the ls -l command on them. The /etc/passwd file should be writable only by "root," and the /etc/shadow file also should be readable only by "root."

5 Review and evaluate the strength of system passwords.

If passwords on the system are easy to guess, it is more likely that an attacker will be able to break into that account, thus obtaining unauthorized access to the system and its resources.

How

Review system settings that provide password composition controls. For Solaris systems, the password policy is usually set in /etc/default/passwd. Perform a more command on this file, and view the PASSLENGTH parameter in order to determine minimum password length. Compare the value of this parameter with your company's IT security policy. Most Linux systems have /etc/login.defs, which provides basic controls such as minimum password length and maximum password age for locally created accounts.

Unfortunately, the standard Unix passwd program does not provide strong capabilities for preventing weak passwords. It will prevent a user from choosing his or her username as a password but not much else. Through discussions with the system administrator, determine whether other tools have been implemented to either replace or enhance the native passwd functionality for password composition requirements. One stronger possibility is npasswd, a replacement for passwd. Npasswd is currently hosted at http://www.utexas.edu/cc/Unix/software/npasswd/. Additional controls also can be provided through PAM by the use of pam_cracklib, pam_passwdqc, or a similar module (pam_cracklib is included in many Linux distributions). Look for lines beginning with password in /etc/pam.conf or the configuration files in /etc/pam.d/ to get an idea of what's in use on the system you're auditing. Perform a more command on these files to view their contents.

Consider obtaining a copy of the password file and the shadow password file and executing a password-cracking tool against the encrypted passwords in order to identify weak passwords. See the "Tools and Technology" section later in this chapter for information on potential password-cracking tools. Judgment should be used in interpreting the results because a brute-force cracking tool eventually will crack any password if given enough time. If the password files have been shadowed, then you really only need to worry about truly weak passwords that are obvious and easy to guess. These sorts of passwords likely will be guessed within the first 30 to 60 minutes when running a password-cracking program.

On the other hand, if the password files have not been shadowed, you likely will want to run the program for much longer because anyone with access to the system will have the ability to do the same thing.

6 Evaluate the use of password controls such as aging.

It is important to change passwords periodically for two primary reasons. First, without aging, an attacker with a copy of the encrypted or hashed passwords will have an unlimited amount of time to perform an offline brute-force cracking attack. Second, someone who already has unauthorized access (though cracking or just password sharing) will be able to retain that access indefinitely.

How

Review system settings that provide password aging controls. For Solaris systems, the password policy is usually set in /etc/default/passwd. Perform a more command on this file and view the MAXWEEKS parameter in order to determine the maximum age for passwords and the MINWEEKS parameter in order to determine the minimum age for passwords. Minimum age is important to prevent a user from changing his or her password and then immediately changing it back to its previous value. View the settings of these parameters and compare them with your company's IT security policy.

Most Linux systems have /etc/login.defs, which provides basic controls such as minimum password length and maximum password age for locally created accounts. Additional controls can be provided through PAM by the use of pam_cracklib, pam_passwdqc, or a similar module (pam_cracklib is included in many Linux distributions). Look for lines beginning with password in /etc/pam.conf or the configuration files in /etc/pam.d/ to get an idea of what's in use on the system you're auditing. Perform a more command on these files to view their contents.

The "root" account generally will not be subject to automatic aging in order to prevent the possibility of the account being locked. However, there still should be a manual process for periodically changing the password in accordance with company policy. Review the process for changing this password, and look for evidence that this process is being followed.

7 Review the process used by the system administrator(s) for setting initial passwords for new users and communicating those passwords.

When new user accounts are created, the system administrator must assign an initial password to that user. If that password is easy to guess, it could allow the account to be hacked, resulting in unauthorized access to the server and its resources. If the initial password is not communicated via a secure channel, it could allow others to view the password and obtain unauthorized access to the account.

How

Interview the system administrator, and review documentation to understand the mechanism used for creating initial passwords. Ensure that this mechanism results in passwords that are difficult to guess and comply with your company's IT security policy.

Also, review the channels used for communicating the new passwords to users. Ensure that unencrypted transmissions are not used. Finally, it is often a good idea for the user to be required to change his or her password immediately on first login. Interview the system administrator to determine whether or not this is done. Accounts can be expired, thus forcing the user to change his or her password on the next login by the use of passwd -f on Solaris and passwd -e on Linux. These commands will expire a user's account immediately, forcing the user to change it on the next login. These are not items that can really be checked for, other than asking the system administrator how he or she does things.

8 Ensure that each account is associated with and can be traced easily to a specific employee.

If the owner of an account is not readily apparent, it will impede forensic investigations regarding inappropriate actions performed by that account. If multiple people use an account, there is no accountability for actions performed by that account.

How

Review the contents of the password file(s). The owner of each account should be obvious, with the user's name or other unique identifier (such as employee number) either used as the username or placed in the GECOS field. Question any accounts that seem to be shared, such as guest accounts. If accounts such as these are required, they should be configured with restricted shells and/or such that a user cannot directly log into them (thus requiring the user to log in as himself or herself first and then using su or sudo to access the shared account, creating an audit trail).

9 Ensure that invalid shells have been placed on all disabled accounts.

This is only a significant risk if trusted access is allowed (see the "Network Security and Controls" section). If trusted access is allowed, this means that a user with a certain username on one system (the trusted system) can log into an account with that same username on another system (the trusting system) without entering a password. This can be done as long as the user account on the trusting system has a valid shell defined to it, even though the account may have been disabled. Therefore, if a system administrator disables an account but leaves it with a valid shell, a user on a remote, trusted system with the same username still could access that account.

How

View the contents of the password files (via the more command). If an account has been disabled, it will have an "*," "*LK*," or something similar in the password field (remember to look in the shadow password file if it is being used). For those accounts, review the contents of the shell field. If it has anything besides /dev/null, /bin/false, or something similar, the account probably still can access a valid shell or program.

10 Review and evaluate access to superuser (root-level) access.

An account with root-level access has the ability to do anything with the system, including deleting all files and shutting the system down. Access to this ability should be minimized.

How

Review the contents of the password files, and identify all accounts with a UID of 0. Question the need for any account besides "root" to have a UID of 0. Determine via interviews who knows the passwords to these accounts, and evaluate the appropriateness of this list. If sudo is used, review the /etc/sudoers file to evaluate the ability of users to run commands as "root" with the sudo command. The sudo tool can be used to grant specific users the ability to run specific commands as if they were "root." This is generally preferable to giving users full root access.

The basic format of an entry in the sudoers file would look something like this:

Andrew     ALL=(root) /usr/bin/cat
Micah        ALL=(ALL) ALL

In this example, user Andrew would be allowed to run the command /usr/bin/cat as the user root on all systems, and user Micah would be allowed to run any command as any user on any system. There are, of course, many other options that will not be covered here. Consult the man page for sudoers for more information.

11 Review and evaluate the usage of groups and determine the restrictiveness of their usage.

This information will provide a foundation for evaluating file permissions in later steps. If all users are placed in one or two large groups, then group file permissions are not very useful. For example, if all users are part of one large group, then a file that allows group "write" permissions effectively allows world "write" permissions. However, if users are placed in selective, well-thought-out groups, group file permissions are effective controls.

How

Review the contents of the /etc/group, /etc/passwd, and related centralized files (e.g., NIS) using the more (e.g., more /etc/passwd) and, for NIS, ypcat (e.g., ypcat passwd and ypcat group) commands.

Look at the password as well as the group files to get an idea of group assignments because user primary group assignments from the password file do not need to be relisted in the group file. In other words, if a user is assigned to the "users" group in the /etc/passwd file, there is no need to list him or her as a member of that group in the /etc/group file. Therefore, to obtain a full listing of all members of the "users" group, you must determine who was assigned to that group in the /etc/group file and also determine who was assigned to that group in the /etc/passwd file (along with any NIS, LDAP, etc. equivalents being used in your environment). It is important to note that a group does not need to be listed in the group file in order to exist. It is therefore necessary to identify all group IDs (GIDs) in the password file and determine the membership of those groups. If you rely on the group file to identify all groups on the system, you may not receive a complete picture.

12 Evaluate usage of passwords at the group level.

Group-level passwords allow people to become members of groups with which they are not associated. If a group has a password associated with it in the group file, then a user can use the newgrp <group name> command and will be prompted to enter that group's password. Once the password is entered correctly, the user will be given the rights and privileges of a member of that group for the duration of the session. There generally is little need for this functionality because users generally are just granted membership to whichever groups they need to access. Creating a group-level password just creates another vector of attack on the system by creating the opportunity for users to hack the group-level passwords and escalate their privileges.

How

Review the contents of the group file(s) by using more /etc/group for the local file and ypcat group for NIS. If the groups have anything besides a common character (such as an "*" or even nothing) in the password field (the second field for each entry), passwords are being used. If they are, speak to the system administrators to understand the purpose and value of using these group-level passwords, and review the process for restricting knowledge of these passwords.

To look for passwords in /etc/group, you could use this command in your audit script:

awk -F: '{if($2!="" && $2!="x" && $2!="*")print "A password is set for group "$1" in /etc/group\n"}' /etc/group

13 Review and evaluate the security of directories in the default path used by the system administrator when adding new users. Evaluate the usage of the "current directory" in the path.

A user's path contains a set of directories that are to be searched each time the user issues a command without typing the full pathname. For example, let's say the ls command on your system is located at /bin/ls. In order to execute this program and view the permissions in the /home directory, you could type /bin/ls /home. By typing in the exact location of the file, you are using the full pathname. However, we rarely do this. Instead, the norm is to type ls /home. In this case, the user's path is the mechanism for finding the file that is to be executed.

For example, let's say that your path looks like this:

/usr/bin:/usr/local/bin:/bin

This means that when you type in a command, the operating system will first look for a file by that name in /usr/bin. If the file doesn't exist there, it will next look in /usr/local/bin. If it still doesn't find a file by that name there, it will look in /bin. If it is still unsuccessful, then the command will fail. Thus, in our example, we have attempted to execute the ls command, which is located in /bin. The system will first see if there is a file called ls in the /usr/bin directory. Since there is not, it will look in the /usr/local/bin directory. Since the file is not there either, it will look in /bin. There is a file called ls in /bin on our system, so it will attempt to execute that file. If the permissions on that file grant you execute permissions, you will be allowed to run the program.

Attackers who can write to a directory in a user's path can perform file name spoofing. For example, if the directory that contains the ls command is not secured, an attacker could replace the ls command with his or her own version. Alternatively, if the "current directory" (meaning whatever directory the user happens to be sitting in at the time the command is executed) or another unprotected directory is placed early in the user's path, the attacker could place his or her own version of the ls command in one of these and never have to touch the real ls command.

Because of all this, directories in the path should be user- or system-owned and should not be writable by the group or world.

A "." or an empty entry (a space) represents the "current directory," which means whatever directory the user happens to be sitting in at the time he or she executes a command. Since this is an unknown, it is generally safer to leave this out of the path. Otherwise, an attacker could trick a user or administrator into switching to a specific directory and then executing a common command, a malicious version of which could be located in that directory.

Each user has the ability to set his or her path in his or her initialization files. However, most users will never touch their path, and it is important for the system administrator to provide a default path that is secure.

How

The easiest way to view your own path is by typing echo $PATH at the command line. The default setting for users' paths may be found in /etc/default/login, /etc/ profile, or one of the files in /etc/skel. Ask the system administrator where the default setting is kept if you are unsure. If the user has modified his or her path, this typically will be done in one of the dot-files in the home directory. Look at the contents of such files as .login, .profile, .cshrc, .bash_login, etc. A quick way to look is to use the command grep "PATH=" .* in the user's home directory. A user's home directory can be determined by viewing his or her entry in the password file.

Once you know the name of the file that contains the path, view the contents of the file using the more command. The ls -ld command then can be performed on each directory in the path in order to view directory permissions. The directories should be writable only by the user and system accounts. Group and world write access should not be allowed (unless the group contains only system-level accounts).

14 Review and evaluate the security of directories in root's path. Evaluate the usage of the "current directory" in the path.

If a user can write to a directory in root's path, it is possible that he or she could perform file name spoofing and obtain access to the root account. See the immediately preceding step for further explanation of this concept.

How

Have the system administrator display root's path for you (using the echo $PATH command when logged in as root), and then review the permissions of each directory using the ls -ld command. All directories in root's path should be system-owned and should not be group or world writable (unless the group contains only system-level accounts such as bin and sys). The "current directory" generally should not be part of root's path.

The following will print the permissions of root's path (assuming that the script is executed as root) and warn if there is a "." in the path or if one of the directories is world writable:

#!/bin/sh
for i in 'echo $PATH | sed 's/:/\n/g'
do
if [ "$i" = . ]
then
echo -e "WARNING: PATH contains "."\n"
else
ls -ld $I
ls -ld $i | awk '{if(substr($1,9,1)=="w")print "\nWARNING - "$9" in root't path is
world writable"}'
fi
done

15 Review and evaluate the security of user home directories and configuration files. They generally should be writable only by the owner.

User config files basically are defined as any file located in the user's home directory that starts with a dot (.). These are commonly referred to as the user's dot-files. These files define the user's environment, and if a third party can modify them, this provides the ability to obtain privileged access to the account. For example, when a user first logs in, commands within his or her .login, .profile, .bashrc, etc. (depending on the shell) are executed. If an attacker is able to modify one of these files, he or she can insert whatever arbitrary commands he or she wishes, and the user will execute those commands the next time he or she logs in. For example, commands could be executed that copy the user's shell to another file and make it Set UID (SUID). The attacker then would be able to execute this new file and "become" that user. Access to these files also provides the ability to change the user's path or create malicious aliases for common commands by modifying these files. Other config files, such as .cshrc and .kshrc are executed at login, when a new shell is run, or when someone uses the su command to switch to the user's account. The ability to insert arbitrary commands into these files results in a similar risk as with the .login and .profile files.

Another config file that should be locked down is the .rhosts file. This file provides trusted access (access without the use of a password) to the user's account from specific accounts on specific other systems. A person who can modify this file can provide himself or herself with trusted access to the user's account.

Even though specific risks were not mentioned earlier for other dot-files, it is generally a good idea to keep them locked down. There is generally no legitimate reason that others should be modifying a user's config files.

Access to a user's home directory also should be locked down. If an attacker has write privileges to the directory, he or she will have the ability to delete any of the user's config files and replace them with his or her own versions.

How

The location of user home directories can be obtained from the account entries in the password file. The ls -ld command should be performed on each directory in order to view directory permissions. The ls -al command should be performed on each directory in order to view the permission on the files (including the config files) within the directory.

File Security and Controls

16. Evaluate the file permissions for a judgmental sample of critical files and their related directories.

If critical files are not protected properly, then the data within these files can be changed or deleted by inappropriate users. This can result in system disruption or unauthorized disclosure and alteration of proprietary information.

How

Using the ls -l command, examine the permissions on critical system files and their related directories. Generally, the most critical files within the Unix and Linux operating systems are those contained in the following directories:

  • /bin, /usr/bin, /sbin, /usr/sbin, and/or /usr/local/bin (programs that interpret commands and control such things as changing passwords)

  • /etc (files that contain such information as passwords, group memberships, and trusted hosts and files that control the execution of various daemons)

  • /usr or /var (contain various accounting logs)

Question the need for write access on these directories and the files contained therein to be granted to anyone besides system administration personnel.

In addition, there likely will be other critical data files (such as files containing key application data and company proprietary information) on the system you are auditing that should be secured. Interview the system administrator to help identify these.

For ease of use and in order to get a full picture of the file system, it may be best to have the system administrator run the ls -alR command against the entire file system and place the results in a file for you. You then can view the contents of this file in performing this and other steps. The system administrator must do this because the superuser is the only user who can access the contents of all directories.

There are several variations of what you might want to look for short of a full ls -alR. If, for example, you want to find all world-writable files (but excluding symlinks), use find / -perm +o=w ! -type l -print. Remember that man is your friend, and check the man pages to get more ideas on how you can use that command in your audit.

17 Look for open directories (directories with permission set to drwxrwxrwx) on the system and determine whether they should have the sticky bit set.

If a directory is open, anyone can delete files within the directory and replace them with their own files of the same name. This is sometimes appropriate for /tmp directories and other repositories for noncritical, transitory data; however, it is not advisable for most directories. By placing the sticky bit on the directory (setting permissions to drwxrwxrwt), only the owner of a file can delete it.

How

Examine directory permissions within the recursive file listing obtained from the preceding step, and search for open directories (in the listing of ls -alR, note that the directory permissions will be listed next to the "."). To find just directories with world-write permissions, you can use the command find / -type d -perm +o=w. For any such directories discovered, discuss the function of those directories with the system administrator, and determine the appropriateness of the open permissions.

18 Evaluate the security of all SUID files on the system, especially those that are SUID to "root."

SUID files allow users to execute them under the privileges of another UID. In other words, while that file is being executed, the operating system "pretends" that the user executing it has the privileges of the UID that owns the file. For example, every user needs the ability to update the password file in order to change passwords periodically. However, it would not be wise to set the file permissions of the password file to allow world-write access because doing so would give every user the ability to add, change, and delete accounts. Therefore, the passwd command was created in order to allow users to update their passwords without the ability to alter the rest of the password file. The passwd file is owned by "root" and has the SUID bit set (-rwsr-xr-x), meaning that when users execute it, they do so using the privileges of "root."

As can be seen, if an SUID file is writable by someone other than the owner, it may be possible for the owning account to be compromised. Other users could change the program being run to execute arbitrary commands under the file owner's UID. For example, a command could be inserted such that the owner's shell is copied to a file and made to be SUID. Then, when the attacker executed this copied shell, it would run as if it were the owner of the SUID file, allowing the attacker to execute any command using the privilege level of the captured account.

How

For Solaris and Linux, a full list of SUID files can be viewed by using the following command:

find / -perm -u+s

Note that the results of this command will not be complete unless it is run by someone with superuser access.

Review the file permissions for those programs, particularly for those that are SUID to root. They should be writable only by the owner.

Also question the need for any programs that are SUID to a user account. There should be little reason for one user to run a program as if he or she were another user. Most SUID programs are SUID to root or some other system or application account. If you see a program that is SUID to a user account, it is possible that this program is being used to capture that user's account.

19 Review and evaluate security over the kernel.

The kernel is the core of the operating system. If it can be altered or deleted, an attacker could destroy the entire system.

How

Perform the ls -l command on the location of the kernel for the system you are auditing. It should be owned and only writable by the superuser. There are a number of possible locations for the kernel. Some common kernel names are /unix (AIX), /stand/vmunix (HP), /vmunix (Tru64), /kernel/genunix (Solaris), and /boot/vmlinuz (Linux). Ask the system administrator for the location of the kernel on the system you are auditing.

20 Ensure that all files have a legal owner in the /etc/passwd file.

Each time a file is created, it is assigned an owner. If that owning account is subsequently deleted, the UID of that account still will be listed as the owner of the file unless ownership is transferred to a valid account. If another account is created later with that same UID, the owner of that account will, by definition, be given ownership of those files. For example, let's say that Grant (UID 226) creates the file /grant/file. UID 226 (Grant) is listed as the owner of this file. Grant then is fired, and his account is deleted. However, ownership of his file is not transferred. The operating system still considers UID 226 to be the owner of that file even though that UID no longer maps to a user in the password file. A few months later, Kate is hired and is assigned UID 226. The system now considers Kate to be the owner of the file /grant/file, and she has full privileges over it. If /grant/ file contains highly sensitive information, this could be a problem. In order to avoid this problem, before deleting an account, the system administrators should disposition all files owned by that account, either by deleting them or by transferring ownership.

How

Have the system administrator perform the quot command (which has to be run by the superuser). This command will show all file owners on the system. Review this list, and ensure that a username, and not a UID, is shown for every entry. If a UID appears, it means that there is no entry in the password file for that UID, which means that the password file could not convert the UID into a username. If a user is added later to the password file with that UID, that user would have ownership of these files.

Note

The quot command is not available on all versions of Unix and Linux. If this is the case, the output of a ls -alR command will need to be reviewed manually to see if any files do not list a valid username as the owner.

21 Ensure that the chown command cannot be used by users to compromise user accounts.

The chown command allows users to transfer ownership of their files to someone else. If a user can transfer an SUID file to another user, he or she then will be able to execute that file and "become" the user. For example, if a user copies his or her shell, makes it SUID and world executable, and then transfers ownership to "root," then, by executing that file, the user becomes "root."

How

Many versions of Unix only allow the superuser to execute chown. Many others do not allow SUID bits to be transferred to another user. In order to determine whether these controls are in place on the machine you are auditing, perform the following in order:

  1. Review the password file and determine where your shell is located (it probably will be something like /bin/csh or /usr/bin/sh).

  2. cp <shell file name> ~/myshell. This will create a copy of your shell file in your home directory.

  3. chmod 4777 ~/myshell. This will make your new shell file SUID and world executable.

  4. Choose another user from the password file to transfer ownership to, preferably a fellow auditor.

  5. chown <new owner name> ~/myshell. This will attempt to transfer ownership of the file to another user.

  6. ls -l ~/myshell. This will let you see whether you transferred ownership successfully and, if so, whether the SUID bit also transferred.

  7. If the SUID bit transferred to another owner, execute the file by typing ~/myshell. This will execute the shell.

  8. whoami. This should show that you are now the other user and have taken over his or her account.

  9. If this happens, the system administrator will need to contact his or her vendor for a fix.

22 Obtain and evaluate the default umask value for the server.

The umask determines what permissions new files and directories will have by default. If the default umask is not set properly, users could inadvertently be giving group and/or world access to their files and directories. The default should be for files to be created securely. Privileges then can be loosened based on need and conscious decisions by the users (as opposed to their being unaware that their new files and directories are not secure).

How

The default may be set in /etc/profile or in one of the files in /etc/skel. However, the easiest test is often just to view the umask value for your own account because this usually will be a representation of the default value for all new users. This can be done by using the umask command.

The umask basically subtracts privileges when files and directories are created using the modular format of file permissions and assuming that the default is for all files and directories to be created fully open (777 permissions). In other words, with a umask of 000, all new files and directories will be created with default permissions of 777 (777 minus 000), meaning full access for the owner, group, and world.

For example, if the umask is set to 027, it will result in the following default permissions for newly created files and directories:

Normal default | 777
Minus the umask | 027
Default permissions on this server | 750

This provides full access to the owner, read and execute access to the group, and no access to the world.

At a minimum, the default system generally should be set to a value of 027 (group write and all world access removed) or 037 (group write/execute and all world access removed).

23 Examine the system's crontabs, especially root's, for unusual or suspicious entries.

A cron executes a program at a preset time. It is basically the Unix or Linux system's native way of letting you schedule jobs. The crontab (short for cron table) contains all the crons scheduled on the system. Crons can be used to create time bombs or to compromise the owning account. For example, if an attacker managed to compromise a user's account, he or she could set up a cron that would, nightly, copy the user's shell and make it SUID and then delete this copy of the shell 15 minutes later. The attacker then could regain access to the account daily during that time period, but security-monitoring tools would not detect it unless the tools happened to run in that 15-minute window. An example of a time bomb would be in a case where a system administrator is fired or quits and schedules a cron to run 6 months later that crashes the system.

How

The crontabs should be located within directory /usr/spool/cron/crontabs or /var/spool/cron/crontabs. By performing the ls -l command on this directory, you will be able to list the contents. Each account with a crontab will have its own file in this directory. The contents of these files can be viewed with the more command. This will allow you to see the commands that are being executed and the schedule for that execution. Based on file permissions, you may need the administrator to display the contents of the crontabs. Also, depending on the level of your Unix knowledge, you may need the administrator's help in interpreting the contents of the files.

24 Review the security of the files referenced within crontab entries, particularly root's. Ensure that the entries refer to files that are owned by and writable only by the owner of the crontab. Also ensure that no crons are being run from open directories (permissions set to drwxrwxrwx).

All crons are run as if the owner of the crontab is running them, regardless of the owner of the file being executed. If someone besides the owner of the crontab can write to a file being executed by the crontab, it is possible for an unauthorized user to gain access to those accounts by altering the program being executed to cause the crontab owner to execute arbitrary commands (such as copying the cron owner's shell and making it SUID). For example, if root's crontab has an entry that executes the file /home/barry/flash, and that file is owned by "Barry," then "Barry" has the ability to add any command he wants to the flash file, causing "root" to execute that command the next time the cron is executed.

If a crontab is executing a file that is in an open directory, this would allow other users to delete the program being run and replace it with their own, again potentially resulting in the owner of the crontab executing arbitrary commands.

How

The contents of each user's crontab should be reviewed (see the preceding step for more information). The ls -l command should be performed on each file being executed in a crontab, and the ls -ld command should be executed for each of the directories containing those files.

25 Examine the system's scheduled atjobs for unusual or suspicious entries.

atjobs are one-time jobs that are scheduled to run some time in the future. They operate much like cron jobs (except that they are executed only once) and can be used to create time bombs.

How

The atjobs should be located within directory /usr/spool/cron/atjobs or /var /spool/cron/atjobs. By performing the ls -l command on this directory, you will be able to list the contents. The contents of these files can be viewed with the more command. This will allow you to see the commands that are being executed and the schedule for that execution. Based on file permissions, you may need the administrator to display the contents of the atjobs. Also, depending on the level of your Unix knowledge, you may need the administrator's help in interpreting the contents of the files.

Network Security and Controls

26. Determine what network services are enabled on the system, and validate their necessity with the system administrator. For necessary services, review and evaluate procedures for assessing vulnerabilities associated with those services and keeping them patched.

Whenever remote access is allowed (i.e., whenever a network service is enabled), it creates a new potential vector of attack, therefore increasing the risk of unauthorized entry into the system. Therefore, network services should be enabled only when there is a legitimate business need for them.

New security holes are discovered and communicated frequently to the Unix/Linux community (including potential attackers). If the system administrator is not aware of these alerts, and if he or she does not install security patches, well-known security holes could exist on the system, providing a vector for compromising the system.

Note

This is one of the most critical steps you will perform. Unnecessary and unsecured network services are the number one vector of attack on *nix servers. They are what will allow someone who has no business being on the system to either gain access to the system or disrupt the system.

How

Use the netstat -an command, and look for lines containing LISTEN or LISTENING. These are the TCP and UDP ports on which the host is available for incoming connections. If LSOF is present on the system (more common on Linux), then lsof -i can be used.

Once you have obtained a list of enabled services, talk through the list with the system administrator to understand the need for each service. Many services are enabled by default and therefore were not enabled consciously by the system administrator. For any services that are not needed, encourage the administrator to disable them.

Understand the process used to keep abreast of new vulnerabilities for enabled services and to receive and apply patches for removing those vulnerabilities. Common sources for vulnerability announcements include vendor notifications and Computer Emergency Response Team (CERT) notices. CERT covers the high-profile vulnerabilities, but you really should be getting notifications from your operating system (OS) and addon software vendors to ensure adequate coverage. Information on this process can be gathered via interviews and review of documentation.

If you need to validate a specific patch or package version, you can view installed packages and patches via the following commands:

  • Solaris: showrev -p will list the patches that have been applied; these can be cross-referenced with the patches listed in the security advisory from Sun.

  • Linux: rpm -q -a (Red Hat or other distributions using RPM) or dpkg --list (Debian and related distributions) will show the versions of installed packages.

Note that software can be installed outside the package-management system provided by the vendor, in which case these commands won't show you the requisite information. If you need to find the version of an executable, try running the command with the -v switch. In most cases, this will show you version information that you can compare with information in vulnerability notices.

A network scan of existing vulnerabilities also can be used to help validate the effectiveness of the patching process. See the next step for further details.

Consider the configuration of the services, not just whether they are allowed. The proper configuration of certain services such as NFS, anonymous FTP, and those that allow trusted access and root login are discussed later in this chapter. Space restrictions prevent us from detailing the proper configuration of every potential service (plus new vulnerabilities are discovered all the time). This is why the use of a network scanning tool is a critical component of an effective audit. Such a tool will keep up with and test for the latest vulnerabilities for you.

27 Execute a network vulnerability-scanning tool in order to check for current vulnerabilities in the environment.

This will provide a snapshot of the current security level of the system (from a network services standpoint). The world of network vulnerabilities is an ever-changing one, and it is unrealistic to create a static audit program that will provide an up-to-date portrait of vulnerabilities that should be checked. Therefore, a scanning tool that is updated frequently is the most realistic mechanism for understanding the current security state of the machine. In addition, if the system administrator has a security-patching process in place, this scan will provide validation as to the effectiveness of that process (or as to whether it is really being executed).

How

See the "Tools and Technology" section later in this chapter for information on potential network vulnerability-scanning tools. Even though many of these tools are designed to be nondisruptive and to not require access to the system, you always should inform the appropriate IT personnel (e.g., the system administrator, the network team, and IT security) that you plan to run the tool, receive their approval, and schedule with them the execution of the tool. There is always a chance that the scanning tool will interact in an unexpected fashion with a port and cause a disruption, so it is important that others be aware of your activities. These tools almost always should be run in a "safe" (nondis-ruptive) mode such that they do not attempt to exploit any vulnerabilities discovered. There may be rare occasions where you will want to run an actual exploit to get more accurate results, but this should be done only with buy-in from and coordination with the system owner and administrator.

28 Review and evaluate the usage of trusted access via the /etc/hosts.equiv file and user .rhosts files. Ensure that trusted access is not used or, if deemed to be absolutely necessary, is restricted to the extent possible.

Trusted access provides the ability for users to access the system remotely without the use of a password. Specifically, the /etc/hosts.equiv file creates trust relationships with specific machines, whereas the .rhosts file creates trust relationships with specific users on specific machines.

For example, if system "Trusting" has an /etc/hosts.equiv file that lists machine "Trusted" as a trusted host, then any user that has an account with the same username on both systems will be able to access "Trusting" (the trusting machine) from "Trusted" (the trusted machine) without the use of a password. Thus, if the username "Hal" exists on both machines, the owner of the "Hal" account on "Trusted" will be able to access the "Hal" account on "Trusting" without using a password. Keep in mind that the key is the account name. If John Jones has an account on both machines, but one has the account name "jjones" and the other has the account name "jjonzz," then the trust relationship won't work. The operating system won't acknowledge them as the same account.

The .rhosts files work similarly except that they are specific to a user. Each user can have a .rhosts file in his or her home directory that provides trusted access to his or her account. If username "Barry" on system "Trusting" has a .rhosts file in his or her home directory and that .rhosts file lists system "Trusted," then the "Barry" account on "Trusted" will be able to access the "Barry" account on "Trusting" without using a password. Alternatively, system and username pairs can be listed in the .rhosts file. The .rhosts file for "Barry" on "Trusting" could list username "Wally" on system "Trusted." This would mean that the "Wally" account on "Trusted" would be able to access the "Barry" account on "Trusting" without using a password.

If the system you are auditing has trust relationships with other machines, then the security of the trusting system depends on the security of the trusted system. If the accounts that are trusted can be compromised, then, by definition, the accounts on the system you are auditing will be compromised. This is so because access to the trusted machine provides access to the trusting machine. It is best to avoid this sort of dependency if at all possible. The first option should be to eliminate trusted access. If it becomes obvious to the auditor that this is not feasible in the environment, the steps in the "How" section below can be used to mitigate the risk.

Note

Trusted access works via the usage of the Berkeley "r" commands (e.g., rlogin, rsh, and rexec). These commands are designed to automatically look for trusted relationships via .rhosts and /etc/hosts.equiv files when executed. If a trusted relationship doesn't exist, these commands will require the entry of a password. If trusted relationships do exist, these commands will not require the entry of a password.
Note

If NIS is used, it is also possible to grant trusted access to specific netgroups (groups of usernames).

How

Examine the contents of the /etc/hosts.equiv file and any .rhosts files on the system. The contents of the /etc/hosts.equiv file can be viewed by using the more /etc/hosts.equiv command. To find .rhosts files, you will need to view the contents of each user's home directory via the ls -l command (the location of user home directories can be found in the password file) in order to see whether a .rhosts file exists. The contents of any .rhosts files found can be viewed by using the more command. If file permissions restrict you from viewing the contents of these files, you will need to have the system administrator perform these commands for you.

Discuss the contents of these files with the system administrator to understand the business need for each entry. Encourage the administrator to delete any unnecessary entries or preferably to eliminate the use of trusted access altogether.

Ensure that none of the files contain the "+" sign. This symbol defines all the systems on the network as trusted and enables them all to logon without using a password (if there is an equivalent username on the trusting server). If the "+" sign exists in the /etc/hosts.equiv file, then any user (except "root") on any system on the network who has the same username as any of the accounts on the trusting system will be able to access the account without using a password. If the "+" sign exists in a .rhosts file, then any user on any system on the network who has the same username as the owner of the .rhosts file will be able to access the account without using a password. This includes the "root" account, so a .rhosts file with a "+" in root's home directory is usually a particularly bad idea.

For any legitimate and necessary trust relationships, determine how the administrator is comfortable that each system to which trusted access is given is as secure as the system being audited. As mentioned earlier, the system's security depends on the security of any system being trusted. System administrators generally should not give trusted access to systems they do not control. If they do, they should take steps to obtain assurance as to the security and integrity of the systems being trusted either by performing their own security scans or by conducting interviews with the system administrator.

If trusted hosts are needed in the /etc/hosts.equiv file, ensure that trusted users are not specified in this file. In some versions of Unix, a trusted user specified in this file will be allowed to log into the system as any username (except "root") without entering a password.

If trusted access is allowed, usernames in the password files must be consistent across each system involved in the trusted relationship. Determine whether this is the case. If system2 trusts system1, then username "Bob" on system1 can log in as username "Bob" on system2 without entering a password. If "Bob" on system1 is Bob Feller, while "Bob" on system2 is Bobby Thompson, then Bobby Thompson's account now has been compromised.

Ensure that the /etc/hosts.equiv and .rhosts files are secured properly (using the ls -l command). The /etc/hosts.equiv file should be owned by a system account (such as "root") and writable only by that account. If others can write to this file, they could list unauthorized machines in the trusted hosts list. The .rhosts files should be owned by the account in whose home directory they sit and should be writable only by that account. If a user can write to another user's .rhosts file, he or she could make himself or herself, or someone else, trusted to log into that user's account from another machine.

Ensure that entries use the fully qualified domain name for systems being trusted (e.g., "http//www.rangers.mlb.com" instead of just "rangers"). An entry that does not use the fully qualified domain name could be spoofed by a machine with the same host name but different domain.

29 If anonymous FTP is enabled and genuinely needed, ensure that it is locked down properly.

Anonymous File Transfer Protocol (FTP) allows any user on the network to get files from or send files to restricted directories. It does not require the use of a password, making it important that it be controlled properly.

How

To determine whether anonymous FTP is enabled, examine the contents of the password file(s). If there is an "ftp" account in the password file and the FTP service is enabled, then anonymous FTP is available on the system. Once an anonymous FTP user has logged in, he or she is restricted to only those files and directories within the "ftp" account's home directory, which is specified in ftp's password entry (we'll assume that the home directory is at /ftp for this step). The "ftp" account should be disabled in the password file and should not have a valid shell.

Ensure that the FTP directory (e.g., /ftp) is owned and writable only by "root" and not by "ftp." When a user uses anonymous FTP, he or she becomes user "ftp." If "ftp" owns its own files and directories, anyone using anonymous FTP could alter the file permissions of anything owned by ftp. This can be determined by performing the ls -l command on the "ftp" home directory. "Ftp" should only own the /ftp/pub directory.

Examine the permissions of the /ftp directory and the subdirectories (by using the ls -l command).

  • The /ftp/pub directory should have the sticky bit set so that people cannot delete files in the directory.

  • The /ftp directory and its other subdirectories should be set with permissions at least as restrictive as dr-xr-xr-x so that users can't delete and replace files within the directories.

Ensure that the /ftp/etc/passwd file contains no user entries (just "ftp") or passwords (by performing the more command on the file). Otherwise, anyone on the network can see usernames on the server and use those for attacking the system. It should not allow group or world write permissions (ls -l /ftp/etc/passwd).

Other files outside of the /ftp/pub directory should not allow group or world write access (verify by using the ls -l command).

Attackers could transfer large files to the /ftp directories and fill up the file system (in order to commit a denial-of-service attack and/or prevent audit logs from being written). The system administrator should consider placing a file quota on the "ftp" user or placing the /ftp home directory on a separate file system.

30 If NFS is enabled and genuinely needed, ensure that it is secured properly.

Network File System (NFS) allows different computers to share files over the network. Basically, it allows directories that are physically located on one system (the NFS server) to be mounted by another machine (the NFS client) as if they were part of the client's file structure. If the directories are not exported in a secure manner, it can expose the integrity and availability of that data to unnecessary risks.

How

NFS use can be verified by examining the /etc/exports file or the /etc/dfs/dfstab file (using the more command). If this file shows that file systems are being exported, then NFS is enabled.

Because NFS authorizes users based on UID, UIDs on all NFS clients must be consistent. If Clark's account is UID 111 on the system being audited, but Bruce's account is UID 111 on an NFS client, then Bruce will have Clark's access level for any files that are exported (because the operating system will consider them to be the same user). After determining which systems can mount critical directories from the system you're auditing, you will need to work with the system administrator to determine how UIDs are kept consistent on those systems. This may involve obtaining a copy of each system's password file and comparing UIDs that appear in both the NFS server and an NFS client. Note: The same risk exists and should be investigated for GIDs.

Review the /etc/exports file or the /etc/dfs/dfstab file (using the more command):

  • Ask the system administrator to explain the need for each file system to be exported.

  • Ensure that the access= option is used on each file system being exported. Otherwise, any machine on the network will be able to access the exported file system. This option should be used to specify the hosts or netgroups that are allowed to access the file system.

  • Ensure that read-only access is given where possible using the "ro" option (note that read/write is the default access given if read-only is not specified).

  • Ensure that root access is not being given to NFS clients (i.e., the root= option is not being used) unless absolutely necessary and unless the NFS clients have the same system administrator as the server. The root= option allows remote superuser access for specified hosts.

  • Ensure that root accounts logging in from NFS clients are not allowed root access. You should not see anon=0, which would allow all NFS clients superuser access.

Review the contents of the /etc/fstab or the /etc/vfstab (or /etc/check-list for HP systems) file (using the more command) to see if the system you are auditing is importing any files via NFS. If it is, ensure that the files are being imported "nosuid." If SUID files are allowed, the NFS client could import a file that is owned by "root" and has permissions set to rwsr-xr-x. Then, when a user on the NFS client runs this program, it will be run as that client's superuser. The root user on the NFS server could have inserted malicious commands into the program, such as a command that creates a .rhosts file in the client "root" user's home directory. This .rhosts file then could be used by the NFS server to obtain unauthorized superuser access to the NFS client. Note: If the system administrator is the same on both the NFS client and the NFS server, this is not a big risk.

On all these NFS steps, the auditor should use judgment. The criticality of the files being exported should influence the scrutiny with which the auditor reviews them.

31 Review for the use of secure protocols.

Certain protocols (e.g., telnet, ftp, rsh, rlogin, and rcp) transmit all information in clear text, including userID and password. This could allow someone to obtain this information by eavesdropping on the network.

How

Review the list of services that are enabled and determine whether telnet, ftp, and/or the "r" commands are enabled. If so, via interviews with the system administrator, determine the possibility of disabling them and replacing them with secure (encrypted) alternatives. telnet, rsh, and rlogin can be replaced by SSH. ftp can be replaced by SFTP or SCP. rcp can be replaced by SCP.

Note

The use of secure protocols is particularly important in a DMZ and other high-risk environments. The auditor may determine that it is of less importance on the internal network. However, it is still advisable to use secure protocols even on internal networks in order to minimize attacks from within.

32 Review and evaluate the use of .netrc files.

.netrc files are used to automate logons. If a confidential password is placed in one of these files, the password may be exposed to other users on the system.

How

The following command can be used to find and print the contents of all .netrc files on the system. You likely will need to have the system administrator run this command to search the entire system.

find / -name ‘.netrc’ -print -exec more {} \;

For any .netrc files found, review the file contents. If read access is restricted, you will need the system administrator to do this for you. Look for indications of passwords being placed in these files. If so, review file permissions via the ls -l command, and ensure that no one besides the owner can "read" the file. Even if file permissions are locked down, anyone with superuser authority still will be able to read the file, so it's better to avoid using them at all. However, if they exist and are absolutely necessary, the auditor should ensure that they have been secured to the extent possible.

33 Ensure that a legal warning banner is displayed when connecting to the system.

A legal logon notice is a warning displayed whenever someone attempts to connect to a system. This warning should be displayed prior to actual login and basically should say, "you're not allowed to use this system unless you've been authorized to do so." Verbiage of this sort may be needed to prosecute attackers in court. Unfortunately, court rulings have dictated that you have to specifically tell someone not to hack your system or you can't prosecute them for doing so.

How

Login to your account using each available mechanism that provides shell access, such as telnet and SSH. Determine whether a warning banner is displayed. The text for this banner frequently is located in files such as /etc/issue and /etc/sshd_config (or /etc/openssh/sshd_config). Via interviews with the system administrator, determine whether the verbiage for this warning banner has been developed in conjunction with the company's legal department.

34 Review and evaluate the use of modems on the server.

Modems bypass corporate perimeter security (e.g., firewalls) and allow direct access to the machine from outside the network. They present significant risk to the security of the machine on which they reside and also may allow the modem user to "break out" of the machine being audited and access the rest of the network. Allowing dial-in modems to be placed on a production machine is usually a bad idea. It is almost always preferable to have access to a machine channeled through standard corporate external access mechanisms such as VPN or RAS.

How

Unfortunately, there is no reliable method of determining whether a modem is connected to a machine outside of physical inspection. If physical inspection is not practical, the next-best option will be to interview the system administrator to understand whether modems are used. As mentioned earlier, if they are used, alternate mechanisms for allowing external access to the machine should be investigated. If it is determined that a dial-in modem is truly necessary, consider implementing compensating controls such as dial-back to trusted numbers (i.e., when a call is received, the machine hangs up and dials back to a trusted number) and authentication.

Audit Logs

35. Review controls for preventing direct "root" logins.

Because a number of people usually know the "root" password, if people are allowed to login directly as that account, there is no accountability for actions performed by that account. If inappropriate actions are performed by the "root" account, there will be no way to trace those actions back to a specific user. It is preferable to force people to login as themselves first and then use su or sudo to access the "root" account.

How

Review the wtmp log (by performing the more command on /usr/adm/wtmp, /var/ adm/wtmp, or /etc/wtmp depending on the type of system) to verify that there are no direct "root" logins. The last command can be used to view the contents of this file on most systems. Exceptions would be direct logins from the console, which may be needed for emergencies.

Review settings for preventing direct "root" logins via telnet and rlogin.

  • The file /etc/default/login can be used to disable direct root logins on Solaris machines. If this file is available, the CONSOLE= parameter should be set to the pathname of a nonexistent device. If the administrator wishes to place the pathname of the actual console device (the terminal directly linked to the Unix machine) into this parameter, the console should be in a secure location. The contents of this file can be viewed by executing the more /etc/default /login command.

  • On Linux and HP systems, the /etc/securetty file can be used to prevent direct logins as "root." The contents of the file should contain all terminals that are allowed direct "root" login. The file should exist but be empty. Sometimes the system administrator will want to allow direct "root" login from the console terminal. This is acceptable, as long as the console is in a secure location. The contents of this file can be viewed by executing more /etc/securetty.

Review settings for preventing direct "root" logins via SSH. The /etc/sshd_config or /etc/openssh/sshd_config file is used for this purpose. Review the contents of this file using the more command. Look for the PermitRootLogin parameter. If this parameter is set to a value of no, "root" logins are not permitted. If the parameter is not there or is set to a value of yes, "root" logins are permitted.

Review settings for preventing direct "root" logins via FTP. This can be done by placing a "root" entry in the /etc/ftpusers file. Review the contents of this file using the more command.

36 Review the su and sudo command logs to ensure that when these commands are used, they are logged with the date, time, and user who typed the command.

The su command is a tool used frequently by attackers to try to break into a user's account. The sudo command allows authorized users to perform commands as if they were "root." The use of both commands should be logged in order to ensure accountability and to aid in investigations.

How

Attempt to perform a more command on the su log. However, the log may be protected, so you may not be able to do this. If this is the case, have the system administrator provide you with a copy. For some systems, the su log will be at /usr/adm/sulog, /var/adm/ sulog, or /var/log/auth.log. For other systems, the /etc/default/su file will determine where the su log will be kept.

  • Ensure that this file exists and is capturing information on su usage (e.g., who performed the command, what account they switched to, the date and time of the command, and indications as to whether or not the command succeeded).

  • Also question any instance of one user su'ing to another user's account. There should be little to no reason for one user to attempt to su to another user's account on the system. Most su's should be from an administrator's account to "root" or from a user account to an application ID.

View the sudo log to ensure that it is capturing information on sudo usage (e.g., who performed the command, what command was performed, and the date and time of the command). By default, the sudo logs are written to the syslog, but this can be changed in /etc/sudoers, so check for the location on your system (using the more command).

37 Evaluate the syslog in order to ensure that adequate information is being captured.

If system audit logs are not kept, there will be no record of system problems or user activity and no way to track and investigate inappropriate activities.

How

View the contents of the /etc/syslog.conf file using the more command. The /etc/syslog.conf file determines where each message type is routed (to a file name, to a console, and/or to a user). At a minimum, crit and err messages related to auth (authorization systems-programs that ask for usernames and passwords), daemon (system daemons), and cron (cron daemon) probably should be captured, along with emerg and alert messages.

Each syslog message contains, in addition to the program name generating the message and the message text, the facility and priority of the message.

Following are some of the common potential syslog facilities (i.e., the type of system function):

  • kern: kernel

  • user: normal user processes

  • mail: mail system

  • lpr: line printer system

  • auth: authorization systems (programs that ask for usernames and passwords)

  • daemon: system daemons

  • cron: cron daemon

Following are the potential priority levels, which indicate the severity of the message:

  • emerg-emergency condition (e.g., imminent system crash)

  • alert-immediate action needed

  • crit-critical error

  • err-normal error

  • warning-warning

  • notice-not an error but special handling needed

  • info-informational message

  • debug-used when debugging programs

Note that these are listed in descending order (most critical to least critical). When specifying a logging level, it encompasses that level and higher, so logging at the debug (lowest) level, for example, also would log all other levels. An asterisk for the facility or level indicates that all facilities or levels are logged.

On HP systems, the /etc/btmp file contains invalid login attempts. Determine whether this file exists. If not, it should be created. On Solaris, the file /var/adm/loginlog will log anytime a user tries to log into the system but types a bad password five times in a row (by default-the number can be configured in the /etc/default/login file). If this file does not exist, it should be created.

38 Evaluate the security and retention of the wtmp log, sulog, syslog, and any other relevant audit logs.

If the audit logs are not secure, then unauthorized users could change their contents, thus damaging their usefulness during investigations. If they are not retained for an adequate period of time, then the administrator may be unable to investigate inappropriate activities and other system issues if needed.

How

The locations of the log files are discussed in previous steps in this section. Perform a ls -l command on those files. They usually should be writable only by "root" or some other system account.

Interview the system administrator to determine retention, which could be either online or offline. It is generally preferable to retain these security logs for at least 3 to 6 months to allow for adequate history during investigations.

39 Evaluate security over the utmp file.

The utmp log keeps track of who is currently logged into the system and includes information regarding what terminals those users are logged in from. By changing the terminal name in this file to that of a sensitive file, an attacker can get system programs that write to user terminals to overwrite the target file. This would cause this sensitive file to be corrupted.

How

Perform an ls -l command on the utmp file, which is usually located at /etc/utmp on Unix systems and at /var/run/utmp on Linux systems. The file should be owned by "root" or another system account and should allow only owner write.

Security Monitoring and Other Controls

40. Review and evaluate system administrator procedures for monitoring the state of security on the system.

If the system administrator does not have processes for performing security monitoring, security holes could exist, and security incidents could occur without his or her knowledge.

How

Interview the system administrator, and review any relevant documentation to get an understanding of security monitoring practices. Numerous levels and methods of security monitoring can be performed. They all do not need to be performed, but you would like to see some level of monitoring. The level of monitoring required should be contingent on the criticality of the system and the inherent risk of the environment (e.g., a web server in the DMZ should have more robust security monitoring than a print server on the internal network). Basically, you want to know how the system administrator is monitoring for problems such as what you've been auditing for throughout the other audit steps in this chapter.

Listed below are four primary levels of monitoring. Potential tools for performing these types of monitoring are discussed in the "Tools and Technology" section later in this chapter:

  • Network vulnerability scanning. This is probably the most important type of security monitoring in most environments. This is monitoring for potential vulnerabilities that could allow someone who has no business being on the system to either gain access to the system or disrupt the system. Since these vulnerabilities can be exploited by anyone on the network, it is important to be aware of them and close them down.

  • Host-based vulnerability scanning. This is scanning for vulnerabilities that would allow someone who's already on the system to escalate their privileges (e.g., exploit the "root" account), obtain inappropriate access to sensitive data (e.g., owing to poorly set file permissions), or disrupt the system. This type of scanning generally is more important on systems where there are many nonadministrative end users.

  • Intrusion detection. This is monitoring in order to detect unauthorized entry (or attempts at unauthorized entry) into the system. Baseline monitoring tools (e.g., Tripwire) can be used to detect changes to critical files, and log-monitoring tools can be used to detect suspicious activities via the system logs.

  • Intrusion prevention. This is a type of monitoring that detects an attempted attack and stops the attack before it compromises the system. Examples include host Intrusion Prevention System (IPS) tools and network-based IPS tools such as Tipping Point.

If security monitoring is being performed, assess the frequency of the monitoring and the quality with which it is performed. Look for evidence that the security monitoring tools actually are used and acted on. Review recent results, and determine whether they were investigated and acted on. Leverage the results of the rest of the audit in performing this assessment. For example, if you found significant issues in an area that they are supposedly monitoring, it might lead to questions as to the effectiveness of that monitoring.

41 If you are auditing a larger Unix/Linux environment (as opposed to one or two isolated systems), determine whether there is a standard build for new systems and whether that baseline has adequate security settings. Consider auditing a system freshly created from the baseline.

One of the best ways to propagate security throughout an environment is to ensure that new systems are built right. In this way, as new systems are deployed, you have confidence that they initially have the appropriate level of security.

How

Through interviews with the system administrator, determine the methodology used for building and deploying new systems. If a standard build is used, audit a newly created system using the steps in this chapter.

42 Perform steps from Chapter 4 as they pertain to the system you are auditing.

In addition to auditing the logical security of the system, it is important to ensure that appropriate physical controls and operations are in place to provide for system protection and availability.

How

Reference the steps from Chapter 4, and perform those that are relevant to the system being audited. For example, the following topics are likely to be pertinent:

  • Physical security

  • Environmental controls

  • Capacity planning

  • Change management

  • System monitoring

  • Backup processes

  • Disaster recovery planning


Tools and Technology

The open-source community has provided numerous valuable tools that an auditor can take advantage of to increase both the accuracy and efficiency of his or her work. Some of the most commonly used tools for auditing *nix systems are listed below with a few tips on their use.

Nessus

The Nessus network vulnerability scanner written by Renaud Deraison first appeared in 1998 and was arguably the most advanced and most popular open-source network vulnerability-assessment tool. Beginning with version 3.0, Nessus is now closed-source and is owned by Tenable Security. Version 3.0 is still free to use, but registration/payment will get you faster access to the latest plugins and vulnerability checks. The source to the 2.x stream is still open, and others have already picked up on its development. In a nutshell, Nessus operates by looking for open ports on the target host, trying to identify the services running on those ports, and then testing those services for specific vulnerabilities. The server operates on Unix/Linux only, but there are clients to control the server that are also available for Windows.

  • http://www.nessus.org/

  • http://www.openvas.org/

NMAP

NMAP can be a handy way to check for open ports on a server without running an all-out vulnerability scanner such as Nessus, perhaps to test the rules of a host-based firewall. NMAP affords the user many options, and the "man" page is a must-read to understand them all.

  • http://www.insecure.org/nmap/

Chkrootkit

Chkrootkit is designed to identify both known rootkits running on a system and "suspicious" files or processes. It can be run in the course of an audit to check for possible compromises and also is suggested to the sysadmin as a tool that could be run on a regular basis for security monitoring. Its effectiveness is enhanced if run from a read-only file system with trusted, statically linked binaries.

  • http://www.chkrootkit.org/

  • http://www.netadmintools.com/art279.html (the author used the instructions on this site, with a few minor tweaks in the build process probably owing to differing versions, to successfully create static binaries for a trusted chkrootkit package)

John the Ripper and Crack

If checking the strength of user-chosen passwords is part of your audit scope, you'll want to take a look at these two tools. Alec Muffett's Crack dates back to the early 1990s and is very widely known and distributed. John the Ripper, however, generally is faster and more full-featured. Either probably will get the job done in most cases. Consider adding additional wordlists to the dictionaries of these tools, including non-English wordlists, to enhance their efficacy.

  • http://www.crypticide.com/users/alecm/security/c50-faq.html

  • http://www.openwall.com/john/

Shell/Awk/etc

While not a tool in the same sense as the others, much can be done in the *nix shell, especially with the help of additional tools such as awk or sed, which can chop up and process text output from commands. Much of the required information to perform the steps in this audit program could be obtained by the use of a shell script. This script can be provided to the sysadmin, who would run it as "root," providing the output to the auditor. Using logical operations to test the values returned even can automate the evaluation process, returning a simple pass/fail grade for some of the steps. A simple example is found in step 2, where the passwd file is checked for duplicate UIDs.


Knowledge Base

If you're interested in learning more about the subject of auditing *nix operating systems, there are many resources available in print and on the Internet.

As far as books go, one of the "go to" books on Unix security is Practical Unix & Internet Security, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, published by O'Reilly Media, Inc. This book provides an excellent overview of the topic, along with detailed guidance on how to secure the Unix environment.

Another excellent print resource is Essential System Administration, by Æleen Frisch, published by O'Reilly Media, Inc. This book is written for *nix administrators but also can serve as an excellent guide for auditors who are looking for details on how to implement many of the concepts discussed in this chapter.

There are also many websites devoted to Unix. The problem is wading through them to determine which ones can be of the most use. Following are some to consider:

  • http://www.sans.org/rr/-certifications and other documents from SANS

  • http://www.sans.org/top20-SANS top 20 vulnerabilities

  • http://www.nsa.gov/snac/-security configuration guides from the National Security Agency

  • http://www.csrc.nist.gov/publications/nistpubs/index.html-security guidelines from the National Institute of Standards and Technologies

  • http://www.insecure.org/tools.html-top 75 security tools as generated from a survey of NMAP users

  • http://www.seclists.org/-list of lists; good security-oriented mailing lists

  • http://www.securityfocus.com/-mailing lists, news, vulnerabilities

  • http://www.cve.mitre.org/-along with the vulnerability database section of security focus, this is a good site to begin research on potential vulnerabilities.

Remember that Google is your friend, and there is a wealth of information on the Internet about how Unix and Linux systems work. For example, try searching for "command list unix" without the quotes.


Master Checklists

This chapter covers several methods for auditing Unix hosts and their variants. The most important thing to take away is the concepts. Because there are so many variants, it is impossible to list every occurrence you'll run across. Here is a list of the items we reviewed in this chapter:

Auditing Account Management and Password Controls

Checklist for Auditing Account Management and Password Controls

  1. qReview and evaluate procedures for creating Unix or Linux user accounts and ensure that accounts are created only when there's a legitimate business need. Also review and evaluate processes for ensuring that accounts are removed or disabled in a timely fashion in the event of termination or job change.

  2. qEnsure that all UID's in the password file(s) are unique.

  3. qEnsure that passwords are shadowed and use strong hashes where possible.

  4. qEvaluate the file permissions for the password and shadow password files.

  5. qReview and evaluate the strength of system passwords.

  6. qEvaluate the use of password controls such as aging.

  7. 7. Review the process used by the system administrator(s) for setting initial passwords for new users and communicating those passwords.

  8. qEnsure that each account is associated with and can be traced easily to a specific employee.

  9. 9. Ensure that invalid shells have been placed on all disabled accounts.

  10. qReview and evaluate super user (root-level) access.

  11. 11. Review and evaluate the use of groups, and determine the restrictiveness of their use.

  12. qEvaluate the use of passwords at the group level.

  13. 13. Review and evaluate the security of directories in the default path used by the system administrator when adding new users. Evaluate the use of the "current directory" in the path.

  14. qReview and evaluate the security of directories in root's path. Evaluate the use of the "current directory" in the path.

  15. 15. Review and evaluate the security of user home directories and config files. They generally should be writable only by the owner.

Auditing File Security and Controls

Checklist for Auditing File Security and Controls

  1. qEvaluate the file permissions for a judgmental sample of critical files and their related directories.

  2. qLook for open directories (directories with permission set to drwxrwxrwx) on the system, and determine whether they should have the sticky bit set.

  3. qEvaluate the security of all SUID files on the system, especially those that are SUID to "root."

  4. qReview and evaluate security over the kernel.

  5. qEnsure that all files have a legal owner in the /etc/passwd file.

  6. qEnsure the chown command cannot be used by users to compromise user accounts.

  7. qObtain and evaluate the default umask value for the server.

  8. qExamine the system's crontabs, especially root's, for unusual or suspicious entries.

  9. qReview the security of the files referenced within crontab entries, particularly root's. Ensure that the entries refer to files that are owned by and writable only by the owner of the crontab. Also ensure that no crons are being run from open directories (permissions set to drwxrwxrwx).

  10. qExamine the system's scheduled atjobs for unusual or suspicious entries.

Auditing Network Security and Controls

Checklist for Auditing Network Security and Controls

  1. qDetermine what network services are enabled on the system, and validate their necessity with the system administrator. For necessary services, review and evaluate procedures for assessing vulnerabilities associated with those services and keeping them patched.

  2. qExecute a network vulnerability-scanning tool in order to check for current vulnerabilities in the environment.

  3. qReview and evaluate the use of trusted access via the /etc/hosts .equiv file and user .rhosts files. Ensure that trusted access is not used or, if deemed to be absolutely necessary, is restricted to the extent possible.

  4. qIf anonymous FTP is enabled and genuinely needed, ensure that it is locked down properly.

  5. qIf NFS is enabled and genuinely needed, ensure that it is secured properly.

  6. qReview for the use of secure protocols.

  7. qReview and evaluate the use of .netrc files.

  8. qEnsure that a legal warning banner is displayed when connecting to the system.

  9. qReview and evaluate the use of modems on the server.

Auditing Audit Logs

Checklist for Auditing Audit Logs

  1. qReview controls for preventing direct "root" logins.

  2. qReview the su and sudo command logs to ensure that when these commands are used, they are logged with the date, time, and user who typed the command.

  3. qEvaluate the syslog in order to ensure that adequate information is being captured.

  4. qEvaluate the security and retention of the wtmp log, sulog, syslog, and any other relevant audit logs.

  5. qEvaluate security over the utmp file.

Auditing Security Monitoring and Other Controls

Checklist for Auditing Security Monitoring and Other Controls

  1. qReview and evaluate system administrator procedures for monitoring the state of security on the system.

  2. qIf you are auditing a larger Unix/Linux environment (as opposed to one or two isolated systems), determine whether there is a standard build for new systems and whether that baseline has adequate security settings. Consider auditing a system freshly created from the baseline.

  3. qPerform steps from Chapter 4 as they pertain to the system you are auditing.


Chapter 8: Auditing Web Servers

Background

The background of Internet web applications is fascinating because it has come so far in such a short time period. Perl, widely used for web applications, was created by Larry Wall in 1987, four years before the first web server was installed in the United States. The rapid development of the Internet is broadly attributed to the need to share information that would accelerate development across research and later business. Entrepreneurs found new business models in the Internet and were able to take advantage of people's need to send and receive information instantly.

The pieces that enabled this rapid growth include the web server, the web browser, and the connected web of computer hosts. Some of the key dates in the development of the web as we know it include

  • 1989: European physicists Tim Berners-Lee and Robert Cailliau in Switzerland come up with the concept of the World Wide Web.

  • 1991: Paul Kunz, a physicist at Stanford, installs the first web server in the United States to communicate with the "Next" computer in Switzerland.

  • 1993: Mosaic is born as Marc Andreessen, a student at the University of Illinois' National Center for Supercomputer Applications (NCSA), creates the first web browser with mass appeal. He later leaves with friends from NCSA to eventually create Netscape Communications Corp.

  • 1995: Java is born with Sun Microsystems Java 1.0.

  • 1995: Apache is officially released to the public.

  • 1996: Microsoft releases Internet Explorer 3.0, and Netscape releases Navigator 3.0.

  • 2000: Hackers take down major websites and deface thousands of others, finally bringing attention to web security.

  • 2001: The Open Web Application Security Project (OWASP) is born (http://www.owasp.org).


Web Auditing Essentials

The trick to auditing your web servers is understanding how to compartmentalize the task and then correctly specify the scope of the work you want to accomplish. Auditing in our case is trying to use 20 percent of the tools and technologies available to discover 80 percent of the possible risks implemented into the system or processes around the system. Remember that auditing, as much as we would like to believe, isn't an exact science, and auditing web servers is one area in which this is apparent. We are going to equip you with the tools to outline and begin execution for your audit. Release yourself from the guilt of not being perfect, or you will either never get started or you'll end up ineffective as you try to cover too much with too few resources and knowledge.

Web Auditing Components

A complete web audit is really an audit of three large components. First, there's the underlying platform or operating system on which the web application is installed and runs. This is covered in earlier chapters. Second, there is the web server itself, such as IIS, Apache, or Tomcat, which is covered below. An encyclopedia could be written about every web application in existence and the individual settings in each one. We cover the concepts, show some examples, and leave it to you to understand how to apply the concepts to any esoteric web servers. Finally, there is the audit of the web application that runs on top of the web server. These are show in Table 8-1.

Table 8-1: Web Auditing Components
Web Audit Component | Key Concerns
Web platform | Security of the operating system, physical and network protection to the host
Web server | Default settings, sample code, general misconfigurations
Web application | Default application settings, input validation, incorrectly serving up data, access to company confidential data, general misconfigurations

There is a wealth of languages and structures for web application development, complicating the audit process. However, there are also several tools available to help us wade through the mix and determine what needs attention. We will go through these in the steps below.


Auditing Web Platforms and Web Applications

The audit of a web platform, or host, should be conducted in conjunction with the audit of the web server and web application(s). Please see Chapters 6 and 7 on Unix or Windows if one of those applies for the audit of the platform. The following steps are intentionally general and cover the common issues found in web servers and applications. These steps will suffice for most audits.

Keep in mind that if the following steps don't fit with your intentions, then you need to review Chapter 10 on Auditing Applications. That chapter is intentionally geared toward conceptually breaking down complex or infrequent audits.

Note

The platform portion of the audit is as important as the audit of the web server and the web applications. Please refer to the Chapters 6 and 7 on auditing Unix or Windows servers for this portion of the audit.


Auditing Web Servers

There are certainly differences among the many web servers available, but there are many commonalities that you need to check. These are listed in the steps that follow. Each step may or may not apply to your situation, but you need to take the time to find out. If these steps apply, then we suggest that you test for the following components of a web server. Keep in mind that we examine the applications that are running on the web server in a separate list that follows this one.

1 Verify that the web server is running on a dedicated system and not in conjunction with other critical applications.

If the web server were hacked with other applications running on the same host, then they also might be subject to compromise. You should use a dedicated machine as a web server. For example, you would never want to install your web server on a domain controller.

How

Determine the infrastructure location with the administrator, and carefully consider other applications that also may be running on the same host as the web server. If other applications exist, question the need for running other applications on the web server.

2 Verify that the web server is fully patched and updated with the latest approved code.

Failure to run adequately patched systems subjects the web server to unnecessary risk of compromise from vulnerabilities that may have been patched with updated code releases.

How

Every organization has its own patch-management systems and policies. Verify that the web server is running the latest approved code with the help of the administrator according to the policies and procedures in the environment. Also review the policies and procedures for appropriate and timely demands for keeping and verifying that systems are up-to-date with the latest code releases.

3 Determine if the web server should be running additional tools to aid in the protection of the web server.

Web servers often come with additional measures designed to protect them, such as IISLockdown and URLScan. These tools are recommended often by the vendors or developers. The additional controls put in place by these tools can lower the overall risk of the server to compromise greatly.

How

Determine through research at the web developer's website and discussions with the web administrator what tools are available and the additional controls the tools offer for the given increase in administration. These tools might include validation checking or tools that monitor web server connections. Some tools offer quite a bit of additional protection for very little additional overhead. In the Microsoft environment, IISLockdown and URLScan should be run on every Window IIS web server with very few exceptions. Check to see if your organization has procedures governing how to configure these tools, and verify that they are configured correctly.

Note

IISLockdown is only for IIS 5.x. IIS 6 is already semisecure; you still can install URLScan on IIS 6 to further harden and reduce functionality. With Windows Server 2003 SP1, the Security Configuration Wizard provides a way to strip all unnecessary functionality from the IIS so that only components that are necessary for the web server to fulfill its role in life are installed and/or running.

4 Verify that unnecessary services or modules are disabled. Running services and modules should be operating under the least privileged accounts.

Unnecessary services and modules present additional opportunities for malicious attackers and malware.

How

Discuss and verify with the help of the administrator that unnecessary services are disabled and that the running services are operating under the least privileged account possible. Verify that FTP, SMTP, Telnet, FrontPage Server Extensions, and NNTP services are disabled if they are not required.

If you are running Apache, only enable modules that are absolutely necessary. Table 8-2 presents a list of modules considered to be the bare minimum. Question the need for anything else that might be running.

Table 8-2: Minimum Apache Modules
Apache Module | Purpose
httpd core | Core module, foundation of the web server
mod access | Necessary for allow, deny, and order directives
mod auth | Supports HTTP basic authentication
mod dir | Supports index files (e.g., index.html)
mod log config | Supports logging
mod mime | Provides support for character set, content encoding, content language, and MIME types of documents

5 Verify that only appropriate protocols and ports are allowed to access the web server.

Minimizing the number of protocols and ports allowed to access the web server reduces the number of attack vectors available to compromise the server.

How

Discuss with the administrator and verify with the administrator's help that only necessary protocols are allowed to access the server. For example, the TCP/IP stack on the server should be hardened to allow only appropriate protocols, and NetBIOS and SMB should be disabled on IIS servers. Note any additional controls that may be in place, such as firewall rules or network access control lists (ACLs) to limit the protocols and ports allowed to access the web server. In general, only TCP on ports 80 (HTTP) and 443 (SSL) should be allowed to access the web server.

6 Verify that accounts allowing access to the web server are managed appropriately and hardened with strong passwords.

Inappropriately managed or used accounts could provide easy access to the web server, bypassing other additional security controls to prevent malicious attacks. This is a large step with a wide scope, covering controls around account use and management.

How

Discuss with the administrator and verify with the administrator's help that unused accounts are removed from the server or completely disabled. The administrator's account on Windows servers should be renamed, and all accounts should be restricted from remote login except for those used for administration.

The root account on Unix flavored hosts (Linux, Solaris, etc) should be strictly controlled and never used for direct remote administration. Never run Unix web servers such as Apache under the root account. They should be run under a distinct user and group such as http://www.-apache. Please see Chapter 7 for more information about the root account.

In general, accounts never should be shared among administrators, and administrators never should share their accounts with users. Strong account and password policies always should be enforced by the server and by the web server application.

Additional considerations for IIS web servers include ensuring that the IUSR_MACHINE account is disabled if it is not used by the application. You also should create a custom least-privileged anonymous account if your applications require anonymous access. Configure a separate anonymous user account for each application if you host multiple web applications.

7 Ensure that appropriate controls exist for files, directories, and virtual directories.

Inappropriate controls for files and directories used by the web server and the system in general allow attackers access to more information and tools than should be available. For example, remote administration utilities increase the likelihood of compromising a web server.

How

Discuss with the administrator and verify with the administrator's assistance that logs and website content are stored on a nonsystem volume where possible. Verify that files and directories have appropriate permissions, especially those containing

  • Website content

  • Website scripts

  • System files (e.g. %windir%\system32 or web server directories)

  • Tools, utilities, and software development kits

Sample applications and virtual directories should be removed. These would include IISSamples, IISAdmin, IISHelp, and Scripts virtual directories in IIS web servers.

Also verify that anonymous and everyone groups (world permissions) are restricted except where absolutely necessary. Additionally, no files or directories should be shared out on the system unless necessary.

8 Ensure that the web server has appropriate logging enabled and secured.

Logging auditable events helps administrators to troubleshoot issues. Logging also allows incident response teams to gather forensic data.

How

Verify with the administrator that key audit trails are kept, such as failed logon attempts. Ideally, these logs should be relocated and secured away from the same volume as the web server. Log files also should be archived regularly. They should be analyzed regularly, preferably by an automated tool in large information technology (IT) environments.

9 Ensure that script extensions are mapped appropriately.

Scripts might allow an attacker to execute the code of his or her choice, potentially compromising the web server.

How

Verify with the web administrator that script extensions not used by the web server are mapped to a 404 web page handler or simply denied altogether. Examples of extensions that you may or may not use include .idq, .htw, .ida, .shtml, .shtm, .stm, .idc, .htr, and .printer.

10 Verify that unnecessary or unused ISAPI filters are removed from the server.

ISAPI filters are tightly wrapped with the web server and were intended to allow rapid script execution, faster than CGI scripts. Support for ISAPI is designed into several web servers, but there have been problems with ISAPI in the past. Unsecured or unused ISAPI filters may present another avenue of attack.

How

Verify with the web administrator that any ISAPI filters installed on the web server are necessary. Unnecessary or unsecured web filters should be removed from the server.

11 Verify the validity and use of any server certificates in use.

Server side certificates enable clients to trust your web server's identity or that your web server is who you say your server is supposed to be. Old or revoked certificates suggest that your website may or may not be valid to end users.

How

Verify with the help of the administrator that any certificates are used for their intended purpose and have not been revoked. Certificate data ranges, public key, and metadata all should be valid. If any of these have changed, then consider the need for a new certificate that reflects your current needs.


Auditing Web Applications

The best compilation of common web application issues is maintained by the Open Web Application Security Project (OWASP). According to its website, it is "dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted." In short, it has a tremendous amount of information that will help you to develop a solid audit program for your web applications. OWASP is supported by companies such as VISA, Deloitte, and Foundstone.

The OWASP "top ten" have made their way into standards, such as the Payment Card Industry (PCI) standard, and these "top ten" are regarded as a set of minimum standards you should examine during an audit. Below you will find an example of how to go about an audit of the OWASP "top ten."

There are important caveats as you move through this audit program. Some of the following steps may be more important to you than other steps because of how your application is designed. We assume for the most part that there are interactions between the web server and the user, such as logging into the application or serving up user-requested data.

Note

Keep in mind that the audience of this book varies greatly in technical abilities, and an attempt has been made to simplify as much as possible for the majority of the readers. Yo u may want to visit http://www.owasp.org/index.php/OWASP_Top_Ten_Project to determine what scope and toolset make sense in your environment.

1 Verify that all input is validated prior to use by the web server.

Information must be validated before being used by a web application. Failure to validate web requests subjects the web server to increased risk from attackers attempting to manipulate input data to produce malicious results.

How

Discuss with the web application developer or web administrator the methodology used for input validation for the application you are testing.

There are several tools that effectively act as a proxy and allow you to see much of the content posted from your client to the remote web server. One such tool is Paros Proxy, located at http://www.parosproxy.org.

Another method used by professional web testers is to understand the movement of data during a code review. This isn't something that should be taken lightly because it may be beyond the scope of what you are trying to accomplish. There is a tradeoff that you as an auditor are going to have to make regarding the amount of effort you put into this versus the cost of the data you are protecting.

In general, two ways to look at validation methods are negative methods and positive methods. Negative methods focus on knowing what bad input to filter out based on the known bad. The problem with negative filtering is that we don't know now what tomorrow's vulnerabilities and input methods will bring. Positive filtering is much more effective and involves focusing on validating the data based on what they should be. This is similar in approach to a firewall that denies everything except what should be accepted.

Common items for positive filtering include criteria you might find in a database or other places that accept data. These include criteria such as

  • Data type (e.g. string, integer, and real)

  • Allowed character set

  • Minimum and maximum length

  • Whether null is allowed

  • Whether the parameter is required or not

  • Whether duplicates are allowed

  • Numeric range

  • Specific legal values (e.g., enumeration)

  • Specific patterns (e.g., regular expressions)

2 Verify that proper authorization controls are enforced.

After a user is authenticated to the web server, the web server determines what kind of access the user should have and to what parts of the website the user should have access. Failure to enforce access controls (authorization) may allow an attacker to step out of authorized boundaries, accessing other users' data or administering unauthorized areas.

How

Discuss the policy requirements with the administrator. Failure to have a policy or other written documentation for a home-grown application is a red flag that suggests that access controls are not being enforced correctly. This is so because access controls are complicated and difficult to get right without carefully documenting and thinking through your desired results. Typical methods for bypassing given authorization include those shown in Table 8-3.

Table 8-3: Common Methods for Bypassing Web Application Authorization
Cached or Insecure IDs | Many websites use some sort of key or ID stored on the client as a means of determining what rights the user has on the web server. If the user can guess and create a token, then he or she may have free reign on the web server.
Forced Browsing | Some websites require certain checks before allowing a user to access content deeper in the site. If the checks are not enforced, then a user can access the content directly.
Path Traversal | These attacks attempt to backtrack and go around normal permission sets to gain access to information or files not normally accessible.
File Permissions | Log and configuration files, among others, may have incorrect permissions and be accessible through the web interface. Correctly setting file permissions also can help in preventing other attacks.
Client Side Caching | Clients should not cache sensitive information such as credit card and personal data. Attackers can take advantage of users' cached data and maliciously reuse this information.

3 Broken Authentication and Session Management

Account credentials and session tokens must be protected. Attackers who can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

How

Discuss with the administrator the authentication mechanism used to authenticate users to the web application. The web application should have built-in facilities to handle the life cycle of user accounts. Verify that help-desk functionality, such as lost passwords, is handled securely. Walk through the implementation with the administrator, and then ask the administrator to demonstrate to you the functionality.

Table 8-4 contains a shortened list of guiding principles when it comes to checking the authentication mechanism used on a website. These are taken from OWASP's website, which contains several more principles, including coding examples.

Table 8-4: Guiding Principles of Web Authentication

When a user enters an invalid credential into a login page, don't return which item was incorrect. Show a generic message instead such as, "Your login information was invalid!"

Never submit login information via a GET request. Always use POST.

Use SSL to protect login page delivery and credential transmission.

Remove dead code and client-side viewable comments from all pages.

Do not depend on client-side validation. Validate input parameters for type and length on the server, using regular expressions or string functions.

Database queries should use parameterized queries or properly constructed stored procedures.

Database connections should be made created using a lower privileged account. Your application should not log into the database using sa or dbadmim.

One way to store passwords is to hash passwords in a database or flat file using SHA-256 or greater with a random salt value for each password.

Prompt the user to close his or her browser to ensure that header authentication information has been flushed.
Note

Please visit http://www.owasp.org/index.php/Authentication for an excellent overview of authentication methods and the strengths and weaknesses of each.

4 Review the website for cross-site-scripting vulnerabilities.

Cross-site scripting (XSS) allows the web application to transport an attack from one user to another end user's browser. A successful attack can disclose the second end user's session token, attack the local machine, or spoof content to fool the user. Damaging attacks include the disclosure of end-user files, installation of Trojan horse programs, redirecting the user to some other page or site, and modifying the presentation of content.

How

Cross-site scripting attacks are very difficult to find, and although tools can help, they are notoriously inept at locating all the possible combinations of XSS possible on a web application. By far the best method for determining if your website is vulnerable is by doing a thorough code review with the administrator.

If you were to review the code, you would search for every possible path by which HTTP input could make its way into the output going to a user's browser. The key method used to protect a web application from XSS attacks is to validate every header, cookie, query string, form field, and hidden field. Drawing on the previous discussion of positive and negative validation measures, you should make sure to employ a positive validation method.

CIRT.net contains two tools, Nikto and a Nessus plugin, that you might be able to use to help you automate the task of looking for XSS vulnerabilities on your web server. Keep in mind that these tools are not as thorough as conducting a complete code review, but at least they can provide more information to those who don't have the skill set, resources, time, and dollars to conduct a complete review. Nikto, a tool from http://www.cirt.net/code/nikto.shtml, searches literally thousands of known issues across hundreds of platforms. It's a powerful tool and should be part of your toolset. Scan items and plugins are updated frequently and can be updated automatically if desired. Commercial tools also are available that may help, such as acunetix (http://www.acunetix.com). These tools may find well-known attacks, but they will not be nearly as good as performing a solid code review.

If you don't have the internal resources available to perform a code review, particularly on a home-grown application, and you believe that the data on the website warrant a deep review, then consider hiring third-party help. There are outfits such as FishNet Security (http://www.fishnetsecurity.com) that perform this kind of work.

5 Verify that the server is updated with all known patches for buffer overflows.

Buffer overflows are quick to find their way into an exploit for web servers in general. You should make sure that all applicable patches covering buffer overflows are installed on the web server to protect your web applications.

How

Buffer overflows aren't something you typically find by looking through the code unless you are a professional hacker paid to do this. By far the easiest method to stay on top of buffer overflows is to stay on top of the patching cycle for your systems. You have patches for the operating system, web platform, and in many cases the web application that you need to research and verify.

Discuss the patching cycle of the web servers with the web administrator to ensure that any applicable web application patches have been installed. This sounds like a repeat of step 2 above for the web platform. However, in certain cases, commercial web applications require their own patches separate from the web platform. Ensure that all known patches are installed to protect the security of the web platform and web application.

6 Ensure that the web application is protected against injection attacks.

Injection attacks allow a web client to pass data through the web server and out to another system. For example, in an SQL injection attack, SQL code is passed through the web interface, and the database is asked to perform functions out of bounds of your authorization. Several websites have coughed up credit-card and Social Security card information to hackers who have taken advantage of injection attacks.

Failure to realize the power of injection attacks and to review your systems for the likelihood of being exploited may result in the loss of critical and sensitive information.

How

Discuss injection attacks with the administrator to ensure that he or she understands how they work, and then ask how he or she is guarding against injection attacks. There aren't any tools that will review and discover every possible injection attack on your web application, but you still can defend against them. The defense methods are a repeat of what was covered in cross-site scripting:

  • Validate all input using positive validation methods.

  • Perform a code review if possible for all calls to external resources to determine if the method could be compromised.

  • Commercial tools are available that may help, such as acunetix (http://www.acunetix.com). These tools are definitely powerful and may find well-known attacks, but they will not be as good as performing a solid code review.

  • Consider hiring third-party help if the application is particularly sensitive, you lack the resources, or you need to verify items such as regulatory compliance.

7 Evaluate the use of proper error handling.

Improperly controlled error conditions allow attackers to gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

How

Improper error handling generally is a function of having detailed plans in place during development of the application to centralize and control all input methods. Ask the administrator how error handling was designed into the web application and how errors are handled internally as the application interfaces with other compartmentalized functions. For example, how would the web application handle an error generated by the database? Does it make a difference whether the database is hosted internally by the application as opposed to hosting the database externally on another server? How does the application handle input validation errors? What about username and password errors?

Error handling is often better controlled if it is centralized as opposed to compartmentalizing it across several interworking objects or components. If you are reviewing the code, the error handling should flow nicely and show structure. If the error handling looks haphazard and like an afterthought, then you may want to look much more closely at the application's ability to handle errors properly.

8 Ensure that secure storage mechanisms are used correctly and appropriately.

Web applications often want to obfuscate or encrypt data to protect the data and credentials. The challenge is that there are two parts to this scheme: the black box that does the magic and the implementation of the black box into your web application. These have proven difficult to code properly, frequently resulting in weak protection.

How

Begin the discussion with the web administrator by talking about the sensitivity of the data you want to protect. If the data are sensitive and not encrypted, then consider whether there are industry or regulatory drivers stating that the data must be encrypted, and note the issue. If data are encrypted, then discuss in detail with the developer or review documentation with the administrator to understand how the encryption mechanism was implemented into your web application. Ensure that the level of encryption is equivalent to the level of data you want to protect. If you have extremely sensitive data such as credit-card data, then you may want to have actual encryption instead of a simple algorithm that obfuscates the data.

Note

Obfuscation simply means to find creative ways of hiding data without using a key. Encryption is considered to be much, much more secure than obfuscation. Encryption uses tested algorithms and unique keys to transform data into a new form in which there is a little or no chance of recreating the original data without a key. Sound complicated? It's that much harder to defeat properly implemented encryption than it is to defeat obfuscation.

9 Determine the use of adequate controls to prevent denial of service.

It is possible for attackers to repeatedly connect to your web application and fill up all available resources until there is nothing left for legitimate users.

How

This is incredibly difficult to defend against, but there are a few things you can do. Discuss with the administrator how he or she is handling user resources. Ideally, authenticated users would have more resources, and visiting users would be limited in scope as to what they can access. Resource-intensive operations in some cases may be offloaded, such as database queries. In some cases, data may be cached so that the same operation isn't performed repeatedly, eating up your resources for an operation that just occurred.

There are also several application testers such as JMeter from Apache located at http://www.jakarta.apache.org/jmeter. Check out http://www.opensourcetesting.org/performance.php for a list of open-source stress-testing tools. Finally, make sure that your hardware and memory are sufficient for the web application.

10 Review controls surrounding maintaining a secure configuration.

This is a catch-all that addresses configuration management, the overarching concept of maintaining the secure configuration of the web server. Failure to maintain a secure configuration subjects the web server to lapses in technology or processes that affect the security of the web platform and web application.

How

Perform the web platform audit, and discuss any issues noted with the administrator. Determine if any of the issues noted are due to inadequate configuration management. Discuss the following with the administrator to ensure that proper configuration management controls are in place:

  • Security mailing lists for the web server, platform, and application are monitored.

  • The latest security patches are applied in a routine patch cycle under the guidance of written and agreed-to policies and procedures.

  • A security configuration guideline exists for the web servers in the environment and is strictly followed. Exceptions are carefully documented and maintained.

  • Regular vulnerability scanning from both internal and external perspectives is conducted to discover new risks quickly and to test planned changes to the environment.

  • Regular internal reviews of the server's security configuration are conducted to compare the existing infrastructure with the configuration guide.

  • Regular status reports are issued to upper management documenting the overall security posture of the web servers.

Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box. Taking the time to understand these options and how to configure them to your environment is fundamental to maintaining sound and secure web servers.


Tools and Technologies

There are several reasons why an automated product will fail to thoroughly audit every possible component of your web server. Code reviews actually may be very fast for experienced coders, but this depends on many variables. For example, how experienced is the coder? How well does the reviewer understand the web application? How well does the reviewer understand the constructs of the programming language used for the application? How complex is the application? What external interfaces exist, and how well does the reviewer understand these external interfaces? If you live and play in this world, then code reviews may be easy for you. If you live and play in many worlds, then you may want to consider augmenting your searches with automated tools.

Note

Automated tools can be quite harmful to production environments. Exercise care, and design the test in a manner that will not affect production systems.

Automated tools can be quite helpful and guide you toward parts of your web platform or web application that might need further review. A strong case could be made that new applications should be tested with good code reviews and tools such as those listed below. This list only scratches the surface of what's out there. Many general vulnerability scanners also test commonly exploited vulnerabilities for web platforms. There are many web testing tools available. Here is a small list of web tools:

  • Acunetix: http://www.acunetix.com

  • Web Sleuth: http://www.sandsprite.com/Sleuth

  • Paros Proxy: http://www.parosproxy.org

  • Web Inspect: http://www.spidynamics.com/products/webinspect

  • nikto: /http://www.cirt.net/code/nikto.shtml

  • XSS NASL plugin for Nessus: http://www.cirt.net/code/nessus.shtml

  • JMeter: http://www.jakarta.apache.org/jmeter


Knowledge Base

  • Apache website: http://www.apache.org/

  • Microsoft IIS website: http://www.microsoft.com/windowsserver2003/iis

  • IIS answers: http://www.iisanswers.com/

  • OWASP "top ten" vulnerabilities to check for when looking at your web server: http://www.owasp.org/index.php/OWASP_Top_Ten_Project

  • CGI security: http://www.cgisecurity.net/

  • Securing IIS: http://www.microsoft.com/technet/security/prodtech/IIS.mspx

  • Windows Server 2003 Security Guide: The web server role: http://www.microsoft..com/technet/security/prodtech/windowsserver2003/w2003hg/s3sgch09.mspx

  • Story about the history of the World Wide Web from Microsoft's perspective: http://www.microsoft.com/misc/features/features_flshbk.htm

  • General story about the history of the World Wide Web: http://www.computerworld.com/developmenttopics/websitemgmt/story/0,10801,73525,00.html


Master Checklists

Auditing Web Servers

Checklist for Auditing Web Servers

  1. qVerify that the web server is running on a dedicated system and not in conjunction with other critical applications.

  2. qVerify that the web server is fully patched and updated with the latest approved code.

  3. qDetermine if the web server should be running additional tools to aid in the protection of the web server.

  4. qVerify that unnecessary services or modules are disabled. Running services and modules should be running with least privileged accounts.

  5. qVerify that only appropriate protocols and ports are allowed to access the web server.

  6. qVerify that accounts allowing access to the web server are managed appropriately and hardened with strong passwords.

  7. qEnsure that appropriate controls exist for files, directories, and virtual directories.

  8. qEnsure that the web server has appropriate logging enabled and secured.

  9. qEnsure that script extensions are mapped appropriately.

  10. qVerify that unnecessary or unused ISAPI filters are removed from the server.

  11. qVerify the validity and use of any server certificates in use.

Auditing Web Applications

Checklist for Auditing Web Applications

  1. qVerify that all input is validated prior to use by the web server.

  2. qVerify that proper authorization controls are enforced.

  3. qBroken authentication and session management

  4. qReview the website for cross-site scripting vulnerabilities.

  5. qVerify that the server is updated with all known patches for buffer overflows.

  6. qEnsure that the web application is protected against injection attacks.

  7. qEvaluate the use of proper error handling.

  8. qEnsure that secure storage mechanisms are used correctly and appropriately.

  9. qDetermine the use of adequate controls to prevent denial of service.

  10. qReview controls surrounding maintaining a secure configuration.


Chapter 9: Auditing Databases

Background

When we refer to databases, the term typically is meant to refer to RDBMS. The more generic term database can be applied to any collection of data in any structured form. For instance, a flat file with customer records in it can serve as a database for an application. However, for this chapter, we are going to focus on auditing full-blown relational database management systems.

Databases usually are the neglected area of the audit. Typically, an audit includes a fairly in-depth review of various areas, including the perimeter, the operating system, the policies, etc. If time allows, an audit might cover one or two of the most critical databases. A lack of knowledge about auditing database makes it convenient to neglect this area. Databases are complex beasts requiring patience and technical know-how to audit and secure properly.

However, neglecting the database is a serious error. Databases are the virtual lock-boxes of the information age. Where do organizations store their most valuable assets? Not in perimeter devices, not in an e-mail system, and not in a flat file. They are stored in a database. When you hear about a security breach and sensitive data being stolen, ask yourself where did that data "live" when it was attacked? In a database!

Databases live both a blessed and a cursed existence. Databases are blessed because they are rarely exposed to the types of attacks that your web servers, firewalls, and other systems confront. Databases should be and almost always are buried deep and far behind the firewall. Most organizations are smart enough to know not to place their most valuable data out in the unsecured public network. Of course, this does not take into consideration that attacks, such as SQL injection, easily can make their way through a firewall and hit the database.

Databases are cursed for the exact same reason. Because databases are so far behind the firewall, securing and auditing your databases are considered afterthoughts, something to be done if you have extra time and maybe just on one or two critical databases. This has led to a situation in which database security typically is left in a shabby condition. The typical database administrator truly believes that the database is far enough behind the firewall that he or she doesn't have to take even rudimentary security measures.

The secured perimeter might serve as enough protection for the database in a perfect world. Unfortunately, we don't live in a perfect world, and the firewall is no longer a valid "last line of defense." Focus is shifting now to protecting data right where they sit, right in the database. As an auditor, you are likely to find that the database is the weak link in the security chain. This is great for the auditor because a few relatively simple recommendations can create vast improvements in your database security.


Database Basics

If you want to be able to audit a database effectively, you need to have a basic understanding of how a database works. Here, we will cover a broad set of components that you as the auditor will need to understand to audit a database properly.

In the early 1990s, applications were written using the client-server model. This consisted of a desktop program connecting over a network directly to a database backend. This was referred to as a two-tier application.

In the late 1990s, three-tiered applications became the norm. This new model consisted of a web browser connecting to a middle-tier web application. The middle tier then connected to the database backend. Three-tiered applications were a great step forward. Custom software was not needed on every client workstation. Software updates only needed to be applied to the central server. Clients could run any operating system that supported a basic browser. Moreover, in the three-tiered model, securing the database was much simpler.

Of course, the infrastructure the database required to support two-tier applications still exists in database backends for three-tiered applications. The danger now exists that an attacker will circumvent the web application to attack the backend database.

Common Database Vendors

Typically, an audit engagement will focus on one or two database vendors, such as Oracle or DB2. However, any medium-sized or large organization typically will be made up of a sampling of many different database platforms. Below is a summary of the most common databases and vendors, along with a short overview of each.

Oracle

Oracle Corporation is the largest database vendor, having an entire series of databases. In addition, Oracle Corporation has grown beyond standard database software, having a variety of products including but not limited to web servers, development tools, identity-management software, a collaboration suite, and multiple enterprise resource planning (ERP) solutions.

In the database market, the Oracle database has one of the largest install bases and an impressive feature set. The database comes in multiple flavors, including Standard Edition, Enterprise Edition, OracleLite, Express Edition, and others. Most Oracle databases you audit will be either Standard Edition or Enterprise Edition. The features are fairly similar; however, the advanced features in Enterprise Edition are changing constantly, so you will need to access the Oracle website to check up on the exact feature sets included in the version you are auditing.

Oracle Corporation also has branched out into other databases, having purchased several other database vendors, including:

  • Sleepycat Software, which maintains Berkeley DB, an open-source, embedded database

  • The TimesTen in-memory database

  • InnoDB, a transaction engine for the MySQL database

IBM

IBM is another of the largest database vendors, although IBM's database software is a small piece of the company's business. IBM's main database is the DB2 product line. This line is composed of two main products:

  • DB2 Universal Database, providing database software for AIX, Linux, HP-UX, Sun, and Windows

  • DB2 Universal Database for z/OS, providing software for the mainframe

There is a lot of confusion around the nomenclature of these two products. Typically, people refer to UDB as the Linux, Unix, and Windows version and DB2 as the mainframe version. This is a misnomer because UDB is actually a term used for all of IBM's latest DB2 software. Understand what people mean when they use these terms, but try to use the correct terms to avoid confusion.

IBM acquired Informix Software in 2001 and now maintains the Informix Dynamic Server. Informix was, for a brief period of time, the second most popular database. Owing to some misgovernance issues, Informix fell out of favor and hit hard times. These days Informix is rarely used for new database installations, but there is a large installed base within many enterprises, and you should expect Informix to exist for quite some time into the future.

IBM also maintains one of the first commercially available database management systems, Information Management System (IMS). IMS dates back to 1969 and is not actually a relational database but rather a hierarchical database. IMS typically runs on the mainframe and does not usually work in a client-server model.

MySQL

MySQL is an open-source database used extensively in small or medium-sized web applications. MySQL is owned and developed under the GNU Public License by MySQL AB, a privately held Swedish company. MySQL has a large and growing grassroots following and is the M in the LAMP (Linux, Apache, MySQL, and PHP) open-source web platform.

MySQL traditionally has been a bare-bones database, providing a small fraction of the functionality available from other database vendors. From the security perspective, this is good because MySQL does exactly what it was meant to do very well-and little else. Administration costs are relatively low, and MySQL provides adequate performance for all but the most demanding web applications.

MySQL AB is investing heavily in the MySQL database, and the results can be seen. MySQL 5.0 has added significant functionality, including stored procedures, views, and triggers. MySQL is one of the simplest databases to secure from hacking because of the small attack surface it exposes. In addition, MySQL development is done in the open, meaning that source code is available for anyone to see. This had led to a relatively secure and vulnerability-free code base. Vulnerabilities have been discovered in the MySQL source code, but security holes are discovered early in the life cycle of each release and are patched quickly.

MySQL AB also offers a second open-source database called MaxDB. MaxDB is designed specifically as a high-reliability backend for SAP systems.

Sybase

Another leading database vendor is Sybase, Inc. Sybase produces several databases, including:

  • The flagship Sybase Adaptive Server Enterprise database, designed for enterprise databases

  • Sybase Adaptive Server Anywhere, designed as a lighter-weight database

Sybase originally partnered with Microsoft to develop the early versions of its database system, which was referred to at the time as Sybase SQL Server on Unix and Microsoft SQL Server on Windows. As of version 4.9, Microsoft and Sybase split the code line and went their separate ways.

Sybase has expanded beyond databases as well. The company has various developer tools and a web application server and currently is focused on the delivery of data to mobile devices. Although the company has lost significant market share to the competition in the database market, it continues to maintain a presence in many places, and its databases will continue to exist for a long time.

Microsoft

Microsoft SQL Server is one of the most popular databases owing to its low price tag and its simplistic administration model, as well as the sheer momentum of Microsoft. Microsoft SQL Server comes in several flavors listed here:

  • Microsoft SQL Server 7.0 is an older version of the product with a few legacy installations still in existence.

  • Microsoft SQL Server 2000 (aka SQL Server 8.0) was Microsoft's main database version for 5 years. As such, it is heavily entrenched in a large number of enterprises.

  • Microsoft SQL Server 2005 is the latest release of the database. It provides a rich new set of security features among other functionality.

  • The Microsoft Database Engine (MSDE) is a free version of SQL Server providing a backend for ISVs to embed databases in their applications. Because MSDE is free, it is embedded in a large number of applications and is very common. With the delivery of SQL Server 2005, MSDE has been renamed to SQL Server 2005 Express Edition.

Microsoft SQL Server is often referred to as SQL, Sql Server, MSSQL, and even MS Sql Server. Although it's best to stick to the proper nomenclature to avoid confusion, it's important to understand the common, although incorrect, lingo.

Because Microsoft SQL Server is so easy to install and administer, it is often used by people with relatively little knowledge about securing it properly. This can lead to problems not because Microsoft SQL Server is insecure but because many people using it haven't taken even the most basic steps to protect it.

Database Components

Each database vendor has a slightly different implementation of the various database components. However, the theories and principles apply to all the different platforms fairly universally. We will cover enough of these basics to give you the 30,000-ft view. From there, you should have enough background to follow a technical guide on a specific database platform. Below are the major pieces of the database that you will need to understand from the auditor's perspective.

Program Files

A database is implemented as a software system, and as such, it is made up of a core set of operating system files. These files include the executable files that will run the database management system. It also may contain other nonexecutable program files such as help files, source and include files, sample files, and installation files.

These files should be protected because the integrity of the database relies on these files not being tampered with. These files should be guarded from any form of modification-particularly any executable files. Access controls should be as restrictive as possible on the directory that holds these files. Ideally, only database administrators should have access to this directory.

Configuration Values

Databases rely heavily on configuration settings to determine how the system operates. Protecting these settings is important because if the configuration can be manipulated, security can be subverted.

Configuration values reside in a variety of places, including:

  • In operating system text files

  • In the data files

  • On Windows, stored in the registry

  • In environment variables

Configuration values are used for a wide range of settings, such as:

  • Setting the type of authentication or trust model

  • Setting which groups are database administrators

  • Determining password management features

Verifying the integrity of configuration values is a critical component of any audit.

Data Files

Databases need to store the data they hold in physical operating system files. Typically, they are comprised of a series of files. The format of the file is typically proprietary, and the data files contain such information as:

  • Data being stored

  • Pointers from one field to the next field or from one row to the next row

  • Index data, including pointers from the index to the physical data

Note

Indices (the plural of index) contain a subset of the data to which they point. This means that if an attacker can get access to the index, he or she may not need access to the physical data themselves. Ensure that access to any index is protected to the same degree as the data themselves.

Usually, the database dictionary is stored in these data files, so again, any access to these files can be used to circumvent controls built into the database.

Client/Network Libraries

An important component of any database system is the client. Typically, the client is on a remote system from the database. The client also can connect from the local system. Connecting locally frequently is used with batch processes.

In order for a client to connect to the database, a client library or driver is required on the client's machine. This usually consists of a set of executables such as DLLs and shared objects, as well as an API that the client can use to connect to the database. The client libraries are hard to protect because they usually exist on remote systems where access controls are much more difficult to maintain. However, it is very important to maintain the integrity of the client drivers in locations from where administrators or even regular users will be connecting.

One weak point in the security model is the integrity of the client libraries. If the client drivers can be manipulated, credentials can be stolen fairly easily. Client drivers can be trojaned, or even something as simple as a keyboard logger on the client system can lead to a compromise of the database.

Communication over the network also requires network drivers on the database. These drivers are another point of focus for the auditor because they are the avenue that the attacker will use to access the database.

Backup/Restore System

Backups are a very important piece of every database platform. Failure in some component of the database is not a question of if but when. Whether the problem is a hardware or a software failure, having a backup is critical. Backups contain a copy of the database. The backup can be to a separate file, to a tape, or to another storage facility.

A very common place that data are stolen from, lost, or leaked is through the backup facility. Backups often are secured by encrypting the data as they are written to a file or encrypting the entire file after it is written. Storing the encryption key then becomes important to properly securing the backup. Just as important is ensuring that you have properly backed up the encryption keys along with the data so that the backup can be restored properly. If you can't restore the files, then the backup becomes worthless. Backups that cannot be restored result in a loss of utility.

SQL Statements

Structured Query Language (SQL) is used to access data in a relational database. Technically, SQL should be pronounced as three separate letters "S-Q-L," but the pronunciation "sequel" has become so commonplace it is also accepted as correct. SQL is a set-based language, meaning that it works on a set of data at a time. It is not a procedural language, meaning that it does not have any procedural components such as while loops, if statements, for loops, etc. Most database platforms do have extensions to SQL to provide procedural components. For instance, Oracle has PL/SQL, and Sybase and Microsoft SQL Server have Transact-SQL.

SQL statements are used to pull data from the database. SQL is built around four core statements, as illustrated in Table 9-1.

Table 9-1: SQL Statement Descriptions
SQL Statement | Description
SELECT | View a subset of data from a table
INSERT | Add new data to a table
UPDATE | Modify existing data in a table
DELETE | Remove a subset of data from a table

The statement you will need to understand best is SELECT. The basic syntax of the SELECT statement is

SELECT <COLUMN LIST> FROM <TABLE NAME> WHERE <CONDITION>

In this statement, <COLUMN LIST> is a comma-separated list of column names that will be displayed. As a shortcut, you can use an asterisk to display all columns in the output. <TABLE NAME> is replaced with the name of the table to be displayed. <CONDITION> and the word WHERE are optional. If you do not indicate a WHERE clause, all rows in the table are returned. Using the WHERE clause, you can SELECT only the rows you are interested in.

An example of selecting the first and last names of all employees who make more than $20,000 is shown here:

SELECT FIRST_NAME, LAST_NAME FROM EMPLOYEES WHERE SALARY > 20000

SELECT statements can get much more complex then this. Your audit typically does not need to go much deeper than this, though.

Database Objects

A database is composed of a variety of objects. Each object has a different task or serves a different purpose. Understanding each object is not necessary. However, you should have a grasp of the common object types.

Table 9-2 shows the most common types of database objects. Each database platform also has many proprietary object types, such as table spaces, schemas, rules, sequences, and synonyms. You should review the specific documentation for your database platform for more details.

Table 9-2: Database Objects
Object Type | Description
Table | Stores rows of data in one or more columns.
View | A SELECT statement on top of a table or another view that creates a virtual table. Views can change the number or order of columns, can call functions, and can manipulate data in a variety of ways.
Stored procedure/function | Procedural code that can be called to execute complex functionality within the database. Functions return values. Procedures do not return values. Stored procedures are very efficient for data access.
Trigger | Procedural code that is called when a table is modified. Can be used to perform any actions, including modifications to other tables, when data are changed.
Index | Mechanism to provide fast lookup of data. Indices are complex objects, and their proper tuning is critical to database performance.

Data Dictionary

The database stores metadata about itself. These metadata are referred to as the data dictionary or also sometimes as the system tables. The metadata tell the database about its own configuration, setup, and objects. Note that the metadata do not say anything about the content of the information in the database, only about the format of the database. The format of the data dictionary is static. The data dictionary does contain metadata about its own structure, but the data dictionary format is not something that can be modified easily.

The metadata in the data dictionary are designed to be manipulated. Rarely is the data dictionary manipulated directly. Instead, special stored procedures with complex validation logic are used to manipulate the system tables. Direct access to the system tables is dangerous because even a small misstep could corrupt the data dictionary, leading to serious database problems.

The data dictionary defines the rest of the database, specifying objects such as users, groups, and permissions. The data dictionary defines the structure of the database, including specifying where physical files are stored on disk, the names of tables, column types and lengths, and the code for stored procedure, trigger, and views.


Performing the Audit

Before actually conducting the audit, you will need a few basic tools. To start off with, you should have a checklist of the items you need to verify. You can create your own checklist, you can find checklists on the Internet, or you can even use the basic checklist we provide here.

Start off by meeting with and discussing the audit with the database administrator (DBA). Clearly, the DBA is not going to be excited about the idea of being audited. Therefore, do your best to approach the DBA in as friendly a way as possible. Make sure that the DBA understands that you are there to help, not hinder, his or her work.

Databases are very often 24/7 systems, meaning they are not allowed any down time. This will mean that you are going to get pushback on anything you want to do that could, with even the remotest possibility, affect database availability. The first time you as the auditor bring the database down, your job is going to be infinitely more difficult.

Be ready to optimize the time you will be accessing the system. Ensure that any account you are given on the system runs with only the permissions you need. Immediately after you are completed with any work, have the DBA lock the account. Don't delete the account-simply lock it until you are officially done with the audit. Then, if you do need to gather more information, the DBA simply will need to unlock the account rather than recreate it.

Perform as much work offline as possible. Ideally, you want to download the system tables, password hashes, files permissions, and all other information onto a local source. Then you can disconnect from the database and perform your audit steps offline with no risk of affecting the database. For instance, you want to ensure that you never do password strength testing on the database. The password hashes can be downloaded, and password strength testing can be done offline.

By you showing the DBA this level of caution with the database, he or she will, hopefully, give you the professional courtesy of letting you do your job. Being at odds with the DBA only results in an audit that provides little value to the organization.

Test Steps

Now that you are equipped with some background on databases, we need a plan for performing an audit. Many of the steps we will cover are almost identical to steps you would perform on an operating system or network audit, but they need to be placed in the context of the database. Some steps are simply unique to the database.

Review Database Permissions

Database permissions are slightly different from operating system privileges. Privileges are managed using the GRANT and REVOKE statements. For instance, the following SQL statement gives USER1 the permission to SELECT from the SALARY table:

GRANT SELECT ON SALARY TO USER1

The REVOKE statement is used to remove permissions that have been granted:

REVOKE SELECT ON SALARY FROM USER1

The GRANT statement can be used to selectively give permissions, such as SELECT, UPDATE, DELETE, or EXECUTE. This allows you to grant access to read the data in the table but limit the ability to modify the table. GRANT and REVOKE also can be used more selectively on a column-by-column basis.

1 Verify that database permissions are granted or revoked appropriately for the required level of authorization.

If database permissions are not restricted properly, access to critical data may occur. Database permissions also should be used to restrict people from using subsystems in the database that may be used to circumvent security. Security best practices dictate that permissions should be granted on a needs basis only. If permission is not specifically needed by an account, it should not be granted.

How

Talk with the database administrator, and determine which user accounts are required to have access to what data. There may be administrators who need access, accounts used by a web application to access the data, or even accounts used by batch jobs. Accounts that do not require permissions or access should be locked, disabled, or even removed.

2 Review database permissions granted to individuals instead of groups or roles.

Database best practices dictate that you should attempt to grant permissions to roles or groups, and those, in turn, should be granted to individuals. Use of roles or groups to allocate permissions reduces the chance of making administrative mistakes and allows for easier maintenance of security controls. When new permissions need to be granted, they can be granted to a single group rather than multiple accounts. In addition, when a user changes jobs, it is straightforward to revoke the role or group and grant new individuals the role or group.

How

Select the list of permissions from the database dictionary. Review for any permissions granted to an account or user. Check that privileges are granted to a role or group. The roles or groups then can be granted to individuals as needed.

You also will need to download the list of roles/groups and users/accounts to determine which are allowed to be granted. The lists of users and groups are stored in the data dictionary.

3 Ensure that database permissions are not implicitly granted incorrectly.

Database permissions can flow from many sources. For instance, ownership of an object grants implicit full control over that object in a database. Privileges such as SELECT ANY TABLE allow access to all data and can lead to unauthorized access to data. If you do not have a complete understanding of how database permissions are implicitly granted, permissions may be granted in a way that was not intended.

How

Review the specifics of the permission model for your database platform, and verify that you fully understand how permissions are inherited. Also review system privileges that allow access to data, such as SELECT ANY TABLE or granting privileged role to a user. Document permissions that are implicitly granted as well as explicitly to ensure that permissions are not allowed when they are not appropriate.

4 Review dynamic SQL executed in stored procedures.

Access to an object also can be gained by running stored procedures or functions. On Microsoft SQL Server, when executing code objects, access to any other objects owned by the stored procedure owner is allowed. On Oracle, running a stored procedure allows you to access objects as the stored procedure owner. This can be dangerous if stored procedures are not constructed properly and can be manipulated.

How

Review stored procedures specifically looking for issues such as SQL injection or any form of dynamic SQL. Restrict use of dynamic SQL in procedures that run with elevated privileges. In addition, ensure that you are logging any and all access to stored procedures that run under elevated privileges.

5 Ensure that row-level access to table data is implemented properly.

Relational databases are designed to GRANT permissions on a table or column. Unfortunately, they are not well designed to restrict access to a subset of rows in a table. When you grant a user SELECT on a table, he or she will have the ability to read every row in the table.

There are technologies to help manage this problem. For instance, Oracle has its virtual private databases (VPDs) that you can use to limit access to specific rows. You also can use views to programmatically restrict rows returned based on the user's context. A very common and practical approach is to use stored procedures to access tables. Using this strategy, the DBA does not need to grant permissions on the table, preventing the user from attempting to circumvent the stored procedure.

How

Discuss with the DBA the method of row-level access controls in the database. Ensure that a user cannot access data in a table that he or she is not authorized to view if he or she circumvents the application or stored procedure providing access. Access the database through a user's account to verify that the "effective" ability of the user is as intended.

6 Revoke PUBLIC permissions where not needed.

Many of the built-in stored procedures and functions in a database are granted to the group PUBLIC by default. Each database has a slightly different implementation of a PUBLIC group-generically, it represents everyone in the database. This means that permissions granted to PUBLIC apply to everyone.

This has led to many security issues in databases. Many of the built-in procedures may not appear dangerous and have no practical use for ordinary users. Security best practices dictate that you should restrict all access unless explicitly needed. If a procedure contains functionality that is not needed, it should not be granted to any users. This is especially important for permissions granted to PUBLIC.

Understand that there is a fine line here that you must try not to cross. If you revoke permissions that are needed, you may end up breaking necessary functionality. Blindly revoking all PUBLIC permissions is a recipe for disaster.

How

Start by gathering a list of all permissions, highlighting those granted to PUBLIC. Discuss with the DBA which procedures and features of the database are being used or may be used in the future. Then determine how much risk would be introduced by revoking permissions from objects that are clearly not needed. If everyone agrees to have the DBA permissions revoked, then it makes sense to revoke them. Always take a backup and provide an undo script that can be used to roll back any changes if you find out later that you need those permissions or something unexpectedly breaks.

Operating System Security

We are not going to go into depth on operating system security here because significant other sections of this book are dedicated to this topic. Start with the premise that a database not secured can be used to break into the operating system. Conversely, an operating system not secured can be used to break into the database. You can't have one without the other. Locking down one but not the other fails to provide proper security to either. Of course, realize that the database is ultimately what you ought to focus on because the database is the most "valuable" target in your network.

7 Restrict access to the operating system.

The best situation is to have the operating system dedicated to the database only. No users other than DBAs should have access to connect to the operating system from a Telnet or SSH shell, FTP, or any other method outside the application.

How

Verify with the sysadmin that all access to the operating system is restricted to DBAs only. Verify that any shell access is done over a secure protocol, preferable SSH. Check for any accounts on the operating system that should be removed.

8 Restrict permissions on the directory to which the database is installed.

Verify that permissions on the directory to which the database is installed are as restrictive as possible. Again, in an ideal world, the permissions on Unix and Linux would allow full control to the file owner and group and would allow no permissions for everyone. Unfortunately, some database functionality was written without security in mind, and we can find ourselves in the position of breaking database functionality by making file permissions too restrictive.

On Windows, similar measures should be taken. File permissions on the directory in which the database is installed should be limited to the account the database runs as. Ensure that the "Everyone" or "Anonymous" user does not have any permissions on database files. In addition, make sure that all drives being used to store database files use NTFS.

In an ideal situation, even the DBA would not need permissions on the underlying operating system files. However, given the need for the DBA to work with database files and backups, patch the database, and accomplish other chores, the DBA will need some access to the operating system files. Privileged users who do not need access to the operating system should not been granted permissions to it.

How

Connect to the operating system, and retrieve a list of file permissions on all database files. Review the listing to find any excessive privileges. On Unix, check that permissions are set to 770. Be careful in that if you revoke all permissions for "Everyone," many programs may break. Setting tight security is a good goal, but you may have to set exceptions to this policy. Document the reasons for exceptions. For Windows, make sure that permissions are not given to "Everyone." The best practice is to grant permissions to the DBAs who require access only.

9 Restrict permissions on the registry keys used by the database.

For database platforms running on Windows, you need to properly secure the registry keys being used by the database. The registry keys are used to store configuration values that are important to the secure functioning of the database. Make sure that only the account the database runs has permission to edit, create, delete, or even view these registry keys.

How

Review the security permissions through the Registry Editor or through a command-line utility such as GetDACL. After retrieving a complete list of the permissions, review to ensure that no excessive permissions exist.

Password Strength and Management Features

Many database platforms maintain their own authentication settings. You should ensure that passwords and the authentication mechanism do not become the weak link in the chain.

Other database platforms integrate with the operating system or some other security subsystem to provide authentication. For instance, DB2 UDB does not maintain its own usernames and passwords instead using the operating system or RACF for authentication. Microsoft SQL Server in Windows mode uses Windows authentication. This does not mean that users are not maintained in the database. Usernames continue to be maintained in the database because there needs to be a mapping of the users to groups as well as permissions and other database settings. However, the authentication happens at the operating system level instead of in the database.

Using integrated operating security for any of the database platforms has many pros and cons. Pros include

  • Operating system authentication typically is more robust than database authentication.

  • Operating system authentication typically includes more password management features.

  • Password management features are more likely to be implemented already at the operating system level.

Negatives include

  • Authentication is out of the DBA's hands.

  • A user with an operating system account can access the operating system of the database if it is not configured properly.

10 Check for default usernames and passwords.

The first basic item to audit for is default usernames and passwords. This continues to be an issue for databases. At least five database worms have been based on propagating through databases using default usernames and passwords. Table 9-3 classifies these default usernames and passwords into a few categories. There are collections of literally thousands of these default passwords that can be found on various security websites on the Internet.

Table 9-3: Default Passwords
Category | Description
Default database password | Created in a standard database install. Can be dependent on the components of the database that are installed. Most of the latest versions of databases have eliminated default database passwords. However, default passwords continue to be a serious concern in older versions of database software.
Sample or example passwords | Many samples, examples, and demonstrations of new or existing features are shown in SQL scripts that include creation of a test or sample account.
Default application password | When installing third-party products on top of a database, these products often will install and run using a default user-name and password to access the database. These are known to hackers and serve as a common route to break in.
User-defined default password | When a new account is created, often the password is set to an initial value and then is reset on first use. Problems arise when an account is created but never accessed. Ensure that passwords set on new accounts are random, strong passwords.

How

Verify that all default usernames and passwords have been removed or locked, or the passwords have been changed. There are utilities and tools both free and commercial that you can use to verify this.

11 Check for easily guessed passwords.

Users often use passwords that can be easily guessed by automated programs or clever hackers. The most common passwords used to be password and secret. People are more clever these days and select more secure passwords, but it is still important to ensure that passwords cannot be found in a dictionary or guessed by knowing your date of birth or dog's name.

How

Run a password strength test on password hashes to determine if any passwords are easily guessed. If you detect passwords that are found in a dictionary or can be guessed, talk to the users and help to educate them on the use of strong passwords.

12 Check that password management capabilities are enabled.

Many of the database platforms provide support for rich passwords management features. Oracle leads this area by including capabilities for all the following features:

  • Password strength validation functions

  • Password expiration

  • Password reuse limits

  • Password expiration grace time

  • Password lockout

  • Password lockout reset

One problem is that if you do not configure these settings, they do not provide any additional security. By default, these features are not enabled.

How

Select the configuration values from the database. Ensure that each password management feature is enabled and configured for an appropriate value for the environment. You will need to review the documentation for the database platform to determine the exact commands required.

Activity Monitoring

In this section we are talking about the type of auditing that involves recording the activity in the database. Proper auditing of access to sensitive data has become a standard requirement because of increased regulatory requirements. Regulations such as the Sar-banes Oxley Act have had a significant and positive impact on companies recording access to sensitive data. Until it became a regulatory requirement, it was simply not something very many organizations considered. There are many forms of auditing:

  • Access and authentication auditing. Determine who accessed which systems, when, and how.

  • User and administrator auditing. Determine what activities were performed in the database by both users and administrators.

  • Suspicious activity auditing. Identify and flag any suspicious, unusual, or abnormal access to sensitive data or critical systems.

  • Vulnerability and threat auditing. Detect vulnerabilities in the database, and then monitor for users attempting to exploit them.

  • Change auditing. Establish a baseline policy for database, configuration, schema, users, privileges, and structure, and then find and track deviations from that baseline.

13 Check that auditing is enabled.

Auditing provides you with a method of knowing when authorized activity is occurring. There are a number of methods that can be used to monitor activity. These include

  • Enabling native auditing in the database

  • Monitoring network traffic to audit database activity

  • Reviewing transaction logs to build an audit trail from the database

Different methods have different strengths and weaknesses. For instance, native auditing is relatively inexpensive because it is typically included in the database. Other solutions are more expensive but meet requirements that native auditing fails to provide.

How

Verify that auditing is enabled for the database. Ensure that the audit configuration meets the requirements of your organization. Review the list of sensitive data in the database, and verify that auditing is properly enabled for sensitive data. Ask the DBA for a list of people who accessed sensitive data for some time period, and see if he or she is able to generate a correct list.

Database Encryption

Encryption is a very broad term used to describe several forms of the subject. Encryption of network traffic has been available for many years-some people use network encryption well, as in SSH and HTTPS. There does remain a large amount of network traffic that is not encrypted, particularly in the database area. Encryption of files has been available even longer and is implemented more widely. Encryption of data in a database is a new topic that has been pioneered only recently. The challenges of encrypting databases are entirely different from those of encrypting files or network traffic. Here we will explore the challenges associated with the various uses of encryption.

14 Verify that network encryption is implemented.

There are two main purposes for network encryption. The first reason is to protect authentication credentials as they move across the network. The second reason is to protect the actual data in the database as they move over the network. The network is not a secure environment-IP addresses can be spoofed, and network traffic can be redirected and sniffed. It is critical that network traffic be encrypted not just over the external network but also on your intranet.

How

Verify that the network and client drivers have been configured to support encrypting network traffic using protocols such as SSL. Verify settings at both the client and the database. If able to, you may even want to take a sampling of network traffic to verify that no cleartext traffic is present.

15 Verify that encryption of data at rest is implemented where appropriate.

Encryption of data-at-rest involves encrypting data as they are stored in the database. While the different forms of encryption use similar algorithms, the format and use of the algorithms are entirely different. Arguably, encryption of data-at-rest is more important than other forms of encryption because the lifetime of data on disk or in the database is much longer than the lifetime of data on the network. If you look at where data are most likely to be stolen, it is directly from the database while at rest, not while traversing the network. This is strong reasoning to support increased use of encryption of data-at-rest.

Encryption of data-at-rest can be problematic, though. Specifically, if encryption is used incorrectly, it can create more problems than it solves. Encryption is not a replacement for the other layers in the security stack-it is a complement to the existing pieces.

The performance bottleneck for encryption in the database is very different from that for file or network encryption. In file/network encryption systems, encryption accelerators can be used to increase the throughput of data because data look substantially more like a stream. In database encryption, the encryption itself is not the bottleneck. The performance impact is almost entirely a product of the mechanisms needed to call out of the database. This is so because databases are working with many, many small pieces of data, so the ability to pull as many pieces of data back and call them out to do the encryption is the limiting factor in performance. Working with database encryption is very different from working with a stream of data, so improving that bottleneck doesn't significantly improve performance.

How

Verify that data that should be encrypted are encrypted properly. Most important, review the location where the encryption keys are stored because the strength of encryption relies on the strength of protection of the encryption keys. If the encryption keys are stored with the encrypted data, an attacker can subvert the security simply by extracting the encryption keys.

Check the disaster-recovery plan to ensure that encryption key management is included as a component. A mistake you do not want your DBA to make is to implement encryption features but fail to include key management in the backup procedures. Failing to back up encryption keys properly results in being unable to recover a database backup.

Database Vulnerabilities, Integrity, and the Patching Process

Databases pose an interesting dilemma with regard to patching. Many databases run on a 24/7 schedule, meaning that they have no allowance for down time. This means that no time is available to bring down the database to apply the patches.

The other major complication for database patching is that testing new patches is typically a 3- to 6-month process. Databases typically are so critical that patches cannot be installed without thorough testing. Given a quarterly patch cycle, the DBAs full-time job easily can become testing and applying new patches. This likely will become a fulltime job for DBAs moving forward, just as we have teams of people dedicated to patching our Windows and Unix systems.

One solution to the downtime problem has been the use of clustering. In a clustered environment, a single node in the cluster can be taken offline, patched, and brought back online. This can work but introduces complexity to the process.

16 Verify that the latest patches for the database have been installed.

One of the most important tasks as an auditor is to ensure that the latest patches have been applied to the database. It is not always easy to keep up with the latest patches because they are changing constantly, and each platform and version may have different patches to apply. In addition, you may have to analyze the patch to determine if the security vulnerabilities addressed in the patch apply to your installation.

Many DBAs attempt to mitigate the need to patch by removing components of the system they determine to have vulnerabilities. While this is a great practice because it does reduce the security risk, it should not be accepted as a long-term replacement for patching. First off, many vulnerabilities fixed in the patches are not documented by the database vendors. Believing that you eliminated the vulnerabilities the database vendor mentioned is a mistake–instead, you need to mitigate the risk using techniques you determine useful, but ultimately you need to apply the patches.

How

Attain as much information as possible about the latest patches, and determine the scope of the vulnerabilities addressed by the patches. Compare the patches with the patch level applied to the database. Talk to the DBA about steps taken to mitigate the risk if the patches are not applied in a timely manner. Even taking mitigating steps should not be accepted as a replacement for applying the latest patches.

17 Verify that the database is running a version the vendor continues to support.

Many legacy databases run versions of the database software that are no longer supported by the database vendor. This can become a problem when a security vulnerability is released, and the database cannot be patched because no patches are available from the vendor.

How

Verify with the database vendor which versions and platforms are supported and whether patches for security issues will be provided. Inventory the versions of the database that are being run, and check for any databases that fall under the unsupported versions. Ideally, you want to keep the databases upgraded to supported versions.

18 Verify that policies and procedures are in place to identify when a patch is available and to apply the patch.

Several of the database vendors, including Oracle and Microsoft, have regularly scheduled patch releases. It is important that you are prepared for the scheduled releases so that you can plan appropriately for patching and testing of the patching. There should be people responsible for reviewing the patches and analyzing them. Installing a patch often can be delayed safely if it is determined that there are ways to mitigate vulnerabilities through simpler steps.

How

Interview the DBA to determine who reviews advisories from vendors, what steps are taken to prepare for the patches, and how long the patches are tested before applying to the production databases, and even ask for notes from the previous patching cycle.

19 Check the integrity of the database by looking for root kits, viruses, backdoors, and Trojan horses.

As the hacker tools designed to break into databases grow in sophistication, we expect to see more robust ways to control the database by hackers. Currently, there are a handful of these types of tools, and their numbers are growing quickly. These attack tools require that an attacker gain some access to the database to install these tools. Many different delivery mechanisms are being used, including installation by a disgruntled employee, being hidden in an e-mail, or leveraging a vulnerability.

How

These malicious tools are difficult to find because they are often designed to hide themselves from detection. There are counter-tools designed specifically to detect and disinfect your database, which are much more accurate than manually attempting to find a backdoor or other infections. You can, of course, check for these types of infections manually, although doing so manually is technically difficult. Doing so requires looking very closely at the data dictionary. Root kits are implemented by modifying the commonly used system-stored procedures and system views, so you will need to look even closer at the dynamic tables that exist underneath the system views.


Tools and Technology

While you can perform most of your audit using manual methods, it is often helpful to have a set of tools to perform repetitive or technical chores. Tools allow you to spend more time working on results rather than doing the actual work or wrestling with the technical details. Auditing tools are useful at providing you raw materials that you will need to analyze and interpret. This is the added value that a human auditor brings when using one of these tools.

Tools are useful for looking for vulnerabilities and patches. There are two common perspectives on scanning a database for patches and vulnerabilities. One is to look for and document as many vulnerabilities as possible. The other is to deemphasize vulnerabilities and instead focus on what patches you have installed. The first view is great for figuring out how bad your security is. The second view focuses less on vulnerabilities and instead pushes you toward a solid plan for implementing a patching process. The first view focuses on ad hoc vulnerabilities and handling them on a one-off basis. At the end of the day, you and the DBA need to know what patches you haven't applied, not the technical details of every vulnerability in the system.

It's also important to understand that network and operating system auditing tools fail miserably at helping with database audits. Why is this? Databases are complex beasts. They have their own access-control systems, their own user accounts and passwords, their own auditing subsystems, and even their own network protocols. Generic scanners simply do not have the expertise to provide more then a cursory look at the database.

There are a number of tools that are specialized to help the auditor run audits on a database. These tools include:

  • AppDetective by Application Security, Inc.

  • NGSSquirrel by NGS Software, Ltd.

  • Database Scanner by Internet Security Systems, Inc.

There are also tools designed to assist you in database activity monitoring. As an auditor, you have influence over the use of these tools to properly record and detect unauthorized or malicious access to sensitive data. You will need to determine what regulations apply to the database and translate them into terms that can be implemented as native auditing or more in-depth activity monitoring.

Several tools are listed below that provide the needed technology for monitoring activity in the database:

  • AppRadar from Application Security, Inc.

  • Database Security & Compliance Platform from IPLocks

  • SQL Guard from Guardium

  • AuditDB from Lumigent

Auditors also need to understand the tools available to meet database encryption requirements. These tools include:

  • DbEncrypt from Application Security, Inc.

  • Secure.Data from Protegrity

  • Encryptionizer from NetLib

  • DataSecure from Ingriam


Knowledge Base

The set of knowledge around database security is not nearly as vast as the knowledge around network or operating system security. There is, however, enough detail to effectively get the job done.

Below is a list of books written to assist in securing and understanding security in databases. If you do need to run an audit, it is recommended you review one of these books that apply to your specific database platform.

  • Oracle Security Handbook, by Marlene L. Theriault and Aaron C. Newman

  • Oracle Security Step-by-Step, by Pete Finnigan

  • The Database Hacker's Handbook, by David Litchfield, Chris Anley, Bill Grindlay, and John Heasman

  • Implementing Database Security and Auditing, by Ron Ben Natan

  • SQL Server Security, by Chip Andrews, David Litchfield, Chris Anley, and Bill Grindlay

  • SQL Server Security Distilled, by Morris Lewis

  • SQL Server Security: What DBAs Need to Know, by K. Brian Kelley

  • Oracle Privacy Security Auditing, by Arup Nanda and Donald Burleson

  • Effective Oracle Database 10g Security by Design, by David Knox

  • Special Ops, by Erik Birkholz et al.

  • Mysql Security Handbook, by Wrox Author Team

  • Cryptography in the Database: The Last Line of Defense, by Kevin Keenan

  • Database Security, by Maria Grazia Fugini, Silvana Castano, and Giancarlo Martella

  • Database Security and Auditing: Protecting Data Integrity and Accessibility, by Sam Afyouni

There are many online technical guides as well. The advantages of these guides are that they are often free, more update to date, and can be accessed from anywhere. Of course, they are also typically incomplete and not nearly as comprehensive as the books just listed.

  • Oracle Database Security Checklist, by Oracle Corporation; available at http://www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_db_database.pdf

  • A Security Check List for Oracle9i, by Oracle Corporation; available at http://www.otn.oracle.com/deploy/security/oracle9i/index.html

  • SANS Oracle Security Checklist; available at http://www.sans.org/score/checklists/Oracle_Database_Checklist.doc

  • Ten Steps to Securing SQL Server 2000; available at http://www.microsoft.com/sql/techinfo/ administration/2000/security/securingsqlserver.asp

  • SQLSecurity.com Checklist; available at http://www.sqlsecurity.com

  • NIST Security Checklists; available at http://www.checklists.nist.gov/repository/ category.html

  • ISACA Auditing Guidelines; available at http://www.isaca.org/

You also can gain practical, hands-on experience by attending a training course on database security. Below is a list of the more popular training courses:

  • Red-Database-Security

  • SANS course

  • MIS Training

The majority of database vulnerabilities discovered and fixed can be credited to a relatively small subset of security researchers. While some groups, including many of the database vendors, view this work as "malicious," security researchers have done the database security market a huge service, and to top it all off, they have done it free of charge. The database vendors themselves have gone as far as to threaten law suits and revoke partnership agreements, and they have been particularly vocal about telling customers about how security researchers are "evil." The silver lining is that these security researchers are real watchdogs in the community. A good number of the really simple security vulnerabilities have been eliminated or at least reduced because of the work of these security researchers. Of course, the vendors have been dragged into securing and fixing their databases kicking and screaming the whole way.

The most prominent database security research teams include

  • Argeniss Information Security at http://www.argeniss.com

  • Red-Database-Security at http://www.red-database-security.com

  • Application Security, Inc., Team SHATTER at http://www.appsecinc.com/aboutus/ teamshatter/index.html

  • NGS Research at http://www.ngssoftware.com

  • Pentest Limited at http://www.pentest.co.uk

  • Pete Finnigan at http://www.petefinnigan.com

  • Integrigy at http://www.integrigy.com

  • Chip Andrews at http://www.sqlsecurity.com

These websites serve as the most definitive source of vulnerability information on databases. If you have a question about a particular vulnerability, search these locations, and you're likely to find an answer.

As always, never forget the most up-to-date source of database security–Google. Simply search on any term of interest such as "Oracle Exploits" or "Auditing MySQL." Google provides a great list of resources to explore to help you do your job.


Master Checklist

Auditing Databases

Checklist for Auditing Databases

  1. qVerify that database permissions are granted or revoked appropriately for the required level of authorization.

  2. qReview database permissions granted to individuals instead of groups or roles.

  3. qEnsure that database permissions are not implicitly granted incorrectly.

  4. qReview dynamic SQL executed in stored procedures.

  5. qEnsure that row-level access to table data is implemented properly.

  6. qRevoke PUBLIC permissions where not needed.

  7. qRestrict access to the operating system.

  8. qRestrict permissions on the directory to which the database is installed.

  9. qRestrict permissions on the registry keys used by the database.

  10. qCheck for default usernames and passwords.

  11. qCheck for easily guessed passwords.

  12. qCheck that password management capabilities are enabled.

  13. qCheck that auditing is enabled.

  14. qVerify that network encryption is implemented.

  15. qVerify that encryption of data-at-rest is implemented where appropriate. Ensure that encryption key management is part of the disaster-recovery plan.

  16. qVerify that the latest patches for the database have been installed.

  17. qVerify that the database is running a version the vendor continues to support.

  18. qVerify that policies and procedures are in place to identify when a patch is available and to apply the patch.

  19. qCheck the integrity of the database by looking for root kits, viruses, backdoors, and Trojan horses.


Chapter 10: Auditing Applications

This chapter should be used to generate thoughts and ideas regarding audit program steps more specific to the application being audited. Staying on top of every new technology that attaches itself to your environment is tough. It's our job as auditors to quickly drill down into new applications to find potential control weaknesses. We're going to discover how to examine applications conceptually using big-picture and abstract frameworks. We also will suggest a fairly comprehensive set of checks that will greatly assist you in covering the vast majority of common control weaknesses.

Application Auditing Essentials

It's perfect when you have a perfect audit program you can apply quickly to your perfect application. However, the reality is that you're faced with new ideas and approaches for solving business problems with new technology that requires a new audit program. As you struggle with the questions to ask, you will find the frameworks and best practices below helpful.


Generalized Frameworks

Generalized frameworks are useful for meetings where you've been put on the spot to come up with questions and possible risks associated with a new application. You might even find yourself walking into a meeting, taking out a blank sheet of paper, and writing "PPTM," "STRIDE," and "PDIO" at the top before the meeting ever starts.

PPTM

People, processes, tools, and measures(PPTM) is a great brainstorming framework to examine an application from the macro level. Detailed specific technical review steps dominate this chapter. PPTM helps you to come up with your own steps quickly and efficiently as they apply to your unique situation.

People People in PPTM describes every aspect of the application that deals with a human. Ensure that the right people are involved in the planning, design, implementation, or operations for the project and that the right stakeholders are involved. If the application involves end users, then ensure that the application has controls around provisioning and deprovisioning access and that the end users have been involved in the components that they ultimately will interface with. There is little that's more embarrassing than to spend time and money rolling out an application just to find out that upper management doesn't approve or that the end users find that the interface is too complicated to use.

Process Process in PPTM describes every aspect of the application that is involved in a policy, procedure, method, or course of action. Review the interaction of the application with interfacing systems and verify compliance in security models or ensure firewalls are in place to protect the application from external applications, users, business partners, and the like. Procedures and policies should be written to support how the application is intended to be used. Adequate documentation also should exist to support technicians that need to maintain the application.

Tools Tools in PPTM describe every aspect of the application that deals with a concrete technology or product. Ensure the right hardware and environment exists to support the application and that the application interfaces with recommended technologies appropriate to your intended policies and procedures. Verify the application and infrastructure are tested and audited appropriately.

Measures Measures in PPTM describe every aspect of the application that is quantifiable conceptually, such as the business purpose or application performance. For example, verify the application meets well-documented and well-thought-out acceptance criteria. The application should solve the business problem it is intended to solve. Logs should be meaningful, and you should be able to measure the performance of the application and ensure you can support it.

STRIDE

STRIDE is a methodology for identifying known threats. The STRIDE acronym is formed from the first letter of each of the following categories and is an example of a simplified threat-risk model that is easy to remember and apply.

Spoofing Identity Identity spoofing is a key risk for applications that have many users but provide a single execution context at the application and database levels. In particular, users should not be able to become any other user or assume the attributes of another user.

Tampering with Data Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, that are obtainable only from within the application itself. The application also should carefully check data received from the user and validate that it is sane and applicable before storing or using it. For web and other applications with a client component, ensure you perform your validation checks on the server and not the client, where the validation checks might be tampered with.

Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, "But I didn't transfer any money to this external account!" and you cannot track his or her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user's privileges, not more, but this may not be possible with many commercial off-the-shelf applications.

Information Disclosure Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also consider if the user's web browser may leak information. Some web browsers may ignore the no-caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser just in case it leaks or leaves information behind which can be used by an attacker to learn details about the application or the user, possibly using that information to assume the role of an authorized privileged user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should never be relied on to secure especially sensitive information or to provide adequate personal privacy safeguards.

Denial of Service Application designers should be aware that their applications may be subject to a denial-of-service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users and not be available to anonymous users.

For applications that don't have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, and to avoid exposing large files or unique links per user in order to prevent simple denial-of-service attacks.

Elevation of Privilege If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his or her role to a higher privileged one. In particular, simply not displaying privileged-role links is insufficient. Instead, all actions should be gated through an authorization matrix to ensure that only the permitted roles can access privileged functionality.

PDIO

PDIO comes from Cisco Systems and stands for planning, design, implementation, and operations. Sometimes it's important to consider the potential challenges at each stage of a project. You might find this framework useful as you look at a new application and think ahead to the upcoming challenges. There might be a problem, for example, if system administrators are tossing around ideas in a planning or design session for a network solution and the senior networking engineer isn't in the room. If you as an auditor are asked to look at the implementation of a new solution, you should immediately ask questions about the ongoing operations of the solution.


Best Practices

These best practice concepts help you quickly spot common weak areas and poor controls.

Apply Defense in Depth

Layered approaches provide more security over the long term than one complicated mass of security architecture. You might, for example, use access-control lists (ACLs) on the networking and firewall equipment to only allow necessary traffic to reach the application. This approach significantly lowers the overall risk of compromise to the system on which the application is running because you quickly eliminate access to services, ports, and protocols that otherwise would be accessible to compromise.

Use a Positive Security Model

Positive (whitelist) security models only allow what is on the list, excluding by default everything else. However, negative (blacklist) security models allow everything by default, eliminating only the items you know are bad. This is the challenge to antivirus programs, which you must update constantly to keep up with the number of new possible attacks (viruses) that could affect you. The problem with this model, if you are forced to use it, is that you absolutely must keep the model updated. Even with the model updated, a vulnerability could exist that you don't know about, and your attack surface is much larger than if you used a positive security model.

Fail Safely

There are basically three responses when an application fails. You can allow, block, or error. In general, application errors should fail in the same manner as a disallow operation as viewed from the end user. This is important because then the end user doesn't have additional information to use that may help him or her to compromise the system. Log what you want, and keep any messages that you want elsewhere, but don't give the user additional information he or she might use to compromise your system.

Run with Least Privilege

The principle of least privilege mandates that accounts have the least amount of privilege possible to perform their activity. This encompasses user rights and resource permissions such as CPU limits, memory capacity, network bandwidth, and file system permissions.

Avoid Security by Obscurity

Obfuscating data, or hiding it instead of encrypting it, is a very weak security mechanism, especially for an application. If a human was able to figure out how to hide the data, there is a good chance that another person is going to learn how to recover the data. A real-world example is how some people will hide a key to their house under the doormat. A criminal wants the easiest possible way into the house and will check common places such as the doormat, the closest rock to the door, and above the door frame for a key. Never obfuscate critical data that can be encrypted or never stored in the first place.

Keep Security Simple

Simple security mechanisms are easy to verify and easy to implement correctly. Bruce Schnieir is famous for suggesting that the quickest method to break a cryptographic algorithm is to go around it. Avoid overly complex security mechanisms, if possible. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler. Don't confuse complexity with layers. Layers are good. Complexity isn't.

Detect Intrusions and Keep Logs

Applications should have built-in logging that's protected and easily read. Logs help you to troubleshoot issues and, just as important, help you to track down when or how an application might have been compromised.

Never Trust Infrastructure and Services

Many organizations use the processing capabilities of third-party partners, who more than likely have differing security policies and postures than you. It is unlikely that you can influence or control any external third party, whether they are home users or major suppliers or partners. Therefore, implicit trust of externally run systems is dangerous.

Establish Secure Defaults

Your applications should arrive to you or be presented to the users with the most secure default settings possible and still allow business to function. This may require training end users or communications messages, but the end result is a significantly reduced attack surface, especially when an application is pushed out across a large population.

Use Open Standards

Where possible, base security on open standards for increased portability and interoperability. Since your infrastructure is likely a heterogeneous mix of platforms, the use of open standards helps to ensure compatibility between systems as you continue to grow. Additionally, open standards are often well known and scrutinized by peers in the security industry to ensure that they remain secure.


Performing the Application Audit

These steps generally refer to controls specific to the application and do not address general controls at the level of the network, operating system, and database management system. Please refer to other sections of this book for general controls at these levels and consider the frameworks and concepts enumerated earlier in this chapter as you approach developing the audit program for your application.

Part 1-Input Controls

Incorrectly implemented or checked input controls consistently remain top reasons why applications suffer vulnerabilities. Examples include buffer overflows and injection attacks.

1 Review and evaluate data input controls.

As much as possible, online transactions should perform upfront validation and editing in order to ensure the integrity of data before they are entered into the system's files and databases.

How

Verify that invalid data are rejected or edited on entry. The auditor will need to understand the business function being supported by the system and the purpose and use of its various data elements. This likely will require discussion not only with the developers but also with the end users. Once the purpose of the system and its data are understood, it will be much easier for the auditor to think through the various data-integrity risks associated with the application. In some cases, a code review may be appropriate if the developers are available and the auditor is a knowledgeable coder. Poorly written, commented, or formatted code is often a red flag that suggests that a deeper review is needed. Some basic examples of good data input controls include

  • Fields that are intended to contain only numbers should not allow entry of alphanumeric characters.

  • Fields that are used to report such things as dates and hours should be set up to either require input in the correct format (such as MMDDYY or HHMM) or to transform input into the correct format.

  • Where applicable, transactions should perform "reasonableness" checks on inputs. An example would be preventing users from reporting labor of more than 24 hours in a day or more than 60 minutes in an hour. Another example would be disallowing entry for time, costs, etc. for an employee who has been terminated or who is on LOA.

  • When there are a finite number of valid entries for a field, entries that are invalid should not be allowed. In other words, input screens should validate such things as cost centers, account numbers, product codes, employee numbers, etc. against the appropriate database(s) or file(s).

  • Duplicate entries should not be allowed for data that are intended to be unique. For example, the transaction should not allow a product code to be added to the product database if that code already exists on the database.

  • Where applicable, the transaction should perform "logic" checks. For example, if there were a transaction used by ticket agents to record how many seats were sold on a flight and how many no-shows there were, the transaction should not allow the agent to input numbers indicating that there were more no-shows than seats sold.

  • Each input screen generally has certain fields that are required for the transaction to be processed accurately. Execution of a transaction should not be allowed until valid data are entered into each of those fields.

  • Where applicable, transactions should perform "calculation" checks on inputs. For example, the system should ensure that journal-entry credits and debits balance to zero before processing a transaction. Another example would be a labor-entry system where hours charged for the week need to add up to at least 40.

  • Programmed cutoff controls should be in place to help prevent users from recording transactions in the wrong period. In other words, the screen should not allow users to record transactions in prior accounting periods.

  • Database operatives such as *, =, or select) should be disallowed as valid input.

2 Determine the need for error/exception reports related to data integrity and evaluate whether this need has been filled.

Error or exception reports allow any potential data-integrity problems to be reviewed and corrected when it's not feasible or practical to use input controls to perform upfront validation of data entered into the system. For example, while it may not be inherently wrong for an employee to enter 80 hours of overtime for one week into a labor system, this sort of unusual event should be captured on a report for review by the appropriate level of management.

How

Discuss the application's error and exception handling with the developer or administrator. Based on the results of the analysis from step 1, look for opportunities for additional data integrity checks (that may not have been feasible to perform with "hard" upfront input requirements). Again, discussions with the end users can be very helpful here. Ask them what sorts of reporting would be helpful for them in catching anomalies and errors. In some cases, a code review may be appropriate if the developers are available and the auditor is a knowledgeable coder. Poorly written, commented, or formatted code is often a red flag that suggests that a deeper review is needed.

Part 2-Interface Controls

3 Review and evaluate the controls in place over data feeds to and from interfacing systems.

When an application passes and/or receives data to or from other applications, controls need to be put in place that ensure that the data are transmitted completely and accurately.

How

Discuss data-feed controls with the application developer or administrator. Expect to see basic controls such as

  • Control totals from interface transmissions should be generated and used by the system to determine whether the transmission completed accurately. If a problem is found, reports should be issued that notify the proper people of the problem. Some examples of control totals that may be applicable are hash totals, record counts, and total amounts (for numerical records). Another type of control total could flag missing record numbers when records are transmitted in a sequential fashion.

  • The system should handle items that did not transmit successfully in such a manner that reports and/or processes enable these items to be resolved quickly and appropriately with audit trails as appropriate.

  • Data files that contain interface source or target information should be secured from unauthorized modifications. This may mean appropriate authentication controls, authorization controls, or encryption where necessary.

  • When it is not feasible to use control totals to verify accurate transmission of data, reconciliation reports should be generated that allow users to compare what was on one system with what was received on another system.

  • Where applicable, data validation and editing, as described in the "Input Controls" section of this checklist, should be performed on data received from outside systems. Error/exception reports should be generated that allow any data-integrity problems to be corrected.

4 In cases where the same data are kept in multiple databases and/or systems, ensure that periodic sync processes are executed to detect any inconsistencies in the data.

How

Determine with the help of the application developer or application administrator where this sort of control is applicable, and review for its existence and effectiveness.

Part 3-Audit Trails

5 Review and evaluate the audit trails present in the system and the controls over those audit trails.

Audit trails are useful for troubleshooting and helping to track down possible breaches of your application.

How

Review the application with the developer or administrator to ensure rinformation is captured when key data elements are changed. This information should include in most cases the original and new values of the data, who made the change, and when the change was made. This information should be kept in a secured log in order to prevent unauthorized updates. The logs should be retained for a reasonable period of time, such as three or six months, in order to aid investigations into errors or inappropriate activities.

6 Ensure the system provides a means to trace a transaction or piece of data from the beginning to the end of the process enabled by the system.

This is important to verify that the transaction was fully processed and to pinpoint any errors or irregularities in the processing of that data.

How

Review the application with the developer or administrator and evaluate the existence of this ability.

Part 4- Access Controls

7 Ensure the application provides a mechanism which authenticates users, based, at a minimum, on a unique identifier for each user and a confidential password.

Failure to authenticate users or just having a poor authentication scheme presents an open opportunity for curious users and malicious attackers.

How

Review the application with the developer or administrator and verify appropriate authentication measures exist commensurate with the type of data on the application. For example, two-factor authentication might be required in some cases to authenticate users in sensitive environments or for end-users accessing your network from their homers.

8 Review and evaluate the application's authorization mechanism to ensure users are not allowed to access any sensitive transactions or data without first being authorized by the system's security mechanism.

The system's security mechanism should allow for each system user to be given a specific level of access to the application's data and transactions.

How

Employees should only be given the amount of access to the system which is necessary for performing their jobs. Review the application with the developer or administrator, and verify this functionality in the application. In other words, it should be possible to specify which specific transactions and datasets or files a system user will access. In general, it also should be possible to specify what level of access (e.g., display, update, and delete) the user will receive to application resources.

9 Ensure that the system's security/authorization mechanism has an administrator function with appropriate controls and functionality.

The administrator user function should exist to help administer users, data, and processes. This account or functionality should be tightly controlled in the application to prevent compromise and disruption of services to other users.

How

Evaluate the use of the administrator function with the developer or application administrator. The user of this function should have the ability to add, delete, or modify user access to the application system and its resources. The security mechanism should also provide the ability to tightly control who has access to this administrator function. Also ensure that the system's security mechanism provides the system's security administrator with the ability to view who has access to the system and what level of access they have.

10 Determine whether the security mechanism enables any applicable approval processes.

The application's security mechanism should support granular controls over who can perform what approval processes, and then lock data that has been formally approved from modification by a lower authority. Otherwise, a lower authority or malicious user could modify or corrupt data in the system.

How

Verify with the developer or application administrator that appropriate controls are in place. For example, if there is a need for sign-off of journal entries before they can be passed on to the general ledger, the system's security mechanism should provide a means for defining who is authorized to perform this sign-off. Any data that have been through this sort of approval process should be locked from any further modifications.

Interviews with system users are a good mechanism for helping the auditor to determine the need for this sort of ability. It is critical for the auditor to understand not only the technical aspects of the application being reviewed but also the business purpose.

11 Ensure that a mechanism or process has been put in place that suspends user access on termination from the company or on a change of jobs within the company.

Poor deprovisioning processes may leave a user with inappropriate access to your application long after the access or authority should have been removed.

How

Verify appropriate deprovisioning processes are in place with the developer and application administrator. Be sure to look at both the application and the procedures around the application to ensure they are being followed and are capable of being followed as written.

For applications that have been in "production" for some time, select a sample of system users, and validate that their access is still appropriate. Alternatively, if possible, select a sample of system users who have changed jobs or left the company, and ensure that their access has been removed.

12 Verify that the application has appropriate password controls.

The appropriateness of the password controls depends on the sensitivity of the data used within the application. Overly weak passwords make the application sensitive to compromise, and overly strong passwords often force users to write them down in plain sight or to never want to change their password.

How

Verify appropriate password controls with the help of the developer or the application administrator. For example, three-digit PIN numbers probably are inappropriate for applications that store credit-card data, and a 20-character password probably is overly paranoid for someone trying to access his or her voicemail. Ensure that the security mechanism requires users to change their passwords periodically (e.g., every 30 to 90 days). When appropriate, the security mechanism also should enforce password composition standards such as the length and required characters. Additionally, the security mechanism should suspend user accounts after a certain number of consecutive unsuccessful log-in attempts. This is typically as low as 3 and can be as high as 25 depending on the application, other forms of authentication required, and the sensitivity of the data.

13 Review and evaluate processes for granting access to users. Ensure that access is granted only when there is a legitimate business need.

Users should have intentional access granted and governed by the application to prevent unauthorized access to areas outside the intended scope for the user. The application should have controls in place to prevent users from having more access than is required for their role. This step embodies the concept of least-privileged access.

How

Review the application with the developer or administrator. Possibly select a sample of users, and ensure that user access was approved appropriately. Verify that the authorization mechanism is working appropriately.

14 Ensure that users are automatically logged off from the application after a certain period of inactivity.

A person could have access to the application if they walk up to a logged-in workstation where the previous user didn't log off and the application is still active.

How

Review the application with the developer or administrator to evaluate the existence of this ability.

15 Evaluate the use of encryption techniques to protect application data.

The need for encryption is determined most often by either policy, regulation, the sensitivity of the network, or the sensitivity of the data in the application. Where possible, encryption techniques should be used for passwords and other confidential data that are sent across the network. This prevents other people on the network from "sniffing" and capturing this information.

How

Review the application with the developer or administrator to evaluate the existence of encryption where appropriate.

16 Evaluate application developer access to alter production data.

In general, system developers should not be given access to alter production data.

How

Discuss with the developer or administrator, and evaluate the separation of duties between developers and administrators.

Part 5- Software Change Controls

Software change management (SCM), used by a trained software development team, generally improves the quality of code written, reduces problems, and makes maintenance easier.

17 Ensure that the application software cannot be changed without going through a standard checkout/ staging/testing/approval process after it is placed into production.

It should not be possible for developers to update production code directly. Should a failure in the application occur without enforced software change controls, then it might be difficult to impossible to track down the cause of the problem. Additionally, developers should not have access to data in production applications. This is particularly true if the application data are sensitive.

How

Evaluate this capability with the developers and application administrator.

18 Evaluate controls around code checkout, modification, and versioning.

Strong software controls around code checkout, modification, and versioning provide accountability, protect the integrity of the code, and have been shown to improve maintenance and reliability.

How

Verify with the developers that the software-change mechanism requires developers to check out code that they wish to modify. If another developer wishes to modify the same code while it is still checked out, he or she should be prevented from doing so. Alternatively, the second developer could be warned of the conflict but allowed to perform the checkout. In such a case, a notification of the duplicate checkout should be sent automatically to the original developer.

Additionally, ensure that the software-change mechanism requires sign-off before code will be moved into production. The system should require that this sign-off be performed by someone other than the person who developed or modified the code. In addition, the software-change mechanism should allow for specific people to be authorized to perform sign-off on the system's programs. The people with this authorization should be kept to a minimum.

Evaluate controls in place to prevent code from being modified after it has been signed off on but before it has been moved to production. Ensure that the software-change mechanism ‘versions’ software so that past versions of the code can be retrieved, if necessary.

19 Evaluate controls around the testing of application code before it is placed into a production environment.

Improperly tested code may have serious performance or vulnerability issues when placed into production with live data.

How

Determine whether the software-change process requires evidence of testing, code walkthroughs, and adherence to software-development guidelines. These should occur before the approver signs off on the code. Testing of any software development or modifications should take place in a test environment using test data. Determine whether this is the case.

Part 6- Backup and Recovery

20 Ensure that appropriate backup controls are in place.

Failure to back up critical application data may severely disrupt business operations in the event of a disaster.

How

Determine whether critical data and software are backed up periodically (generally weekly full backups with daily incremental backups for the data) and stored off-site in a secured location. If cost beneficial and appropriate, duplicate transaction records should be created and stored in order to allow recovery of data files to the point of the last processed transaction. Also ensure that the application code is backed up and stored offsite in a secured location, along with any tools necessary for compiling and using the code.

21 Ensure that appropriate recovery controls are in place.

Recovery procedures and testing are necessary to ensure that the recovery process is understood and functions operationally as intended.

How

Discuss with the application administrator and appropriate personnel to ensure that detailed recovery procedures are documented that define what tasks are to be performed, who is to perform those tasks, and the sequence in which they are to be performed. Testing of the recovery from backup tapes using the documented recovery procedures should be performed periodically.

Part 7- Data Retention and Classification

22 Evaluate controls around the application's data retention.

Data should be archived and retained in accordance with tax and legal requirements.

How

Evaluate the appropriateness of the controls with the developers and application administrator. These requirements will vary based on the type of data and should be acquired from the appropriate departments within your company.

23 Evaluate the controls around data classification within the application.

All application data should be assigned a business owner, and this owner should classify the data (e.g., public, internal use only, or confidential).

How

This classification should appear on any reports or transactions that display system data. Determine whether this has been done.

Part 8-Operating System, Database, and Other Infrastructure Controls

Detailed guidelines for controlling the operating system, database, and other related infrastructure components are beyond the scope of this chapter. However, security of the infrastructure on which the application resides is a critical part of application security. The applicable audit programs from this book's other chapters should be executed in addition to the application-specific steps provided earlier in this chapter.


Master Checklists

Application Best Practices

Checklist for Best Practices

  • qApply defense-in-depth.

  • qUse a positive security model.

  • qFail safely.

  • qRun with least privilege.

  • qAvoid security by obscurity.

  • qKeep security simple.

  • qDetect intrusions and keep logs.

  • qNever trust infrastructure and services.

  • qEstablish secure defaults.

  • qUse open standards.

Auditing Applications

Checklist for Auditing Applications

  1. qReview and evaluate data input controls.

  2. qDetermine the need for error/exception reports related to data integrity, and evaluate whether this need has been fulfilled.

  3. qReview and evaluate the controls in place over data feeds to and from interfacing systems.

  4. qIn cases where the same data are kept in multiple databases and/or systems, periodic ‘sync’ processes should be executed to detect any inconsistencies in the data.

  5. qReview and evaluate the audit trails present in the system and the controls over those audit trails.

  6. qThe system should provide a means to trace a transaction or piece of data from the beginning to the end of the process enabled by the system.

  7. qThe application should provide a mechanism that authenticates users based, at a minimum, on a unique identifier for each user and a confidential password.

  8. qReview and evaluate the application's authorization mechanism to ensure that users are not allowed to access any sensitive transactions or data without first being authorized by the system's security mechanism.

  9. qEnsure that the system's security/authorization mechanism has an administrator function with appropriate controls and functionality.

  10. qDetermine whether the security mechanism enables any applicable approval processes.

  11. qEnsure that a mechanism or process has been put in place that suspends user access on termination from the company or on a change of jobs within the company.

  12. qVerify that the application has appropriate password controls.

  13. qReview and evaluate processes for granting access to users. Ensure that access is granted only when there is a legitimate business need.

  14. qEnsure that users are automatically logged off from the application after a certain period of inactivity.

  15. qEvaluate the use of encryption techniques to protect application data.

  16. qEvaluate application developer access to alter production data.

  17. qEnsure that the application software cannot be changed without going through a standard checkout/staging/testing/approval process after it is placed into production.

  18. qEvaluate controls around code checkout, modification, and versioning.

  19. qEvaluate controls around the testing of application code before it is placed into a production environment.

  20. qEnsure that appropriate backup controls are in place.

  21. qEnsure that appropriate recovery controls are in place.

  22. qEvaluate controls around the application's data retention.

  23. qEvaluate controls around data classification within the application.


Chapter 11: Auditing WLAN and Mobile Devices

WLAN and Mobile Devices Background

Mention wireless inside a corporate environment and people immediately think of either their data-enabled mobile phones or the nearest WLAN access point. For different reasons, both these growing-and now generally accepted-technologies present challenges to corporate security.

Conceptually, WLAN and mobile devices both communicate using electromagnetic radio waves from the device to a remote base station. Laptops wirelessly connect to the network through access points (APs) set up by your company. Data-enabled mobile devices communicate to cell towers set up by the mobile operators such as Verizon, Orange, and Cingular before reaching your network. Both technologies are capable of carrying sensitive company data over the network and out over the airwaves. Both technologies also have issues that necessitate forethought into the security of the data en route from the user to your protected and beloved network.

WLAN Background

WLAN enables you to roam past your cube into the conference room and still get your e-mail. However, WLAN traditionally presents problems to information technology (IT) administrators because of the low cost of the access points and the willingness of corporate citizens to compromise the security of the network in favor of getting more work completed. The good news is that WLAN is improving in both the standards and education of the administrators to keep the network secure. Enough bad press and stories of "wardriving" have forced even home users to start paying attention to the security of their networks.

In 1990, the Institute of Electrical and Electronic Engineers (IEEE) formed a group to develop a standard for wireless equipment. The 802.11 standard was born on June 26, 1997, built on using the physical and data-link layers of the OSI model to allow mobile devices to communicate wireless with wired networks.

You might hear Wi-Fi used in the place of WLAN. Wi-Fi is a brand originally licensed by the Wi-Fi Alliance to describe the underlying technology based on IEEE 802.11 specifications. The term Wi-Fi is used widely, and the brand is no longer protected. The Wi-Fi Alliance originally began as an initiative to help bring interoperability to the growing number of devices using different implementations of the 802.11 technologies. New versions are on the horizon, such as 802l.11n, but Table 11-1 references the most common wireless technologies used.

Table 11-1: Common 802.11 Technologies
Protocol | Release Date | Frequency | Bandwidth
IEEE 802.11 | 1997 | 2.4 GHz | 2 Mbps
IEEE 802.11a | 1999 | 5 GHz | 6, 9, 12, 18, 24, 36, 48, 54 Mbps
IEEE 802.11b | 1999 | 2.4 GHz | 5.5, 11 Mbps
IEEE 802.11g | 2003 | 2.4 GHz | 6, 9, 12, 18, 24, 36, 48, 54 Mbps
Note

Note that technically every component in a wireless network is called a station. There are two types, access points and wireless clients.

Wireless clients are also called supplicants. The access points connect the wireless network to the wired network, and the wireless clients or supplicants connect the wireless network to the mobile device. Mobile devices could be a laptop, a wireless enabled personal digital assistant (PDA), or other device configured to communicate with the access point. The set of stations communicating with each other is the basic service set (BSS). The BSS identifier (BSSID) is usually the media access contral (MAC) address of the access point servicing the clients.

There are two types of BSSs, independent and infrastructure. Independent BSSs are ad hoc networks working without an access point. Infrastructure BSSs have access points that can communicate with each other, allowing stations in one BSS to communicate with other stations in a different BSS. An extended service set (ESS) is a set of connected BSSs. Each ESS has an ID called the SSID consisting up to 32 characters. Finally, access points in an extended service set then are further connected by a distribution system (Figure 11-1).

Image from book
Figure 11-1: Example WLAN architecture.

If you're new to WLANs, then this probably sounds like a lot, and you may think that it's overly difficult to audit. We are going to stick to the basics during the audit process and suggest that you do the same. It's easy to let the scope of a WLAN audit get out of hand, but you can audit for most of the risk by concentrating your efforts on the items listed below. We'll discuss how to go about this process in easily digestible sections.

Data-Enabled Mobile Devices Background

Blackberry devices were by far the most widely used mobile devices in the corporate world at the turn of the century. Since then, other providers have developed similar personal information management (PIM) services and software clients to run on data-enabled mobile devices, or "smartphones." Development is in process and continues such that soon devices will support clients from multiple providers such as Blackberry and Goodlink.

In essence, these smartphones with PDA-like features enable the workforce to take data outside the walls of their companies. This is done with the help of providers such as Blackberry and Good Technologies, which interface your users with your network and the rest of the world through the mobile operator's wireless framework. A typical communications path is illustrated in Figure 11-2.

Image from book
Figure 11-2: Service provider illustration.

The components we want to understand as part of the audit are those that interface directly with your network and users, such as the gateway into your network and the mobile device the user carries.


WLAN and Mobile Device Auditing Essentials

WLAN and data-enabled mobile device auditing requires an understanding of how the technology is implemented in your organization. WLAN typically is managed by networking teams, whereas data-enabled mobile devices sometimes are jostled back and forth between networking, help desk, e-mail, productivity, and other teams in the organization.

Both WLAN and data-enabled mobile devices require at a conceptual level

  • Physically wired network gateways

  • Management software

  • Clients

  • Some agreed-on method of communicating wirelessly between the wired network gateway and the wireless clients

For the purpose of our discussion, wired network gateways include those items physically touching our network and acting as the interface or gateway between the wireless world and our organization's network. An audit of the wired network components includes verifying the security of the underlying platform and the settings on that platform. Management software for our purposes includes the software that manages the process enabling our mobile clients to communicate with the network. This may be Cisco's software that manages our access points or Blackberry Enterprise Server's software that manages client access. The management software may or may not run on the gateway component that isolates clients from your physical network. The clients in our case present unique risks to data theft, and we'll explore some very easy and very common methods for mitigating the risk. Finally, the method used to transmit your data wirelessly may be of concern if you are using older protocols or unsecure methods to transmit data. An audit of this transmission may include something as simple as reading up on and verifying the use of secure protocols, or it may include more complex hacking attempts and wardrives.

Understand that this is how we will approach the technical portion of the two audits conceptually. Specific tools and other necessary components are discussed in line with the audit steps.

In addition to the technical component of the audit, there are a number of critical intangibles that affect the ongoing operations of mobile users. These include such things as problem tracking for end-user issues, security policies, wireless system monitoring, and general continuity of operations. Collectively, we'll address these as operational components. Too often ignored, any one of these could undermine the best intentions of your organization to roll out robustly secure and effective mobile solutions.


Performing the Wireless LAN Audit

We divided the audit into technical and operational sections with examples of what you could audit. Depending on your goals and needs, you might need less or more than what's listed here.

Part 1-WLAN Technical Audit

1 Ensure that access points are running the latest approved software.

Running old firmware on the access point may leave the access point open to known attacks or prevent the organization from taking advantage of more robust security features.

How

Evaluate a representative sample of access points with an administrator, and verify that the code running on the access point is the latest version. Verify that the latest version is correct using the manufacture's website or some other similar updated source of information from the manufacturer. Examine the change-management processes around evaluating and maintaining current code releases for the access points. Note whether this process is automated and coordinated and whether it scales operationally across regional offices.

2 Evaluate the controls around centralized WLAN management.

This step verifies that management software is used to the fullest extent possible and that it's kept under tight control with sound policies and procedures. Centrally managed WLAN tool suites are a powerful method for controlling the many access points likely under the network team's supervision, especially across different geographic locations. Often management software is available from the same company that manufactured the access points. The access controls surrounding the tool suite are another avenue for someone to purposefully or inadvertently wreak havoc on your network and user population by changing access point settings.

How

Discuss this with your administrator, and ask for a demonstration of the management suite and its capabilities. Ask for procedures on handling the management suite, including who has access and how that access is controlled. If passwords are used, ensure that they match company policy and are rotated according to general company or other more stringent policies. In some organizations, every 90 days may be fine. Others may want their passwords rotated every 180 days or as quickly as 30 days. This is driven in large part by the perceived value of the information accessed wirelessly and the use of mitigating factors such as second-factor authentication tokens. Passwords do not have to be changed as often for systems that support robust or second-factor authentication because the password is one of two authentication pieces needed. For example, the second authentication factor might come from a SecureID token.

3 Verify that your mobile clients are running protective software.

This is a broad step to ensure that your clients have basic protections in place to mitigate the risk of compromise from an external source. You also want to make sure that the connecting client isn't going to harm your network.

How

Ensure that your clients have basic protection mechanisms in place if they are going to wirelessly connect to your network. At a minimum, your clients should have firewall and antivirus software. Other mitigating protections in place might include ensuring that all laptops are managed by a patch-management suite and members of your active directory. In this way, you can keep your systems patched and push down policies as makes sense for your network. You also might use standard known images for the laptops to minimize the complexity of the systems, the costs to your help desk, and the likelihood that your laptops have malware on them that could hurt your network.

4 Evaluate the security of the chosen authentication method.

If you don't have an authentication method set up, then anyone with a wireless card can access your network. This seriously violates the integrity of your network and places your systems at real risk of being compromised by a curious passerby. In densely populated areas where you have more than one company offering wireless to their users, the authentication method becomes very important. You most likely want your users mutually authenticated, meaning that your access points authenticate to your clients and your clients authenticating to your network.

How

There are several considerations to the chosen authentication method for your environment. Do you want your users authenticating or just the mobile device? What systems do you want your clients using on the backend for authentication? How is your infrastructure set up? Choosing the correct authentication method is beyond the scope of this short section, but you should have an understanding of the most common authentication methods outlined in Table 11-2. You should ask the team responsible for the wireless implementation for proof as to what they are using for their authentication method and ensure that there is something in place with which you feel comfortable. If your organization isn't using authentication for protecting network access from wireless users, then this should be raised as an issue.

Table 11-2: Common WLAN Authentication Methods
Authentication Method | Description
EAP-TLS (Transport Layer Security) | This method requires both user and server digital certificates and supports strong mutual authentication.
EAP-TTLS (Tunneled Transport Layer Security) | This method eliminates the client-side certificates and is typically used in organizations that wish to retain a non-EAP RADIUS infrastructure, such as those running Microsoft Active Directory, by using a TTLS server in front of the RADIUS server. The TTLS server converts EAP requests to legacy authentication methods.
PEAP (Protected EAP) | PEAP is very similar to EAP-TTLS; however, PEAP is supported by Windows XP and 2000 operating systems natively. TTLS is supported natively by many more operating systems.
EAP-MD5 | This method doesn't support mutual authentication and isn't recommended for wireless networks except in cases where nothing else will work. Keep in mind that EAP-MD5 can be used as the client authentication algorithm inside a tunnel created by TTLS or PEAP.
LEAP (Cisco-EAP Wireless) | This method is for Cisco-only implementations and has had serious security issues in the past.

5 Evaluate the security of the chosen communications method.

After the clients authenticate to the network, they begin passing data through their agreed-on communications channel. If the data are passed in cleartext or an easily broken format, then the data are subject to eavesdropping.

How

More than likely you are passing data over an encrypted link if you have implemented wireless in the last couple of years. This step is a reminder that your data are passing wirelessly and are subject to another party intercepting and recording the conversation. Well-designed yagi antennas can detect and read traffic hundreds of yards or even miles away in a clear line of sight. Work with your network administrator to understand how the traffic is encrypted between the supplicants (clients) and the access points.

6 Evaluate the use of security monitoring software and processes.

Security monitoring and regular log reviews can reveal potential issues before a serious event occurs.

How

Speak with the WLAN administrator in an attempt to understand what's being logged and whether those logs are ever looked at or reviewed. It's preferred to have an automated review process. The monitoring devices or software ideally would help you to identify issues, record authentication events, and locate potential rogue access points. Work with the administrator to understand if these logs are useful, and if not, then determine what barriers exist to prevent them from being reviewed and serving up useful data.

7 Verify that rogue access points are not used on the network.

This is the step that most people think about when someone brings up a wireless audit. We hope that you do more than just locate rogue access points and realize that the scope of an effective WLAN audit is much greater than "just" this step. This said, we don't want to take away from the importance of finding rogue access points that are violating your policies and bypassing intended authentication and communication security measures designed to protect your network from outside sources.

How

There are a number of ways to approach a search for rogue access points, including specialized wireless monitoring appliances, wardriving tools, and searching through your network traffic.

Commercial WLAN Security Monitoring Tools

If you have commercial WLAN monitoring tools available, use them to corroborate other evidence you may find. Examples include Aruba, Air Defense, and Air Magnet. Centrally managed wireless detection and prevention systems are a key component to enterprise control of wireless operations and compliance with policies. Proactive wireless monitoring is really the best way to identify wireless intrusions and vulnerabilities because wardriving only shows you what happens at a particular moment in time.

Wardriving

The most common method is to use wardriving software and tools to search for signals coming from rogue access points. This is similar to what an attacker might use and fun for most auditors. Wardriving can be effective in some scenarios, but here are the challenges that must be addressed:

  • WLAN signal density or noise may make this prohibitive.

  • The results are for only that snapshot in time.

  • There is a wide choice of software and hardware.

  • The work scope needs to be carefully defined.

If you are considering wardriving or warwalking around a high rise in a densely populated area, then you may find it nearly impossible to detect rogue access points among the noise on your network. However, if you are located in the country, this may be very easy to do. There is a wide choice of hardware and software available, but for most purposes, we recommend sticking to the basics. There are commercial versions of wardriving software, but most people will find free tools such as netstumbler (http://www.netstumbler.com) and kismet (http://www.kismetwireless.net) more than adequate for their purposes. If you are comfortable with Linux or Mac and have a laptop available for use, then you probably will prefer using kismet because of its rich feature set.

Built-in wireless tools come with most security-focused and self-booting Linux distributions. These are free and a great way to get your feet wet with Linux-based tools:

  • BackTrack, http://www.remote-exploit.org/index.php/BackTrack

  • Operator, http://www.ussysadmin.com/operator

  • PHLAK, http://www.public.planetmirror.com/pub/phlak/?fl=p

  • Knoppix-STD, http://www.knoppix-std.org/download.html

Netstumbler is a great tool if you prefer using your Windows laptop. It's very simple to set up and use (Figure 11-3). A number of nontechnical people have used it in the past to find hotspots when they travel.

Image from book
Figure 11-3: Network Stumbler in action.
Note

Use these tools carefully and only with permission in conjunction with your job. Never break into another person's network "just because you can." Also consider how your WLAN card is configured, and never connect to open networks unless you have permission. Remember that as an auditor, you're held to a code of ethics and generally very high standards.

If you would like to extend the range of the default antenna you use for daily wireless connectivity, then consider buying a high-powered card and a wireless antenna. We have used http://www.wardrivingworld.com (an eBay storefront) and have had great success with its pricing and services. The company sells several setups for this purpose. Speak with an old-hat shortwave radio enthusiast, and you'll quickly get bogged down in the complexities of antenna design and function. This is well beyond the scope of what you need to know to use them. You basically need to be aware of two types of antennas:

  • Directional antennas. An example is a yagi antenna. This is a cannon-shaped antenna. Yagi antennas have a 30-degree directional beam that will help you to triangulate and pinpoint where rogue access points may be hiding. Users will find this an attractive way to locate a source while driving or walking around a building. The range of a yagi antenna generally is very good because all its sensitivity is focused in one direction.

  • Omnidirectional antennas. An example is a blade antenna. These antennas are capable of communicating with sources in all directions, which is great if you just want to add an antenna booster to your laptop. If you tried this with a yagi antenna and pointed the yagi in the wrong direction, then you would be sorely disappointed because you would never get your signal. The range of a blade antenna typically is much less than that of a yagi antenna.

Carefully consider the scope of the work to be done. It's one thing to use these tools to locate rogue access points and another to use tools similar to these to compromise your network. Scope the finding of rogue access points separately from determining the level of risk associated with weak protocols and weak authentication schemes.

Searching Through MAC OUIs

Finally, you theoretically could search through your network for MAC addresses belonging to wireless access points. Each network card has a MAC address uniquely assigned to it by the manufacturer. Each MAC address contains as part of the address an OUI, or company_id, a 24-bit globally unique assigned number. The OUI usually is concatenated with another 24 bits that are assigned by the company in order to make a 48-bit number that is unique to a particular piece of hardware. The 48-bit number is the MAC address. Each network card has a MAC address assigned to the card used to route packets from the network card to the next hop on the network. The idea is to uniquely address a piece of hardware. There have been attempts by people in the past to search for equipment on their network using the OUI, or company_id, which works in some cases but not in all cases.

Your ability to do this depends on your network topology, the skill of your network administrator, the monitoring tools you have in place, and the amount of work you want to do. MAC addresses are kept by IEEE and located in their entirety at http://www.standards.ieee.org/regauth/oui/oui.txt. The challenge you will run into if you choose to do this is false positives and false negatives. Some MAC addresses have been reassigned or bought by others, and one company may use another manufacture's chipset. If this is not enough, MAC addresses are easily spoofed! It's an elegant solution on the surface. However, you may have challenges and find that one of the other methods is an easier solution.

Part 2- WLAN Operational Audit

8 Evaluate procedures in place for tracking end-user trouble tickets.

Failure to establish ownership and tracking of end-user issues could result in end users being unable to resolve connectivity problems.

How

End-user issues should be tracked through a trouble ticketing system. There needs to be an owner for these issues and a group responsible for tracking the progress to closure of any tickets opened because of WLAN issues. Discuss these processes with the administrator.

9 Ensure that appropriate security policies are in place for your WLAN.

Policies help to ensure compliance with a standard and help with repeatable processes and allow the company the ability to act against documented company violations.

How

Determine if WLAN policies exist and whether the administrator responsible for the WLAN knows and understands the content of the policies. Determine if the policies are being followed or what barriers might exist that prevent them from being followed. Some common policy items might be

  • All wireless transmissions must be encrypted to prevent eavesdropping.

  • All access points must have updated firmware.

  • Only authorized people on the [insert name here] team may have direct administrative controls of the access points.

  • Only authorized people on the [insert name here] team may install access points.

  • Passwords to access points must adhere to company policy.

  • Default SSID names are not allowed or broadcasted.

  • All efforts will be made to reduce propagation of radio waves outside the facility.

  • Devices accessing the network must use personal firewalls and antivirus programs.

  • Client devices must use IPSec-based virtual private network (VPN) technology.

  • The [insert name here] team must monitor for rogue access points on a [insert time frame here] basis.

  • Only authorized systems owned by the company may access the network and only for appropriate business use.

10 Evaluate disaster-recovery processes in place to restore wireless access should a disaster happen.

Failure to have appropriate recovery processes in place prevents a timely restoration of wireless access for users who must have it to conduct company business. Additionally, it would extremely easy without a plan and during the recovery process to deploy a insecure WLAN, leaving the organization's network open to unwanted guests.

How

Restoring WLAN may not be at the top of most people's list following a critical disaster, but there should at least be some thought around and procedures in place to facilitate this process. Discuss this with the administrator, and ensure that the recovery processes are in line with the expectations and standards of other recovery processes in the company. Depending on the use of wireless, this may be a critical component, such as in a large warehouse that depends on wireless mobile scanners. Other environments, such as one that uses wireless to supplement existing and working wired infrastructures, may not view this as very important. This is a business risk that should be evaluated and measured appropriately when reviewing the WLAN security policies and the WLAN disaster-recovery/business-continuity (DR/BC) processes.

11 Evaluate whether effective change-management processes exist.

Change-management processes help to track and provide controlled changes to the environment. Controlled environments are more secure and have less impact on user productivity.

How

Discuss change-management practices with the administrator. Consider asking for evidence of a recent change, and following through how the change was handled from start to finish.


Performing the Mobile Device Audit

We discuss both Goodlink and Blackberry gateways and clients because they are similar in feature sets as pertains to security. The implementation may be slightly different, but they usually arrive to the same end result. We will cover some of the supporting company infrastructure specific to their implementation, but we don't go beyond this. We will not touch on such components as e-mail servers or switch gear, which may or may not be in the scope of your audit. Please consider other sections of this book as necessary if you feel that you want to expand the scope of the audit beyond what we have listed below. The following checks conceptually follow closely to the checks in the WLAN audit earlier with some slight changes.

Part 1- Mobile Device Technical Audit

1 Ensure that mobile device gateways are running the latest approved software and patches.

Running old software on the mobile device gateways may leave the gateways or remote mobile devices open to known attacks or prevent the organization from taking advantage of more robust security features.

How

Evaluate the gateway with an administrator, and verify that the code running on the gateway is the latest version. Verify that the latest version is correct using the manufacture's website or other similar updated source of information from the manufacturer. Examine the change-management processes around evaluating and maintaining current code releases for the access points. Note whether this process is automated and coordinated and whether it scales operationally across regional sites.

2 Verify that mobile clients have protective features enabled if they are required by your mobile device security policy.

Goodlink and Blackberry Enterprise Server (BES) both provide several client features such as password controls and remote or local wiping that can bolster your security should a device become lost or stolen.

How

Requisition a mobile device with an administrator's help, and verify that it has the protective features enabled as determined by your mobile security policy or other agreed-on standard. If you don't have a policy, then we'll suggest some components for a mobile security policy in a later step. Some very common features available with both Goodlink and BES include enforced passwords, password settings, remote lock, remote wipe, and local wipe. Passwords can be set up to meet several different requirements in terms of length and complexity. Emergency calls to 911 are allowed on both Goodlink and BES when configured to enforce passwords. Remote lock allows administrators to lock a lost or stolen mobile device until it is either found or a decision is made to remotely wipe the device. Wiping the devices prevents an attacker from retrieving any data. The local wipe feature is designed to wipe the device if a user exceeds the maximum number of tries to log into the device.

If you have the capability, you should evaluate the process a user would follow if his or her PDA phone were lost or stolen. Test these features to verify that your company processes work as designed and that all parties understand how to carry out the process.

3 Determine the effectiveness of device security controls around protecting data when a hacker has physical access to the device.

This is an advanced step and would be performed with the help of your company's computer forensic or security team. The subtle reason for performing this step is to help shed light on the need for security on mobile devices. The company's e-mail server and global address book are accessible remotely on lost or stolen devices until the device account tied into the company network is removed.

How

In one large company, it was estimated by the administrator that wiping a device succeeds only about 20 percent of the time. One of the reasons for this is because users tend to wait too long before reporting that their devices have been lost or stolen. If users are not aware of what to do when they lose a device, then this opens the window of opportunity for someone with malicious intent to attempt to record data from the device. Waiting to raise a potential issue renders the remote lock and erase controls ineffective.

There are several ways to go about this step. You could, for example, assume that it takes 3 hours to pull data from a device before remotely attempting to kill the device. Assume that you have the ability to remotely kill devices, and assume that Faraday bags are not used by the attacker. Faraday bags prevent radio signals from reaching a device and lend an unfair advantage to an attacker. These bags might be used by a skilled, in-tentioned attacker, but they are not common.

Your forensics team might use something similar to Paraben's Device Seizure. Visit http://www.paraben-forensics.com/cell_models.html to see if the device you're interested in testing is supported by this tool. You'll also find more information about Paraben's Device Seizure on the company's website. We had some interesting findings on older devices, such as recovering e-mail that the user thought was deleted. Deleted e-mail messages could not be recovered through the interface but were accessible using these relatively low-cost tools.

The following are additional controls that help to prevent physical access hacks. These must be turned on manually and should be in line with your policies. Some organizations see these as too restrictive, but there are several that will not allow managed BES and Goodlink devices to operate without these additional controls.

  • Managed devices must be password-protected and erase themselves automatically after 15 incorrect password attempts.

  • Devices can be locked or erased remotely.

  • A password is required to read data on a mobile device or turn on the USB port.

4 Evaluate the use of security monitoring software and processes.

Security monitoring and regular log reviews can reveal potential issues before a serious event occurs.

How

Speak with the mobile device administrator in an attempt to understand what's being logged and whether those logs are ever looked at or reviewed. It's preferred to have an automated review process. The monitoring devices or software ideally would help you to identify issues, record authentication events, and locate potential rogue access points. Work with the administrator to understand if these logs are useful, and if not, then determine what barriers exist to prevent them from being reviewed and serving up useful data.

5 Verify that unmanaged devices are not used on the network. Evaluate controls over unmanaged devices.

Unmanaged devices often contain sensitive personal and corporate data without the benefit of the security controls enforced on managed TREO and Blackberry devices. This makes them easy targets for compromise when they are lost or stolen.

How

One method for discovering the number of potential unmanaged devices on your network is to look for the existence of the supporting desktop software on your systems. This doesn't prove that an employee is actively using the device but suggests that at one point he or she tried to do so. You could use SMS, for example, to search for the existence of the executables listed in Table 11-3 associated with the desktop software used with the mobile devices.

Table 11-3: Mobile Operating Systems and Desktop Executables
Mobile Operating System | Desktop Executable
Palm | Hotsync.exe
Microsoft Mobile | wcescomm.exe
Blackberry | desktopmgr.exe

Part 2- Mobile Device Operational Audit

6 Evaluate procedures in place for tracking end-user trouble tickets.

Failure to establish ownership and tracking of end-user issues could result in end users being unable to resolve connectivity problems.

How

End-user issues should be tracked through a trouble ticketing system. There needs to be an owner for these issues and a group responsible for tracking the progress to closure for any tickets opened because of mobile device issues. Discuss these processes with the administrator.

7 Ensure that appropriate security policies are in place for your mobile devices.

Policies help to ensure compliance with a standard, help with repeatable processes, and allow the company the ability to act against documented company violations.

How

Determine if mobile device policies exist and whether the administrator responsible for the mobile devices knows and understands the content of those policies. Determine if the policies are being followed or what barriers might exist to prevent them from being followed. Some example policy items might include

  • You must use one of the defined and supported devices.

  • Synchronizing to your local workstation is allowed with only approved managed devices.

  • When available, antivirus and encryption tools should be used on your handheld device.

  • The password policy for handhelds that access the company's Internet and/or email systems is [defined policy].

  • After 15 failed password tries, the handheld must be erased automatically.

  • The device must time out after 30 minutes of inactivity.

8 Evaluate disaster recovery processes in place to restore mobile device access should a disaster happen.

Failure to have appropriate recovery processes in place prevents a timely restoration of mobile e-mail access for users who must have it to conduct company business.

How

Restoring mobile device access may not be at the top of most people's list following a critical disaster, but there should at least be some thought around and procedures in place to facilitate this process. Discuss this with the administrator, and ensure that the recovery processes are in line with the expectations and standards of other recovery processes in the company. Depending on the use of mobile e-mail, this may be a critical component, such as with a large mobile sales force that depends on wireless mobile e-mail to efficiently conduct business and close deals. Other environments, such as one that uses wireless e-mail to supplement existing and working wired infrastructures, may not view this as very important. This is a business risk that should be evaluated and measured appropriately when you review the mobile device security policies and DR/BC (disaster recovery/business continuity) processes.

9 Evaluate whether effective change management processes exist.

Change management processes help track and provide controlled changes to the environment. Controlled environments are more secure and have less impact on user productivity.

How

Discuss change management practices with the administrator as they relate to changing components in the environment that affect the infrastructure and especially changes that might affect the end user. Consider asking for evidence of a recent change and following through how the change was handled from start to finish.

10 Evaluate controls in place to manage the service life cycle of personally owned and company-owned devices and any associated accounts used for the gateway.

The service life cycle of devices is defined as the provisioning, servicing, and deprovision-ing of devices over the period of time such devices are used at the company. The risk of not tracking a device through the service life cycle includes losing track of the device to an employee who leaves the company with sensitive information still on the mobile device.

How

Measures should exist to manage the service life cycle of the mobile devices managed by your company and the accounts associated with those devices. Discuss this with the administrator, and look for records supporting his or her statements. Walk through a recent provisioning and deprovisioning process with the administrator.


Additional Considerations

Additional considerations might exist for your environment depending on your size, your geographic reach, and what kind of data exist on your network. Some of these additional considerations might include

  • License management for software tracked by the number of users.

  • Verify that processes exist for international support for diverse or geographically scattered organizations.

  • Categorize the types of data typically stored on corporately managed mobile devices and the level of protection typically required in accordance with your information classification policy.

  • Evaluate the switching and routing infrastructure as it relates to these components.


Tools and Technology

Here is a list of tools discussed in this chapter and others you might find useful:

  • http://www.netstumbler.com

  • http://www.kismetwireless.net

  • Introduction to kismet: http://www.wi-fiplanet.com/tutorials/article.php/3595531

  • BackTrack: http://www.remote-exploit.org/index.php/BackTrack

  • Operator: http://www.ussysadmin.com/operator

  • PHLAK: http://www.public.planetmirror.com/pub/phlak/?fl=p

  • Knoppix-STD: http://www.knoppix-std.org/download.html

  • Wardriving hardware: http://www.wardrivingworld.com

  • Software tools: http://www.wardrive.net/security/tools

  • http://www.paraben-forensics.com


Knowledge Base

Following is a list of URLs and books where readers can find more information. We can't discuss everything, but we can point to other places where others discuss more than a reader could possibly want to know.

  • NIST Special Publication 800-48: Wireless Network Security: http://www.csrc.nist.gov/publications/nistpubs/800-48/NIST_SP_800-48.pdf

  • http://www.standards.ieee.org/regauth/oui/oui.txt

  • Wireless tutorials: http://www.wi-fiplanet.com/tutorials

  • http://www.paraben-forensics.com/cell_models.html

  • http://www.good.com

  • http://www.blackberry.com


Master Checklists

Auditing Wireless LANs

Checklist for Auditing Wireless LANs

  1. qEnsure that access points are running the latest approved software.

  2. qEvaluate the use and controls around centralized WLAN management.

  3. qVerify that your mobile clients are running protective software.

  4. qEvaluate the security of the chosen authentication method.

  5. qEvaluate the security of the chosen communications method.

  6. qEvaluate the use of security monitoring software and processes.

  7. qVerify that rogue access points are not used on the network.

  8. qEvaluate procedures in place for tracking end-user trouble tickets.

  9. qEnsure that appropriate security policies are in place for your WLAN.

  10. qEvaluate disaster-recovery processes in place to restore wireless access should a disaster happen.

  11. qEvaluate whether effective change-management processes exist.

Auditing Mobile Devices

Checklist for Auditing Mobile Devices

  1. qEnsure that mobile device gateways are running the latest approved software and patches.

  2. qVerify that mobile clients have protective features enabled if they are required by your mobile device security policy.

  3. qDetermine the effectiveness of device security controls around protecting data when a hacker has physical access to a device.

  4. qEvaluate the use of security monitoring software and processes.

  5. qVerify that unmanaged devices are not used on the network. Evaluate controls over unmanaged devices.

  6. qEvaluate procedures in place for tracking end-user trouble tickets.

  7. qEnsure that appropriate security policies are in place for your mobile devices.

  8. qEvaluate disaster recovery processes in place to restore mobile device access should a disaster happen.

  9. qEvaluate whether effective change management processes exist.

  10. qEvaluate controls in place to manage the service life cycle of personally owned and company-owned devices and any associated accounts used for the gateway.


Chapter 12: Auditing Company Projects

All the other chapters in this part have dealt with how to audit specific technologies and processes that are already in place and operating in a production environment (e.g., operating systems, data centers, applications, etc.). However, before any system or process can be implemented, there has to be a project that is funded and staffed to develop or procure that system or process. If proper disciplines are not followed during that project, the chances that the project will fail to meet requirements and/or result in inefficient use of company assets are greatly increased.

Note

Note that in this chapter we are not discussing the concept of early involvement discussed in Chapter 1. The early-involvement concept discussed in that chapter is for the purpose of building internal controls into the systems and processes being developed at your company. This chapter deals instead with the processes used to ensure that those projects are being managed efficiently and effectively. The concept of building controls in up front certainly can be merged with an audit of project management processes, but they are two different topics. We will touch on the early-involvement concept briefly in this chapter as a reminder of where it might fit in but otherwise will let the discussion from our earlier chapter stand.

Background

Proper project management disciplines are an essential element of the success of any company endeavor. These disciplines help to ensure that pertinent requirements are gathered and tested, project resources are used efficiently, and all elements of the system are tested properly. Without project management disciplines, it is far more likely that the system being developed won't work or won't do what your key stakeholders expect it to do. This leads to rework and extra costs to the company (and also sometimes leads to people losing their jobs). Good project management does not ensure success, but it improves the chances significantly. The intent of this chapter is not to provide a training course on the basics of project management or the software development life cycle (SDLC), but it is instead intended to provide a list of basic risks to review when auditing a systems project in order to ensure that the most essential project management disciplines are being followed.

High-Level Goals of a Project Audit

Project audits are performed for the purpose of identifying risks to the success of company projects. In this chapter we'll be specifically referring to IT projects (e.g., software and infrastructure development), but the concepts could apply to any sort of project. Some of the high-level goals of a project audit include ensuring that

  • All appropriate stakeholders are involved in the development of requirements and testing of the system and that frequent and effective communication is provided to all stakeholders. Failure to gather customer requirements and to obtain ongoing customer involvement leads to software, systems, and processes being developed or procured that do not align with business needs.

  • Project issues, budgets, milestones, etc. are recorded, baselined, and tracked. Without these mechanisms, projects are more likely to go overbudget and overschedule and to have unresolved issues.

  • Effective testing takes place, encompassing all system requirements. Inadequate testing leads to unstable, low-quality systems and a failure to meet customer requirements.

  • Appropriate documentation is developed and maintained. Incomplete or out-of-date technical and user documentation could increase cost and cycle time to maintain the software, increase support and training costs, and limit the system's usefulness to the customer.

  • Adequate training is provided to end users on implementation. Inadequate training leads to systems, processes, and software that go unused or are used improperly.

Basic Approaches to Project Auditing

There are two basic approaches that can be taken with project auditing. The first approach is quick and short term, the in-and-out approach. The second approach takes a long-term view of the project and is considered a consistent approach.

There are challenges to the short-term approach, in which auditors pick a point in the project to perform their audit. The auditors then review the project as of that point in time and make a judgment based on what's happened and what's planned. There are two major downfalls with this approach:

  • It is difficult for the auditors to have an impact on the phases that have already been completed. For example, the user acceptance testing phase is a poor time to find out that things were messed up during the project definition phase. The project either has to go back and perform a bunch of rework or just understand that things were messed up and move forward, hoping for the best. Either way, the auditors' input is not very timely.

  • It is difficult to fully evaluate the phases that have not yet begun. The auditors might be able to review plans for user acceptance testing at the beginning of the project, but until those plans are fully developed and are being executed, it is difficult to evaluate their true effectiveness.

The longer-term, or consistent-involvement, approach allows auditors to perform some assessment activities during each major phase of the project. Each audit evaluates the processes within the current phase while also assessing and providing input on plans for future phases. This is a much more effective means of auditing projects and also leads to a much more collaborative approach with your audit customers. The only negatives are that it stretches the audit out over a long period of time and that it can be difficult to schedule. However, the positives far outweigh the negatives.

If the project spans an exceptionally long period of time, the auditors might consider one of two approaches:

  • Release interim audit reports after each major project phase so that the information in the report doesn't become too stale.

  • Meet with the project manager to go over issues on a regular basis (e.g., once every 2 weeks). At this meeting, the auditors can communicate new risks to the project discovered since the last meeting and also follow up on the status of previous issues to determine if remediation is complete. If, in the auditors' opinion, the project risk is increasing to an unsatisfactory level, or if issues are not being mitigated, the auditors can escalate to a higher level of management at their discretion. The auditors should reserve the right to issue a full-scale audit report at any time, but by trying to work with the project manager first, it is more likely that issues will be resolved without escalation and without the issuance of interim audit reports.

Seven Major Parts of a Project Audit

Project audits can be divided into seven major parts, each of which require disciplines and controls that we will evaluate during project audits:

  1. Ongoing project management. This topic covers those mechanisms that should be used throughout the project, such as issue tracking, project documentation, and change management.

  2. Project startup: requirements gathering and initial design. This topic covers the birth of a project, where the need for the project is established, requirements are gathered, and the initial design and feasibility studies are performed.

  3. Detailed design and system development. This topic covers the "meat" of the project, where the code is written, the product is procured or implemented, the processes are developed, etc.

  4. Testing. This is the part of the project where the system, software, or process is tested to ensure that it meets requirements.

  5. Implementation. This part of the project involves, obviously, implementing or installing the system, software, or process into a production environment.

  6. Training. This topic covers the activities for training end users on using the system, software, or process that has been developed and implemented.

  7. Project wrap-up. This topic covers postimplementation activities.

The rest of this chapter will focus on key audit steps and tests to perform related to these seven categories.


Test Steps

In order to provide some context and structure, the test steps in this section are divided by project phase. However, it won't always work out as neatly as what's laid out here, so this cannot be a robotic process. For example, there may be occasions when the right time to address a step from the testing section is during the requirements-gathering phase.

The auditor should perform each step at the point in the project where it makes the most sense, based on how the project is run. It is critical for the auditor to understand the methodology of the project and adjust his or her approach accordingly. For example, if the project is using incremental development, where each project phase is executed multiple times, then the auditor may need to audit each phase concurrently or possibly even multiple times. The controls needed for a project generally will be the same regardless of the project methodology, but matching the audit phase to the project and coordinating the timing will be more difficult for some types of projects than for others. Part of the planning process should involve obtaining an understanding of the project methodology used and determining the appropriate timing and method for accomplishing the steps in this program.

The auditors should determine what project management tool is used by the project team and obtain a familiarity with the tool and its terminology. This will allow the auditors to "speak the same language" as the people they are auditing and further enhance credibility.

In addition, some of these steps may be overkill for smaller projects. The auditor should use judgment in determining which of these risks are material enough to address for each specific project. Finally, these steps are written in such a way that they can be used for any sort of IT project, whether it involves acquiring or developing software, procuring new technology, or developing a process. Auditor judgment should be used in determining which steps are most applicable based on the kind of project being audited.

The words software, system, and process are used in the following steps interchangeably and in conjunction with one another. They are basically intended to represent "the thing that is being developed by the project team." The use of one word versus another in a given test step is not intended to convey any specific meaning.

Overall Project Management

Note

The steps in this section likely should be performed thoroughly at the beginning of the project and then hit again lightly during each phase of the project to ensure that the disciplines are still being followed. Project management may start out strong, but it often wanes as people become busy and are scrambling to meet deadlines.

1 Ensure that sufficient project documentation and software development process documentation (if applicable) have been created. Ensure that the company's project methodology standards are being followed.

This sort of documentation will increase the likelihood that the project is being implemented in a disciplined manner and is following your company's established standards and methodologies. This, in turn, greatly increases the chances that the project will be executed successfully and will produce the business value desired. Also, this documentation can be of benefit to future projects, therefore allowing the company to leverage past efforts. Finally, your company may have specific standards for executing projects based on either internal or regulatory requirements.

How

Get copies of whatever project documentation exists. Review this documentation and compare it with the standards and requirements of your company. The documents required will vary by company, but look for documents covering areas such as milestones, work breakdown structure (WBS), project approach, statement of work (SOW), requirements, test plans, and design documents. Obtain a copy of your company's project methodology standards and compare them with the methodology being executed on the project being reviewed. When reviewing this documentation, determine whether there seems to be evidence of adequate project and resource planning. Performance of this step is not an exact science. Instead, the auditor is trying to develop a feel for the overall level of documentation and processes established for the project. Some of this documentation will be examined in more detail during later steps. In this step, the auditor should obtain the document(s) that constitute the basic project plan and determine whether customer needs, deliverables, objectives, and scope are clearly defined.

2 Review procedures for ensuring that project documentation is kept up-to-date.

For reasons mentioned in the preceding step, this documentation enhances the quality of current and future projects. However, if it is allowed to become outdated, it quickly becomes useless.

How

Through interviews with the project team, understand the processes in place for updating these documents when necessary. Look for evidence that updates have been made.

3 Evaluate security and change-management processes for critical project documentation.

If proper security and change controls are not in place, unauthorized, inaccurate, and /or unnecessary changes may be made to the project documentation.

How

Ensure that files containing project documentation are locked down and can be modified only by an appropriate subset of project personnel (using techniques described in Chapters 6 and 7). Interview project personnel to understand processes for changing critical project documents. Ensure that there is an approval process required before changes are made to significant project documents and that the approval process cannot be circumvented. The documents that constitute the basic project plan (e.g., customer needs, deliverables, objectives, scope, budget, risks, and communication strategies) should be baselined early in the project such that it cannot be changed without agreement from all key stakeholders.

4 Evaluate procedures for backing up critical project software and documentation. Ensure that backups are stored offsite and documented procedures exist for recovery.

If these processes are not in place, a system crash or data center disaster could result in the permanent loss of project software and documentation.

How

Review processes or scripts indicating that project data are backed up. If offsite backup is accomplished via tape storage, review the logs or records indicating that they have been taken offsite. Review written recovery procedures, ensuring that they specify what steps are to be performed for recovery, the order of those steps, and who is to perform each step.

5 Ensure that an effective process exists for capturing project issues, escalating those issues as appropriate, and tracking them to resolution.

During the course of any project, issues inevitably will arise regarding the project itself or the system, process, or software being developed. Without a robust method of capturing and resolving those issues, there likely will be instances where issues will "slip through the cracks" and not be resolved, resulting in failures in the product or failures in execution of the project.

How

Review the issues database, issues spreadsheet, or whatever other method has been established for recording and tracking issues. Ensure that the issue-tracking tool records adequate information regarding each issue, including description of the issue, priority level, due date, latest status, and resolution information. Ensure that controls exist over the tool used to track issues, such as backups and security to prevent unauthorized updates. Review processes for escalating issues and for ensuring that issues are tracked to resolution. Review the issues list for evidence that issues are being closed. Interview customers to ensure that the process is working.

6 Ensure that an effective process exists for capturing project change requests, prioritizing them, and disposi-tioning them.

During most projects, requests for additional functionality will arise after the project has commenced and the requirements have been established and approved. Without a method for ensuring that these requests are prioritized and dispositioned, these requests may get lost, and/or the scope of the project will be shifting continually, making it impossible to execute the project effectively. A change request process will help prevent scope creep.

How

Review the change-management process and ensure that it provides allowance for entering, ranking, and approving change requests. Verify that it covers changes to scope, schedule, budget, requirements, design, etc. (i.e., all major elements of the project). Ensure that it records adequate information regarding each change request, including description of the request, priority level, latest status, approval, and resolution information. Select a sample of change requests, and walk them through the process, ensuring that proper approvals were received prior to final resolution.

7 Verify that a project schedule has been created and that it contains sufficient detail based on the size of the project. Ensure that there is a process in place for monitoring progress and reporting significant delays.

Project schedules are used to ensure that the project is on track, resources are being used effectively, and all tasks have been accounted for and scheduled.

How

Review the project schedule, and look for items such as a work breakdown, milestone dates, task dependencies, and the critical path. Look for evidence that the schedule is followed and kept up-to-date. Seek explanations for any significant deltas. Ensure that an escalation procedure exists for any significant schedule or resource overruns, and review evidence that the process has been used. One potential methodology for the project to accomplish this is to have strategic points in the life cycle where it goes through a tollgate process. During this process, the project team goes before a review panel and reports the status of the project, successes and issues, and progress versus the schedule and budget. This helps to identify struggles and runaway failures early.

8 Ensure that there is a method for tracking project costs and reporting overruns. Ensure that all project costs, including labor, are considered and tracked.

Without these mechanisms, it is more likely that project budgets will be exceeded and that the appropriate levels of management will not be made aware. Management presumably has a cap on the amount of money it intends to spend on a specific project. If all relevant expenses are not being tracked, management will be unaware if that cap has been exceeded, taking away the opportunity for it to make a decision as to whether to continue.

How

Obtain a copy of the budget, and compare it with expenses to date. Seek explanations for any significant deltas. Ensure that it includes all costs associated with the project. Ensure that an escalation procedure exists for any significant cost overruns, and review evidence that the process has been used. See the tollgate description from the preceding step for a potential review methodology.

9 Evaluate the project leadership structure to ensure that both the business and IT are represented adequately.

Except for some pure infrastructure projects, most projects are undertaken at the request of the business in order to meet a business need. If the key business stakeholders are not part of the overall leadership and approval structure for the project, the odds of the project getting off track from the business needs increase because information and decisions about the project will be handled by IT people, who may not have the perspective necessary to make all decisions. Conversely, IT personnel also should be part of the structure because they generally bring important knowledge and perspective regarding the elements of success for IT-related projects.

How

Obtain a copy of the project's leadership structure, and look for evidence that both business and IT leaders and stakeholders are represented.

Project Startup-Requirements Gathering and Initial Design

10 Ensure that appropriate project approval processes were followed prior to project initiation.

Projects should not be initiated without approval from the appropriate members of management, who are authorized to allocate resources and funds to new projects.

How

Review evidence that the project went through the company's standard approval process. If no such process exists, review evidence that an appropriate member of management approved the project prior to startup. Look for evidence that alternative and cost-benefit analyses were performed. Ensure that cost-benefit analyses considered the cost of ongoing maintenance, an element that is often omitted erroneously.

11 Ensure that a technical feasibility analysis has been performed along with, if applicable, a feasibility analysis by the company's legal department.

Prior to the startup of an IT project, it is important for qualified technical architects, network personnel, database administrators, and other applicable IT experts to agree that the proposed concept will work in the company's environment. If these sorts of people are brought in early, it is likely that the technical experts can find a way to make the concept work. However, if they are brought in after key elements of the system have been developed or procured, it may be determined that the solution is not technically feasible, leading to costly rework or discontinuation of the project. Likewise, it is important to engage the legal team in order to ensure that regulatory requirements are considered.

How

Review evidence that appropriate technical and legal personnel were involved in the initial project proposal and that they agreed to the feasibility of the project.

12 Review and evaluate the requirements document. Determine if and how customer requirements for the project are obtained and documented before development takes place. Ensure that the customers sign off on the requirements and that the requirements encompass standard IT elements.

Systems, software, and processes should be built based on the requirements of the end users. If those end-user requirements are not captured and agreed to by the customers, the product likely will not meet their needs, requiring rework and changes. In addition, there are certain standard IT elements that should be included in the requirements definition of any system. Customers may not be aware of these elements and therefore require guidance from the IT team.

How

Review project documentation for evidence that customer requirements were gathered. Ensure that all key stakeholders, including the project sponsors, were involved in this process. Look for evidence that the key stakeholders agreed to the final list of requirements.

Ensure that the requirements encompass standard IT elements such as

Execution frequency | Service-level agreements (e.g., availability, speed of response to problems)
Response time | Interface requirements
Security | Backup/recovery/restart requirements
Distributed and centralized processing requirements (e.g., the location of the storage and processing in a multitier architecture) | Hardware requirements
Data retention requirements | Capacity, including needs for future anticipated growth
Requirements for output distribution | Fault tolerance and redundancy
Screen definitions

If this project is intended to replace an existing system, look for evidence that an analysis of the current system was performed in order to determine what is working well and what is not. The results of this analysis should be reflected in the requirements documentation (i.e., the requirements should call for the new system to do the things that work well in the old system and to improve on the things that don't). Error logs and backlog requests from the old system can aid in the effort of determining what is not working well.

13 Evaluate the process for ensuring that all affected groups who will be helping to support the system, software, or process are involved in the project and will be part of the sign-off process, indicating their readiness to support it.

There are usually multiple organizations in the IT environment that will be involved in supporting any new system, including network support, operating system support, database support, data center personnel, IT security, and the help desk. If these organizations are not involved in the project early, they may not be prepared to support the system once it is ready, and/or the system may not be in compliance with applicable standards and policies.

How

Review evidence that other affected IT organizations have been notified of the project and are part of the approval process (as it relates to their readiness to support it).

14 Review the process for establishing the priority of requirements.

There are often more system requirements than can be encompassed in the project (or at least in the initial phase of the project). It is important that the most critical requirements be identified and implemented.

How

Look for evidence that the requirements were prioritized and that the key stakeholders approved the prioritization.

15 Determine whether the system requirements and preliminary design ensure that appropriate internal control and security elements will be designed into the system, process, or software.

Internal controls are necessary to protect company systems and to ensure their integrity. It is much easier to build controls into new systems up front than to attempt to attach them postimplementation.

How

This step is referring to the execution of the early-involvement concepts discussed in Chapter 1. The auditor will need to determine what sorts of controls he or she would audit the system for postimplementation and ensure that those controls are being designed into the system. Applicable application controls and infrastructure controls should be considered. The other chapters in Part II provide most of the detail needed in performing those steps. While those chapters discuss the techniques for auditing systems, processes, and software postimplementation, the same information can be used for providing input as to what controls need to be built in during design. In addition, it might be appropriate to assign a financial/operational auditor to the project to ensure that the proper business controls are built into the system logic and workflows.

16 If the project involves the purchase of software or technology, review and evaluate the vendor selection process and related contracts.

Purchasing a product from an outside vendor usually is a significant investment and represents a commitment to that vendor's product. If the process for selecting the vendor is inadequate or the contract does not provide the company with adequate protection, it can lead to the purchase of products that do not meet the requirements of the project and a lack of legal recourse.

How

Review the vendor selection process for elements such as

  • Ensure that products from multiple vendors are evaluated as to their ability to meet all project requirements and their compatibility with the company's IT environment.

  • Ensure that a cost analysis has been performed on the products being evaluated. This analysis should include all relevant costs, including product costs, one-time startup costs, licensing fees, and maintenance costs.

  • Determine whether the vendors' financial stability was investigated as part of the evaluation process.

  • Determine whether the vendors' experience with providing support for the product for similar companies in the industry was evaluated. This may include obtaining and interviewing references from companies that currently use the product.

  • Ensure that the vendors' technical support capabilities were considered and evaluated.

  • Once a vendor is chosen, ensure that the contract clearly identified deliverables, requirements, and responsibilities. The contract should specify how performance will be measured and penalties for nonperformance or delayed performance. It also should provide conditions for terminating the agreement.

  • Ensure that the contract contains a nondisclosure clause preventing the vendor from disclosing company information.

  • Ensure that the contract contains a "right to audit" clause allowing you to audit vendor activities that are critical to your company.

  • Where applicable, ensure that code is put in escrow to protect against the vendor going out of business.

Detailed Design and System Development

17 Ensure that all requirements can be mapped to a design element.

A defined process for tracing requirements to the system design will provide assurance that all requirements are addressed, including such standard IT elements as interfaces, response time, and capacity.

How

If it exists, review the requirements trace map and verify that all requirements are represented and mapped to a design element. If a trace map doesn't exist, review the process for ensuring that all requirements are encompassed.

18 Verify that the key stakeholders have signed off on the detailed design document (or equivalent).

This is the document that will be used to actually design the system, software, or process. If key stakeholders have not signed off on it, there is a greater chance that the output of the project will not meet their needs.

How

Look for the equivalent of a detailed design document and for evidence of customer approval. Note that nontechnical personnel may not be in a position to understand the document, depending on how it is written. If this is the case, ensure that compensating design reviews have been developed that allow the stakeholders to understand the planned design elements.

19 Review processes for ensuring ongoing customer involvement with the prioritization of tasks on the project.

There is always some fluidity to projects, with the initial set of requirements rarely ending up as the final set of requirements. If key stakeholders are not involved throughout the project, the project runs the risk of getting off-track from customer desires and of making decisions that are not in alignment with customer wishes.

How

Determine whether there is a direction-setting group containing key customers and whether they are involved in project decisions on a regular basis. Consider interviewing a small sample of customers to obtain their opinion on customer involvement. Look for evidence of periodic project review meetings and periodic communication with key stakeholders.

20 Look for evidence of peer reviews in design and development.

This quality-control discipline, which involves a review of code and configuration by the developer's peers, can help to increase the odds that the system will be designed with sound logic and a minimum of errors.

How

Determine whether peer reviews are required by the process, and look for evidence that they are actually occurring.

21 Verify that appropriate internal controls and security have been designed into the system.

See step 15.

How

Validate (either through interviews or design reviews) that the input you provided in step 15 has been encompassed in the design of the system.


Testing

22 Verify that design and testing are taking place in a development/test environment and not in a production environment.

Failure to perform design and test work in dedicated environments could result in disruption of normal business activities.

How

View evidence that the environments being used during development and test are separate from the environment being used for production. View a layout of the architecture, and validate segregation of the environments. View project member logins to the various environments, and confirm that the servers being used for design, testing, and production match the architecture layout.

23 Review and evaluate the testing process. Ensure that the project has an adequate test plan and follows this test plan.

Testing of the system, software, or process will provide assurance that it works as intended.

How

Review the test plan for elements such as

  • Determine whether the test plan includes

    • Unit testing (testing of individual system modules or units or groups of related units)

    • Integration testing (testing of multiple modules or units to ensure that they work together correctly)

    • System testing (testing of the overall system by the development team)

    • Acceptance testing (testing performed by the end users to validate that the system meets requirements and is acceptable)

    • Regression testing (retesting select areas to ensure that changes made to one part of the system did not cause problems in other parts of the system)

  • Ensure that the test plan and related procedures and test cases are repeatable so that they can be used for regression testing and future releases.

  • Ensure that test plans and cases go through a peer review to ensure quality.

  • Determine if the test plan includes testing of bad/erroneous data, system error handling, and system recovery.

  • Determine if the test plan includes testing of security and internal controls.

  • Ensure that results of testing are fully documented.

  • Ensure that gaps identified during testing are documented, tracked, resolved, and retested. Ensure that the gap/bug-tracking process is agreed to up front. This process needs to be baselined and a system of controlled change established quickly, or it can quickly become a mess with code being pulled in and out of production haphazardly.

  • Ensure that the project team has agreed to metrics to be captured and reported during testing and that these metrics are reported in a timely fashion to the appropriate members of the project leadership.

  • Ensure that the test plan includes the testing of performance requirements and thresholds.

  • Ensure that each test case identifies the product, component, or module that it is testing.

  • Evaluate that the process for ensuring all major functionality is tested and that all key logic paths are identified and tested.

  • Ensure that test data have been created and that the customers agree that they are valid test data.

  • Determine whether test steps define expected results and customer-acceptance criteria.

  • Ensure that all test tasks are identified and assigned an owner and that the "who, what, where, and when" of testing have been clearly identified for all parties involved.

  • Ensure that appropriate sign-offs have been obtained for the plan.

  • Determine whether the test plan lists the sequence in which test steps should be performed.

  • Ensure that test planning includes the identification of and plans for obtaining hardware and software needed for testing.

  • If using a combination of vendor software and internally developed code, determine whether there is a process defined for ensuring that both parties' code will be merged together in a well-coordinated fashion.

Note

This list should not be used as a mechanical checklist. The absence of one of these items should not automatically result in an audit issue. Instead, look at the testing process as a whole, and determine whether enough of the key elements are present to provide a reasonable comfort level that adequate and controlled testing is taking place.

24 Ensure that all requirements can be mapped to a test case.

A defined process for tracing requirements to the test plan will provide assurance that all requirements are addressed and tested.

How

If it exists, review the requirements trace map, and verify that all requirements are represented and map to a test case. If a trace map doesn't exist, review the process for ensuring that all requirements are tested.

25 Ensure that users are involved in testing and agree that the system meets requirements. This should include IT personnel who will be supporting the system and IT personnel who were involved in performing initial technical feasibility studies for the project.

The system, software, or process is being developed to meet a specific business need. The project cannot be a success if the key stakeholders are not satisfied. Therefore, they must be involved in testing and signing off on the system prior to implementation. Also, as mentioned in step 13, there are usually multiple organizations in the IT environment that will be involved in supporting any new system, including network support, operating system support, database support, data center personnel, IT security, and the help desk. If these organizations are not involved in testing and signing off on the system, they may not be prepared to support it, and/or the system may not be in compliance with applicable standards and policies.

How

Look for evidence of user acceptance testing. Ensure that key stakeholders who were involved in requesting and approving the project and in defining system requirements (including affected IT organizations) are also involved in testing and project sign-off.

26 Consider participating in user acceptance testing and validating that system security and internal controls are functioning as intended.

This is necessary for the same reasons outlined in step 15. By participating in testing, you will be able to independently validate these controls.

How

During earlier steps, you should have worked with the project team to identify the internal controls that should be built into the system, software, or process. Review the test plan to ensure that it encompasses testing of those internal controls. Participate as an acceptance tester of those test cases.


Implementation

27 Ensure that an effective process exists for recording, tracking, escalating, and resolving problems that arise after implementation.

Unforeseen problems arise after the implementation of almost any new system. Without a robust method for capturing and resolving those issues, there likely will be instances where issues will "slip through the cracks" and not be resolved in a timely fashion. Also, an issue-tracking system is needed to ensure that issues are being prioritized and worked according to their importance.

How

Review the issues database, issues spreadsheet, or whatever other method has been established for recording and tracking postimplementation issues. Ensure that the issue-tracking tool records adequate information regarding each issue, including description of the issue, priority level, due date, latest status, and resolution information. Ensure that controls exist over the tool used to track issues, such as backups and security to prevent unauthorized updates. Review processes for escalating issues and for ensuring issues are tracked to resolution. Review the issues list for evidence that issues are being closed. Interview customers to ensure that the process is working.

28 Review and evaluate the project's conversion plan. Ensure that the project has an adequate conversion plan and follows this plan.

If the project being reviewed involves replacing an existing system, there will need to be a point at which users switch over to the new system. It is critical that existing data be converted successfully to the new system prior to this cut-over to ensure a smooth transition.

How

Review the conversion plan, and look for elements such as the following:

  • Ensure that all critical data are identified and considered for conversion.

  • Review controls for ensuring that all data are converted completely and accurately. Examples of these control mechanisms could be control totals on key fields, record counts, and user reconciliation procedures.

  • Determine whether all conversion programs are fully tested with user involvement and that the test results are documented.

  • If historical data are not converted, ensure that a method is developed for accessing these data if needed. For example, if financial data are involved, historical financial data may be needed in the future for IRS reporting.

  • Review and evaluate plans for parallel processing or other fallback methods in case difficulties are experienced during cut-over to the new system.

  • Ensure that the conversion process includes establishing data that were not used in the legacy systems. For example, a record in the new system may contain fields that were not contained in a similar record on the legacy systems. Consideration should be given to populating these new fields.

  • Review and evaluate the plan for "conversion weekend." There should be a detailed plan containing criteria and checkpoints for making "go/no-go" decisions.

Note

This list should not be used as a mechanical checklist. The absence of one of these items should not automatically result in an audit issue. Instead, look at the conversion process as a whole, and determine whether enough of the key elements are present to provide a reasonable comfort level that adequate and controlled conversion is taking place.

29 Review plans for converting the support of the new system or software from the project team to an operational support team.

Once the project has been completed, it is likely that project personnel will be redeployed to other projects. It is therefore critical that run/maintain support personnel be trained properly in the functionality of the system so that they will be prepared to support it when users identify issues or request enhancements.

How

Through interviews or review of documentation, look for evidence that support personnel have been identified, adequately involved in the project, and appropriately trained on the system and its functionality.

30 Ensure that sufficient documentation has been created for use of the system or process being developed and maintenance of the system or software. Evaluate processes for keeping the documentation up-to-date. Evaluate change controls and security over that documentation.

Incomplete or out-of-date technical and user documentation could increase costs and cycle time to maintain the software, increase support and training costs, and limit the system, process, or software's usefulness to the customer.

How

Obtain copies of existing documentation, and evaluate its adequacy. Look for evidence that would indicate that documentation has been updated when the system has changed, and review processes for ensuring ongoing maintenance of the documentation. Ensure that files containing documentation are locked down and can be modified only by appropriate personnel (using techniques described in Chapters 6 and 7). Interview appropriate personnel to understand processes for changing critical documents. Ensure that an approval process is required before changes are made to significant documents and that the approval process cannot be circumvented.


Training

31 Review plans for making sure that all affected users are trained on use of the new system, software, or process.

Training is an essential element for preparing end users on the functionality and nuances of what has been developed. If training is not given or is inadequate, the new system, software, or process likely will be misused, used ineffectively, or avoided.

How

Review the training plans and interview users to develop an opinion on its adequacy. Compare a list of planned training recipients with the population of end users to ensure that there are no significant gaps.

32 Ensure that processes are in place for keeping training materials up-to-date. Evaluate change controls and security over the training materials.

As new employees and new users have a need to use the system, they will want to take advantage of the training materials. If these training materials have become outdated (e.g., owing to system changes), the effectiveness of the training materials will be limited.

How

Look for evidence that would indicate that training has been updated when the system has changed, and review processes for ensuring ongoing maintenance of the documentation. Ensure that files containing documentation are locked down and can be modified only by appropriate personnel (using techniques described in Chapters 6 and 7). Interview appropriate personnel to understand processes for changing critical documents. Ensure that an approval process is required before changes are made to significant documents and that the approval process cannot be circumvented.


Project Wrap-up

33 Ensure that there is a process for closing out the project and recording lessons learned and that the process is followed.

Finalized project documentation and recorded lessons learned can be used to aid in the effectiveness and efficiency of future company projects.

How

Review the project documentation, and ensure that all relevant documents have been finalized and baselined. Look for evidence that a final list of lessons learned from the project has been documented.


Knowledge Base

The Project Management Institute (PMI) is responsible for publishing the well-known Project Management Professional (PMP) certification. If you would like more information about PMI or the PMP, visit http://www.pmi.org.

The Software Engineering Institute (SEI) and its Capability Maturity Model Integration (CMMI) are useful tools for gathering best practices for software-development methodology. The SEI's mission is to advance software engineering and related disciplines to ensure the development and operation of systems with predictable and improved cost, schedule, and quality. The CMMI is a process-improvement approach that provides organizations with the essential elements of effective processes. If you would like more information on them, visit http://www.sei.cmu.edu.


Master Checklists

Auditing Overall Project Management

Checklist for Auditing Overall Project Management

  1. qEnsure that sufficient project documentation and software development process documentation (if applicable) have been created. Ensure that the company's project methodology standards are being followed.

  2. qReview procedures for ensuring that project documentation is kept up-to-date.

  3. qEvaluate security and change-management processes for critical project documentation.

  4. qEvaluate procedures for backing up critical project software and documentation. Ensure that backups are stored offsite and that documented procedures exist for recovery.

  5. qEnsure that an effective process exists for capturing project issues, escalating those issues as appropriate, and tracking them to resolution.

  6. qEnsure that an effective process exists for capturing project change requests, prioritizing them, and dispositioning them.

  7. qVerify that a project schedule has been created and that it contains sufficient detail based on the size of the project. Ensure that there is a process in place for monitoring progress and reporting significant delays.

  8. qEnsure that there is a method for tracking project costs and reporting overruns. Ensure that all project costs, including labor, are considered and tracked.

  9. qEvaluate the project leadership structure to ensure that both the business and IT are represented adequately.

Auditing Project Startup

Checklist for Auditing Project Startup

  1. qEnsure that appropriate project approval processes were followed prior to project initiation.

  2. qEnsure that a technical feasibility analysis has been performed along with, if applicable, a feasibility analysis by the company's legal department.

  3. qReview and evaluate the requirements document. Determine if and how customer requirements for the project are obtained and documented before development takes place. Ensure that the customers sign off on the requirements and that the requirements encompass standard IT elements.

  4. qEvaluate the process for ensuring that all affected groups who will be helping to support the system, software, or process are involved in the project and will be part of the sign-off process, indicating their readiness to support it.

  5. qReview the process for establishing the priority of requirements.

  6. qDetermine whether the system requirements and preliminary design ensure that appropriate internal control and security elements will be designed into the system, process, or software.

  7. qIf the project involves the purchase of software or technology, review and evaluate the vendor selection process and related contracts.

Auditing Detailed Design and System Development

Checklist for Auditing Detailed Design and System Development

  1. qEnsure that all requirements can be mapped to a design element.

  2. qVerify that the key stakeholders have signed off on the detailed design document (or equivalent).

  3. qReview processes for ensuring ongoing customer involvement with the prioritization of tasks on the project.

  4. qLook for evidence of peer reviews in design and development.

  5. qVerify that appropriate internal controls and security have been designed into the system.

Auditing Testing

Checklist for Auditing Testing

  1. qVerify that design and testing are taking place in a development/test environment and not in a production environment.

  2. qReview and evaluate the testing process. Ensure that the project has an adequate test plan and follows this test plan.

  3. qEnsure that all requirements can be mapped to a test case.

  4. qEnsure that users are involved in testing and agree that the system meets requirements. This should include IT personnel who will be supporting the system and IT personnel who were involved in performing initial technical feasibility studies for the project.

  5. qConsider participating in user acceptance testing and validating that system security and internal controls are functioning as intended.

Auditing Implementation

Checklist for Auditing Implementation

  1. qEnsure that an effective process exists for recording, tracking, escalating, and resolving problems that arise after implementation.

  2. qReview and evaluate the project's conversion plan. Ensure that the project has an adequate conversion plan and follows this plan.

  3. qReview plans for converting the support of the new system or software from the project team to an operational support team.

  4. qEnsure that sufficient documentation has been created for use of the system or process being developed and maintenance of the system or software. Evaluate processes for keeping the documentation up-to-date. Evaluate change controls and security over that documentation.

Auditing Training

Checklist for Auditing Training

  1. qReview plans for making sure that all affected users are trained on the use of the new system, software, or process.

  2. qEnsure that processes are in place for keeping training materials up-to-date. Evaluate change controls and security over the training materials.

Auditing Project Wrap-up

Checklist for Auditing Project Wrap-up

  1. qEnsure that there is a process for closing out the project and recording lessons learned and that the process is followed.


Part III: Frameworks, Standards, and Regulations

Chapter List

Chapter 13: Frameworks and Standards
Chapter 14: Regulations
Chapter 15: Risk Management


Chapter 13: Frameworks and Standards

Introduction to Internal IT Controls, Frameworks, and Standards

In the 1970s, concern over the rise in corporate bankruptcies and financial collapses began to heighten a demand for more accountability and transparency among publicly held companies. The Foreign Corrupt Practices Act of 1977 (FCPA) criminalized bribery in foreign countries and was the first regulation that required companies to implement internal control programs to keep extensive records of transactions for disclosure purposes.

When the savings and loan industry collapsed in the mid-1980s, there was a cry for governmental oversight of accounting standards and the auditing profession. In an effort to deter governmental intervention, an independent private-sector initiative, later called COSO, was initiated in 1985 to assess how best to improve the quality of financial reporting. COSO formalized the concepts of internal control and framework in 1992 when it issued the landmark publication Internal Control-Integrated Framework.

Since that time, other professional associations have continued to develop additional frameworks and standards to provide guidance and best practices to their constituents and the IT community at large. The following sections will highlight COSO and some of the other most prominent IT frameworks and standards in use today.


COSO

In the mid-1980s, the National Commission on Fraudulent Financial Reporting was formed as a response to growing U.S. financial crises and the cry for governmental oversight of accounting and audit practices. This independent private-sector consortium was more commonly referred to as the Treadway Commission because it was headed by James C. Treadway, Jr., executive vice president and general counsel at Paine Webber Incorporated and a former commissioner of the U.S. Securities and Exchange Commission. In its initial 1987 report, the group recommended that the organizations sponsoring the commission work together to develop comprehensive guidelines for internal control. Hence the Committee of Sponsoring Organizations (COSO) was formed by the five (5) major professional associations in the United States:

  • American Institute of Certified Public Accountants (AICPA)

  • American Accounting Association (AAA)

  • Financial Executives Institute (FEI)

  • Institute of Internal Auditors (IIA)

  • Institute of Management Accountants (IMA)

The commission is wholly independent of each of the sponsoring organizations and contains representatives from industry, public accounting, investment firms, and the New York Stock Exchange.

COSO published the first formalized guidelines for internal controls, Internal Control- Integrated Framework, in 1992. This publication established a common definition for internal control and a framework against which organizations can assess and improve their control systems. In 1994, COSO's work was endorsed by the head of the General Accounting Office (GAO) of the U.S. Congress. These voluntary industry guidelines were intended to help public companies become self-regulating and thus avoid the need for governmental regulation of the accounting and auditing industries.

In 2001, COSO began its second major initiative aimed at expanding previous work on internal controls to address the growing emphasis on risk management. At about the same time, the United States was barraged with the sensational failures of Enron, Tyco, Global Crossing, Kmart, Adelphia, Worldcom, HealthSouth, and many others. The U.S. government quickly enacted the Sarbanes-Oxley Act of 2002 to mandate the requirement for internal controls to be audited along with financial statements (as discussed in more detail in Chapter 14). On the heels of all this high-profile activity, COSO published in 2004, Enterprise Risk Management-Integrated Framework. This second document provided a more comprehensive framework for identifying, assessing, and managing risk.

The COSO works are commonly accepted today in the United States as the cornerstones of modern internal control and enterprise risk-management practices. COSO revolutionized the accounting and auditing professions by establishing a common definition for internal control, enterprise risk management, and some fundamental concepts.

COSO Definition of Internal Control

Internal control is a process, affected by an entity's board of directors, management, and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following categories:

  • Effectiveness and efficiency of operations

  • Reliability of financial reporting

  • Compliance with applicable laws and regulations

Key Concepts of Internal Control

The following are key concepts of internal control according to COSO:

  • Internal control is a process. It is a means to an end, not an end in itself.

  • Internal control is affected by people. It's not merely policy manuals and forms, but people at every level of an organization.

  • Internal control can be expected to provide only reasonable assurance, not absolute assurance, to an entity's management and board.

  • Internal control is geared to the achievement of objectives in one or more separate but overlapping categories.

Internal Control-Integrated Framework

The Internal Control-Integrated Framework publication introduced what is now a well-known graphic: the COSO cube (Figure 13-1).

Image from book
Figure 13-1: COSO cube.

As explained by COSO, internal control consists of five interrelated components. These are derived from the way management runs a business and are integrated with the company's management process. Although the components apply to all entities, small and midsize companies may implement them differently than large ones. Its controls may be less formal and less structured, yet a small company still can have effective internal control. The components are

  • Control environment

  • Risk assessment

  • Control activities

  • Information and communication

  • Monitoring

Control Environment

The control environment sets the tone of an organization, influencing the control consciousness of its people. It is the foundation for all other components of internal control, providing discipline and structure. Control-environment factors include the integrity, ethical values, and competence of the entity's people; management's philosophy and operating style; the way management assigns authority and responsibility and organizes and develops its people; and the attention and direction provided by the board of directors.

Risk Assessment

Every entity faces a variety of risks from external and internal sources that must be assessed. A precondition to risk assessment is establishment of objectives that should be linked at different levels and internally consistent. Risk assessment is the identification and analysis of relevant risks to achievement of the objectives forming a basis for determining how the risks should be managed. Because economic, industry, regulatory, and operating conditions will continue to change, mechanisms are needed to identify and deal with the special risks associated with change.

Control Activities

Control activities are the policies and procedures that help to ensure that management directives are carried out. They help to ensure that necessary actions are taken to address risks and thus achieve the entity's objectives. Control activities occur throughout the organization, at all levels and in all functions. They include a range of activities as diverse as approvals, authorizations, verifications, reconciliations, reviews of operating performance, security of assets, and segregation of duties.

Information and Communication

According to COSO, pertinent information must be identified, captured, and communicated in a form and time frame that enable people to carry out their responsibilities. Information systems produce reports containing operational, financial, and compliance-related information that make it possible to run and control the business. They deal not only with internally generated data but also with information about external events, activities, and conditions necessary to informed business decision making and external reporting.

Effective communication also must occur in a broader sense, flowing down, across, and up the organization. All personnel must receive a clear message from top management that control responsibilities must be taken seriously. They must understand their own role in the internal control system, as well as how individual activities relate to the work of others. They must have a means of communicating significant information upstream. There also needs to be effective communication with external parties, such as customers, suppliers, regulators, and shareholders.

Monitoring

Internal control systems need to be monitored-a process that assesses the quality of the system's performance over time. This is accomplished through ongoing monitoring activities, separate evaluations, or a combination of the two. Ongoing monitoring occurs in the course of operations. It includes regular management and supervisory activities and other actions personnel take in performing their duties. The scope and frequency of separate evaluations will depend primarily on an assessment of risks and the effectiveness of ongoing monitoring procedures. Internal control deficiencies should be reported upstream, with serious matters reported to top management and the board.

Component Relationships

There is synergy and linkage among these components, forming an integrated system that reacts dynamically to changing conditions. The internal control system is intertwined with the entity's operating activities and exists for fundamental business reasons. Internal control is most effective when controls are built into the entity's infrastructure and are a part of the essence of the enterprise. "Built in" controls support quality and empowerment initiatives, avoiding unnecessary costs and enabling quick response to changing conditions.

There is a direct relationship between the three categories of objectives (described in the COSO definition of internal control) that are what an entity strives to achieve and components that represent what is needed to achieve the objectives. All components are relevant to each objectives category. When looking at any one category-the effectiveness and efficiency of operations, for instance-all five components must be present and functioning effectively to conclude that internal control over operations is effective.

The internal control definition-with its underlying fundamental concepts of a process, affected by people, providing reasonable assurance-together with the categorization of objectives and the components and criteria for effectiveness and the associated discussions, constitutes this internal control framework.

Enterprise Risk Management-Integrated Framework

COSO published Enterprise Risk Management-Integrated Framework in 2004 to provide companies with a benchmark for managing risk within their organizations.

COSO Definition of Enterprise Risk Management

Enterprise risk management is a process, affected by an entity's board of directors, management, and other personnel, applied in strategy setting and across the enterprise and designed to identify potential events that may affect the entity, and manage risk to be within its risk appetite, to provide reasonable assurance regarding the achievement of entity objectives.

This definition reflects certain fundamental concepts. Enterprise risk management is

  • A process, ongoing and flowing through an entity

  • Affected by people at every level of an organization

  • Applied in strategy setting

  • Applied across the enterprise, at every level and unit, and includes taking an entity-level portfolio view of risk

  • Designed to identify potential events that, if they occur, will affect the entity and to manage risk within its risk appetite

  • Able to provide reasonable assurance to an entity's management and board of directors

  • Geared to achievement of objectives in one or more separate but overlapping categories

Enterprise Risk Management-Integrated Framework Concepts

In the publication Enterprise Risk Management-Integrated Framework, the original COSO cube was expanded, as illustrated in Figure 13-2.

Image from book
Figure 13-2: Expanded COSO cube.

This enterprise risk-management framework is geared to achieving an entity's objectives, set forth in four categories:

  • Strategic-high-level goals, aligned with and supporting its mission

  • Operations-effective and efficient use of its resources

  • Reporting-reliability of reporting

  • Compliance-compliance with applicable laws and regulations.

Enterprise risk management consists of eight interrelated components. These are derived from the way management runs an enterprise and are integrated with the management process. These components are

  • Internal environment

  • Objective setting

  • Event identification

  • Risk assessment

  • Risk response

  • Control activities

  • Information and communication

  • Monitoring

Internal Environment The internal environment encompasses the tone of an organization and sets the basis for how risk is viewed and addressed by an entity's people. It includes risk-management philosophy and the entities risk appetite, integrity, and ethical values.

Objective Setting Objectives must exist before management can identify potential events affecting their achievement. Enterprise risk management ensures that management has in place a process to set objectives and that the chosen objectives support and align with the entity's mission and are consistent with its appetite for risk.

Event Identification Internal and external events affecting achievement of an entity's objectives must be identified, distinguishing between risks and opportunities. Opportunities are channeled back to management's strategy or objective-setting processes.

Risk Assessment Risks are analyzed, considering likelihood and impact, as a basis for determining how they should be managed. Risks are assessed on an inherent and a residual basis.

Risk Response Management selects risk responses-avoiding, accepting, reducing, or sharing-developing a set of actions to align risks with the entity's risk tolerances and risk appetite.

Control Activities Policies and procedures are established and implemented to help ensure that the risk responses are carried out effectively.

Information and Communication Relevant information is identified, captured, and communicated in a form and time frame that enables people to carry out their responsibilities. Effective communication also occurs in a broader sense, flowing down, across, and up the entity.

Monitoring The entirety of enterprise risk management is monitored and modifications made as necessary. Monitoring is accomplished through ongoing management activities, separate evaluations, or both.

Relationship between Internal Control and Enterprise Risk-Management Publications

Because Internal Control-Integrated Framework has stood the test of time and is the basis for existing rules, regulations, and laws, the document remains in place as the definition of and framework for internal control. At the same time, internal control is an integral part of enterprise risk management. The entirety of the Internal Control-Integrated Framework is incorporated by reference into the publication Enterprise Risk Management-Integrated Framework. The enterprise risk-management framework incorporates internal control, forming an additional conceptualization and tool for management.

The Impact of COSO

The far-reaching principles outlined in the landmark COSO documents are gradually being implemented across the United States in publicly held corporations. COSO is the only framework for internal control mentioned by the U.S. Securities and Exchange Commission (SEC) and the Public Company Accounting Oversight Board (PCAOB) as a framework for internal control[*].

Note

COSO is specifically referenced by the SEC in its guidance to companies for implementing the provisions of the Sarbanes-Oxley Act.

The PCAOB is the agency within the SEC that was created by the Sarbanes-Oxley Act of 2002 to oversee the accounting processes used by publicly held corporations. This is discussed in more detail in Chapter 14. In Auditing Standard No. 2, "An Audit of Internal Control over Financial Reporting Performed in Conjunction with an Audit of Financial Statements," the PCAOB specifically references COSO.

In providing guidance related to the Sarbanes-Oxley Act, Audit Standard No. 2 states, "Management is required to base its assessment of the effectiveness of the company's internal control over financial reporting on a suitable, recognized control framework. The COSO report known as Internal Control-Integrated Framework provides a suitable and available framework for purposes of management's assessment. For that reason, the performance and reporting directions in this standard are based on the COSO framework."

Further, COSO principles are also making their way into governmental agencies, private companies, non-profit organizations, and additional entities around the globe. Stakeholders are recognizing that good practices for public companies are often good practices for them as well.

COSO's Effect on IT Controls

Note

COSO introduces the concept of controls over information systems.

In Internal Control-Integrated Framework, COSO states that due to widespread reliance on information systems, controls are needed over significant systems. It classifies information systems control activities into two broad groupings. The first is general computer controls, which include controls over IT management, IT infrastructure, security management, and software acquisition, development, and maintenance. These controls apply to all systems-from mainframe to client-server to desktop computer environments.

The second grouping is application controls, which include computerized steps within application software to control the technology application. Combined with other manual process controls where necessary, these controls ensure completeness, accuracy, and validity of information.

[*]Copyright © 1992/2004 by the Committee of Sponsoring Organizations of the Treadway Commission. Reproduced with permission from the AICPA acting as authorized copyright © administrator for COSO.


CoBIT

CoBIT is the short name for Control Objectives for Information and Related Technologies. First published in April 1996, CoBIT is the foremost internationally recognized framework for IT governance and control. The most recent version, CoBIT 4.0, was released in 2005.

CoBIT was developed by the IT Governance Institute (ITGI) using a worldwide panel of experts from industry, academia, government, and the IT security and control profession. In-depth research was conducted across a wide variety of global sources in order to pull together the best ideas from all germane technical and professional standards.

CoBIT Concepts

CoBIT divides its primary control objectives into four domains: plan and organize, acquire and implement, deliver and support, and monitor and evaluate. Each of the domains shows the key IT control activities associated with that area. The framework highlights seven qualities of information:

  • Effectiveness

  • Efficiency

  • Confidentiality

  • Integrity

  • Availability

  • Compliance

  • Reliability

There are 34 high-level control objectives and 215 lower-level control activities that are outlined within the CoBIT framework. IT resources are defined as people, applications, infrastructure, and information.

The model shows how all IT activities need to support the governance objectives that, in turn, support the business objectives. The control activities of the four domains work together in a cyclic manner to produce a well-governed IT support organization that produces optimal results based on the priorities and resources of the organization.

The CoBIT framework goes on to elaborate on each of the control activities by providing detailed auditing guidelines (Figure 13-3).

Image from book
Figure 13-3: CoBIT framework.

CoBIT Features

Following are some are some additional features that CoBIT provides:

  • CoBIT represents a generally applicable and internationally accepted standard of good practice for IT controls.

  • CoBIT is independent of technical platform.

  • CoBIT is management and business process owner-oriented.

  • CoBIT has become the international de facto standard for IT governance.

The nonprofit, independent ITGI (http://www.itgi.org) is a research entity affiliated with ISACA. ITGI was established in 1998 to advance international thinking and standards in directing and controlling an enterprise's IT. In addition, ITGI offers original research and case studies to assist organizations and boards of directors in managing their IT resources.

ISACA (http://www.iscaca.org) is a recognized worldwide leader in IT governance, control, security, and assurance, with more than 50,000 members in over 140 countries. Founded in 1969, ISACA sponsors international conferences, publishes the Information Systems Control Journal, and develops international information systems auditing and control standards. Additionally, ISACA administers the globally respected Certified Information Systems Auditor (CISA) designation and the Certified Information Security Manager (CISM) designation.

IT Governance

ISACA was an early promoter of the IT governance concept. It created the ITGI to assist enterprise leaders in their responsibility to ensure that IT goals align with those of the business by ensuring that IT delivers value, performance is measured, resources are allocated properly, and risks mitigated.

ITGI provides the following definition: "IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization's IT sustains and extends the organization's strategies and objectives."

The growing need for IT governance tools and techniques was fueled by the following factors:

  • Growing complexity of IT environments

  • Fragmented or poorly performing IT infrastructures

  • User frustration leading to ad hoc solutions

  • IT costs perceived to be out of control

  • IT managers operating like firefighters

  • Communication gap between business and IT managers

  • Increasing pressure to leverage technology in business strategies

  • Need to comply with increasing laws, standards, and regulations

  • Scarcity of skilled staff

  • Lack of application ownership

  • Resource conflicts/shifting priorities

  • Impaired organizational flexibility and nimbleness to change

  • Concern for risk exposures

  • Volatile organizational, political, or economic environment

IT Governance Maturity Model

ITGI developed a maturity model for the internal control of IT that provides to organizations a pragmatic and structured approach to measuring how well developed their processes are against a consistent and easy-to-understand scale. The maturity model was fashioned after the one originated by the Software Engineering Institute (SEI) for software development. SEI is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

ITGI expanded the basic concept of the maturity model by applying it to the management of IT processes and controls. The principles were used to define a set of levels that allow an organization to assess where it is relative to the control and governance over IT. As shown in the Figure 13-4, these levels are presented on a scale that moves from nonexistent on the left to optimized on the right. By using such a scale, an organization can determine where it is and define where it wants to go, and if it identifies a gap, it can do an analysis to translate the findings into projects. Reference points can be added to the scale. Comparisons can be performed with what others are doing if those data are available, and the organization can determine where emerging international standards and industry best practices are pointing for the effective management of security and control. A description of the ITGI rating is given in Figure 13-5.

Image from book
Figure 13-4: IT Governance Institute maturity scale.
Image from book
Maturity Model for Internal Control
Maturity Level | Status of the Internal Control Environment | Establishment of Internal Controls
0 Nonexistent | There is no recognition of the need for internal control. Control is not part of the organisation'n culture or mission. There is a high risk of control deficiencies and incidents. | There is no intent to assess the need for internal control. Incidents are dealt with as they arise.
1 Initial/ ad hoc | There is some recognition of the need for internal control. The approach to risk and control requirements is ad hoc and disorganised, without communication or monitoring. Deficiencies are not identified. Employees are not aware of their responsibilities. | There is no awareness of the need for assessment of what is needed in terms of IT controls. When performed, it is only on an ad hoc basis, at a high level and in reaction to significant incidents. Assessment addresses only the actual incident.
2 Repeatable but Intuitive | Controls are in place but are not documented. Their operation is dependent on knowledge and motivation of individuals. Effectiveness is not adequately evaluated. Many control weaknesses exit and are not adequately addressed; the impact can be severe. Management actions to resolve control issues are not prioritised or consistent. Employees may not be aware of their responsibilities. | Assessment of control needs occurs only when needed for selected IT processes to determine the current level of control maturity, the target level that should be reached and the gaps that exist An informal workshop approach, involving IT managers and the team involved in the process, is used to define an adequate approach to controls for the process and to motivate an agreed action plan.
3 Defined Process | Controls are in place and are adequately documented. Operating effectiveness is evaluated on a periodic basis and their is an average number of issues. However, the evaluation process is not documented. While management is able to deal predictably with most control issues, some control weaknesses persist and impacts could still be severe. Employees are aware of their responsibilities for control. | Critical IT processes are identified based on value and risk drivers. A detailed analysis is performed to identify control requirements and the root cause of gaps and to develop improvement opportunities. In addition to facilitated workshops, tools are used and interviews are performed to support the analysis and ensure that an a IT process owner owns and drives the assessment and improvement process.
4 Managed and Measurable | There is an effective internal control and risk management environment. A formal, documented evaluation of controls occurs frequently. Many controls are automated and regularly reviewed. Management is likely to detect most control issues but not all issues are routinely identified. There is consistent follow-up to address identified control weaknesses. A limited, tactical use of technology is applied to automate controls. | IT process criticality is regularly defined with full support and agreement from the relevant business process owners. Assessment of control requirements is based on policy and the actual maturity of these processes, following a thorough and measured analysis involving key stakeholders. Accountability for these assessments is clear and enforced. Improvement strategies are supported by business cases. Performance in achieving the desired outcomes is consistently monitored. External control reviews are organised occasionally.
5 Optimized | An enterprisewide risk and control programme provides continuous and effective control and risk issues resolution. Internal control and risk management are integrated with enterprise practices, supported with automated real-time monitoring with full accountability for control monitoring, risk management and compliance enforcement. Control evaluation is continuous, based on self-assessments and gap and root cause analyses. Employees are proactively involved in control improvements. | Business changes consider the criticality of IT processes, and cover any need to reassess process control capability. IT process owners regularly perform self-assessments to confirm that controls are at the right level of maturity to meet business needs and they consider maturity attributes to find ways to make controls more efficient and effective. The organisation benchmarks to external best practices and seeks external advice on internal control effectiveness. For critical processes, independent reviews take place to provide assurance that the controls are at the desired level of maturity and working as planned.
Image from book

Figure 13-5: IT Governance Institute maturity model for internal control.

The COSO-CoBIT Connection

Figure 13-6 illustrates how CoBIT carries forward the COSO concepts by providing the domains, processes, and control activities for the IT world that guide an enterprise toward meeting the internal control requirements it deems appropriate for its own environment. For more information on CoBIT, visit http://www.isaca.org. For more information on CoBIT visit http://www.isaca.org.

Image from book

Note The COSO mapping is based on the original COSO framework. The mapping also applies generally to the later COSO Enterprise Risk Management--Integrated Framework, which expands on internal control, providing a more robust and extensive focus on the broader subject of enterprise risk management. While it is not intended to and does not replace the original COSO internal control framework, but rather incorporates the internal control framework within it, users of CoBIT may choose to refer to this enterprise risk management framework both to satisfy their internal control needs and to move toward a fuller risk management process.
Figure 13-6: CoBIT-COSO relationships.


ITIL

The IT Infrastructure Library (ITIL) was developed by the U.K. government in the mid-1980s and has become a de facto standard for best practices in the provision of IT infrastructure management and service delivery. ITIL is a registered trade mark of the U.K. Office of Government Commerce, which owns and develops the ITIL best-practices frameworkpractices framework[*].

The ITIL evolved as a result of businesses' growing dependence on IT and has enjoyed a growing global recognition and adoption from organizations of all sizes.

Unlike many standards and frameworks, the widespread adoption of the ITIL has caused a variety of commercial and not-for-profit product vendors to develop products directly supporting the ITIL. In addition, major infrastructure service management products have been refined and organized around the ITIL approaches, which, in turn, has fostered wider acceptance.

In addition, the growth of ITIL has been supplemented by the proliferation of ITIL professional consulting and manager certifications that provide ready access to the expertise needed to plan, configure, and implement the standards.

ITIL Concepts

The ITIL provides a series of practical references and specific standards for infrastructure and services management adaptable to virtually any organization. The service-support functions address such issues as problem management, incident management, service desk, change management, release management, and configuration management. The service-delivery functions address capacity management, availability management, financial management, continuity management, and service levels.

In order to keep the ITIL current and to foster continued growth of the standard, OCG has continued to work closely with the British Standards Institute (BSI) and the Information Technology Service Management Foundation (itSMF). In 2000, BSI and OGC undertook to work together to align the BSI Management Overview (PD0005), the Specification for Service Management (BS 15000-1), the Code of Practice for Service Management (BS 15000-2), and ITIL guidance into a consolidated framework. The management overview provides the introduction to ITIL and leads users into supplemental and increasingly expanded information regarding the standards.

[*]ITIL is a registered trade mark and a registered community trade mark of the Office of Government Commerce and is registered in the U.S. Patent and Trademark Office.


ISO 27001/ISO 17799/BS 7799

Since its inception in 1947, the International Organization for Standardization (ISO) has created a number of standards for network security management, software development, and quality control, in addition to a number of other standards for various business and government functions.

The series of identifiers in this section's heading refer to what are, essentially, the same core set of standards dealing with several aspects of information security practices, information security management, and information security risk management.

The precursor to BS 7799 was first promulgated as an information security standard in 1993 by the U.K. governments' Department of Trade and Industry. Two years after the information security standard was published by the Department of Trade and Industry, it became formalized into the British Standard 7799. Subsequent to that initial publication, BS 7799 has gone through three distinct iterations as the British Standard 7799, adding information security management standards and the most recent version (2005), which added guidelines for information security risk management.

In December 2000 the BS 7799 morphed into ISO Standard 17799. Participation from the international standards community updated the original British standard but the core of the BS 7799 remained largely intact despite the fact that BS 7799 itself has been discontinued.

Continuing the thread, ISO 27001 was published in October of 2005. This standard dealt largely with the topic of BS 7799-2, that is, management of information security systems. This ISO standard was created to provide guidelines for effective information management systems. One of the underlying principles in this incarnation of the information security standard is use of the Organization for Economic Cooperation and Development (OECD) principles governing security of information and network systems. ISO 27001 is the first in a series of information security management and practices standards. This series of standards (27001) was created to "harmonize" with other widely recognized international operations standards, namely, ISO 9001 (quality management) and ISO 14001 (environmental management).

Confusing as the standards names are, adoption and compliance can be equally challenging. Some organizations use one or more versions of the standards as implementation frameworks to guide development of internal information security practices, procedures, and controls. Compliance with certain of the standards may be "certified" by being audited by a qualified "assessor" working for a "certification body" duly recognized by the local (country-specific) "certifying authority."

Fully adopting these standards is not a trivial undertaking and should be done with a significant amount of preplanning and analysis. Consulting, training, and products supporting various aspects of these standards are widely available.

Despite the evolving names and scope, this series of standards has become one of the most recognized and internationally accepted sets of information security practices, frameworks, and guidelines available.

ISO 17799 Concepts

Also referred to as the Code of Practice for Information Security Management, ISO 17799:2005 addresses 11 major areas within the information security discipline. The standard outlines 133 security controls in the following 11 areas:

  • Security policy

  • Organization of information security

  • Asset management

  • Human resources security

  • Physical and environmental security

  • Communications and operations management

  • Access control

  • Information systems acquisition, development, and maintenance

  • Information security incident management

  • Business continuity management

  • Compliance


NSA INFOSEC Assessment Methodology

The National Security Agency INFOSEC Assessment Methodology (NSA IAM) was developed by the U.S. National Security Agency and incorporated into its INFOSEC Training and Rating Program (IATRP) in early 2002.

NSA INFOSEC Assessment Methodology Concepts

The NSA IAM is an information security assessment methodology that baselines assessment activities. It breaks information security assessments into three phases: pre-assessment, on-site activities, and post-assessment. Each of these phases contains mandatory activities to ensure information security assessment consistency. It is important to note, however, that NSA IAM assessments consist of only documentation review, interviews, and observation. There is no testing done during an NSA IAM assessment. The NSA released the INFOSEC Evaluation Methodology to baseline testing activities.

Pre-assessment Phase

The purpose of the pre-assessment phase is to define customer requirements, set the assessment scope and determine assessment boundaries, gain an understanding of the criticality of the customer's information, and create the assessment plan. The NSA IAM measures both organizational information criticality and system information criticality. Organizational information consists of the information required to perform major business functions. System information then is identified by analyzing the information that is processed by the systems that support the major business functions.

The NSA IAM provides matrices that are used to analyze information criticality. A matrix is created for each organization/business function and each system that supports the organization. The vertical axis consists of the information types, whereas the horizontal axis includes columns for confidentiality, integrity, and availability. Information criticality impact values are assigned for each cell. Table 13-1 is an example of a human resources organization information criticality matrix.

Table 13-1: Organizational Information Criticality Matrix
Information Type | Confidentiality | Integrity | Availability
Payroll | H | H | M
Benefits | L | M | L
Employee performance appraisals | H | H | L

On-Site Activities Phase

The on-site activities phase consists of validating pre-assessment-phase conclusions, gathering assessment data, and providing initial feedback to customer stakeholders. There are 18 baseline areas that are evaluated during an IAM assessment:

  • Information security documentation such as policies, procedures, and baselines

  • Roles and responsibilities

  • Contingency planning

  • Configuration management

  • Identification and authentication

  • Account management

  • Session controls

  • Auditing

  • Malicious code protection

  • System maintenance

  • System assurance

  • Networking/connectivity

  • Communications security

  • Media controls

  • Information classification and labeling

  • Physical environment

  • Personnel security

  • Education, training, and awareness

Post-assessment Phase

Once the assessment information is gathered, it is analyzed and consolidated into a report in the final post-assessment phase. The final report includes an executive summary, recognition of good security practices, and a statement regarding the overall information security posture of the organization. Additional information regarding the NSA INFO-SEC Assessment and Evaluation Methodologies can be found at http://www.iatrp.com.


Frameworks and Standards Trends

All over the globe, accounting- and technology-related professional associations are collaborating on standards. Business practices vary significantly around the world, so a single set of frameworks and standards will not appear in the near future. However, these developing frameworks and standards generate discussions that do serve to clarify and provide understanding among disparate foreign bodies in the conduct of trade. While a single set of international standards is not imminent, the tools described in this chapter are nonetheless serving to bridge understanding and promote trade that ultimately benefits all the participants.


References

  • Auditing Standard No. 2: "An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements" (Effective June 17, 2004), http://www.pcaobus.org.

  • Committee of Sponsoring Organizations of the Treadway Commission, http://www.coso.org.

  • http://www.en.wikipedia.org/wiki/COSO.

  • http://www.en.wikipedia.org/wiki/ITIL_v3.

  • International Organization for Standardization, "ISO-Overview", February 2004, http://www.iso.org.

  • ISACA, (prior to January 1, 2006 was known as Information Systems Audit and Control Association), http://www.isaca.org.

  • IT Infrastructure Library, http://www.itil.co.uk.

  • IT Governance Institute, http://www.itgi.org.

  • IT Governance Institute, Board Briefing on IT Governance, 2nd ed. Rolling Meadows, IL, 2003. Copyright © 2003 by the IT Governance Institute, http://www.itgi.org.

  • IT Governance Institute, CoBIT 4.0, Rolling Meadows, IL, 2005. Copyright © 2005 by the IT Governance Institute, http://www.itgi.org.

  • "NSA INFOSEC Assessment and Evaluation Methodologies", http://www.iatrp.com.

  • Soleil, Darcy, "Sarbanes Oxley Section 404 Compliance Tips for IT Managers," 2004, per ISACA SOX Forum listserv.

  • Soleil, Darcy, "Sarbanes Oxley Section 404 Compliance for IT Managers," Auditnet.org.

  • Software Engineering Institute, http://www.sei.cmu.edu.


Chapter 14: Regulations

An Introduction to Legislation Related to Internal Controls

The global nature of business and technology has long dictated a common understanding and support of standards, as demonstrated by the strategic partnerships of the International Organization of Standardization (ISO), the International Electrotechnical Commission (IEC), the International Telecommunication Union (ITU), and the World Trade Organization (WTO). Participation in these standards bodies has been voluntary, with a common goal of promoting global trading for all countries at all levels. Individual countries have gone further to establish governmental controls on business activities of corporations operating within their boundaries.

Regulatory Impact on IT Audit

Over the past decade, the U.S. government has passed numerous industry-specific privacy acts and other regulations. Each has been intended to protect and support the business consumer. Consequently, internal and external audit groups are tasked with reviewing business processes and procedures to ensure that appropriate business controls are in place to mitigate risks to the business and the consumer.

The International Association of Internal Auditors (IIA) and the International Information Systems Audit and Control Association (ISACA) publish guidelines to assist members of these internal and external audit groups in establishing common controls and audit processes.

Note

Despite numerous voluntary standards and guidelines in addition to regulatory mandates, corporations operating in the United States have been involved in notorious scandals in the early years of the twenty-first century. These scandals rocked global confidence in the U.S. public markets.

History of Corporate Financial Regulation

In the 1970s, the concern over internal controls related to financial reporting began to take shape as a result of the growth in bankruptcies and financial collapses such as Penn Central Railroad in 1970, the largest bankruptcy in U.S. history at that point in time. In 1976, a congressional investigation by the Moss and Metcalf committees recommended increased federal regulation in the areas of accounting and auditing. In 1977, the Foreign Corrupt Practices Act made bribes illegal and required corporations to keep extensive records of transactions for disclosure purposes.

By the mid-1980s, the savings and loan industry had collapsed. Congress looked at whether the government should take over the issuance of accounting standards and oversight of auditors. In 1986, the Committee of Sponsoring Organizations (COSO) examined how fraudulent financial management could be curtailed and how auditors could reduce the recognized gap between what auditors do and what the public expects. COSO published the first formalized guidelines for internal controls known as Internal Controls-Integrated Framework, described in more detail in Chapter 13. These voluntary industry guidelines were intended to help public companies become self-regulating and thus avoid the need for governmental regulation.

In 1991, Federal Deposit Insurance Corporation Act (FDICIA) was enacted for the banking industry as a response to the savings and loan collapse. It introduced upper-management accountability using sign-offs.

However, when Enron and other major corporations failed in 2001 and 2002, the U.S. government moved swiftly to enact the most extensive corporate reforms of all in an effort to restore public confidence in U.S. business operations. The Sarbanes-Oxley Act of 2002 and its subsequent revisions have far-reaching impact on all corporations (foreign and domestic) doing business with the United States and on the technology groups supporting those businesses. This chapter will summarize the impact of Sarbanes-Oxley and other government- and industry-imposed regulations on information services departments.


The Sarbanes-Oxley Act of 2002

The Sarbanes-Oxley Act of 2002 (formally known as the Public Company Accounting Reform and Investor Protection Act) was a response from the U.S. government to a rash of notorious corporate scandals that began with Enron and Arthur Andersen, followed closely by Tyco, Adelphia Communications, WorldCom, HealthSouth, and many others.

The Sarbanes-Oxley Act and the Public Company Accounting Oversight Board (PCAOB) were created to restore investor confidence in U.S. public markets. The primary goal was to enhance corporate responsibility, enhance financial disclosures, and deter corporate and accounting fraud.

Sarbanes-Oxley's Impact on Public Corporations

The monetary impact on corporations of complying with this legislation has brought much dissent and lobbying for less strict guidelines. Small companies are seeking exemption from the extensive documentation and reporting. Adjustments during 2005-2006 clarified the extent to which technology controls must be tested and which companies must assert adequate internal controls for all areas with any impact on financial transactions and reporting.

The Sarbanes-Oxley Act requires company executives to attest to the adequacy and effectiveness of their internal controls related to financial transactions and reporting, including information technology (IT) controls. These controls must be audited externally, and a statement of control must be included in the annual corporate report filed with the Security and Exchange Commission (SEC). Consequently, corporate CEOs and CFOs are now being held accountable for the quality and integrity of information generated by their company's applications and communications, as well as the infrastructure that supports those applications.

As a result, information services managers (IS managers) who may not be keenly aware of the internal control measures necessary when dealing with the requirements of Sarbanes-Oxley are being asked to thoroughly examine the technology risks and test all controls. This means that many IS managers request guidelines or consulting assistance to ensure that they are in compliance with the new laws. Because of the different business cultures involved in global corporations and the number of international investors in U.S.-based corporations, it is essential that the global IT community is aware of the impact that financial audits have on the way information services departments operate.

Core Points of the Sarbanes-Oxley Act

The Sarbanes-Oxley Act has many provisions. Sections 101, 302, 404, 409, and 906 are the key sections with relevance and impact on information services departments.

Section 101

In section 101, the PCAOB is established as the governing agency to create auditing standards and rules for public companies. In addition, the PCAOB is given the authority to regulate the accounting firms that audit public companies. The rules issued by the PCAOB and approved by the SEC are referred to as Auditing Standards.

The primary guidance from the PCAOB in regard to auditing internal controls is provided in Auditing Standard No. 2, effective June 17, 2004, entitled, "An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements." We will explore Auditing Standard No. 2 later in this chapter.

Section 302

Section 302 specifies the legal responsibilities of the company's CEO and CFO. According to the Sarbanes-Oxley Act, the CEO and CFO are responsible for all internal controls and for reporting quarterly on any significant changes to internal controls that could affect the company's financial statement. Basically, these two officers must personally certify that they are responsible for and knowledgeable about all financial statements submitted quarterly and annually. They also must certify that they have knowledge of the design and have evaluated the effectiveness of all internal controls and that these controls ensure that complete and accurate information is reported to them. Significant changes to disclosure controls and any deficiencies, weaknesses, or fraudulent acts that may compromise the accuracy of reporting must be disclosed.

Section 302 also defines the external auditor's role over financial reporting. The external auditor evaluates internal controls to determine if modifications need to be made for accuracy and compliance. The external auditor must attest that he or she has reviewed management's assessment of internal controls and has approved the process and evaluation of that assessment.

This section also requires that management particularly address any changes to internal controls over financial reporting that has occurred during the last quarter.

Section 404

Under Section 404, the CEO and CFO attest that internal controls are in place, documented, and effective. Management assessment contains four parts. The first three parts cover the following:

  • Responsibility of management for the existence and rigidity of internal controls

  • Evaluation of the effectiveness of internal controls

  • Statement of the framework used to evaluate the effectiveness of controls

Management is prohibited from stating that internal controls are effective if there are one or more material weaknesses in the controls.

The fourth part concerns the external auditor. The company's external auditor must separately attest that management's statement concerning the effectiveness of internal controls is accurate.

Note

The greatest difficulty most organizations have is furnishing the formal documentation of internal controls and the evidence of the effectiveness of internal controls.

PCAOB Auditing Standard No. 2 On 9 March 2004, the PCAOB approved Auditing Standard No. 2, entitled, "An Audit of Internal Control over Financial Reporting Performed in Conjunction with an Audit of Financial Statements." This audit standard establishes the requirements for performing an audit of internal control over financial reporting and provides some important directions on the scope and approach required of corporation management and external auditors. It also provides guidance on the controls that should be considered, including program development, program changes, computer operations, and access to programs and data. PCAOB Auditing Standard No. 2 specifically addresses the financial reporting controls that should be in place for a period before the attestation date and the controls that may operate after the attestation date.

Section 409

Section 409 states that the CEO and CFO will ensure "rapid and current public disclosure" of any material event that could affect the company's financial or operational performance. Material events could include any type of company restructuring, changes in personage or duties of key personnel, budget overruns on IT projects, and stock sales by corporate officers. It may even be necessary to disclose a major new financial or operational application that is determined to "not work." "Rapid and current disclosure" essentially requires near-real-time reporting. This can be a huge nightmare for companies with a dependence on batch-oriented processing methods that tend to take longer to complete.

Section 906

Section 906 consists of three parts. First is that every periodic report with financial information must be accompanied by a written statement by the CEO and CFO. The second part specifies that the content of this report fairly represent the financial condition of the company. The last section lays out the fines and imprisonment penalties for either knowingly or unknowingly submitting a false statement. It also sets criminal penalties for failure of corporate officers to certify the financial reports in a timely manner-60 days after end of year in 2004, 45 days after end of year in 2005, and 30 days after end of year in 2006.

Sarbanes-Oxley's Impact on IT Departments

For most organizations, IT services are now a vital part of the financial reporting process. The applications and services support creation, storage, processing, and reporting of financial transactions. Therefore, Sarbanes-Oxley compliance also must include controls for the use of technology in data handling, processing, and reporting. General computing controls thus are critical to the overall financial reporting process in ensuring data integrity and secure operations. IT departments now must formally address the design, documentation, implementation, testing, monitoring, and maintaining of IT internal controls.

The CEOs and CFOs look to the information services department to ensure that the general and specific internal controls for all applications, data, networking, contracts, licenses, telecommunications, and physical environment are documented and effective. Overall risk and control considerations are assessed at the departmental level of information services and then at the entity level. Entity-level review may vary depending on the following questions:

  • How large is the organization?

  • Are key functions outsourced?

  • What is the division of process and responsibilities for geographically dispersed locations?

  • How are the control responsibilities split among user groups, IS functions, and third-party providers?

  • How is the strategy for IS-both application and infrastructure-developed, documented, and managed?

To date, audits have found that the primary weaknesses among corporations are consistency, documentation, and communication. A given group within IS may believe that its strategy, tactical procedures, and applications are well controlled. However, communication with other groups may be lacking to the point that no one group knows what the other is doing. One of the most common deficiencies in organizations is the lack of a comprehensive strategic plan concerning how IT can best serve the overall business objectives. Together, these omissions lead to weak security and an uncontrolled or inconsistent architecture.

Sarbanes-Oxley Considerations for Companies with Multiple Locations

Global organizations and non-U.S.-based companies should examine their business-unit technology operations to determine their significance to the organization as a whole. The assessment of an IS business unit depends on the materiality of transactions processed by that unit, the potential impact on financial reporting if the IS business unit fails, and other qualitative risk factors.

A few examples of these assessment considerations might include

  • A U.S. multinational organization that has a single business unit that does not transact enough volume to be financially material, but the IS department within it processes a large amount of information and/or consolidates financial statements for additional locations

  • A U.S.-based insurance company that outsources IS application development, technical support, or maintenance to an IT business unit based in India

Impact of Third-Party Services on Sarbanes-Oxley Compliance

Controls surrounding third-party services should ensure that roles and responsibilities of third parties are clearly defined, adhered to, and continue to satisfy requirements. Control measures are aimed at reviewing and monitoring existing contracts and procedures for their effectiveness and compliance with organization policy. The dissolution of a major contract could have significant impact on financial reporting. Thus it would fall within the guidelines for disclosure by the company officers.

During an audit, company organizations often will contend that they are not responsible for a given control because either the function is outsourced or the software was purchased from and maintained by a third party. According to legislative guidelines, a company can outsource service but not the responsibility for control of that service. It is next to impossible for a company to outsource problems and expect the problems to go away.

Documentation of the third-party controls is required for attestation by the independent auditor, so an assessment must determine the effectiveness and completeness of the service organization's internal controls. If SAS 70 or similar audit opinions do not include controls testing, results of the testing, and the third-party service auditor's opinion on control effectiveness, the reports are not sufficient for Sarbanes-Oxley compliance. Companies should be sure to note whether the specific environment, platforms, and applications used in fulfillment of the outsourced services are covered by the SAS 70 (or similar audit) reports.

Four functional objectives for auditing third-party services and outsourcing major portions of company activities that are relevant to companies, corporation subsidiaries, and multinationals are summarized as follows:

  • Policy statements regarding data integrity, availability, and confidentiality are determined by senior management and must be maintained and contractually supported by any outsource arrangement.

  • Asset-protection requirements should be clearly defined and understood by the principals in any outsourcing agreement.

  • Data and information custodial responsibilities should be well defined and complied with.

  • Service levels should be defined, measurable, and acceptable to both parties. Failure to meet service-level agreements should have some compensatory action. Billing and invoices should be accurate and costs within budgeted amounts.

Specific IT Controls Required for Sarbanes-Oxley Compliance

To date, the PCAOB and external auditors reviewing compliance with Sarbanes-Oxley have been attentive primarily to security, change management, and problem management. A key focus for the audit is integrity of the technology infrastructure for processing, storage, and communication of financial data. This is especially true when financial reports are generated from a data warehouse fed by multiple accounting and business operation systems.

Ownership of IT controls may be unclear, especially for application controls. Therefore, the audit in each area must integrate automated and manual controls at the business-process level.

In general, the following IT controls must be documented and evaluated as effective in order to be in compliance with Sarbanes-Oxley requirements:

  • IT security

  • Change control

  • Data management

  • IT operations

  • Network operations

  • Asset management

IT Security

Security administration must have an effective, documented process for monitoring and enforcing the security policies dictated by management. These policies and processes must be communicated to all user groups. If "user group stewards" are used to spread the security administration workload, those stewards must follow the same policies and procedures as the IS support staff. They, too, must communicate thoroughly and effectively with the user community.

Who has access to the application and data? Who authorizes access? How often is access level reviewed? What is the authorization process? What happens when an authorized person leaves or changes jobs? Is data security enforced at the element level? Are passwords enforced and changed regularly?

Execution of financial transactions or transactions that lead to financial transactions must be limited to those individuals who have an authorized business reason to do so. Access to financial and "protected personal" data likewise must be limited to those individuals who have an authorized business reason for access.

Change Control

To ensure accuracy, completeness, and integrity of financial reporting, companies must have a documented, effective change-control process that includes changes to financial applications, all interface applications, operating systems that control the desktop and host server, productivity tools used to create summary analysis, database management systems, and networks. The change process must provide the following:

  • Points for management review

  • Authorization

  • Migration of changed components

  • Change scheduling

  • Management reporting

  • Communication of changes to the user community

Who can initiate a change? Who authorizes changes? Who can make changes? What testing should be done prior to making a change to production components? Who does the testing and validates the changes? How is testing documented? What process is used to promote development components into production?

Change control applies to applications, productivity tools, and operating system software. Communication of infrastructure changes traditionally has been weak. IS department personnel have long felt that users do not care what is changed or when as long as it works. But what if it doesn't? What if a seemingly unrelated change to an application or operating system causes a category of transactions to be unreported?

Financial application change control is an obvious concern when reviewing controls over financial reporting. Frequently, compliance auditors have not assessed the risks of inadequate change control for interface systems, database infrastructure, operating systems, network systems, or hardware configurations. Even internal IS groups may not realize the relevance of documented and enforced controls in these areas related to financial reporting activities. Recent analysis by risk-assessment experts has shown that inadequate change-control methods can lead to a loss of information integrity in financial applications and data systems. The potential risks include inaccurate reporting or incomplete reporting.

Data Management

Data management encompasses both logical and physical data management as well as identification and protection of critical data, especially data related to financial processing and reporting.

Data Transfer between Systems Timing and frequency of downloads from interface systems to a financial data warehouse or ERP system are audit review items. The response performance of data warehouse queries and reporting is not an issue for Sarbanes-Oxley but is critical for data warehouse functionality. The relevant issue is whether downloads are consistent, timely, and complete with validation routines. Errors found in the extract, transform, and download process should be segregated, reported, and cleared within a reasonable time frame to ensure accurate financial reporting.

Database Structures Compatibility of database management systems used to store financial data is important. If the transactional data used for financial reporting are stored in different data structures, the integrity of summation, interpretation, and analysis can be jeopardized. If different data structures are necessary, then compensating controls must be in place to validate the final compilation of data.

Data-Element Consistency Many companies run multiple accounting systems that use different terminology to represent the same information or the same terminology to represent different information. Therefore, metadata files and data dictionaries should be used to ensure consistent interpretation of key data elements.

Physical Control of Data The physical control of data is crucial to the integrity of financial reporting as well. If the facilities where servers, workstations, and hard-copy reports are located are not secured, then unauthorized viewing or change may compromise transactions and/or data.

Data Backup Timing and frequency of the backup process should be determined by the business need for short-term recovery of data in problem situations. Disaster recovery and business continuity plans are not an inherent part of the latest requirements for Sarbanes-Oxley compliance but are critical to business resiliency. See Chapter 4 for additional information about disaster recovery.

IT Operations

The PCAOB stated that ineffective IT control environments are a significant indication that material weaknesses in internal control over financial reporting exist. IT operations controls extend well beyond the obvious management of hardware and the data center. With respect to acquiring an IT environment, there are controls over the definition, acquisition, installation, configuration, integration, and maintenance of the IT infrastructure. Ongoing daily controls over operations include

  • Day-to-day service-level management

  • Management of third-party services

  • System availability

  • Client services

  • Configuration and systems management

  • Problem management and resolution

  • Operations management scheduling

  • Facilities management

The system software component of operations includes controls over acquisition, implementation, configuration, and maintenance of operating system software, database management systems, middleware software, network communications software, security software, and utilities. System software also includes the incident tracking, logging, and monitoring functions. Finally, another inapparent example of an IT operations control would relate to detail reporting on the use of utilities that alert management to unauthorized access to powerful data-altering functions.

Network Operations

Audit of the network operations and problem management includes a review of entry points to the wide area network (WAN) or local area network (LAN). Proper configuration of firewalls, routers, and modems is essential to avoid unauthorized access to and potential modification of the company financial applications and data. The complete network configuration diagram, including all servers, routers, and firewalls, must be included in the documentation provided to the auditors. Inbound modem and virtual private network (VPN) connections pose a particularly high risk of unauthorized access. All outside telecommunication connections (Internet or point-to-point) must be forced to go through the company network routers and firewalls. See Chapter 5 for more information about auditing network devices.

The current threat of hackers, viruses, worms, and other malicious behavior dictates that each server and workstation (especially portable computers) have antivirus software and the latest antivirus definitions. Potential risk for loss of critical financial data is high should companies not keep antivirus software up to date.

Any virus or worm problems encountered on a workstation or server in the company network should be fully documented. Such documentation should include the determined impact and resolution steps taken.

Asset Management

Audit of asset management deals mostly with authorization, financial expenditure, and appropriate depreciation and reporting. Have key assets (e.g., software, data, hardware, middleware, and facilities) been inventoried and their "company owners" identified? The following asset-management-related items are reviewed during a Sarbanes-Oxley audit:

  • Fixed-asset recording

  • Purchase price

  • Delivery

  • Segregated responsibility for ordering

  • Purchase approval

  • Receipt and disbursement

  • Inventory

  • Depreciation

  • Asset disposal

  • Change management of asset inventory

  • Overall understanding of asset procedures

As a result, records management is an indispensable part of the asset-management plan.

Within asset management, companies should consider facilities controls. Are data center facilities equipped with adequate environmental controls to maintain systems and data, for example, fire suppression, uninterrupted power supply (UPS), air conditioning, elevated floors, and documented emergency procedures. See Chapter 4 for more information pertaining to auditing facilities controls.

The Financial Impact of Sarbanes-Oxley Compliance on Companies

Costs for reviewing internal controls and complying with the Sarbanes-Oxley Act can be high-both in internal costs and in external services costs. Most of the internal IS personnel do not have the background, knowledge, or experience with controls to adequately assess whether the current environment meets Sarbanes-Oxley requirements. Individuals may not have the motivation to do thorough documentation or communication either. Therefore, specialized IT auditors often are brought into the company to do a gap analysis-to determine what is deficient or unreliable. Companies may decide that implementation of automated documentation controls or new financial reporting software is necessary. The level of this commitment will determine the cost.

Despite the high cost of compliance, ineffective controls or noncompliance will result in a much higher cost. Should a company's external auditor find material weaknesses in controls, the competency and credibility of the company may be questioned-thus causing a drop in share price and capital availability. Investors now will be presented with a view of the risks associated with management structure and controls that may prompt them to divest. Foreign issuers may risk enforcement actions and personal liability that they have not encountered before.

In multinational corporations, auditors may be pressed to more closely question suspicious payments that have the earmarks of bribes. In the past, corporate executives did not have a duty to disclose questionable payments that were paid to receive offshore services. This may no longer be an option.

For more specific points to consider, illustrative controls, or tests of those controls, see http://www.isaca.org for the IT Control Objectives for Sarbanes-Oxley.


Gramm-Leach-Bliley Act

The formal title of this law is the Financial Services Modernization Act. The act is more commonly known as the Gramm-Leach-Bliley Act or as the acronym GLBA. The act was directed primarily at allowing expanded functions and relationships among financial institutions. The law covers how and under what circumstances bank holding companies can undertake new affiliations and engage in previously restricted activities.

GLBA Requirements

From the perspective of an impact on internal controls, the GLBA Title V section provided a series of specific regulations governing how individual information for customers of financial institutions may be shared. GLBA requires that financial firms disclose to customers the institutions' privacy policies and practices. The law provides some limited control to customers about how the information retained by a financial institution may be retained via an "opt-out" option. On an annualized basis, the financial institution is required to reinform clients of the institutions' privacy policies.

Enforcement of the act's provisions is assigned to the Federal Trade Commission, the federal banking agencies, the National Credit Union Administration, and the SEC.

Customer Privacy Provisions

GLBA requires financial institutions to review and, in many cases, overhaul how they deal with maintaining the privacy of customer information. Further, the act requires an ongoing review of who has access to what information, under what circumstances the information could be shared, and with whom. The most pervasive impact of the act is an ongoing requirement to control access to and use of client information on an individual-by-individual basis. The legislated "opt-out" requirement made operational and marketing activities much more complicated.

Internal Control Requirements

Section 501B of GLBA essentially mandates three high-level control objectives:

  • Ensuring the confidentiality of customer financial information

  • Protecting against anticipated threats to customer records

  • Protecting against unauthorized access to customer information that could result in substantial impact to the customer

Section 501B also gives governing agencies the authority to establish appropriate standards within their jurisdiction. The governing agencies include

  • Federal Trade Commission (FTC)

  • Federal Deposit Insurance Corporation (FDIC)

  • Office of the Comptroller of the Currency (OCC)

  • Office of Thrift Supervision (OTS)

  • Security and Exchange Commission (SEC)

  • Federal Reserve Board (FRB)

  • National Credit Union Administration (NCUA)

  • Commodity Futures Trading Commission (CFTC)

There are two prevalent standards that outline internal control requirements: the "FTC Safeguard Rule" and "Interagency Guidelines Establishing Standards for Safeguarding Customer Information," which was released by the OCC, OTS, FDIC, and FRB. Generally, the interagency guidelines document, which affects banks, requires the following:

  • A written information security program/strategy

  • Risk assessment and management

  • Access controls for customer information systems

  • Physical access control for areas containing customer information

  • Encryption of customer information either stored or transmitted electronically

  • Change-control procedures

  • Dual control procedures, segregation of duties, employee background checks

  • Security monitoring systems to detect unauthorized access to customer information

  • Incident-response program to effectively address security incidents

  • Protection from physical destruction of customer information

It is important to note, however, that different agencies govern different types of entities. Other rules and guidelines differ to some extent.

Federal Financial Institutions Examination Council

The Federal Financial Institutions Examination Council (FFIEC) is made up of the FRB, FDIC, OCC, OTC, and NCUA. The FFIEC provides IT examination handbooks that can be used by auditors to identify required controls in specific areas such as business continuity, e-banking, and information security. These FFIEC handbooks can be found at http://www.ffiec.gov.


Privacy Regulations Such as California SB 1386

California SB 1386 was one of the first and certainly the most visible state law dealing with breaches of security that cause private information to be disclosed. The law requires an agency, person, or business that conducts business in California and owns or licenses computerized personal information to disclose any breach of security to any resident whose unencrypted data is "believed to have been" disclosed. The law applies not only to companies with direct operations but also those who operate out of state and have California resident data on file.

Included in the law are definitions of what is considered private information, methods of evaluating whether or not information has been unlawfully disclosed, and requirements for notifications of California citizens.

Impact on Companies

The potential downside impacts for a company suffering a breach or loss of data can be substantial. Costs include potential loss of operating licenses in the State of California and damage to company reputation. In fact, most of the security incidents that have been made public, such as the ChoicePoint incident in February 2005 and the CardSys-tems incident in June 2005, were made public only because SB 1386 and other similar privacy laws required it.

One of the most controversial and costly components of the law is sorting through data retained by a company and identifying California residents who might have been affected by a data breach. For many companies, the solution is to notify everyone affected rather than be selective. In many cases, this approach was pursued because it was less expensive rather than because of true concern for customers.

SB 1386 Impact on Internal Controls

From a controls perspective, the law forced many companies to become serious about how they managed private information. In many cases, companies had few, if any, useful privacy or security controls focused on protecting customer information. Many organizations adopted security controls built around the ISO 17799 framework and encrypted private information in order to comply.

SB 1386 and other privacy laws forced controls to be established around internal third-party oversight of information security, typically via the adoption of a security officer role. Additional controls include more stringent data classification controls and access controls, both logical and physical. Controls regarding the identification, disclosure, and reporting of data security breaches are required, as are formalized incident-reporting and management controls.

From an operational perspective, additional controls are required to assess the security profile of third parties, as well as what private data might be shared and the additional controls required.

International Privacy Laws

Although U.S. privacy laws, including SB 1386, are becoming more prevalent, some international privacy legislation is more stringent. Two such laws include the European Directive on the Protection of Personal Data and the Canadian Personal Information Protection and Electronic Documentation Act (PIPEDA).

European Directive on the Protection of Personal Data

In October 1995, the European Union passed the European Directive on the Protection of Personal Data. The directive governs personal information within all member countries of the EU and places minimum protection requirements on it. The directive also prohibits the transmission of information to entities in nonmember states with lesser information privacy protection requirements, including the United States. As with many laws that govern information privacy, the European directive requires entities that collect, transmit, process, or disclose personal information to use appropriate measures to protect such information. Some of the other directive requirements include

  • Notification of individuals about the purposes for which their information is collected

  • Opt-out provisions regarding third-party disclosure or use beyond the original purpose

  • The right of individuals to correct, alter, or delete information pertaining to them that is inaccurate

  • Confinement of stored information to that which is relevant to the stated purpose

Canadian Personal Information Protection and Electronic Document Act

Canada enacted a national privacy law in 2004 commonly referred to as PIPEDA, the Personal Information Protection and Electronic Document Act. It sets forth the following provisions to govern the collection, use, and disclosure of personal information:

  • Parties engaged in the collection of information must show accountability.

  • Information collectors must identify the purposes for the collection of personal information.

  • Information collectors must obtain consent from consumers.

  • The collection of personal information must be limited.

  • The use of personal information must be limited.

  • Disclosure and retention of personal information must be limited.

  • Information collectors must ensure the accuracy of personal information.

  • Information collectors must provide adequate security for the protection of personal information.

  • Information collectors must make information management policies readily available.

  • Information collectors must provide individuals with access to information about themselves.

  • Individuals are given the right to challenge an organization'n compliance with these principles.

Privacy Law Trends

One of the consequences of the SB 1386 is the adoption of identical or nearly identical versions of the bill by other states within the United States. Keeping up with the multiple varieties of similar laws is a significant task. Additionally, there are many countries that have or are in the process of adopting privacy laws. Some of the countries that have enacted privacy laws include Argentina, Japan, Australia, Canada, and of course, all the EU member states. A number of countries, including the United States, are considering privacy legislation at a national level.


Health Insurance Portability and Accountability Act of 1996

In 1996, the U.S. Congress passed the Health Insurance Portability and Accountability Act (HIPAA). The act includes two sections. The first, Title I, provides health insurance coverage after employees have lost or changed jobs. The second section, Title II, deals with administrative actions intended to simplify and standardize health information. The IT component of Title II deals with security and handling of health information in an electronic age. When the topic of HIPAA arises, particularly among IT staff, it is the implications of this section that are most prevalent.

The IT components of the act prescribe a standard methodology for security. Further, HIPAA standardizes formats for health-related information. The standards encompass methods that ensure patient confidentiality and data integrity for any information that can be associated with an individual patient.

The most commonly identified component of the act is a body of data collectively known as protected health information (PHI). These data represents the entire spectrum of individually identifiable health-related information. Any entity that maintains and uses individually identifiable PHI is subject to the act. The effective scope of HIPAA encompasses everyone from hospitals, to insurers, to doctors (of all types), to laboratories, and to companies that operate or participate in health plans. Organizations affected by HIPAA are referred to by the act as covered entities.

HIPAA Privacy and Security Rules

Two rules were published in the Federal Register by the Department of Health and Human Services after HIPAA was passed. The HIPAA Privacy Rule was published in December 2000, and the HIPAA Security Rule was published in February 2003.

The HIPAA Privacy Rule is focused mostly on administrative controls designed to protect patient privacy, such as securing or masking medical charts, locking file cabinets, and establishing privacy policies. The HIPAA Privacy Rule was enforced beginning April 2003.

The HIPAA Security Rule is focused on technical controls such as network perimeter protection encryption and workstation security. The HIPAA Security Rule is broken out into high-level standards and implementation specifications that support each standard. Implementation specifications are either required (mandatory) or addressable (required unless justified otherwise). Table 14-1 that outlines the implementation specifications required by the HIPAA Security Rule. The implementation specifications with (R) next to them are required; those with (A) are addressable. Organizations were given until April 2005 to comply with the HIPAA Security Rule.

Table 14-1: HIPAA Security Rule Requirements
Standard | Security Rule Reference | Implementation Specification
Administrative Safeguards
Security management process | 164.308(a)(1) | Risk Analysis (R) Risk Management (R) Sanction Policy (R) Information System Activity Review (R)
Assigned security responsibility | 164.308(a)(2) | Assigned Security Responsibility (R)
Workforce security | 164.308(a)(3) | Authorization and/or Supervision (A) Workforce Clearance Procedure Termination Procedures (A)
Information access management | 164.308(a)(4) | Isolating Health Care Clearinghouse Function (R) Access Authorization (A) Access Establishment and Modification (A)
Security awareness and training | 164.308(a)(5) | Security Reminders (A) Protection from Malicious Software (A) Log-in Monitoring (A) Password Management (A)
Security incident procedures | 164.308(a)(6) | Response and Reporting (R)
Contingency plan | 164.308(a)(7) | Data Backup Plan (R) Disaster Recovery Plan (R) Emergency Mode Operation Plan (R) Testing and Revision Procedure (A) Applications and Data Criticality Analysis (A)
Evaluation | 164.308(a)(8) | Evaluation (R)
Business associate contracts and other arrangements | 164.308(b)(1) | Written Contract or Other Arrangement (R)
Physical Safeguards
Facility access controls | 164.310(a)(1) | Contingency Operations (A) Facility Security Plan (A) Access Control and Validation Procedures (A) Maintenance Records (A)
Workstation use | 164.310(b) | Workstation Use (R)
Workstation security | 164.310(c) | Workstation Security (R)
Device and media controls | 164.310(d)(1) | Disposal (R) Media Reuse (R) Accountability (A) Data Backup and Storage (A)
Technical Safeguards
Access control | 164.312(a)(1) | Unique User Identification (R) Emergency Access Procedure (R) Automatic Logoff (A) Encryption and Decryption (A)
Audit controls | 164.312(b) | Audit Controls (R)
Integrity | 164.312(c)(1) | Mechanism to Authenticate Electronic Protected Health Information (A)
Person or entity authentication | 164.312(d) | Person or Entity Authentication (R)
Transmission security | 164.312(e)(1) | Integrity Controls (A) Encryption (A)

HIPAA's Impact on Covered Entities

For large health care organizations, compliance with HIPAA provisions has been expensive but did not necessarily represent a major shift in the way they did business. For smaller organizations or those that would not have thought themselves custodians of PHI, the implications have been far more extensive. Successful compliance requires an IT involvement and a focus on security controls associated with access, modification, movement, and handling of PHI. Controls associated with PHI from a privacy and security standpoint are complex but represent commonly used approaches. As a general rule, smaller organizations or those that historically have not maintained significant amounts of PHI have found that implementing the technical security components of HIPAA is challenging. Not surprisingly, this group of entities is the least likely to have had a preexisting and strong privacy and security focus.

Successfully complying with HIPAA provisions also requires cultural and organizational alignment with the requirements of the act. Education and compliance activities, along with associated identified compliance roles, are required. A privacy officer and, in most cases, a security officer are also required. Reporting relationships regarding visibility and accessibility to senior management often mean that key security and compliance individuals charged with HIPAA compliance have an unambiguous solid or dotted reporting line to the CEO.

Compliance with HIPAA is certainly far more than IT. Policies, procedures, and controls should precede the application of IT. Many HIPAA compliance experts caution against letting technology overshadow the underlying requirements for strong and ongoing policy development/administration. For those organizations where HIPAA compliance required the most changes, a visible and engaged senior management endorsement of the policies, procedures, and privacy/security investments has been the key to success.


EU Commission and Basel II

Because of European corporate scandals comparable with those in the United States, the EU Commission is imposing similar requirements for improvement in auditing standards, oversight, and responsibilities by creating directives related to corporate governance, transparency, audit, accounting standards, and information services. A major difference is that the U.S. Sarbanes-Oxley Act carries fines and criminal sanctions, whereas the EU Commission does not recommend that level of enforcement.

Although the Sarbanes-Oxley legislation originated in the United States, there are ramifications for companies headquartered in other countries. Emerging European professional standards such as those established by the International Accounting Standards Board and the Basel II Capital Accord also will affect many multinational companies.

Basel II Capital Accord

Basel II is a consortium of international banks mostly in Europe but also in the United States and Canada. Initiated in 1974, the group publishes accords that cover a variety of banking topics and are intended to provide increased supervision and oversight of international banks. The advisory committee intended to promulgate a variety of technical and financial standards. The focus of the group is to provide a risk-management framework around capitalization standards for international banks. The Basel II accords are entirely voluntary, and any adoption is governed by the central bank of each country.

The Basel II Capital Accord is the most recent and most visible of the recommendations. The intention of this accord is to implement increased risk-management and capital-supervisory regulations governing the capital adequacy of internationally active banks.

In general, the Basel II Capital Accord provides for IT controls revolving around risk management in relation to loans. Therefore, as with Sarbanes-Oxley, the IT auditor should be concerned primarily with controls that protect the integrity of financial information.


Payment Card Industry (PCI) Data Security Standard

Visa USA created the Cardholder Information Security Program (CISP) in mid-2001. The standard became a requirement for Visa member banks. The CISP program was intended to ensure high levels of information security for Visa cardholder data. The security standard applies to all Visa member banks, merchants accepting Visa cards, and all service providers processing Visa cardholder transactions. In 2004, the data security standards were cosponsored by Visa and MasterCard into an industry standard now known as the Payment Card Industry Data Security Standard. Other card issuers have adopted the standard and incorporated it into their own programs. In addition, an international version of the VISA CISP program called the Visa Account Information Security (AIS) applies to non-U.S.-based entities.

The PCI standard is not a law per se, but it is a mandatory compliance requirement for participants in the card payment-processing industry. Generally speaking, any entity, system, or component that handles Visa cardholder information anywhere in the value chain is subject to the standard if they wish to remain a participant in the Visa payment-processing system.

Participants in the Visa payment-processing system not only must adopt PCI but also must validate compliance with the standard. Specific standards apply to various sections of the payment-processing environment. Specific compliance standards and auditing requirements are published for member banks, merchants, and service providers. The auditing standards and compliance requirements are very specific and scaled to fit the relative risks represented by the various classifications.

In order to facilitate the program, Visa and other card issuers have published lists of organizations authorized to conduct validation inspections (audits), as well as conduct incident-response investigations. The publication of the auditing standards, approved service providers, and the various approved auditing organizations has served to raise the bar significantly on information security in the payment-processing industry.

PCI Impact on the Payment Card Industry

Conformance to the PCI data security standard represented by PCI has become a "cost of doing business." In order to participate in the card payment-processing industry, conformance is not negotiable. The only enforcement necessary to ensure adoption of the standard is exclusion from participation in the industry. Visa, MasterCard, and other card issuers have "decertified" service providers for nonconformance with the standard. The most notable of these events have occurred after disclosure of security breaches resulting in loss of cardholder private data.

From a data security standpoint, the PCI standard represents commonly accepted data security standards and practices. There is nothing extraordinary in the standard. It is a set of standard best practices already well accepted in the IT security field. While the PCI standard represents basic security practices, the imposition of the PCI standard on the card payment-processing industry has had a dramatic impact on the technical infrastructure of the industry.

PCI has changed the focus of every software developer of card payment-processing software in any form to shift from adding feature functionality and reducing cost to restructuring their software to accommodate the standard. The impact has been felt across the spectrum of commercial software and system providers to individual retailers who develop and maintain their own systems. Similar to the general impact of SOX, the PCI standard has added vocabulary regarding standards, controls, and audits to an entire industry from smallest to largest and across the spectrum of industries.

A specialized cottage industry has arisen from the introduction of the standard around evaluating conformance to the PCI standard, testing for conformance, and training companies on how to assess and comply with the standard. While the standard does not represent cutting-edge security technology, the introduction and enforced compliance with the standard changed the entire card payment-processing industry in less than 4 years.


Other Regulatory Trends

As computers proliferated in the heyday of the 1980s and 1990s, internal controls over IT did not keep pace with the rapidly changing infrastructure architectures. However, the crackdown on internal controls initiated over financial reporting has expanded to include IT, and rightfully so.

Now, in addition to Sarbanes-Oxley, Gramm Leach Bliley, SB 1386, HIPAA, and other regulations, further requirements are coming. As of 2006, over 30 U.S. state and federal laws were pending. With identity theft nearing crisis proportions, data protection and privacy are very pressing topics for legislators.

The increased regulatory requirements are raising awareness among senior corporate management. Information security is gaining increasingly serious visibility. Most companies are now realizing that they previously had little understanding of their exposures and are admitting that they need to make a conscious effort to identify their risks and take increasingly definitive measures to address them.

References

  • Auditing Standard No. 2: "An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements" (effective June 17, 2004), http://www.pcaobus.org.

  • California State Senate, http://www.info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html.

  • Federal Reserve Board, Basel II Capital Accord, http://www.federalreserve.gov/generalinfo/ basel2.

  • Federal Trade Commission, http://www.ftc.gov/privacy/privacyinitiatives/glbact.html.

  • FFIEC Information Technology Handbook, http://www.ffiec.gov.

  • Ford, Paul, "Sarbanes-Oxley and the Global Capital Market," Simpson Thacher & Bartlett, New York, 2004.

  • "Implications of Sarbanes-Oxley on IT Departments," Seminar and Panel Discussion, Baylor University, Waco, TX, April 15, 2004.

  • International Accounting Standards Board, http://www.iasb.org.

  • International Organization for Standardization, ISO-Overview, February 2004, http://www.iso.org.

  • IT Governance Institute, IT Control Objectives for Sarbanes-Oxley: The Importance of IT in the Design, Implementation and Sustainability of Internal Control Over Disclosure and Financial Reporting, Rolling Meadows, IL, 2004, http://www.isaca.org.

  • IT Governance Institute, CoBIT, Committee of Sponsoring Organizations of the Treadway Commission (COSO), Rolling Meadows, IL, July 2000, http://www.coso.org.

  • "Implications of Proposed Auditing Standard on Internal Control," KPMG's Defining Issues, KPMG, No. 03-22, October 2003, http://www.us.kpmg.com/RutUS_prod/Documents/12/1921810Alert0322.pdf.

  • McDowall, Bob, "U.S. Approach to Corporate Governance Looks Set to be Introduced in Europe," http://www.it-analysis.com.

  • Mishkin, Frederic S., "Evaluating FDICIA," Federal Reserve Bank of New York, Graduate School of Business, Columbia University, and National Bureau of Economic Research, December 1996, http://www.0.gsb.columbia.edu/faculty/fmishkin/PDFpapers/FDICIA96.pdf.

  • Office of the Privacy Commissioner of Canada, Personal Information Protection and Electronic

  • Payment Card Industry Data Security Standard, Version 1.0, December 15, 2004, © 2004 Visa U.S.A., Inc., http://www.usa.visa.com/download/business/accepting_visa/ops_risk_management/

  • http://www.cisp_PCI_Data_Security_Standard.pdf.

  • Protiviti, Inc., Guide to the Sarbanes-Oxley Act: It Risks and Controls-Frequently Asked Questions, December 2003.

  • Public Company Accounting Oversight Board, "An Audit of Internal Control Over Financial Reporting Performed in Conjunction with an Audit of Financial Statements," Final Auditing Standard, Release No. 2004-001, March 9, 2004.

  • Sarbanes-Oxley Act 2002, U.S. Securities and Exchange Commission (effective July 30, 2002), http://www.sec.gov/about/laws/soa2002.pdf.

  • "Sarbanes-Oxley: A Focus on IT Controls," ISACA SOX-IT Symposium, Chicago, IL, April 7, 2004.

  • "Sarbanes-Oxley Financial Rules Will Challenge IS Organizations," Gartner FirstTake, Gartner Research, May 30, 2003.

  • "Sarbanes-Oxley Section 404 Compliance for Information Technology Managers," Auditnet.org "SEC Extends Sarbanes-Oxley Section 404 Deadlines," E-Compliance Advisor, March 12, 2004, http://www.advisor.com.

  • "Section 302 Corporate Responsibility for Financial Reports," RSM McGadrey, 2003, http://www.rsmmcgladrey.com.

  • "Section 906-Corporate Responsibility for Financial Reports," University of Cincinnati College of Law, 2002.

  • "The Clock Ticks on Sarbanes-Oxley Section 404," Financial Executives International, May 15, 2004, http://www.fei.org.

  • Trainor, Ed, "Do the Right Thing! Making Sense of Sarbanes-Oxley," SIM publication, 2003.

  • U.S. Department of Health & Human Services, Office of Civil Rights, HIPAA, http://www.hhs.gov/ocr/hipaa/privacy.html.

  • Van Ecke, Patrick, "EMC Centera-Corporate Governance in the European Union: Enhancing Credibility," Belgium, April 2005, http://www.bitpipe.com/detail/RES/1118421898_858.html.


Chapter 15: Risk Management

Benefits of Risk Management

No doubt the potential of IT risk management is still a well-kept secret. Over the past few years, many organizations have increased the effectiveness of their IT controls or reduced their cost by employing sound risk-analysis and risk-management practices. When management has a representative view of organizational IT exposures, it can direct appropriate resources to mitigate the areas of highest risk rather than spending scarce resources in areas that provide little or no return on investment. The net result is a higher degree of risk reduction for every dollar spent.


Risk Analysis

With few exceptions, whether related to financial, physical, or technological resources, different types of risk can be calculated using the same universal formula. Risk can be defined by the following calculation:

Risk = asset value × threat × vulnerability

Elements of Risk

As you can see with the preceding equation, there are three elements of risk: asset value, threat, and vulnerability. Estimating these elements correctly is critical to assessing risk accurately.

Assets

Normally represented as a monetary value, assets can be defined as anything of worth to an organization that can be damaged, compromised, or destroyed by an accidental or deliberate action. In reality, an asset's worth is rarely the simple cost of replacement; therefore, to get an accurate measure of risk, an asset should be valued taking into account the bottom-line cost of its compromise. For example, a breach of personal information may not cause a monetary loss at first glance, but if it actually were realized, it likely would result in legal action, damage to the company's reputation, and regulatory penalties. These consequences potentially would cause a significant financial loss. In this case, the asset-value portion of the equation would represent the personal information. The calculated value of the personal information would include an estimate of the cumulative dollar cost of the legal action, reputation damage, and regulatory penalties.

Threats

A threat can be defined as a potential event that, if realized, would cause an undesirable impact. The undesirable impact can come in many forms, but often results in a financial loss. Threats are generalized as a percentage, but two factors play into the severity of a threat: degree of loss and likelihood of occurrence. The exposure factor is used to represent the degree of loss. It is simply an estimate of the percentage of asset loss if a threat is realized. For example, if we estimate that a fire will cause a 70 percent loss of asset value if it occurs, the exposure factor is 70 percent, or 0.7. The annual rate of occurrence, on the other hand, represents the likelihood that a given threat would be realized in a single year in the event of a complete absence of controls. For example, if we estimate that a fire will occur every 3 years, the annual rate of occurrence would be 33 percent, or 0.33. A threat, therefore, can be calculated as a percentage by multiplying the exposure factor by the annual rate of occurrence. Given the preceding example, the threat of fire would result in a value of 23.1 percent, or 0.231.

Vulnerabilities

Vulnerabilities can be defined as the absence or weakness of cumulative controls protecting a particular asset. Vulnerabilities are estimated as percentages based on the level of control weakness. We can calculate control deficiency (CD) by subtracting the effectiveness of the control by 1 or 100 percent. For example, we may determine that our industrial espionage controls are 70 percent effective, so 100 percent - 70 percent = 30 percent (CD). This vulnerability would be represented as 30 percent, or 0.3.

Note

Most of the time, more than one control is employed to protect an asset. For example, we may have identified the threat of an employee stealing trade secrets and selling them to the competition. To counter this threat, we implement an information classification policy, monitor outgoing e-mail, and prohibit the use of portable storage devices.

Practical Application

Now that we've defined how to analyze risk, we can begin to put it into practice. Below are a couple of examples of how this equation is relevant in IT as well as other areas.

Physical Risk Scenario

The U.S. government regards a command and control center at a military installation in the Middle East to be critical to its ability to operate in the region. If this facility is destroyed, it likely will cause loss of life (both in the facility and in the field), damage to the facility itself, and a setback to military objectives.

In this example, the asset is the command and control center. The actual value of the command and control center includes the lives of the soldiers that would be affected, the command and control facility itself, and the military objectives that would go unmet in the event of its loss. The experts estimate that the cumulative cost of a loss of the command and control center would be $500 million (not that you can put a dollar figure on a soldier's life). We have identified a threat of a bomb to the facility and estimate that a successful attack would cause an 85 percent loss. The experts say that this type of attempted attack would occur once per week, or 52 times annually, if no controls were in place to prevent it. The command and control center has several safeguards, such as physical barriers, perimeter alarm systems, military police patrols, and 3,500 additional soldiers on base protecting it. As a result, we estimate that the controls are 99.99 percent effective, or 0.01 percent deficient. With this information, we can calculate the monetary value of the risk of a command and control center bomb to be $500 million [asset value] × 0.85 loss (EF) × 52 times per year (ARO) [threat] × 0.001 control deficiency (CD) [vulnerability] = $22,100,000 [risk].

To take this exercise a step further, we can justify a total investment of up to $22.1 million to protect the command and control center. The exact amount that we can justify will depend entirely on the dollars already spent to mitigate this risk and the projected level of risk reduction for the selected control. We are aiming for maximum risk mitigation by reducing the vulnerability part of the risk equation. We will get into more detail on choosing controls later in this chapter.

IT Risk Scenario

The IT audit director at a national retailer has determined that the legal climate is changing in relation to the credit-card information with which the company is entrusted. Until now, the company had not considered the risk of a disclosure of its customer's personal or credit-card-specific information.

After interviewing public relations, legal, and finance stakeholders, the IT audit director estimates the cost of a single breach to be approximately $30 million in lost revenues, legal costs, and regulatory consequences. So we now know that the asset is personal credit-card and associated financial information and that its value to the company is $30 million. Since there have been several breaches in the news recently that involved hacking, the audit director decides to explore this threat. In a conversation with the information security director, the audit director learns that the company is under constant attack, although most of the attacks are nothing more than probes for vulnerabilities. He estimates that there is about one actual attack per week and that a compromise of the credit-card processing system would result in a complete asset loss. The information security director estimates that current controls are 99.99 percent effective but that if the company does not invest in additional controls, a successful breach is imminent. Given this information, we can calculate the risk of an external security breach to be $30 million [asset value] × 100 percent loss (EF) × 52 hacking attempts per year (ARO) [threat] × 0.01 percent or 0.0001 control deficiency (CD) [vulnerability] = $156,000 [risk].

Risk Analysis in Practice

Okay, we know what you're thinking: "This is all pie in the sky. In the real world, there is barely enough time to perform essential job duties, let alone spend a lot of time calculating risk. Though these calculations are great theory, I don't have the time to apply them for every threat? In fact, who has time to identify every threat?" Well, the truth is that it is impractical to perform these calculations for every threat, although you should do your best to identify all the threats that your organization faces.

If you haven't tried to identify your organization's current threats, it may be worthwhile to do so. From there, identifying new threats can be a daily mental exercise. As business or technology changes, you should be asking, "What new threats does this change introduce." If realized, how would these threats affect your business? When you identify significant threats and want to make a business justification for purchasing additional controls, then you can use the preceding calculations to support your case.

Common Causes for Inaccuracies in Risk Analyses

Most risk analyses attempted today result in bottom-line estimates that are way off the mark. Unfortunately, when organizational management loses faith in the risk information that is presented to it, it tends to dismiss a disproportionate number of requests for risk-mitigation investments. Management is interested in investing limited resources in areas that either will make the organization money or will save the organization money. This is why it is so important to present a solid analysis of risk whenever approaching management for additional resources. Below are the most common causes of risk-analysis inaccuracies.

Failure to Identify Assets, Threats, or Vulnerabilities

The most common cause of inaccuracies in the risk-analysis process is the failure to identify assets, threats, and vulnerabilities. This is mostly due to the fact that most organizations do not use a formal risk-management process and practitioners have not been trained to analyze risk. As we pointed out earlier, it can be especially difficult to identify threats and vulnerabilities because they are dynamic in nature. For example, we know that new variants of viruses, worms, and other forms of malware are introduced daily. Additionally, new computer-related vulnerabilities are discovered almost daily. Although identifying threats and vulnerabilities can be difficult, there are resources that can help, such as information security alerts from CERT, Bugtraq, and other free and subscription-based security vulnerability notification services. IT auditors also can examine security incidents when they are publicized to learn how such violations occur. One Internet web resource that consolidates and chronicles information about security incidents is http://www.privacyrights.org/ar/ChronDataBreaches.htm. We will discuss proven methods for identifying assets, threats, and vulnerabilities later in this chapter.

Note

In February 2005, Bank of America made national headlines by losing the personal information of 1.2 million customers while shipping backup tapes through a common carrier. Two months later, in April, the incident was virtually repeated when Ameritrade lost the personal information of 200,000 customers during the shipment of backup tapes through a common carrier. Yet again, in June 2005, Citi Financial lost the personal information of 3.9 million customers while shipping backup tapes through UPS. Although the Bank of America incident made national headlines, Ameritrade and Citi Finacial apparently failed to identify the threat of tapes being lost by a common carrier and implement the necessary controls to prevent unauthorized disclosure of customers' private information. As you can see, it is important to monitor the headlines to identify emerging threats, not to mention keep your organization's name off the privacyrights.org list.

Inaccurate Estimations

Unfortunately, there is a fair amount of estimation involved in analyzing risk, which makes it an inexact science. Many errors can be attributed to this fact.

Assets The traditional approach to risk analysis does not take into account the costs resulting from a compromise outside of the loss to the asset itself. As we saw in the preceding examples, the cost of a compromise rarely stops at the asset book value. Therefore, it is important to include the consequential losses as well as the actual loss in asset value. Including these costs will increase the accuracy of your risk assessment.

Threats Unlike assets or vulnerabilities, the threat is the only element of the risk-analysis equation that is always derived from a single value. In the IT risk scenario discussed earlier, the threat involved hacking attempts. Combining the hacking threat with another threat such as employees abusing access privileges, stealing, and selling credit-card information would cause an inaccurate calculation of risk.

Another common error is failing to estimate and incorporate the exposure factor into the threat value. This error often inflates the risk value. In order to calculate an accurate threat value, both exposure factor and annual rate of occurrence must be included.

Vulnerabilities As we discussed earlier, vulnerability is the absence of or weaknesses in cumulative controls. Therefore, in order to identify a vulnerability, we must understand the strength of the controls. Risk-analysis errors are made often because the strength of a control is not evaluated properly or compensating controls are not taken into account.


IT Risk Management Life Cycle

As with most methodologies, risk management, when applied properly, takes on the characteristics of a life cycle (Figure 15-1). It can be broken out into several phases beginning with identification of information assets and culminating with management of residual risk. The specific phases are as follows:

Image from book
Figure 15-1: 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 ongoing risk

Phase 1-Identifying Information Assets

The first phase in the risk-management life cycle is to identify the organization's information assets. There are several tasks that must be completed in order to be successful. These steps include the following:

  • Define information criticality values

  • Identify business functions

  • Map information processes

  • Identify information assets

  • Assign criticality values to information assets

The goal of this phase is to identify all information assets and assign each information asset a criticality value of high, medium, or low for its confidentiality, integrity, and availability requirements. For example, we may identify credit card information as an information asset that is processed by our retail system. This information asset is governed by the Payment Card Industry (PCI) data security standard and is valuable to thieves if disclosed in an unauthorized manner. We also know that if altered, this information is useless to us but that in most cases a temporary loss of access to this information is tolerable. As a result, we would assign credit card information values of high for both confidentiality and integrity and medium for availability.

The best way to identify information assets is to take a top-down approach beginning with organization functions, identifying the processes that support those business functions, and drilling down to the information assets that are processed. Figure 15-2 represents this approach to information asset identification using business function decomposition.

Image from book
Figure 15-2: Business function decomposition.

Defining Information Criticality Values

Okay, so before we begin to identify information assets, shouldn't we know what information criticality values of high, medium, and low mean to our business? This is why the first step in the process is to define each value in terms of how severe the impact would be in the event of a breach of an asset with a given value. For example, we may define the high value to mean a potential monetary loss of $500,000 or more in the event of a security violation. This definition would be consistent with the confidentiality, integrity, and availability of any information asset we identify.

In order to be successful, it is important to gain consensus from major organizational stakeholders regarding the definitions and to document those definitions. If a criticality value of high means something different to the CEO, CFO, and vice president of operations, we will want to gain a level set with these individuals and obtain their buy-in on the definition. We surely will need it later in the process. Clearly documenting these definitions is critical once a consensus is gained.

Identifying Business Functions

One of the most difficult aspects of risk management is identifying where information assets reside and then which assets are most critical to the business. Fortunately, most businesses are organized by function. As a result, most critical business functions can be identified using the organization chart. Of course, it is still necessary to verify that all the business functions are represented accurately.

Once the business functions are identified, we can assign criticality values to each. For example, we may determine that the retail operations business function requires a high level of confidentiality because of use of credit card information. It may require a high degree of information integrity because transactions are financial in nature and a medium degree of information availability because a short delay in processing the transactions would have only a moderate impact on the organization.

Mapping Information Processes

Since the nature of IT is to process information, IT risk (as opposed to other types of risk) has the added complexity of touching several points in a process. Identifying these process flows is absolutely critical for a few reasons:

  • It helps us to identify which information assets are used by each process.

  • It helps us to identity process points (steps) that require manual input (which tend to be more vulnerable than fully automated processes).

  • It helps us to understand which information systems need protection.

Once we have identified our organization's critical business functions, we can begin to identify the processes that support those business functions and the information assets that flow though the processes. It is important to note that we are not concerned with the technology used to process the information at this point but rather with the process flow itself.

We had identified the retail operations business function earlier. We know that the retail operations business function is responsible for processing credit card transactions that feed all the company's cash flow and are regulated by PCI. Thus, we can identify credit card processing as a critical process. From here we will need to determine the steps or systems (process points) that are included in the process. For our example, we may determine that credit cards are processed in the following manner (Figure 15-3):

  1. Associate swipes a credit card during a retail sale.

  2. Transactions are aggregated to a system within each retail store.

  3. Aggregated transactions are transmitted to the main office during the night over the Internet via site-to-site virtual private networks (VPNs).

  4. Store transactions are aggregated with transactions from all the other stores.

  5. All transactions are sent to the credit-card processing house over a dedicated telecom data link in a batch file the following day.

  6. The credit card processing house deposits funds into a corporate bank account 2 days later.

Assigning Information Criticality Values to Information Assets

Once we have mapped out the information process, we can identify the information asset(s) and assign them criticality values. When identifying information assets that traverse a process, it is important to consider all the potential assets. For example, it is obvious that credit card data are an information asset, but we also may want to consider system management or monitoring information used for the systems that aggregate the credit cards transactions in the preceding illustration. These types of information assets often are overlooked but can be critical.

When assigning criticality values, we need consider the asset's requirements for confidentiality, integrity, and availability. This relationship is represented well using the information criticality matrix employed by the National Security Agency (NSA) INFOSEC Assessment Methodology. An example of this matrix is given in Table 15-1.

Table 15-1: Information Criticality Matrix
Information Asset | Confidentiality | Integrity | Availability
Credit card data | H | H | M
System configurations | M | H | M
System monitoring information | L | H | H

Phase 2-Quantifying and Qualifying Threats

Information threats impact organizations due to lost business, lost resources and recovery costs, and legal and regulatory actions. When threats are realized, these costs often are unaccounted for because they are not identified properly. For example, let's say that our organization is attacked by a malicious worm that causes a temporary loss of processing capacity and several hundred hours of recovery time. The cost may be calculated by quantifying the hours required for recovery and estimating the losses associated with the processing delays. However, has the company's reputation been adversely affected because it was not able to service customers? Were there any lost sales? Were some employees unable to work? What is the organization's legal exposure due to the security breach? As you can see, identifying all the areas within an organization that may be affected requires a fair amount of thought. Therefore, we will help break down the process of analyzing of these threats.

The next step in the risk-management life cycle is to quantify and qualify threats (Figure 15-4). We'll also take a top-down approach as we identify threats, starting with business threats and moving on to technical threats that may give rise to the identified business threats. We'll explain this in more detail later. This phase of the risk-management life cycle requires the following steps:

Image from book
Figure 15-4: Risk-management process.

  • Assess business threats

  • Identify technical, physical, and administrative threats

  • Identify process-component threats

  • Quantify threats

Note

In order to identify threats to our information effectively, we need to complete the first phase of the risk-management process: identifying information assets. This is so because properly identified threats are associated with an information asset or a group of information assets. Threats associated with systems flow through to the information assets that they process.

Assessing Business Threats

There are several ways that threats can be accounted for, but at a high level, business threats to information can be broken out into three categories: financial threats, legal threats, and regulatory threats. All business threats will fall into one of these categories.

Financial Threats One could argue that all information threats are financial in nature because they all boil down to a monetary loss, if realized. Although this may be true, we will break out regulatory and legal threats because of their prevalence. For our purposes, a financial threat will be defined as a threat that, if realized, would cause a loss of actual funds, reputation, operational effectiveness, or competitive advantage, ultimately resulting in a monetary impact. Financial threats may include the following:

  • Financial fraud

  • Loss of proprietary information

  • Loss of productivity

Once the information assets are identified, these types of threats become more evident. For example, the credit card-information asset we identified earlier has exposure to all three of these threats. The next question becomes, "If realized, how would this threat affect operational effectiveness, company reputation, competitive advantage, or the company's cash position?"

Legal Threats Now that we've identified some of the financial threats, what is the potential legal exposure associated with realization of a threat. With new privacy laws being enacted on almost a monthly basis, if an individual's private information such as his or her name and associated address, Social Security Number, health information, or credit information is disclosed in an unauthorized manner, you can bet that there will be some legal exposure. Additionally, if service levels are affected or another organization's confidential information is disclosed, there could be a breach of contract. Needless to say, legal expenses can be very expensive, even if a court finds in your organization's favor.

In order to get an accurate business-threat assessment, it is necessary to identify potential legal exposure in the event of an information security violation.

Regulatory Threats Along with financial and legal threats, it is important to consider regulatory threats. A regulatory infraction resulting from an information security incident could lead to fines or other penalties (including imprisonment of company officers), as well as temporary or permanent suspension of company operations. Financial institutions generally take the laws governing their operation very seriously because of the severe consequences of noncompliance, but health care entities and public companies are also heavily regulated.

The key to identifying regulatory threats is understanding the laws or mandatory industry standards governing the information your organization is processing. Given our earlier example, we know that the PCI data security standard will govern protection of the credit card information our organization processes. See Chapter 14 for additional information regarding regulations affecting U.S. companies.

Identifying Technical, Physical, and Administrative Threats

Once all the business threats pertaining to our information assets are identified, we can begin identifying the technical, physical, and administrative threats. These threats, if realized, will give rise to one of the business threats that we have identified. For example, a system malfunction will give rise to a loss of organizational productivity.

Technical Threats Technical threats generally are system-related, affecting electronically stored or transmitted information. Given our previous credit card processing example, one technical threat might be system intrusion. This threat then could give rise to the theft of proprietary information, regulatory or legal business threats. Some examples of technical threats include

  • System intrusion

  • Worms, viruses, and spyware

  • System failures

  • Logical access control failures

Physical Threats Physical threats normally are facility-related and often can be tied to natural events or mechanical breakdowns. Some physical threats include

  • Natural or man-made disasters

  • Physical intrusion

  • Fire

  • Water seepage from burst pipes or weather-related flooding

  • Excessive heat or humidity

  • Electrical disruptions or black-outs

Although physical in nature, these threats can cause significant information loss. Business continuity/disaster recovery plans and data center controls aim to address these threats. See Chapter 4 for information on auditing data centers and business continuity plans.

Administrative Threats It is common knowledge in information security circles that the "human factor" is the cause of most security violations. Administrative threats are people-related. They may include

  • Unintentional disclosure of sensitive information

  • Social engineering

  • Industrial espionage

  • Malicious destruction of information

  • Accidental deletion or corruption of information

  • Inappropriate use of computing resources (e.g., pornography in the office)

Administrative threats are often overlooked because they tend to be more nebulous and imply an inherent mistrust of employees. Nonetheless, people within an organization introduce quite a few threats to information assets.

Note

The Great Wall of China was built to defend China from northern armies, but what many people don't realize is that it was rendered useless by a trusting Chinese general who allowed the Manchu army through the gate at the Shanhai Pass. Once China was conquered by the Manchus, the wall was of little strategic value because Manchu-controlled lands extended far north of the wall. Similarly, a single employee could introduce a world of peril to your organization.

Identifying Process Component Threats

Now that we understand our business and high-level technical threats, we can examine the processes that we mapped out when we identified our information assets. We will specifically analyze the threats to different process components such as systems and manual input steps or outputs. Figure 15-3 outlines six steps in a credit card payment process:

Image from book
Figure 15-3: Credit card process diagram.

  1. Associate swipes a credit card during a retail sale.

  2. Transactions are aggregated to a system within each retail store.

  3. Aggregated transactions are transmitted to the main office during the night over the Internet via site-to-site virtual private networks (VPNs).

  4. Store transactions are aggregated with transactions from all the other stores.

  5. All transactions are sent to the credit card processing house over a dedicated telecom data link in a batch file the following day.

  6. The credit card processing house deposits funds into a corporate bank account 2 days later.

Our goal is to identify the threats associated with each step in the process. For example, we might identify a threat of employees keeping credit cards or credit card numbers of store customers for step 1. For step 2, we might identify a risk of system failure or system intrusion. We should be able to identify several threats for each process component. When combined, they represent all the threats associated with the processing of an information asset.

Quantifying Threats

Now that we've identified our threats, we need to understand their potential impact and the probability that they will occur if not mitigated. As we discussed in the risk analysis section earlier, two factors play into estimating the severity of a threat:

  • Degree of asset loss

  • Likelihood of occurrence

As we outlined earlier, we can use the exposure factor (EF) to represent the degree of loss and the annual rate of occurrence (ARO) to represent the likelihood of an occurrence. A threat then can be quantified by multiplying EF × ARO. If we look at our credit card processing example, we may estimate that a hard-disk failure would cause the loss of one day's worth of a store's sales and would fail in the store-side systems once every 2 years. We would calculate the threat by multiplying 1/365 (0.00274) by 0.5. The result would be approximately 0.00137. We then would multiply this by each store's annual sales to quantify the threat.

Phase 3-Assessing Vulnerabilities

We now have identified our information assets and the threats to each asset. In this phase, we will assess vulnerabilities. In examining threats, the common denominator is the information asset because each threat is tied to an information asset. When assessing vulnerabilities, on the other hand, the common denominator is the information process. We will first identify process-component vulnerabilities and then combine them to determine our process vulnerabilities. Process vulnerabilities then will be combined to determine business function vulnerabilities. Instead of working from the top down (from business function to process component), we will work from the bottom up in assessing vulnerabilities. We will use the following steps in analyzing vulnerabilities:

  • Identify existing controls in relation to threats.

  • Determine process component control gaps.

  • Combine control gaps into processes and then business functions.

  • Categorize control gaps by severity.

  • Assign risk ratings.

Note

Prior to World War II, France recognized Germany, its neighbor to the east, as a growing threat. Therefore, the French government built a line of walls, tank defenses, and bunkers called the Maginot Line to defend against invasion. The country decided to end the wall on the north side at the Ardennes Forest, which was believed to be impassable as a result of its dense nature. When the Germans invaded in 1940, they bypassed the Maginot Line fortifications in favor of the dense forest. History shows that the French certainly understood the threat, but miscalculated their vulnerabilities.

Identifying Existing Controls

The initial step in examining vulnerabilities is to review threats and inventory existing controls that mitigate each threat. In our credit card processing example we identified the threat of a hard-disk failure. We also may determine that there are systems that back up disk information nightly and a RAID level 5 disk array providing hard-disk redundancy.

To get an accurate understanding of an organization's risk, it is important to identify all the controls that have been applied. Like threats, controls can be technical, physical, or administrative in nature. Table 15-2 provides a partial list of each type of control.

Table 15-2: Types of Controls
Types of Control | Examples
Technical | Access control systems, two-factor authentication, firewalls, encryption systems, uninterruptible power supplies, intrusion detection systems, antivirus software, redundant systems or system components, backup systems, audit and logging systems, system hardening
Physical | Security guard, key-card physical access systems, alarm systems, safes, fire suppression systems, HVAC systems, fences, lighting, security cameras
Administrative | Acceptable-use policy, business continuity plan, password policy, incident response plan, system baseline configurations, remote access policy, file recovery procedures, information classification, information security training and awareness, audits, and assessments

Determining Process Component Control Gaps

Once we've identified the existing controls that have been employed, we can begin to see areas where controls are either ineffective or simply do not exist. In the preceding example, we identified two controls that are mitigating the threat of a hard-disk failure: Nightly backups and RAID level 5 disk redundancy. Each store closes at 9:00 PM, and the store-side system transmits the transactions beginning at midnight. A full system backup occurs at 3:00 AM at the main office. A system failure anytime during the day would result in loss of the entire day's transactions. The system backup strategy therefore is not as effective as a RAID level 5 disk array that provides real-time redundancy. In this step, it is important not only to identify control gaps but also to measure the effectiveness of existing controls.

Combining Control Gaps

Once we have identified all the control gaps for process components, we can combine them to begin to see a risk posture for the information process. We then can combine the processes supporting each business function to begin to see the risk posture for each of the business functions. The combined business-function risk postures give us the organizational risk posture.

Categorizing Control Gaps by Severity

Now, once we have a good view of organizational risk, some of the underlying risks naturally will begin to emerge as more critical than others because they affect valuable information assets or are unmitigated. At this point, you should be able to assign business functions, information processes, and process components qualitative risk ratings of high, medium, or low. We will want to focus our attention on the risks to which we assigned high risk ratings. The more severe risks can be analyzed further to determine their quantitative value to justify additional investments in controls.

Phase 4-Control Gap Remediation

By now our risks should be categorized as high, medium, or low. Initially, we will focus on mitigating the most severe risks because we most likely will see the highest return on our investment. In essence, we are likely to mitigate more risk with less money. We will use the following steps in control gap remediation:

  • Choose controls

  • Implement controls

  • Validate new controls

  • Recalculate risk ratings

Choosing Controls

Too often organizations implement controls because of their use of advanced technologies or a slick interface. More often than not the controls that mitigate the most risk do not fit into either of these categories. Choosing controls should be purely a business decision that takes into account the level of risk to be mitigated, the cost, and the ease of use of the controls.

Identifying Potential Controls There are almost always several ways to mitigate a risk. The methods will range the cost spectrum from very inexpensive to prohibitively expensive and can be technical, physical, or administrative in nature. Organizations often overlook administrative controls such as security policy, security awareness training, and agreements. These controls, when implemented properly, can be extremely effective and affordable.

Rating Controls by Cost and Effectiveness Once controls are identified, they can be compared in three ways: cost, effectiveness, and ease of use. The cost of a control is very quantifiable and often is the only attribute considered. In choosing controls properly, however, it is important to consider the effectiveness of the control. For example, to mitigate the threat of network intrusion, an organization may upgrade its existing firewall to a $100,000 firewall appliance that has advanced network inspection technologies. However, since the existing firewall mitigated all but a fraction of the risk, was this the best use of company funds? Equally important is a control's ease of use. Many organizations have purchased intrusion detection systems only to find out that they require a high degree technical of expertise and a large amount of analysis time to operate properly.

One method of choosing controls is to list them in a spreadsheet and rate each of the three attributes in separate columns on a scale of 1 to 10. The attributes even can be weighted if you want to get fancy. Either way, this is a tool that can be used to make more informed decisions.

Implementing Controls

Now that we've selected our controls, we must implement them properly. When companies are subjects of IT audits or assessments, most findings are related to misconfigu-rations or improperly implemented controls, not the absence of controls. Therefore, it is important to implement new controls properly.

Validating New Controls

To take it one step further, new controls should be tested by an organization's IT audit department to validate their effectiveness. This will provide assurances to management that its investment has been well spent. The results of this audit or assessment also will feed calculation of the organization's new risk posture.

Recalculating Risk Ratings

If we've done our job correctly, our overall organizational risk and business-function risk now should be reduced from its original level. The information process where we implemented the controls also will be affected. Therefore, it is necessary to recalculate risk in these areas to reflect the addition of the new controls. Our risk ratings will be based on the residual risk, which is the risk that remains after mitigation. Instead of having a high risk rating, our process may be assigned a medium or low risk rating.

Phase 5-Managing Ongoing Risk

Risk is inherently dynamic in nature, especially the threat component of risk. As a result, we will need to measure risk continually and invest in new controls to respond to emerging threats. There are basically two steps in this phase:

  • Create a risk baseline

  • Reassess risk

Creating a Risk Baseline

Since we now have the recalculated risk ratings, we can aggregate them to create a risk baseline. We will use this baseline to measure changes in our risk posture and identify trends as we cycle through the risk management process in the future. The risk baseline should include overall organizational, business-function, and process risk ratings, as well as narratives describing the reasoning used in the decision to implement controls or accepted risk.

Reassessing Risk

Now that the process is complete, we will need to plan on reassessing risk periodically. Because of the ever-changing nature of IT, organizations should complete the risk-management life cycle at least once per year. Risk assessments, however, should be triggered by certain events, such as

  • Corporate mergers or acquisitions

  • New system installations

  • Business-function changes

  • The enactment of new laws or regulations that mandate the addition of new controls (or require risk analysis)


Summary of Formulas

Use | Description | Formula
Definition of risk | Used to represent risk | Risk = asset value × threat × vulnerability
Threat calculation | Numeric representation of threat | Threat = exposure factor (EF) × annual rate of occurrence (ARO)
Vulnerability calculation | Measures control deficiency | Control deficiency (CD) = 1 - control effectiveness
Risk calculation | Used to quantify risk | Risk = asset value × EF × ARO × CD


Index

A

AAA (authentication, authorization, and accounting), 121
access control lists (ACLs), 117, 211
access controls, 36, 84, 255-259
access points (APs), 263, 267-268, 270
account management
Unix and Linux operating systems, 173-182, 203-204
Windows Server, 146-149
ACLs (access control lists), 117, 211
action plans list, in audit report, 54
activity monitoring, database, 238-239
Acunetix, 217, 221
Administration Tools Pack (adminpak), 161
administrative threats, identifying, 363
adversarial relationships, 18
air conditioning, 86, 93
alarms
burglar, 84, 96
chemical, 85
fire, 84, 96-97
gas, 85
humidity, 85, 97-98
power fluctuation, 85
water, 85
Alerter utility, 145
analytical skills, of IT auditors, 27
annual rate of occurrence (ARO), 364
anonymous access, 159
anonymous File Transfer Protocol (FTP), 192-193
antennas, 272
antivirus programs, 141-142, 157
Application Layer Gateway Service, 145
application proxies, 117
application-level firewalls, 117
applications auditing, 247-262
best practices, 250-252
applying defense in depth, 250
avoiding security by obscurity, 251
detecting intrusions and keep logs, 251
establishing secure defaults, 251
failing safely, 250-251
keeping security simple, 251
master checklists, 261
never trusting infrastructure and services, 251
overview, 250
running with least privilege, 251
using open standards, 252
using positive security model, 250
generalized frameworks, 247-250
overview, 247
people, processes, tools, and measures (PPTM), 248
planning, design, implementation, and operations (PDIO), 250
STRIDE, 248-250
master checklists, 262
overview, 21, 247
performing, 252-261
access controls, 255-259
audit trails, 255
backup and recovery, 260
data retention and classification, 260-261
input controls, 252-254
interface controls, 254-255
operating system, database, and other infrastructure controls, 261
overview, 252
software change controls, 259-260
approving new projects, 66
APs (access points), 263, 267-268, 270
ARO (annual rate of occurrence), 364
assets, 352
assigning information criticality values to, 359
failure to identify, 354-355
identifying, 356-359
assigning information criticality values to information assets, 359
defining information criticality values, 357
identifying business functions, 357-358
mapping information processes, 358-359
overview, 356-357
moving and disposal procedures, 76
procurement process, 76
tracking, 76
atjobs, 187-188
audit committee, 4, 6
audit logs
master checklist, 205
test steps, 196-199
audit process, 33-58
determining what to audit, 36-41
creating audit universe, 37-38
overview, 36
ranking audit universe, 39-41
internal controls, 33-36
examples of, 35-36
overview, 33-34
types of, 34-35
overview, 33
stages of audit, 41-57
field work and documentation, 44-45
issue discovery and validation, 45-46
issue tracking, 55-57
overview, 41
planning, 42-44
report drafting and issuance, 50-55
solution development, 46-50
standards, 57-58
audit reports. See report drafting and issuance
audit scope, in audit report, 303
audit trails, 255
audit universe
creating, 36-37
business applications, 38
centralized IT functions, 37
decentralized IT functions, 38
regulatory compliance, 38
ranking, 39-41
auditees, use of term, 20
authentication, 255-256
devices for, in data center, 91
mechanism of, 256
security of authentication method, 268-269
Unix and Linux operating systems auditing, 170-171
overview, 170
Unix Group File, 171
Unix Password File, 170
Unix Shadow File, 170-171
authentication, authorization, and accounting (AAA), 121
authority, 63
authorization controls, 215
Autologin, 159
autoruns tool, 139
autorunsc tool, 139
autoruns(c) utility, 143


Previous Page
Next Page

Index

B

backdoors, 242
BackTrack, 272
backup and recovery, 36, 85, 95, 107-108, 229, 260, 288-289
basic service set (BSS), 264
biometric authentication devices, in data center, 92
blade antennas, 272
bootcfg tool, 139, 143
broken authentication, 215-216
BSS (basic service set), 264
BSSID (BSS identifier), 264
budget
for projects, 290
tracking performance against, 65
burglar alarms, 84, 96
business applications, 38
business functions, identifying, 357-358
business threats, assessing, 361-362
financial threats, 361
legal threats, 361-362
overview, 361
regulatory threats, 362


Previous Page
Next Page

Index

C

cable locks, 160
California SB 1386, 340-341
Canadian Personal Information Protection and Electronic Document Act (PIPEDA), 341-342
capacity management, 105
capacity monitoring and planning, 78
card-key devices, in data center, 91
career IT auditors, 23-25
overview, 23-24
sources for, 24-25
CD (control deficiency), 352
ceilings, of data center, 91
Center for Information Security, 150
centralized IT functions, 37
CEO (chief executive officer), 4, 6, 63
CERT (Computer Emergency Response Team) notices, 188
certificates, server side, 213
certifications, 30
Certified Information Systems Auditor (CISA) certification, 23
Certified Information Systems Security Professional (CISSP) certification, 23, 30
CFO (chief financial officer), 4, 6
change management, 118-119, 274, 278-279, 288
change requests, for, 289
change-control documentation, 77
checkout of code, 259
chemical alarms, 85
chief executive officer (CEO), 4, 6, 63
chief financial officer (CFO), 4, 6
chief information officer (CIO), 7, 63
Chkrootkit, 201-202
chown command, 185
CIO (chief information officer), 7, 63
CISA (Certified Information Systems Auditor) certification, 23
Cisco-EAP Wireless (LEAP), 269
CISSP (Certified Information Systems Security Professional) certification, 23, 30
classification, data, 260-261
client/network libraries, 228-229
Clipbook utility, 145
closed items, in audit report, 54
CoBIT (Control Objectives for Information and Related Technologies), 38, 315-319
concepts, 316-317
connection with COSO, 319
IT governance, 318-319
overview, 315
website with information on, 79
code
checkout, modification, and versioning, 259
reviews, 220-221
testing, 260
collaboration, attitude of, 20
college hires, 25, 26
committee, audit, 4, 6
Committee of Sponsoring Organizations. See COSO
communication skills, of IT auditors, 27
communications method, security of, 269
Computer Emergency Response Team (CERT) notices, 188
configuration change management, 76-77
configuration files, backups for, 123
configuration management, 220
configuration values, 227-228
consultants
auditors as, 13
outside, 28
contractors, 28
contracts, with third-party services, 73
control deficiency (CD), 352
control gaps, 366-367
categorizing by severity, 366
choosing controls, 366-367
identifying potential controls, 366
overview, 366
rating controls by cost and effectiveness, 366-367
combining, 366
determining process component control gaps, 365
implementing controls, 367
overview, 366
recalculating risk ratings, 367
validating new controls, 367
Control Objectives for Information and Related Technologies. See CoBIT
control self-assessment (CSA) model, 17
controls
See also internal controls
entity-level, auditing, 61-81
background, 61-62
knowledge base, 79
master checklist, 80-81
overview, 61
test steps, 62-79
environmental controls, 92-93
facility-based, 84-85
access-control systems, 84
alarm systems, 84-85
fire-suppression systems, 85
overview, 84
physical access control, 90-92
conversion plan, for projects, 299-300
cooperation, attitude of, 20
core dumps, 129
corporate financial regulation, history of, 328
corrective controls (reactive controls), 34
COSO (Committee of Sponsoring Organizations), 308-315
definition of internal control, 309
enterprise risk management-integrated framework, 311-315
control activities, 314
COSO effect on IT controls, 315
definition of enterprise risk management, 312
event identification, 313
impact of COSO, 314-315
information and communication, 314
internal environment, 313
monitoring, 314
object setting, 313
overview, 311-313
relationship with internal control-integrated framework, 314
risk assessment, 313
risk response, 314
internal control-integrated framework, 309-311
component relationships, 311
control activities, 310
control environment, 310
information and communication, 310-311
monitoring, 311
overview, 309-310
risk assessment, 310
website with information on, 79
key concepts of internal control, 309
overview, 308-309
cosourcing, 28
costs
of internal auditors, justifying, 7
tracking for projects, 290
Crack tool, 202
credibility, 19
crime rate, around data centers, 89-90
crontabs, 186-187
cross-site scripting (XSS) vulnerabilities, 216-217
CSA (control self-assessment) model, 17
customer steering teams, 72
customers, use of term, 20


Previous Page
Next Page

Index

D

data center auditing, 83-106
alarm systems, 96-98
data center operations, 86, 101-106
environmental controls, 92-93
facility-based controls, 84-85
access-control systems, 84
alarm systems, 84-85
fire-suppression systems, 85
overview, 84
fire suppression, 98-100
master checklists, 111-112
neighborhood and environment, 87-90
overview, 83-84, 86-87
physical access control, 90-92
power continuity, 92-96
surveillance systems, 100-101
system and site resiliency, 85-86
heating, ventilation, and air conditioning, 86
network connectivity, 86
overview, 85
power, 85
data classification, 71, 261
data dictionary, 231
data entry, 64
data extraction and analysis, 23
data files, 228
data input controls, 252-253
data retention, 260-261
database auditing, 223-246
background, 223-224
database basics, 224-231
common database vendors, 224-227
database components, 227-231
overview, 224
knowledge base, 244-246
master checklist, 246
overview, 21, 223
performing audit, 231-242
overview, 231-232
test steps, 232-242
tools and technology, 242-243
decentralized IT functions, 38
default umask value, 186
denial of service, 219-220, 249
detective controls, 34
determining what to audit, 36-41
creating audit universe, 36-37
business applications, 38
centralized IT functions, 37
decentralized IT functions, 38
overview, 37
regulatory compliance, 38
overview, 36
ranking audit universe, 39-41
device security controls, 276
direct "root" logins, 196
directional antennas, 272
director of audits, 6
directories, controls for, 212
disaster recovery auditing, 106-110, 156
data backup and restore, 107-108
disaster-recovery plans, 36
disaster-recovery processes, 274
master checklists, 112
mobile devices, 278
overview, 106
planning, 108-110
system resiliency, 106-107
disposal of media, 77-78, 105-106
distributing audit reports, 55
documentation, 16, 44-45
importance of, 44-45
and IT professionals, 26
of projects, 287-289, 300
doors, of data center, 90
dot-files, 181 "drive by" audits, 17
DTP (Dynamic Trunking Protocol), 126-127
DumpSec utility, 139, 144, 147, 152
duties, segregation of, 63
dynamic packet-filtering firewalls, 117
dynamic SQL, executed in stored procedures, 233
Dynamic Trunking Protocol (DTP), 126-127


Previous Page
Next Page

Index

E

EAP-MD5, 269
EAP-TLS (Transport Layer Security), 269
EAP-TTLS (Tunneled Transport Layer Security), 269
early involvement, 9-11
earth movement hazards, 89
EF (exposure factor), 352, 364
electronic shielding, in data centers, 93
electronic vaulting, 107
elevation of privilege, 250
emergency operations, 103-104, 110
emergency services, distance of data centers from, 90
encryption
database, 239-240
network, 239-241
techniques, 258
enterprise resource planning (ERP) application, 21
enterprise risk management-integrated framework, 311-315
control activities, 314
COSO effect on IT controls, 315
definition of enterprise risk management, 312
event identification, 313
impact of COSO, 314-315
information and communication, 314
internal environment, 313
monitoring, 314
object setting, 313
overview, 311, 312-313
relationship with internal control-integrated framework, 314
risk assessment, 313
risk response, 314
entity-level controls, auditing, 21, 61-81
background, 61-62
knowledge base, 79
master checklist, 80-81
overview, 61
test steps, 62-79
environmental controls, 92-93
environmental hazards around data centers, 88-89
ERP (enterprise resource planning) application, 21
error handling, 218-219
Error Reporting Service, 145
error/exception reports, 253-254
ESS (extended service set), 264
estimations, inaccurate, 355
/etc/hosts.equiv file, 190-192
/etc/passwd file, 184-185
EU Commission and Basel II, 345
European Directive on the Protection of Personal Data, 341
execution of projects, standards for, 66
executive summary, in audit report, 51, 303
exposure factor (EF), 352, 364
extended service set (ESS), 264
exterior lighting, of data centers, 88


Previous Page
Next Page

Index

F

facility monitoring procedures, 102-103
facility-based controls, data center auditing, 84-85
access-control systems, 84
alarm systems, 84-85
fire-suppression systems, 85
overview, 84
Fax Service, 145
FCPA (Foreign Corrupt Practices Act of 1977), 307
Federal Deposit Insurance Corporation Act (FDICIA), 328
Federal Financial Institutions Examination Council (FFIEC), 340
field work, 44-45
file security and controls
See also permissions
master checklist, 204
test steps, 182-188
file system layout and navigation, 167-169
File Transfer Protocol (FTP), anonymous, 192-193
finance audit manager, 6
financial auditors, 22-23
financial threats, 361
fire alarms, 84, 96-97
fire suppression, 85, 98-100
firewalls, 116-117, 157
additional controls, 130-131, 134
application proxies, 117
application-level firewalls, 117
overview, 116-117
packet-filtering firewalls, 117
stateful packet inspection (SPI) firewalls, 117
flame sensors, 97
flood elevations, 89
floors, of data center, 91
Foreign Corrupt Practices Act of 1977 (FCPA), 307
formal training, 29
Fport tool, 139, 144, 161
frameworks and standards, 307-325
Committee of Sponsoring Organizations (COSO), 308-315
definition of internal control, 309
enterprise risk management-integrated framework, 311-315
key concepts of internal control, 309
overview, 308-309
Control Objectives for Information and Related Technologies (CoBIT), 315-319
concepts, 316-317
connection with COSO, 319
IT governance, 318-319
overview, 315
International Organization for Standardization (ISO) 27001/ISO 17799/BS 7799, 322-323
IT Infrastructure Library (ITIL®), 319-322
National Security Agency Infosec Assessment Methodology (NSA IAM), 323-325
concepts, 323
on-site activities phase, 324-325
overview, 323
post-assessment phase, 325
pre-assessment phase, 324
overview, 307-308
trends, 325
FTP (File Transfer Protocol), anonymous, 192-193


Previous Page
Next Page

Index

G

gas alarms, 85
gateways, 117
generators, 85, 95-96
GLBA (Gramm-Leach-Bliley Act), 338-340
Federal Financial Institutions Examination Council (FFIEC), 340
overview, 338
requirements, 338-339
customer privacy provisions, 338
internal control requirements, 339
overview, 338
Gramm-Leach-Bliley Act. See GLBA
ground to earth, 85, 94
Group File, Unix, 171
groups, 147-148, 178-179
guest accounts, 159


Previous Page
Next Page

Index

H

hands-on training, 29
hardware
procurement and movement of, 76
redundancy, 106
standards, 67
hashes, password, 174
hazardous materials handling and storage, 99
Health Insurance Portability and Accountability Act of 1996. See HIPAA
heat sensors, 97
heating, 86, 93
HIPAA (Health Insurance Portability and Accountability Act) of 1996, 342-345
ensuring effective policies exist for compliance with, 71-72
impact on covered entities, 344-345
overview, 342
privacy and security rules, 343-344
hiring procedures, 75-76
home directories, 181
host-based vulnerability scanning, 155-156, 199
hotfixes, 158-159
human resources (HR) policies, 70, 75-76
humidity, 85, 93, 97-98


Previous Page
Next Page

Index

I

IBM, 225
identity spoofing, 248
IIA (Institute of Internal Auditors), 79
IIS, 159
IISLockdown, 210
IMAPI CD-Burning COM Service, 145
IMS (Information Management System), 225
incentives for employees, 70
"independence" of internal audit department, 5-7
Indexing Service Wireless, 145
indices, 228
industrial areas, data center proximity to, 90
informal audits, 11-14
information criticality values
assigning to information assets, 359
defining, 357
information disclosure, 249
Information Management System (IMS), 225
Information Systems Audit and Control Association (ISACA), 29, 79
information technology (IT) audit function, internal. See internal information technology (IT) audit function
infrastructure control, 261
injection attacks, 218
input controls, 252-254
Institute of Internal Auditors (IIA), 79
interface controls, 254-255
internal control-integrated framework, 309-311
component relationships, 311
control activities, 310
control environment, 310
information and communication, 310-311
monitoring, 311
overview, 309-310
risk assessment, 310
internal controls, 33-36
See also internal control-integrated framework
defined, 5
examples of, 35-36
access controls, 35
backups and disaster-recovery plans, 36
overview, 35
software change controls, 35
legislation related to, 327-328
history of corporate financial regulation, 328
overview, 327
regulatory impact on IT audit, 327-328
overview, 33-34
types of, 34-35
detective controls, 35
overview, 34
preventive controls, 34-35
reactive controls (corrective controls), 35
internal information technology (IT) audit function, 3-31
early involvement, 9-11
forming and maintaining effective IT audit team, 23-28
career IT auditors, 23-28
cosourcing, 28
IT professionals, 25-26
overview, 23
informal audits, 11-14
knowledge sharing, 14-16
common issues, best practices, and innovative solutions, 15-16
control guidelines, 14-15
overview, 14
tools, 16
maintaining expertise, 28-30
overview, 28
sources of learning, 29-30
mission of internal audit department, 3-5
overview, 3
relationship building, 17-20
building partnerships, 19-20
overview, 17-18
relationship with external auditors, 30-31
role of IT audit team, 20-23
information systems auditors, 22
IT auditors, 22-23
overview, 20-21
support for financial auditors, 22
self-assessments, 17
whether internal audit department is independent, 5-7
International Organization for Standardization (ISO) 27001/ISO 17799/BS 7799, 322-323
international privacy laws, 341-342
Canadian Personal Information Protection and Electronic Document Act (PIPEDA), 341-342
European Directive on the Protection of Personal Data, 341
overview, 341
Intersite Messaging, 145
intranet, 14
intrusion detection and prevention, 154, 200
inventory of all equipment, 76
ISACA (Information Systems Audit and Control Association), 29, 79
ISAPI filters, 213
ISO (International Organization for Standardization) 27001/ISO 17799/BS 7799, 322-323
issue discovery and validation, 45-46
issue tracking, 55-57
issues list, in audit report, 51-54
IT (information technology) audit function, internal. See internal information technology (IT) audit function
IT audit manager, 6
IT organization structure, 62-63
IT professionals, 22-26
vs. career IT auditors, 27-28
overview, 25-26
sources for, 26
IT risk scenario, 353-354
IT strategic planning process, 64-65
ITIL (IT Infrastructure Library), 319-322


Previous Page
Next Page

Index

J

JMeter, 221
job descriptions, 70
John the Ripper tool, 202
John utility, 149


Previous Page
Next Page

Index

K

kernel, security over, 184
key controls, in audit report, 54
kickoff meeting, 43-44
kismet, 272
Knoppix, 166, 272
knowledge sharing, 14-16
after training, 30
common issues, best practices, and innovative solutions, 15-16
control guidelines, 14-15
with employees, 70
overview, 14
tools, 16


Previous Page
Next Page

Index

L

LAN auditing. See wireless local-area networks (LAN) auditing
LANs (local area networks), 115-116
layer 2 devices, 126
layer 3 switches, 115
LDAP, 171-172
leading projects, 28, 290-291
LEAP (Cisco-EAP Wireless), 269
learning, sources of, 29-30
certifications, 30
formal training, 29
knowledge sharing after training, 30
overview, 29
research time, 29
specialization, 29
learning ability, of IT auditors, 27
legal threats, 361-362
legal warning banner, 152, 195
legislation related to internal controls, 327-328
history of corporate financial regulation, 328
overview, 327
regulatory impact on IT audit, 327-328
licenses, software, 74-75
life cycle, risk management, 356-368
overview, 356
phase 1: identifying information assets, 356-359
assigning information criticality values to information assets, 359
defining information criticality values, 357
identifying business functions, 357-358
mapping information processes, 358-359
overview, 356-357
phase 2: quantifying and qualifying threats, 359-364
assessing business threats, 361-362
identifying process component threats, 363-364
identifying technical, physical, and administrative threats, 362-363
overview, 359-361
quantifying threats, 364
phase 3: assessing vulnerabilities, 364-366
categorizing control gaps by severity, 366
combining control gaps, 366
determining process component control gaps, 365
identifying existing controls, 365
overview, 364-365
phase 4: control gap remediation, 366-367
choosing controls, 366-367
implementing controls, 367
overview, 366
recalculating risk ratings, 367
validating new controls, 367
phase 5: managing ongoing risk, 367-368
creating risk baseline, 367-368
overview, 367
reassessing risk, 368
lighting of data centers, 88
Linux. See Unix and Linux operating systems auditing
local area networks (LANs), 115-116
location of data centers, 88
locks, cable, 160
logon auditing, 159
logs, 92, 124
audit logs
master checklist, 205
test steps, 196-199
wtmp log, 198
long-term technical planning, 65


Previous Page
Next Page

Index

M

MAC (media access control) addresses, 264, 272-273
man traps, 84, 91
management-response approach, to solution development, 47-48
mapping information processes, 358-359
MBSA (Microsoft Baseline Security Analyzer), 157, 159
media
disposal of, 77-78, 105-106
storage of, 105-106
transportation, storage, reuse, disposal, 77-78
media access control (MAC) addresses, 264, 272-273
meetings, with IT management, 19
Microsoft Baseline Security Analyzer (MBSA), 157, 159
Microsoft Database Engine (MSDE), 227
Microsoft Management Console (MMC), 152
Microsoft SQL Server, 226-227
middleware auditing, 21
minor issues, in audit report, 54
MIS Training Institute, 29
MMC (Microsoft Management Console), 152
mobile device auditing, 274-279
See also wireless local-area networks (LAN) auditing
background, 265-266
knowledge base, 280
master checklists, 281
operational audit, 277-279
overview, 274-275
technical audit, 275-277
tools and technology, 279-280
modems, 195
modification of code, 259
monitoring procedures, 102-103
monitoring state of security on system, 153-154, 199-200
MSDE (Microsoft Database Engine), 227
MySQL, 226


Previous Page
Next Page

Index

N

naming conventions, 125-126
NAT (network address translation), 117
National Security Agency Infosec Assessment Methodology (NSA IAM), 323-325
concepts, 323
on-site activities phase, 324-325
overview, 323
post-assessment phase, 325
pre-assessment phase, 324
National Vulnerability Database (NVD), 119
NDAs (nondisclosure agreements), 74
neighborhood, where data centers located, 88
Nessus plugin, 201, 217
Nessus Scanner, 161
NetMeeting Remote Desktop Sharing, 145 .netrc files, 194-195
Netsh tool, 139
Netstat utility, 139, 144
netstumbler, 272
network
connectivity, 86
encryption, 239-241
remote access into, 75
network address translation (NAT), 117
network auditing, 113-134
background, 113-114
firewalls, 116-117
additional firewall controls, 130-131, 134
application proxies, 117
application-level firewalls, 117
overview, 116-117
packet-filtering firewalls, 117
stateful packet inspection (SPI) firewalls, 117
general steps, 118-126, 132-133
knowledge base, 132
overview, 21, 113
routers, 116, 129-130, 133
switches, 114-116, 126-128, 133
tools and technologies, 131-132
Network File System (NFS), 193-194
network scanners, 160
network security and controls
Unix and Linux operating systems auditing
master checklist, 205
test steps, 188-195
Windows Server, 151-156
host-based vulnerability scanning, 155-156
intrusion detection, 154
intrusion prevention, 154
network vulnerability scanning, 154-155
overview, 151-154
Network Time Protocol (NTP), 124
network vulnerability scanning, 154-155, 189-190, 199
NFS (Network File System), 193-194
Nikto tool, 217
NIS, 171-172
NIS+, 171-172
Nitko, 221
*nix systems. See Unix and Linux operating systems
NMAP, 201
nondisclosure agreements (NDAs), 74
nonemployee logical access, 73-74
NSA IAM (National Security Agency Infosec Assessment Methodology), 323-325
concepts, 323
on-site activities phase, 324-325
overview, 323
post-assessment phase, 325
pre-assessment phase, 324
NTP (Network Time Protocol), 124
NVD (National Vulnerability Database), 119


Previous Page
Next Page

Index

O

objectivity of internal auditors, 7
objects, database, 230
omnidirectional antennas, 272
ongoing risk, managing, 367-368
creating risk baseline, 367-368
overview, 367
reassessing risk, 368
open directories, 183
Open Web Application Security Project (OWASP), 213-214
operating system
auditing, 21
controls, 261
operational software team, 300
Operator tool, 272
Ophcrack utility, 149
Oracle Corporation, 224-225
organization structure, IT, 62-63
outsourced IT support, 73
OWASP (Open Web Application Security Project), 213-214
ownership of company data, 71


Previous Page
Next Page

Index

P

packet-filtering firewalls, 117
packets, 116, 131
Paraben's Device Seizure, 276
Paros Proxy, 221
partnership building, 19-20
attitude of collaboration and cooperation, 20
formal audit liaisons with different IT organizations, 19
getting invited to key meetings, 19
overview, 19
updates and meetings with IT management, 19
parts inventories, 109-110
Password File, Unix, 170
passwords, 174-176, 179, 257-258
controls, 122-123, 146-149
for databases, 236-238
for remote access, 75
for web server access, 211-212
patch-management solution, 142, 158, 241-242
Payment Card Industry (PCI) Data Security Standard, 346-347
PCI (Payment Card Industry) Data Security Standard, 346-347
PDIO (planning, design, implementation, and operations), 250
PEAP (Protected EAP), 269
peer reviews, 295
pendmoves tool, 139, 143
people, processes, tools, and measures (PPTM), 248
performance indicators and measurements, 65
performance-review processes, 70
permissions
database, 232-234, 236
file system, 169-170
personal information management (PIM) services, 265
personnel, of data centers, 103-105
PHI (protected health information), 332
PHLAK, 272
physical access-control, 90-92, 101-102
physical authentication devices, in data center, 91
physical facilities auditing, 21
physical risk scenario, 353
physical security controls, 160
physical threats, identifying, 362-363
PIM (personal information management) services, 265
PIPEDA (Canadian Personal Information Protection and Electronic Document Act), 341-342
plain-text.info utility, 149
planning, design, implementation, and operations (PDIO), 250
policy coverage, 68
positive filtering, 214
postimplementation audits, 8
power continuity, 85, 92-96
PPTM (people, processes, tools, and measures), 248
preimplementation opinions, 8
preventive controls, 34-35
prioritizing
new projects, 66
tasks, for projects, 295
privacy regulations
California SB 1386, 340-341
international privacy laws, 341-342
Canadian Personal Information Protection and Electronic Document Act (PIPEDA), 341-342
European Directive on the Protection of Personal Data, 341
overview, 341
trends, 342
Proactive Password Auditor utility, 149
process component threats, 363-364
process of audit. See audit process
processes around policies, 69
procexp tool, 139
program files, 227
programmers, duties of, 64
project approval or review process, 9-10
project auditing, 283-304
background, 284-286
basic approaches to project auditing, 285
high-level goals of project audit, 284
overview, 284
seven major parts of project audit, 286
detailed design and system development
master checklist, 303
test steps, 294-295
implementation
master checklist, 304
test steps, 298-300
knowledge base, 301-302
overall project management
master checklist, 302
test steps, 287-291
overview, 283
project startup, 302-303
project wrap-up
master checklist, 304
test steps, 301
requirements gathering and initial design, 291-294
testing
master checklist, 303
test steps, 296-298
training
master checklist, 304
test steps, 300-301
Protected EAP (PEAP), 269
protected health information (PHI), 332
protocols, secure, 194
proximity devices, in data center, 91
psfile tool, 152
psinfo tool, 139, 158-159
Pslist tool, 139
psservice tool, 139, 144
pstools, 141
Public Company Accounting Reform and Investor Protection Act. See Sarbanes-Oxley Act of 2002
PUBLIC permissions, 234-235
pwdump tool, 139


Previous Page
Next Page

Index

Q

quality assurance, 66, 67


Previous Page
Next Page

Index

R

radio frequency identification (RFID) chips, 91
RAID (redundant array of inexpensive drives), 106
rating system, in audit reports, 302-303
rcrack utility, 149
reactive controls (corrective controls), 35
recommendation approach, to solution development, 46-47
recovery. See backup and recovery
redundant array of inexpensive drives (RAID), 106
redundant power feeds, 85, 94
regulations, 327-347
EU Commission and Basel II, 345
Gramm-Leach-Bliley Act (GLBA), 338-340
Federal Financial Institutions Examination Council (FFIEC), 340
overview, 338
requirements, 338-339
Health Insurance Portability and Accountability Act (HIPAA) of 1996, 342-345
impact on covered entities, 344-345
overview, 342
privacy and security rules, 343-344
legislation related to internal controls, 327-328
history of corporate financial
regulation, 328
overview, 327
regulatory impact on IT audit, 327-328
overview, 327
Payment Card Industry (PCI) Data Security Standard, 346-347
privacy regulations
California SB 1386, 340-341
international privacy laws, 341-342
trends, 342
Sarbanes-Oxley Act of 2002, 328-338
considerations for companies with multiple locations, 332
core points of, 329-331
financial impact of Sarbanes Oxley compliance on companies, 337-338
impact of third-party services on compliance, 332-333
impact on IT departments, 331-332
impact on public corporations, 329
overview, 328-329
specific IT controls required for compliance, 333-337
trends, 347
regulatory compliance, 38
regulatory threats, 362
relationship building, 17-20
learning to build partnerships, 19-20
attitude of collaboration and cooperation, 20
formal audit liaisons with different IT organizations, 19
getting invited to key meetings, 19
overview, 19
updates and meetings with IT management, 19
overview, 17-18
remote access, 75, 151, 188
remote journaling, 107
report drafting and issuance, 50-55
distributing audit report, 55
essential elements of audit report, 51-54
closed items, 54
executive summary, 51
key controls, 54
list of issues and action plans, 51-54
minor issues, 54
overview, 51, 54
statement of audit scope, 51
overview, 50-51
repudiation, 249
requirements
for audits, 300
for projects, 291-292
research time, 29
resource constraints, 12
Resource Kit tools, 138, 161
retention, data, 260-261
Retina Scanner, 154-155, 161
reuse of media, 77-78
RFID (radio frequency identification) chips, 91
.rhosts file, 182, 190-192
risk analysis, 351-355
common causes for inaccuracies in, 354-355
failure to identify assets, threats, or vulnerabilities, 354-355
inaccurate estimations, 355
overview, 354
elements of risk, 351-352
assets, 352
overview, 351
threats, 352
vulnerabilities, 352
overview, 351
risk management, 351-368
benefits of, 351
life cycle, 356-368
overview, 356
phase 1: identifying information assets, 356-359
phase 2: quantifying and qualifying threats, 359-364
phase 3: assessing vulnerabilities, 364-366
phase 4: control gap remediation, 366-367
phase 5: managing ongoing risk, 367-368
overview, 351
risk analysis, 351-355
common causes for inaccuracies in, 354-355
elements of risk, 351-352
overview, 351
practical application, 353-354
in practice, 354
summary of formulas, 368
risk-assessment processes, 69-70
risk-based audit scheduling, 12
rogue access points, 270
role of IT audit team, 20-23
information systems auditors, 22
IT auditors, 22-23
overview, 20-21
support for financial auditors, 22
root kits, 242
rotation of auditors, 27, 40
routers, 116, 129-130, 133
routing updates, authentication of, 129-130
rsop.msc tool, 139


Previous Page
Next Page

Index

S

SAMInside utility, 149
SANS (SysAdmin Audit Network Security), 29
Sarbanes-Oxley Act of 2002, 308, 328-338
considerations for companies with multiple locations, 332
core points of, 329-331
ensuring effective policies exist for compliance with, 71-72
financial impact of Sarbanes Oxley compliance on companies, 337-338
impact of third-party services on compliance, 332-333
impact on IT departments, 331-332
impact on public corporations, 329
overview, 328-329
specific IT controls required for compliance, 333-337
asset management, 337
change control, 334-335
IT operations, 336
IT security, 334
network operations, 336-337
overview, 333-334
website with guidelines for, 79
sc tool, 139, 144
scheduled tasks, Windows Server, 143-146
schedules for projects, 290
scheduling audits, 12
schtasks tool, 139, 146
SCM (software change management), 259
script extensions, 213
secpol.msc tool, 139
secure protocols, 194
security guards, 92
security monitoring and other controls
policies, 67
security monitoring software, 270, 276
security through obscurity, 88
Unix and Linux, 199-201, 205
Windows Server, 150-151
segregation of duties, 63
self-assessments, 17
self-study activities, 29
sensitive areas, security of, 92
server management policy, 145
server side certificates, 213
service packs, 158-159
service-level agreements (SLAs), 65
services, Windows Server, 143-146
session management, 215-216
Shadow File, Unix, 170-171
shares on host, 152-153
Shell/Awk/etc, 202
signage of data centers, 88
Simple Network Management Protocol (SNMP), 120
skills, processes for ensuring employees have, 70
SLAs (service-level agreements), 65
smoke sensors, 97
SNMP (Simple Network Management Protocol), 120
software
change controls, 35, 259-260
development standards, 66-67
licenses, 74-75
minimum required, 158-159
standards, 67
software change management (SCM), 259
solution development, 46-50
guidance on, 49-50
management-response approach, 47-48
overview, 46
recommendation approach, 46-47
solution approach, 48
Spanning-Tree Protocol attack mitigation, 127
specialization, 29
SPI (stateful packet inspection) firewalls, 117
spoofing identity, 248
SQL (Structured Query Language) statements, 229-230
stages of audit, 41-57
field work and documentation, 44-45
issue discovery and validation, 45-46
issue tracking, 55-57
overview, 41
planning, 42-44
report drafting and issuance, 50-55
distributing audit report, 55
essential elements of audit report, 51-54
overview, 50-51
solution development, 46-50
guidance on solution development, 49-50
management-response approach, 47-48
overview, 46
recommendation approach, 46-47
solution approach, 48
stakeholder buy-in, 68
standard wording, 302
standards. See frameworks and standards startup information, 143
stateful packet inspection (SPI) firewalls, 117
statement of audit scope, 51
stations, 264
storage mechanisms, 219
storage of media, 77-78, 105-106
stored procedures, dynamic SQL executed in, 233
strategic planning process, IT, 64-65
STRIDE, 248-250
denial of service, 249
elevation of privilege, 250
information disclosure, 249
overview, 248
repudiation, 249
spoofing identity, 248
tampering with data, 249
Structured Query Language (SQL) statements, 229-230
su command, 196-197
sudo tool, 178, 196-197
SUID files, 183
sulog, 198
superuser (root-level) access, 178
supplicants, 264
surveillance systems, 100-101
switches, 114-116, 126-128, 133
Sybase, Inc., 226
synchronization, 255
SysAdmin Audit Network Security (SANS), 29
SysInternals tools, 138, 161
syslog, 197-198
system and site resiliency, 85-86
heating, ventilation, and air conditioning, 86
network connectivity, 86
overview, 85
power, 85
system configurations, 67, 76-77
system resiliency. See disaster recovery auditing Systeminfo tool, 139


Previous Page
Next Page

Index

T

tables, row-level access to, 234
tampering with data, 249
tcpvcon utility, 144
tcpview tool, 139
technical feasibility analysis, 291
technical planning, long-term, 65
technical threats, identifying, 362
technical training classes, 29
temperatures, in data centers, 93
TEMPEST project, 93
termination procedures, 75-76
terms, standard, 302
testing process, 296-298
third-party services
logical access by, 73-74
reviewing processes for managing, 73
threats, 352
administrative, 363
business, 361-362
financial threats, 361
legal threats, 361-362
overview, 361
regulatory threats, 362
failure to identify, 354-355
physical, 362-363
process component threats, 363-364
quantifying, 364
technical, 362
tools and technology, 161
training
overview, 28
reviewing and evaluating processes for, 70
sources of, 29-30
transaction tracing, 255
Transport Layer Security (EAP-TLS), 269
transportation of media, 77-78
transportation-related hazards, data center proximity to, 89
Treadway Commission, 308
Trojan horses, 242
trouble ticketing system, 273, 277
trunk autonegotiation, 126
trust, 19
Tunneled Transport Layer Security (EAP-TTLS), 269


Previous Page
Next Page

Index

U

umask value, default, 186
uninterrupted power supply (UPS), 85, 95
Unix and Linux operating systems auditing, 165-205
account management and password controls
master checklist, 203-204
test steps, 173-182
audit logs
master checklist, 205
test steps, 196-199
background, 165-166
file security and controls
master checklist, 204
test steps, 182-188
file system layout, navigation, and permissions, 167-170
knowledge base, 202-203
LDAP, NIS, or NIS+, 171-172
network security and controls
master checklist, 205
test steps, 188-195
overview, 165
security monitoring and other controls
master checklist, 205
test steps, 199-201
tools and technology, 201-202
Chkrootkit, 201-202
John Ripper and Crack, 202
Nessus, 201
NMAP, 201
overview, 201
Shell/Awk/etc, 202
users and authentication, 170-171
overview, 170
Unix Group File, 171
Unix Password File, 170
Unix Shadow File, 170-171
unmanaged devices, 277
UPS (uninterrupted power supply), 85, 95
URLScan, 210
user access, 257, 258. See also authentication
user accounts, 146-147, 173-180
user IDs, 75, 174
user rights, Windows Server, 150-151
users and authentication, 170-171
overview, 170
Unix Group File, 171
Unix Password File, 170
Unix Shadow File, 170-171
utmp file, 199


Previous Page
Next Page

Index

V

vendors
agreements with, 109-110
reviewing processes for managing, 73
ventilation, 86, 93
versioning of code, 259
virtual LANs (VLANs), 115-116, 127-128
viruses, 242
VLAN Trunking Protocol (VTP), 128
VLANs (virtual LANs), 115-116, 127-128
VTP (VLAN Trunking Protocol), 128
vulnerabilities, 352
assessing, 364-366
categorizing control gaps by severity, 366
combining control gaps, 366
determining process component control gaps, 365
identifying existing controls, 365
overview, 364-365
failure to identify, 354-355
scanning for
host-based, 155-156
network, 154-155


Previous Page
Next Page

Index

W

walls, of data center, 90
wardriving, 271-272
water alarms, 85, 97
weather threats, 89
web applications auditing, 213-220, 222
Web Inspect, 221
web servers auditing, 207-222
background, 207-208
knowledge base, 221
master checklist, 222
overview, 207
tools and technology, 220-221
web auditing components, 208
Web Sleuth, 221
website, of audit department, 14
WFT (Windows Forensic Toolchest), 138
Windows Client
master checklist, 163
simplified audit, 157-161
Windows Forensic Toolchest (WFT), 138
Windows Messenger Service, 145
Windows operating systems auditing, 135-163
See also Windows Server
background, 135-136
basics, 136-139
command-line tips, 137
common commands, 138
essential command-line tools, 137-138
overview, 136-137
Windows Server administrative tools, 138-139
knowledge base, 161-162
overview, 135
performing audit, 139-140
tools and technology, 161
Windows Client
master checklist, 163
simplified audit, 157-161
Windows Server, 140-156
account management and password controls, 146-149
administrative tools, 138-139
master checklist, 162-163
network security and controls, 151-156
host-based vulnerability scanning, 155-156
intrusion detection, 154
intrusion prevention, 154
network vulnerability scanning, 154-155
overview, 151-154
overview, 140
reviewing services, installed applications, and scheduled tasks, 143-146
reviewing user rights and security options, 150-151
setting up and general controls, 140-143
wireless local-area networks (LAN) auditing, 267-274
See also mobile device auditing background, 263-265
knowledge base, 280
master checklists, 280
operational audit, 273-274
overview, 267
technical audit, 267-273
commercial WLAN security monitoring tools, 270
overview, 267-270
searching through MAC OUIs, 272-273
wardriving, 271-272
tools and technology, 279-280
wording, standard, 302
wscui.cpl tool, 139
wtmp log, 198


Previous Page
Next Page

Index

X

XSS (cross-site scripting) vulnerabilities, 216-217
XSS NASL plugin for Nessus, 221


Previous Page
Next Page

Index

Y-Z

yagi antennas, 272


List of Figures

Chapter 1: Building an Effective Internal IT Audit Function

Figure 1-1: Audit committee board of directors
Figure 1-2: Potential auditing subject areas.

Chapter 2: The Audit Process

Figure 2-1: Types of internal controls and their implementation.
Figure 2-2: Example audit ranking table.
Figure 2-3: Audit process overview.
Figure 2-4: Audit process overview-planning stage.
Figure 2-5: Audit process overview-fieldwork and documentation stage.
Figure 2-6: Audit process overview-issue discovery and validation stage.
Figure 2-7: Audit process overview-solution development stage.
Figure 2-8: Audit process overview-report drafting and issuance stage.
Figure 2-9: Audit process overview-issue-tracking stage.

Chapter 4: Auditing Data Centers and Disaster Recovery

Figure 4-1: Data-processing hierarchy.

Chapter 6: Auditing Windows Operating Systems

Figure 6-1: Auditing hosts model.
Figure 6-2: Retina scanner.

Chapter 7: Auditing Unix and Linux Operating Systems

Figure 7-1: Unix permissions.

Chapter 11: Auditing WLAN and Mobile Devices

Figure 11-1: Example WLAN architecture.
Figure 11-2: Service provider illustration.
Figure 11-3: Network Stumbler in action.

Chapter 13: Frameworks and Standards

Figure 13-1: COSO cube.
Figure 13-2: Expanded COSO cube.
Figure 13-3: CoBIT framework.
Figure 13-4: IT Governance Institute maturity scale.
Figure 13-5: IT Governance Institute maturity model for internal control.
Figure 13-6: CoBIT-COSO relationships.

Chapter 15: Risk Management

Figure 15-1: Risk-management life cycle.
Figure 15-2: Business function decomposition.
Figure 15-4: Risk-management process.
Figure 15-3: Credit card process diagram.


List of Tables

Chapter 2: The Audit Process

Table 2-1: Potential Opportunities for Auditing Centralized Activities

Chapter 5: Auditing Switches, Routers, and Firewalls

Table 5-1: Simplified OSI Model Description
Table 5-2: Routers and Switches
Table 5-3: Unnecessary Services

Chapter 6: Auditing Windows Operating Systems

Table 6-1: List of Common Commands Used in This Chapter
Table 6-2: Tools for Viewing Service Information
Table 6-3: Unnecessary Services
Table 6-4: Common Password Crackers
Table 6-5: Account Policies
Table 6-6: Audit Policies
Table 6-7: Tools and Technology-Auditing Windows

Chapter 7: Auditing Unix and Linux Operating Systems

Table 7-1: Common Unix and Linux Directories
Table 7-2: Common Linux and Unix Navigation Commands
Table 7-3: Interaction Between File and Directory Permissions
Table 7-4: Components of a Unix Password File
Table 7-5: Components of a Unix Shadow File
Table 7-6: Components of a Unix Group File

Chapter 8: Auditing Web Servers

Table 8-1: Web Auditing Components
Table 8-2: Minimum Apache Modules
Table 8-3: Common Methods for Bypassing Web Application Authorization
Table 8-4: Guiding Principles of Web Authentication

Chapter 9: Auditing Databases

Table 9-1: SQL Statement Descriptions
Table 9-2: Database Objects
Table 9-3: Default Passwords

Chapter 11: Auditing WLAN and Mobile Devices

Table 11-1: Common 802.11 Technologies
Table 11-2: Common WLAN Authentication Methods
Table 11-3: Mobile Operating Systems and Desktop Executables

Chapter 13: Frameworks and Standards

Table 13-1: Organizational Information Criticality Matrix

Chapter 14: Regulations

Table 14-1: HIPAA Security Rule Requirements

Chapter 15: Risk Management

Table 15-1: Information Criticality Matrix
Table 15-2: Types of Controls