Equifax in data collection

vamsimarimganti

Principles-of-Incident-Response-and-Disaster-Recovery-2nd-Edition-B00C6SITOS.pdf

Home >Information Systems homework help >Equifax in data collection

Michael E. Whitman Ph.D., CISM, CISSP

Herbert J. Mattord Ph.D., CISM, CISSP

Andrew Green MSIS Kennesaw State University

Principles of Incident Response and Disaster Recovery Second Edition

This is an electronic version of the print textbook. Due to electronic rights restrictions, some third party content may be suppressed. Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. The publisher reserves the right to

remove content from this title at any time if subsequent rights restrictions require it. For valuable information on pricing, previous editions, changes to current editions, and alternate formats, please visit www.cengage.com/highered to search by

ISBN#, author, title, or keyword for materials in your areas of interest.

Principles of Incident Response & Disaster Recovery, Second Edition

Michael E. Whitman, Herbert J. Mattord, Andrew Green

Vice President, Careers & Computing:

Dave Garza

Acquisitions Editor: Nick Lombardi

Product Development Manager:

Leigh Hefferon

Senior Product Manager:

Michelle Ruelos Cannistraci

Brand Manager: Kristin McNary

Marketing Development Manager:

Mark Linton

Marketing Coordinator:

Elizabeth Murphy

Senior Production Director:

Wendy Troeger

Production Manager: Andrew Crouth

Senior Content Project Manager:

Andrea Majot

Art Director: GEX

Cover image: iStock.com

ALL RIGHTS RESERVED. No part of this work covered by the copyright herein may be reproduced, transmitted, stored or used in any form or by any means graphic, electronic, or mechanical, including but not limited to photocopying, recording, scanning, digitizing, taping, Web distribution, information networks, or information storage and retrieval systems, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the publisher.

For product information and technology assistance, contact us at

Cengage Learning Customer & Sales Support, 1-800-354-9706

For permission to use material from this text or product,

submit all requests online at cengage.com/permissions

Further permissions questions can be emailed to

[email protected]

Library of Congress Control Number: 2013932024

ISBN-13: 978-1-111-13805-9

ISBN-10: 1-111-13805-2

Course Technology 20 Channel Center Street Boston, MA 02210 USA

Cengage Learning is a leading provider of customized learning solutions with office locations around the globe, including Singapore, the United Kingdom, Australia, Mexico, Brazil, and Japan. Locate your local office at: international.cengage.com/region

Cengage Learning products are represented in Canada by Nelson Education, Ltd.

For your lifelong learning solutions, visit www.cengage.com/coursetechnology

Purchase any of our products at your local college store or at our preferred online store www.cengagebrain.com

Visit our corporate website at cengage.com.

Some of the product names and company names used in this book have been used for identification purposes only and may be trademarks or registered trademarks of their respective manufacturers and sellers.

Any fictional data related to persons or companies or URLs used throughout this book is intended for instructional purposes only. At the time this book was printed, any such data was fictional and not belonging to any real persons or companies.

Course Technology and the Course Technology logo are registered trademarks used under license.

Course Technology, a part of Cengage Learning, reserves the right to revise this publication and make changes from time to time in its content without notice.

The programs in this book are for instructional purposes only. They have been tested with care, but are not guaranteed for any particular intent beyond educational purposes. The author and the publisher do not offer any warranties or representations, nor do they accept any liabilities with respect to the programs.

Printed in the United States of America 1 2 3 4 5 6 7 16 15 14 13

To Rhonda, Rachel, Alex, and Meghan, thank you for your loving support. —MEW

To my daughter, Becky. Always stay strong. —HJM

For my nieces, Lexidoodle and Alliecat, and my nephew Timmy. —AG

Brief Contents

PREFACE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

CHAPTER 1 An Overview of Information Security and Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

CHAPTER 2 Planning for Organizational Readiness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CHAPTER 3 Contingency Strategies for IR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

CHAPTER 4 Incident Response: Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

CHAPTER 5 Incident Response: Detection and Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

CHAPTER 6 Incident Response: Organizing and Preparing the CSIRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

CHAPTER 7 Incident Response: Response Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

CHAPTER 8 Incident Response: Recovery and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

CHAPTER 9 Disaster Recovery: Preparation and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

CHAPTER 10 Disaster Recovery: Operation and Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

CHAPTER 11 Business Continuity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

CHAPTER 12 Crisis Management and International Standards inIR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

APPENDIX A Sample Business Continuity Plan for ABC Co. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

APPENDIX B Contingency Plan Template from the Computer Security Resource Center at the National Institute of Standards and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537

APPENDIX C Sample Crisis Management Plan for Hierarchical Access, Ltd.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

Table of Contents

PREFACE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

CHAPTER 1 An Overview of Information Security and Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Opening Case Scenario: Pernicious Proxy Probing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Information Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Key Information Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Overview of Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Know Yourself. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Know the Enemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Risk Assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Risk Control Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Contingency Planning and Its Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Business Impact Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Incident Response Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Disaster Recovery Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Business Continuity Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Contingency Planning Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Role of Information Security Policy in Developing Contingency Plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Key Policy Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Enterprise Information Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Issue-Specific Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Systems-Specific Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Virtualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Ethical Considerations in the Use of Information Security Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Closing Case Scenario: Pondering People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

CHAPTER 2 Planning for Organizational Readiness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Opening Case Scenario: Proper Planning Prevents Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Beginning the Contingency Planning Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Commitment and Support of Senior Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Elements Required to Begin Contingency Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Contingency Planning Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A Sample Generic Policy and High-Level Procedures for Contingency Plans . . . . . . . . . . . . . . . . . . . . . . . . . . 55

vii

Business Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Determine Mission/Business Processes and Recovery Criticality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Identify Resource Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Identify System Resource Recovery Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

BIA Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Online Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Facilitated Data-Gathering Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Process Flows and Interdependency Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Risk Assessment Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 IT Application or System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Financial Reports and Departmental Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Audit Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Production Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Budgeting for Contingency Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Incident Response Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Disaster Recovery Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Business Continuity Budgeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Crisis Management Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Closing Case Scenario: Outrageously Odd Outages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

CHAPTER 3 Contingency Strategies for IR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Opening Scenario: Panicking over Powder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Data and Application Resumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Online Backups and the Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Disk to Disk to Other: Delayed Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Redundancy-Based Backup and Recovery Using RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Database Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Application Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Backup and Recovery Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Real-Time Protection, Server Recovery, and Application Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Site Resumption Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Exclusive Site Resumption Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Shared-Site Resumption Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Service Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Hands-On Project 3-1: Command-line Backup Using rdiff-backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Hands-On Project 3-2: Copying Virtual Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Closing Case Scenario: Disaster Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

viii Table of Contents

CHAPTER 4 Incident Response: Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Opening Case Scenario: DDoS Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

The IR Planning Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Forming the IR Planning Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Developing the Incident Response Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Building the Computer Security Incident Response Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Incident Response Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Information for attack success end case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Planning for the Response During the Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Planning for “After the Incident”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Reaction!. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Planning for “Before the Incident”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

The CCDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Assembling and Maintaining the Final IR Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Closing Case Scenario: The Never-Ending Story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

CHAPTER 5 Incident Response: Detection and Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Opening Case Scenario: Oodles of Open Source Opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Detecting Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Possible Indicators of an Incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Probable Indicators of an Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Technical Details: Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Definite Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Identifying Real Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Intrusion Detection and Prevention Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Technical Details: Processes and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 IDPS Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Why Use an IDPS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 IDPS Network Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Technical Details: Ports and Port Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 IDPS Detection Approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Automated Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Incident Decision Making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Collection of Data to Aid in Detecting Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Challenges in Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Table of Contents ix

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Closing Case Scenario: Jokes with JJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

CHAPTER 6 Incident Response: Organizing and Preparing the CSIRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Opening Case Scenario: Trouble in Tuscaloosa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Building the CSIRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Step 1: Obtaining Management Support and Buy-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Step 2: Determining the CSIRT Strategic Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Step 3: Gathering Relevant Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Step 4: Designing the CSIRT Vision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

A Sample Generic Policy and High-Level Procedures for Contingency Plans . . . . . . . . . . . . . . . . . . . . . . . . . 243 Step 5: Communicating the CSIRT’s Vision and Operational Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Step 6: Beginning CSIRT Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Step 7: Announce the operational CSIRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Step 8: Evaluating CSIRT Effectiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Final Thoughts on CSIRT Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Outsourcing Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Current and Future Quality of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Division of Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Sensitive Information Revealed to the Contractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Lack of Organization-Specific Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Lack of Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Handling Incidents at Multiple Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Maintaining IR Skills In-House . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Closing Case Scenario: Proud to Participate in Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

CHAPTER 7 Incident Response: Response Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Opening Case Scenario: Viral Vandal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

IR Response Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Response Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 Incident Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

The Cuckoo’s Egg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Incident Eradication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Incident Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Incident Containment and Eradication Strategies for Specific Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Egghead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Handling Denial of Service (DoS) Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

x Table of Contents

Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Unauthorized Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Inappropriate Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Hybrid or Multicomponent Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Automated IR Response Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Closing Case Scenario: Worrisome Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

CHAPTER 8 Incident Response: Recovery and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Opening Case Scenario: Wily Worms Wake Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314

Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Identify and Resolve Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Restore Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Restore Services and Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Restore Confidence across the Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 After-Action Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Plan Review and Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Rehearsal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Law Enforcement Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Reporting to Upper Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Loss Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Sample Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Incident Forensics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Legal Issues in Digital Forensics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Digital Forensics Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Technical Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Digital Forensics Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

eDiscovery and Anti-Forensics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Closing Case Scenario: Bureaucratic Blamestorms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

CHAPTER 9 Disaster Recovery: Preparation and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Opening Case Scenario: Flames Force Fan Fury . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Disaster Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Table of Contents xi

Forming the Disaster Recovery Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Organization of the DR Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 Special Documentation and Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Disaster Recovery Planning Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Develop the DR Planning Policy Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Review the Business Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Identify Preventive Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Develop Recovery Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Develop the DR Plan Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Plan Testing, Training, and Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Plan Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Information Technology Contingency Planning Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Client/Server Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 Data Communications Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Mainframe Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Sample Disaster Recovery Plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 The Business Resumption Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

The DR Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Closing Case Scenario: Proactively Pondering Potential Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

CHAPTER 10 Disaster Recovery: Operation and Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

Opening Case Scenario: Dastardly Disaster Drives Dialing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Facing Key Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Preparation: Training the DR Team and the Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Plan Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Plan Triggers and Notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Disaster Recovery Planning as Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 DR Training and Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 DR Plan Testing and Rehearsal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Rehearsal and Testing of the Alert Roster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

Disaster Response Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

Recovery Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Resumption Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

Restoration Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Repair or Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 Restoration of the Primary Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Relocation from Temporary Offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Resumption at the Primary Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Standing Down and the After-Action Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

xii Table of Contents

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

Closing Case Scenario: Smart Susan Starts Studying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

CHAPTER 11 Business Continuity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Opening Case Scenario: Lovely Local Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

Business Continuity Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 BC Team Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Special Documentation and Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

Business Continuity Policy and Plan Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Develop the BC Planning Policy Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 Review the BIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Identify Preventive Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Create BC Contingency (Relocation) Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Develop the BC Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Ensure BC Plan Testing, Training, and Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Ensure BC Plan Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Sample Business Continuity Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Implementing the BC Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Preparation for BC Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 Returning to a Primary Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457 BC After-Action Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459

Continuous Improvement of the BC Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Improving the BC Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459 Improving the BC Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Maintaining the BC Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Periodic BC Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 BC Plan Archivist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

Closing Case Scenario: Exciting Emergency Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

CHAPTER 12 Crisis Management and International Standards inIR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Opening Case Scenario: Terrible Tragedy Today . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

Crisis Management in the Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Crisis Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479 Crisis Misconceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481

Preparing for Crisis Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 General Preparation Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Organizing the Crisis Management Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Table of Contents xiii

Crisis Management Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 Developing the Crisis Management Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Crisis Management Training and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

Ongoing Case: Alert Roster Test at HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

Post-crisis Trauma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 Posttraumatic Stress Disorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494 Employee Assistance Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495 Immediately after the Crisis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

Getting People Back to Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496 Dealing with Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

Law Enforcement Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497 Federal Agencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 Local Agencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Managing Crisis Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Crisis Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

The 11 Steps Of Crisis Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Avoiding Unnecessary Blame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

Succession Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 Elements of Succession Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510 Succession Planning Approaches for Crisis Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

International Standards in IR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 NIST Standards and Publications in IR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 ISO Standards and Publications in IR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513 Other Standards and Publications in IR/DR/BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517

Review Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Real-World Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Hands-On Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Closing Case Scenario: Boorish Board Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

Endnotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

APPENDIX A Sample Business Continuity Plan for ABC Co. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

APPENDIX C Sample Crisis Management Plan for Hierarchical Access, Ltd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

xiv Table of Contents

Preface

As global networks expand the interconnection of the world’s technically complex infra- structure, communication and computing systems gain added importance. Information secu- rity has gained in importance as a professional practice, and information security has emerged as an academic discipline. Recent events, such as malware attacks and successful hacking efforts, have pointed out the weaknesses inherent in unprotected systems and exposed the need for heightened security of these systems. In order to secure technologically advanced systems and networks, both education and the infrastructure to deliver that educa- tion are needed to prepare the next generation of information technology and information security professionals to develop a more secure and ethical computing environment. There- fore, improved tools and more sophisticated techniques are needed to prepare students to recognize the threats and vulnerabilities present in existing systems and to design and develop the secure systems needed in the near future. Many years have passed since the need for improved information security education has been recognized, and as Dr. Ernest McDuffie of NIST points out:

While there is no doubt that technology has changed the way we live, work, and play, there are very real threats associated with the increased use of technology and our growing dependence on cyberspace….

Education can prepare the general public to identify and avoid risks in cyber- space; education will ready the cybersecurity workforce of tomorrow; and

education can keep today’s cybersecurity professionals at the leading edge of the latest technology and mitigation strategies.

Source: NIST

The need for improvements in information security education is so great that the U.S. National Secu- rity Agency (NSA) has established Centers of Academic Excellence in Information Assurance, as described in Presidential Decision Directive 63, “The Policy on Critical Infrastructure Protection,” May 1998:

The program goal is to reduce vulnerabilities in our National Information Infrastructure by promoting higher education in information assurance, and producing a growing num- ber of professionals with IA expertise in various disciplines.

Source: National Security Agency

The technical nature of the dominant texts on the market does not meet the needs of students who have a major other than computer science, computer engineering, or electronic engineering. This is a key concern for academics who wish to focus on delivering skilled undergraduates to the commer- cial information technology (IT) sector. Specifically, there is a clear need for information security, information systems, criminal justice, political science, and accounting information systems students to gain a clear understanding of the foundations of information security.

Approach This book provides an overview of contingency operations and its components as well as a thorough treatment of the administration of the planning process for incident response, disaster recovery, and business continuity. It can be used to support course delivery for information-security-driven programs targeted at information technology students, as well as IT management and technology management curricula aimed at business or technical management students.

Learning Support—Each chapter includes a Chapter Summary and a set of open-ended Review Questions. These are used to reinforce learning of the subject matter presented in the chapter.

Chapter Scenarios—Each chapter opens and closes with a case scenario that follows the same fic- tional company as it encounters various contingency planning or operational issues. The closing sce- nario also includes a few discussion questions. These questions give the student and the instructor an opportunity to discuss the issues that underlie the content.

Hands-On Learning—At the end of each chapter, Real-World Exercises and Hands-On Projects are provided. These give students the opportunity to examine the contingency planning arena outside the classroom. Using these exercises, students can pursue the learning objectives listed at the begin- ning of each chapter and deepen their understanding of the text material.

Boxed Examples—These supplemental sections, which feature examples not associated with the ongoing case study, are included to illustrate key learning objectives or extend the coverage of plans and policies.

New to This Edition This edition provides a greater level of detail than the previous edition, specifically in the examination of incident response activities. It incorporates new approaches and methods that have been developed at NIST. Although the material on disaster recovery, business continuity, and crisis management has not

xvi Preface

been reduced, the text’s focus now follows that of the IT industry in shifting to the prevention, detection, reaction to, and recovery from computer-based incidents and avoidance of threats to the security of infor- mation. We are fortunate to have had the assistance of a reviewer who worked as a contributing author for NIST, ensuring alignment between this text and the methods recommended by NIST.

Author Team Long-time college professors and information security professionals Michael Whitman and Herbert Mattord have jointly developed this text to merge knowledge from the world of academic study with practical experience from the business world. Professor Andrew Green has been added to this proven team to add a new dimension of practical experience.

Michael Whitman, Ph.D., CISM, CISSP Michael Whitman is a professor of information security and assurance in the Information Systems Department, Michael J. Coles College of Business at Ken- nesaw State University, Kennesaw, Georgia, where he is the director of the KSU Center for Informa- tion Security Education (infosec.kennesaw.edu). Dr. Whitman has over 20 years of experience in higher education, with over 12 years of experience in designing and teaching information security courses. He is an active researcher in information security, fair and responsible use policies, and computer-use ethics. He currently teaches graduate and undergraduate courses in information secu- rity. He has published articles in the top journals in his field, including Information Systems Research, Communications of the ACM, Information and Management, Journal of International Business Studies, and Journal of Computer Information Systems. He is a member of the Association for Computing Machinery and the Association for Information Systems. Under Dr. Whitman’s lead- ership, Kennesaw State University has been recognized by the National Security Agency and the Department of Homeland Security as a National Center of Academic Excellence in Information Assurance Education three times; the university’s coursework has been reviewed by national-level information assurance subject matter experts and determined to meet the national training standard for information systems security professionals. Dr. Whitman is also the coauthor of Principles of Information Security, 4th edition; Management of Information Security, 4th edition; Readings and Cases in the Management of Information Security; Readings and Cases in Information Security: Law and Ethics; The Hands-On Information Security Lab Manual, 3rd edition; Roadmap to the Management of Information Security for IT and Information Security Professionals; Guide to Fire- walls and VPNs, 3rd edition; Guide to Firewalls and Network Security, 2nd edition; and Guide to Network Security, all published by Course Technology. In 2012, Dr. Whitman was selected by the Colloquium for Information Systems Security Education as the recipient of the 2012 Information Assurance Educator of the Year award.

Herbert Mattord, Ph.D. CISM, CISSP Herbert Mattord completed 24 years of IT industry experi- ence as an application developer, database administrator, project manager, and information security practitioner before joining the faculty of Kennesaw State University in 2002. Dr. Mattord is an assistant professor of information security and assurance and the coordinator for the Bachelor of Business Administration in Information Security and Assurance program. He is the operations man- ager of the KSU Center for Information Security Education and Awareness (infosec.kennesaw.edu) as well as the coordinator for the KSU certificate in Information Security and Assurance. During his career as an IT practitioner, Dr. Mattord has been an adjunct professor at: Kennesaw State Uni- versity; Southern Polytechnic State University in Marietta, Georgia; Austin Community College in Austin, Texas; and Texas State University: San Marcos. He currently teaches undergraduate courses in information security, data communications, local area networks, database technology, project management, systems analysis and design, and information resources management and policy. He

Preface xvii

was formerly the manager of corporate information technology security at Georgia-Pacific Corpora- tion, where much of the practical knowledge found in this textbook was acquired. Professor Mat- tord is also the coauthor of Principles of Information Security, 4th edition; Management of Informa- tion Security, 4th edition; Readings and Cases in the Management of Information Security; Readings and Cases in Information Security: Law and Ethics; The Hands-On Information Security Lab Man- ual, 3rd edition; Roadmap to the Management of Information Security for IT and Information Security Professionals; Guide to Firewalls and VPNs, 3rd edition; Guide to Firewalls and Network Security, 2nd edition; and Guide to Network Security, all published by Course Technology.

Andrew Green, MSIS Andrew Green is a lecturer of information security and assurance in the Informa- tion Systems Department, Michael J. Coles College of Business at Kennesaw State University, Kennesaw, Georgia. Mr. Green has over a decade of experience in information security. Prior to entering academia full time, he worked as an information security consultant, focusing primarily on the needs of small and medium-sized businesses. Prior to that, he worked in the healthcare IT field, where he developed and supported transcription interfaces for medical facilities throughout the United States. Mr. Green is also a full-time Ph.D. student at Nova Southeastern University, where he is studying information systems with a concentration in information security. He is the coauthor of Guide to Firewalls and VPNs, 3rd edition and Guide to Network Security, both published by Course Technology.

Structure The textbook is organized into 12 chapters and 3 appendices. Here are summaries of each chapter’s contents:

Chapter 1. An Overview of Information Security and Risk Management This chapter defines the concepts of information security and risk management and explains how they are integral to the management processes used for incident response and contingency planning.

Chapter 2. Planning for Organizational Readiness The focus of this chapter is on how an organiza- tion can plan for and develop organizational processes and staffing appointments needed for suc- cessful incident response and contingency plans.

Chapter 3. Contingency Strategies for IR/DR/BC This chapter explores the relationships between contingency planning and the subordinate elements of incident response, business resumption, disas- ter recovery, and business continuity planning. It also explains the techniques used for data and application backup and recovery.

Chapter 4. Incident Response: Planning This chapter expands on the incident response planning process to include processes and activities that are needed as well as the skills and techniques used to develop such plans.

Chapter 5. Incident Response: Detection and Decision Making This chapter describes how incidents are detected and how decision making regarding incident escalation and plan activation occur.

Chapter 6. Incident Response: Organizing and Preparing the CSIRT This chapter presents the details of the actions that the CSIRT performs and how they are designed and developed.

Chapter 7. Incident Response: Response Strategies This chapter describes IR reaction strategies and how they are applied to incidents.

xviii Preface

Chapter 8. Incident Response: Recovery and Maintenance This chapter describes how an organiza- tion plans for and executes the recovery process when an incident occurs; it also expands on the steps involved in the ongoing maintenance of the IR plan.

Chapter 9. Disaster Recovery: Preparation and Implementation This chapter explores how organi- zations prepare for disasters and recovery from disasters.

Chapter 10. Disaster Recovery: Operation and Maintenance This chapter presents the challenges an organization faces when engaged in DR operations and how such challenges are met.

Chapter 11. Business Continuity Planning This chapter covers how organizations ensure continu- ous operations even when the primary facilities used by the organization are not available.

Chapter 12. Crisis Management and International Standards in IR/DR/BC This chapter covers the role of crisis management and recommends the elements of a plan to prepare for crisis response. The chapter also covers the key international standards that affect IR, DR, and BC.

Appendices. The three appendices present sample BC and crisis management plans and templates.

Text and Graphic Conventions Wherever appropriate, additional information and exercises have been added to this book to help you better understand what is being discussed in the chapter. Icons throughout the text alert you to additional materials. The icons used in this textbook are described here:

Notes present additional helpful material related to the subject being described.

Offline boxes offer material that expands on the chapter’s contents but that may not be central to the learning objectives of the chapter.

Technical Details boxes provide additional technical information on informa- tion security topics.

Real World Exercises are structured activities to allow students to enrich their understanding of selected topics presented in the chapter by exploring Web- based or other widely available resources.

Hands-On Projects offer students the chance to explore the technical aspects of the theories presented in the chapter.

Preface xix

Instructor’s Materials The following supplemental materials are available for use in a classroom setting. All the supple- ments available with this book are provided to the instructor on a single CD-ROM (ISBN: 9781111138066) and online at the textbook’s Web site.

Please visit login.cengage.com and log in to access instructor-specific resources.

To access additional course materials, please visit www.cengagebrain.com. At the CengageBrain.com home page, search for the ISBN of your title (from the back cover of your book) using the search box at the top of the page. This will take you to the product page, where these resources can be found.

Additional materials designed especially for you might be available for your course online. Go to www.cengage.com/coursetechnology and search for this book title periodically for more details.

Electronic Instructor’s Manual—The Instructor’s Manual that accompanies this textbook includes additional instructional material to assist in class preparation, including suggestions for classroom activities, discussion topics, and additional projects.

Solution Files—The Solution Files include answers to selected end-of-chapter materials, including the Review Questions and some of the Hands-On Projects.

ExamView—This textbook is accompanied by ExamView, a powerful testing software package that allows instructors to create and administer printed, computer (LAN-based), and Internet exams. ExamView includes hundreds of questions that correspond to the topics covered in this text, enabling students to generate detailed study guides that include page references for further review. The computer-based and Internet testing components allow students to take exams at their compu- ters, and also save the instructor time by grading each exam automatically.

PowerPoint Presentations—This book comes with Microsoft PowerPoint slides for each chapter. These are included as a teaching aid for classroom presentation. They can also be made available to students on the network for chapter review, or they can be printed for classroom distribution. Instruc- tors, feel free to add your own slides for additional topics you introduce to the class.

Information Security Community Site—Stay Secure with the Information Security Community Site! Connect with students, professors, and professionals from around the world, and stay on top of this ever-changing field.

● Visit www.cengage.com/community/infosec. ● Download resources such as instructional videos and labs. ● Ask authors, professors, and students the questions that are on your mind in our Discussion

Forums. ● See up-to-date news, videos, and articles. ● Read author blogs. ● Listen to podcasts on the latest Information Security topics.

Acknowledgments The authors would like to thank their families for their support and understanding for the many hours dedicated to this project, hours taken in many cases from family activities. Special thanks to Karen Scarfone, coauthor of several NIST SPs. Her reviews and suggestions resulted in a more read- able manuscript. Additionally, the authors would like to thank Doug Burks, primary developer of

xx Preface

the Security Onion project used in this textbook. Doug’s insight and suggestions for the Hands-On Projects helped make them more robust and practical for students to use.

Reviewers We are indebted to the following individuals for their respective contributions of perceptive feed- back on the initial proposal, the project outline, and the individual chapters of the text:

Karen Scarfone, Scarfone Cybersecurity Gary Kessler, Embry-Riddle Aeronautical University

Special Thanks The authors wish to thank the editorial and production teams at Course Technology. Their diligent and professional efforts greatly enhanced the final product:

Michelle Ruelos Cannistraci, Senior Product Manager

Kent Williams, Developmental Editor

Nick Lombardi, Acquisitions Editor

Andrea Majot, Senior Content Project Manager

Nicole Ashton Spoto, Technical Editor

In addition, several professional and commercial organizations and individuals have aided the development of the textbook by providing information and inspiration, and the authors wish to acknowledge their contribution:

Bernstein Crisis Management

Continuity Central

Information Systems Security Associations

Institute for Crisis Management

National Institute of Standards and Technology

Oracle, Inc.

Purdue University

Rothstein Associates, Inc.

SunGard

Our colleagues in the Department of Information Systems and the Michael J. Coles College of Business, Kennesaw State University

Dr. Amy Woszczynski, Interim Chair of the Department of Information Systems, Michael J. Coles College of Business, Kennesaw State University

Dr. Kathy Schwaig, Dean of the Michael J. Coles College of Business, Kennesaw State University

Our Commitment The authors are committed to serving the needs of the adopters and readers. We would be pleased and honored to receive feedback on the textbook and its supporting materials. You can contact us through Course Technology.

Preface xxi

chapter1

An Overview of Information Security and Risk Management

An ounce of prevention is worth a pound of cure. —Benjamin Franklin

Upon completion of this material, you should be able to: ● Define and explain information security ● Identify and explain the basic concepts of risk management ● List and discuss the components of contingency planning ● Describe the role of information security policy in the development of contingency plans

Introduction This book is about being prepared for the unexpected, being ready for such events as incidents and disasters. We call this contingency planning, and the sad fact is that most organizations don’t incorporate it into their day-to-day business activities. Such organi- zations are often not well prepared to offer the proper response to a disaster or security incident. By July 2012, Internet World Stats estimated that there were over 2.4 billion people online,1 representing one third of the world’s 6.9 billion population. Each one of those online users is a potential threat to any online system. The vast majority of Inter- net users will not intentionally probe, monitor, attack, or attempt to access an organiza- tion’s information without authorization; however, that potential does exist. If even less than 1/10 of 1 percent of online users make the effort, the result would be almost two and a half million potential attackers.

Paul Alexander and his boss Amanda Wilson were sitting in Amanda’s office discussing the coming year’s budget when they heard a commotion in the hall. Hearing his name mentioned, Paul stuck his head out the door and saw Jonathon Jasper (“JJ” to his friends) walking quickly toward him.

“Paul!” JJ called again, relieved to see Paul waiting in Amanda’s office. “Hi, Amanda,” JJ said, then, looking at Paul, he added, “We have a problem.” JJ was

one of the systems administrators at Hierarchical Access LTD (HAL), a Georgia-based Internet service provider that serves the northwest region of metropolitan Atlanta.

Paul stepped out into the hall, closing Amanda’s door behind him. “What’s up, JJ?” “I think we’ve got someone sniffing around the e-mail server,” JJ replied. “I just

looked at the log files, and there is an unusual number of failed login attempts on accounts that normally just don’t have that many, like yours!”

Paul paused a moment. “But the e-mail server’s proxied,” he finally said to JJ, “which means it must be an

internal probe.” “Yeah, that’s why it’s a problem,” JJ replied. “We haven’t gotten this kind of thing

since we installed the proxy and moved the Web and e-mail servers inside the DMZ. It’s got to be someone in-house.”

JJ looked exasperated. “And after all that time I spent conducting awareness training!” “Don’t worry just yet,” Paul told him. “Let’s make a few calls, and then we’ll go

from there. Grab your incident response book and meet me in the conference room in 10 minutes. Grab Tina in network operations on the way.”

Opening Case Scenario: Pernicious Proxy Probing

2 Chapter 1 An Overview of Information Security and Risk Management

1 In the weeks that followed the September 11, 2001 attacks in New York, Pennsylvania, and Washington D.C., the media reported on the disastrous losses that various organizations were suffering. Still, many organizations were able to continue conducting business. Why? The reason is that those organizations were prepared for unexpected events. The cataclysm in 2001 was not the first attack on the World Trade Center (WTC). On February 26, 1993, a car bomb exploded beneath one of the WTC towers, killing 6 and injuring over 1000. The attack was limited in its devastation only because the attackers weren’t able to acquire all the components for a coordinated bomb and cyanide gas attack.2

Still, this attack was a wake-up call for the hundreds of organizations that conducted business in the WTC. Many began asking the question, “What would we have done if the attack had been more successful?” As a direct result, many of the organizations occupying the WTC on September 11, 2001 had developed contingency plans. Although thousands of people lost their lives in the attack, many were able to evacuate, and many organizations were prepared to resume their businesses in the aftermath of the devastation.

A 2008 Gartner report found that two out of three organizations surveyed had to invoke their disaster recovery or business continuity plans in the two years preceding the study.3 Consider- ing that nearly 80 percent of businesses affected by a disaster either never reopen or close within 18 months of the event, having a disaster recovery and business continuity plan is vital to sustaining operations when disasters strike.4 Considering the risks, it is imperative that management teams create, implement, and test effective plans to deal with incidents and disasters. For this reason, the field of information security has been steadily growing and is taken seriously by more and more organizations, not only in the United States but throughout the world.

Before we can discuss contingency planning in detail, we must introduce some critical con- cepts of which contingency planning is an integral part. The first of these, which serves as the overall disciplinary umbrella, is information security. This refers to many interlinked programs and activities that work together to ensure the confidentiality, integrity, and availability of the information used by organizations. This includes steps to ensure the protection of organiza- tional information systems, specifically during incidents and disasters. Because information security is a complex subject, which includes risk management as well as information security policy, it is important to have an overview of that broad field and an understanding of these major components. Contingency planning is an important element of information security, but before management can plan for contingencies, it should have an overall strategic plan for information security in place, including risk management processes to guide the appropriate managerial and technical controls. This chapter serves as an overview of information security, with special consideration given to risk management and the role that contingency planning plays in (1) information security in general and (2) risk management in particular.

Information Security The Committee on National Security Systems (CNSS) has defined information security as the protection of information and its critical elements, including the systems and hard- ware that use, store, and transmit that information. This definition is part of the CNSS model (see Figure 1-1), which serves as the conceptual framework for understanding information security. The model evolved from a similar model developed within the

Information Security 3

computer security industry, known as the C.I.A. triangle. An industry standard for com- puter security since the development of the mainframe, the C.I.A. triangle illustrates the three most critical characteristics of information used within information systems: confi- dentiality, integrity, and availability.

Information assets have the characteristics of confidentiality when only those persons or com- puter systems with the rights and privileges to access it are able to do so. Information assets have integrity when they are not exposed (while being stored, processed, or transmitted) to corruption, damage, destruction, or other disruption of their authentic states; in other words, the information is whole, complete, and uncorrupted. Finally, information assets have availability when authorized users—persons or computer systems—are able to access them in the specified format without interference or obstruction. In other words, the information is there when it is needed, from where it is supposed to be, and in the format expected.

In summary, information security (InfoSec) is the protection of the confidentiality, integrity, and availability of information, whether in storage, during processing, or in transmission. Such protection is achieved through the application of policy, education and training, and technology.

Key Information Security Concepts In general, a threat is an object, person, or other entity that is a potential risk of loss to an asset, which is the organizational resource being protected. An asset can be logical, such as a Web site, information, or data, or it can be physical, such as a person, com- puter system, or other tangible object. A threat can become the basis for an attack—an intentional or unintentional attempt to cause damage to or otherwise compromise the information or the systems that support it. A threat-agent is a specific and identifiable instance of a general threat that exploits vulnerabilities set up to protect the asset. NIST defines a vulnerability as “a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or violation of the system’s secu- rity policy.”5 Vulnerabilities that have been examined, documented, and published are referred to as well-known vulnerabilities. Some vulnerabilities are latent and thus not revealed until they are discovered and made known.

Po lic

y E du

ca tio

n T ec

hn olo

gy Confidentiality

Integrity

Availability

Polic y Edu

catio n Te

chno logy

Storage Processing Transmission

Confidentiality

Integrity

Availability

Storage Processing Transmission © Cengage Learning 2014

Figure 1-1 The CNSS security model

4 Chapter 1 An Overview of Information Security and Risk Management

1 There are two common uses of the term exploit in information security. First, threat-agents are said to exploit a system or information asset by using it illegally for their personal gains. Second, threat-agents can create an exploit, or means to target a specific vulnerabil- ity, usually found in software, to formulate an attack. A defender tries to prevent attacks by applying a control, a safeguard, or a countermeasure; these terms, all synonymous with control, represent security mechanisms, policies, or procedures that can successfully counter attacks, reduce risk, resolve vulnerabilities, and generally improve the security within an organization.

The results of a 2012 study that collected, categorized, and ranked the identifiable threats to information security are shown in Table 1-1. The study compared its findings with a prior study conducted by one of its researchers.

The threat categories shown in Table 1-1 are explained in detail in the following sections.

Trespass Trespass is a broad category of electronic and human activities that can breach the confidentiality of information. When an unauthorized individual gains access to the information an organization is trying to protect, that act is categorized as a deliber- ate act of trespass. In the opening scenario of this chapter, the IT staff members at HAL were more disappointed than surprised to find someone poking around their mail server, looking for a way in. Acts of trespass can lead to unauthorized real or virtual actions that enable information gatherers to enter premises or systems they have not been autho- rized to enter.

Threat Category 2010 Ranking Prior Ranking

Espionage or trespass 1 4

Software attacks 2 1

Human error or failure 3 3

Theft 4 7

Compromises to intellectual property 5 9

Sabotage or vandalism 6 5

Technical software failures or errors 7 2

Technical hardware failures or errors 8 6

Forces of nature 9 8

Deviations in quality of service from service providers 10 10

Technological obsolescence 11 11

Information extortion 12 12

Table 1-1 Threats to information security6 Source: 2003 Study © Communications of the ACM used with permission

Information Security 5

The classic perpetrator of deliberate acts of espionage or trespass is the hacker. In this text, hackers are people who bypass legitimate controls placed on information systems in order to gain access to data or information against the intent of the owner. More specifically, a hacker is someone who uses skill, guile, or fraud to attempt to bypass the controls placed around information that belongs to someone else.

Software Attacks Deliberate software attacks occur when an individual or group designs software to attack a system. This software is referred to as malicious code, mali- cious software, or malware. These software components or programs are designed to damage, destroy, or deny service to the target systems. Some of the more common instances of malicious code are viruses and worms, Trojan horses, logic bombs, bots, rootkits, and back doors. Equally prominent among the recent incidences of malicious code are the denial-of-service attacks conducted by attackers on popular e-commerce sites. A denial-of-service (DoS) attack seeks to deny legitimate users access to services by either tying up a server’s available resources or causing it to shut down. A variation on the DoS attack is the distributed DoS (DDoS) attack, in which an attacker compro- mises a number of systems, then uses these systems (called zombies or bots) to attack an unsuspecting target.

A potential source of confusion when it comes to threats posed by malicious code are the differences between the method of propagation (worm versus virus), the payload (what the malware does once it is in place, such as deny service or install a back door), and the vector of infection (how the code is transmitted from system to system, whether through social engineering or by technical means, such as an open network share). Various concepts related to the topic of malicious code are discussed in the following sections.

Viruses Computer viruses are segments of code that perform malicious actions. The code attaches itself to an existing program and takes control of that program’s access to the targeted computer. The virus-controlled target program then carries out the virus’s plan by replicating itself and inserting itself into additional targeted systems.

Opening an infected e-mail or some other seemingly trivial action can cause anything from random messages popping up on a user’s screen to the destruction of entire hard drives of data. Viruses are passed from machine to machine via physical media, e-mail, or other forms of computer data transmission. When these viruses infect a machine, they may immedi- ately scan the local machine for e-mail applications; they may even send themselves to every user in the e-mail address book.

There are several types of viruses. One type is the macro virus, which is embedded in auto- matically executing macrocode, common in word-processed documents, spreadsheets, and database applications. Another type, the boot virus, infects the key operating systems files located in a computer’s boot sector.

Worms Named for the tapeworm in John Brunner’s novel The Shockwave Rider, worms are malicious programs that replicate themselves constantly without requiring another pro- gram to provide a safe environment for replication. Worms can continue replicating them- selves until they completely fill available resources, such as memory, hard drive space, and

6 Chapter 1 An Overview of Information Security and Risk Management

1 network bandwidth. These complex behaviors can be invoked with or without the user downloading or executing the file. Once the worm has infected a computer, it can redis- tribute itself to all e-mail addresses found on the infected system. Further, a worm can deposit copies of itself onto all Web servers that the infected system can reach, so that users who subsequently visit those sites become infected themselves. Worms also take advantage of open shares found on the network in which an infected system is located, placing working copies of the worm code onto the server so that users of those shares are likely to become infected.

Back Doors and Trap Doors A virus or worm can have a payload that installs a back door or trap door component in a system, which allows the attacker to access a system, at will, with special privileges. Examples of these kinds of payloads are SubSeven, Back Orifice, and Flashfake.

Polymorphism One of the biggest ongoing problems in fighting viruses and worms are polymorphic threats. A polymorphic threat is one that changes its apparent shape over time, making it undetectable by techniques that look for preconfigured signatures. These viruses and worms actually evolve, changing their size and appearance to elude detection by antivi- rus software programs. This means that an e-mail generated by the virus may not match previous examples, making detection more of a challenge.

Propagation Vectors The way that malicious code is spread from one system to another can vary widely. One common way is through a social engineering attack—that is, getting the computer user to perform an action that enables the infection. An example of this is the Trojan horse, often simply called a Trojan. A Trojan is something that looks like a desirable program or tool but is in fact a malicious entity. Other propagation vectors do not require human interaction, leveraging open network connections, file shares, or software vulnerabil- ities to spread themselves.

Malware Hoaxes As frustrating as viruses and worms are, perhaps more time and money is spent on resolving malware hoaxes. Well-meaning people can disrupt the harmony and flow of an organization when they send random e-mails warning of dangerous malware that is fictitious. While these individuals feel they are helping out by warning their coworkers of a threat, much time and energy is wasted as everyone forwards the message to everyone they know, posts the message on social media sites, and begins updating antivirus protection software. By teaching its employees how to verify whether a malware threat is real, the organization can reduce the impact of this type of threat.

Human Error or Failure This threat category includes acts performed by an authorized user, usually without malicious intent or purpose. When people use information systems, mistakes sometimes happen as a result of inexperience, improper training, incorrect assumptions, and so forth. Unfortunately, small mistakes can produce extensive damage with catastrophic results. This is what is meant by human error. Human failure, on the other hand, is the intentional refusal or unintentional inability to comply with policies, guidelines, and procedures, with a potential loss of information. An organization may be

Information Security 7

doing its part to protect information, but if an individual employee fails to follow estab- lished protocols, information can still be put at risk.

Theft The threat of theft—the illegal taking of another’s property—is a constant prob- lem. Within an organization, property can be physical, electronic, or intellectual. The value of information assets suffer when they are copied and taken away without the own- er’s knowledge. This threat category also includes acts of espionage, given that an attacker is often looking for information to steal. Any breach of confidentiality can be construed as an act of theft.

Attackers can use many different methods to access the information stored in an information system. Some information gathering is quite legal—for example, when doing research. Such techniques are collectively referred to as competitive intelligence. When information gathering employs techniques that cross the threshold of what is considered legal or ethical, it becomes known as industrial espionage.

Also of concern in this category is the theft or loss of mobile devices, including phones, tablets, and computers. Although the devices themselves are of value, perhaps even more valu- able is the information stored within. Users who have been issued company equipment may establish (and save) VPN-connection information, passwords, access credentials, company records, customer information, and the like. This valuable information becomes a target for information thieves. In fact, it has become commonplace to find lost or stolen devices in the trash, with the hard drives or data cards (like phone SIMs) removed or the data having been copied and erased The information is more valuable and easier to conceal than the actual device itself.

Users who travel or use their devices away from home should be extremely careful when leav- ing the device unattended at a restaurant table, conference room, or hotel room. Actually, most globally engaged organizations now have explicit policy directives that prohibit taking these portable devices to certain countries and direct employees required to travel to take sanitized, almost disposable, devices that are not allowed contact with internal company net- works or technology.

Compromises to Intellectual Property Many organizations create or support the development of intellectual property as part of their business operations. FOLDOC, an online dictionary of computing, defines intellectual property (IP) this way:

The ownership of ideas and control over the tangible or virtual representation of those ideas. Use of another person’s intellectual property may or may not involve royalty payments or permission but should always include proper credit to the source.7

Source: FOLDOC

IP includes trade secrets, copyrights, trademarks, and patents, all of which employees use to conduct day-to-day business. Once an organization has properly identified its IP, breaches in the controls placed to control access to it constitute a threat to the security of this information.

Often, an organization purchases or leases the IP of other organizations and must therefore abide by the purchase or licensing agreement for its fair and responsible use.

8 Chapter 1 An Overview of Information Security and Risk Management

1 Of equal concern is the exfiltration, or unauthorized removal of information, from an organization. Most commonly associated with disgruntled employees, the protection of intellectual property from unauthorized disclosure to third parties further illustrates the severity of this issue. Theft of organizational IP, such as trade secrets or trusted informa- tion like customer personal and financial records, is a commonplace issue. Data exfiltration is also being made tougher to combat because of the increasing popularity of “bring your own device” (or BYOD) systems, which allow employees to attach their own personal devices to the corporate network. These devices are frequently not as secure as the systems owned and maintained by the organization. If compromised by attackers prior to attaching to the corporate network, BYOD systems can easily be used as conduits to allow data to be exfiltrated. Additionally, unhappy employees can use these devices to copy data, then leave the organization with that valuable asset in their hands and no one the wiser.

Among the most common IP breaches is the unlawful use or duplication of software-based intellectual property, more commonly known as software piracy. Because most software is licensed to a particular purchaser, its use is restricted to a single user or to a designated user in an organization. If the user copies the program to another computer without securing another license or transferring the license, he or she has violated the copyright. Software licenses are strictly enforced by a number of regulatory and private organizations, and soft- ware publishers use several control mechanisms to prevent copyright infringement. In addition to the laws surrounding software piracy, two watchdog organizations investigate allegations of software abuse: the Software & Information Industry Association (SIIA), the Web site for which can be found at www.siia.net, and the Business Software Alliance (BSA), which can be found at www.bsa.org.

Sabotage or Vandalism This threat category involves the deliberate sabotage of a computer system or business or acts of vandalism to either destroy an asset or damage an organization’s image. The acts can range from petty vandalism by employees to organized sabotage by outsiders. A frequently encountered threat is the assault on an organization’s electronic profile—its Web site.

A much more sinister form of hacking is cyberterrorism. Cyberterrorists hack systems to conduct terrorist activities through network or Internet pathways. The United States and other governments are developing security measures intended to protect the critical computing and communications networks as well as the physical and power utility infrastructures.

Technical Software Failures or Errors This threat category stems from purchasing software with unknown hidden faults. Large quantities of computer code are written, pub- lished, and sold before all the significant security-related bugs are detected and resolved. Also, combinations of particular software and hardware may reveal new bugs. While most bugs are not a security threat, some may be exploitable and may result in potential loss or damage to information used by those programs. In addition to bugs, there may be untested failure conditions or purposeful subversions of the security controls built into systems. These may be oversights or intentional shortcuts left by programmers for benign or malign rea- sons. Collectively, shortcut access routes into programs that bypass security checks are called trap doors; they can cause serious security breaches.

Information Security 9

Software bugs are so commonplace that entire Web sites are dedicated to documenting them—for example, Bugtraq (www.securityfocus.com) and the National Vulnerability Data- base (http://nvd.nist.gov). These resources provide up-to-the-minute information on the latest security vulnerabilities and a very thorough archive of past bugs.

Technical Hardware Failures or Errors Technical hardware failures or errors occur when a manufacturer distributes equipment containing a known or unknown flaw. These defects can cause the system to perform outside of expected parameters, resulting in unreliable service or lack of availability. Some errors are terminal, in that they result in the unrecoverable loss of the equipment. Some errors are intermittent, in that they only periodi- cally manifest themselves, resulting in faults that are not easily identified. For example, equipment can sometimes stop working or can work in unexpected ways. Murphy’s Law says that if something can possibly go wrong, it will. In other words, it’s not whether some- thing will fail but when.

Forces of Nature Forces of nature, also known as force majeure, or acts of God, pose some of the most dangerous threats imaginable because they often occur with very little warn- ing. Fire, flood, earthquake, lightning, volcanic eruptions, even animal or insect infestation— these threats disrupt not only the lives of individuals but also the storage, transmission, and use of information.

Deviations in Quality of Service by Service Providers This threat category covers situations in which a product or service is not delivered to the organization as expected. Utility companies, service providers, and other value-added organizations form a vast web of interconnected services. An organization’s information system depends on the successful operation of such interdependent support systems, including power grids, telecom networks, parts suppliers, service vendors, and even the janitorial staff and garbage haulers. Any one of these support systems can be interrupted by storms, employee illnesses, or other unforeseen events.

An example of this threat category occurs when a construction crew damages a fiber-optic link for an ISP. The backup provider may be online and in service but may only be able to supply a fraction of the bandwidth the organization needs for full service. This degradation of service is a form of availability disruption. Internet service, communications, and power irregularities can dramatically affect the availability of information and systems.

Technological Obsolescence This threat category involves antiquated or outdated infrastructure that leads to unreliable and untrustworthy systems. Management must recog- nize that when technology becomes outdated, there is a risk of a loss of data integrity from attacks. Strategic planning should always include an analysis of the technology that is currently in use. Ideally, proper planning will prevent the risks stemming from technology obsolesce, but when obsolescence is identified, management must take immediate action. IT professionals play a large role in the identification of obsolescence.

Information Extortion The threat of information extortion is the possibility that an attacker or trusted insider will steal information from a computer system and demand compensation for its return or for an agreement to not disclose the information. Extortion

10 Chapter 1 An Overview of Information Security and Risk Management

1 is common in credit card number theft. Unfortunately, organized crime is increasingly involved in this area.

Other Threats Listings The Computer Security Institute conducts an annual study of computer crime, the results for which are shown in Table 1-2. Malware attacks continue to cause the most financial loss, and malware continues to be the most frequently cited attack (with a reported loss of over $42 million in 2009 alone). Nearly 70 percent of respondents noted that they had experienced one or more malware attacks in the 12-month reporting period—and that doesn’t include companies that are unwilling to report attacks. The fact is, almost every company has been attacked. Whether or not that attack was successful depends on the company’s security efforts.

Type of Attack or Misuse 2010/11 2008 2006 2004 2002 2000

Malware infection (revised after 2008) 67% 50% 65% 78% 85% 85%

Being fraudulently represented as sender of phishing message

39% 31% (new category)

Laptop/mobile hardware theft/loss 34% 42% 47% 49% 55% 60%

Bots/zombies in organization 29% 20% (new category

Insider abuse of Internet access or e-mail 25% 44% 42% 59% 78% 79%

Denial of service 17% 21% 25% 39% 40% 27%

Unauthorized access or privilege escalation by insider

13% 15% (revised category)

Password sniffing 11% 9% (new category)

System penetration by outsider 11% (revised category)

Exploit of client Web browser 10% (new category)

Other Attacks/Misuse categories with less than 10% responses not listed above include (listed in decreasing order of occurrence/reporting):

Financial fraud

Web site defacement

Exploit of wireless network

Other exploit of public-facing Web site

Theft of or unauthorized access to PII or PHI due to all other causes

Instant Messaging misuse

Theft of or unauthorized access to IP due to all other causes

Exploit of user’s social network profile

Theft of or unauthorized access to IP due to mobile device theft/loss

Theft of or unauthorized access to PII or PHI due to mobile device theft/loss

Exploit of DNS Server

Extortion or blackmail associated with threat of attack or release of stolen data

Table 1-2 Top Ten CSI/FBI survey results for types of attack or misuse (2000-2011)8 Source CSI/FBI surveys 2000 to 2010/11 (www.gocsi.com)

Information Security 11

Overview of Risk Management One part of information security is risk management, which is the process of identifying and controlling the risks to an organization’s information assets. All managers are expected to play a role in the risk management process, but information security managers are expected to play the largest roles. Very often, the chief information officer (CIO) will delegate much of the responsibility for risk management to the chief information security officer (CISO).

Given that contingency planning is considered part of the risk management process, it is important to fully understand how risk management works and how contingency planning fits within that process. Risk management consists of two major undertakings: risk identifica- tion and risk control. Risk identification is the process of examining, documenting, and asses- sing the security posture of an organization’s information technology and the risks it faces. Risk control is the process of applying controls to reduce the risks to an organization’s data and information systems. The various components of risk management and their relationships to one another are shown in Figure 1-2.

As an aspiring information security professional, you will have a key role to play in risk management. As part of the management team within an organization’s management, you may find yourself on the team that must structure the IT and information security func- tions to perform a successful defense of the organization’s information assets—the infor- mation and data, hardware, software, procedures, and people. The IT community must serve the information technology needs of the broader organization and, at the same

Inventorying assets

Classifying assets

Identifying threats & vulnerabilities

Risk controlRisk identification

Selecting strategy

Justifying controls

Risk assessment is the documented result of

the risk identification process.

Risk management

Figure 1-2 Components of risk management

12 Chapter 1 An Overview of Information Security and Risk Management

1 time, leverage the special skills and insights of the information security community. The information security team must lead the way with skill, professionalism, and flexibility as it works with the other communities of interest to appropriately balance the usefulness and security of the information system.

Looked at another way, risk management is the process of identifying vulnerabilities in an organization’s information systems and taking carefully reasoned steps to ensure the confi- dentiality, integrity, and availability of all the components of the organization’s information system. Each of the three elements in the C.I.A. triangle is an essential part of an organiza- tion’s ability to sustain long-term competitiveness. When the organization depends on IT- based systems to remain viable, information security and the discipline of risk management move beyond theoretical discussions and become an integral part of the economic basis for making business decisions. These decisions are based on trade-offs between the costs of apply- ing information systems controls and the benefits realized from the operation of secured, avail- able systems.

An observation made over 2400 years ago by Chinese General Sun Tzu is relevant to informa- tion security today:

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.9

Source: Oxford University Press

Consider for a moment the similarities between information security and warfare. Information security managers and technicians are the defenders of information. The many threats mentioned earlier are constantly attacking the defenses surrounding information assets. Defenses are built in layers, by placing safeguard upon safeguard. You attempt to detect, prevent, and recover from attack after attack after attack. Moreover, organizations are legally prevented from switching to offense, and the attackers themselves have no need to expend their resources on defense. To be victorious, you must therefore know yourself and know the enemy.

Know Yourself First, you must identify, examine, and understand the information and systems currently in place within your organization. To protect assets, which are defined here as informa- tion and the systems that use, store, and transmit information, you must understand what they are, how they add value to the organization, and to which vulnerabilities they are susceptible. Once you know what you have, you can identify what you are already doing to protect it. Just because you have a control in place to protect an asset does not necessarily mean that the asset is protected. Frequently, organizations implement control mechanisms but then neglect to periodically perform the necessary review, revision, and maintenance of their own systems. The policies, education and training programs, and technologies that protect information must be carefully maintained and administered to ensure that they are still effective.

Overview of Risk Management 13

Know the Enemy Once you are informed of your organization’s assets and weaknesses, you can move on to the other part of Sun Tzu’s advice: know the enemy. This means identifying, examining, and understanding the threats facing the organization. You must determine those threat aspects that most directly affect the organization and the security of the organization’s information assets. You can then use your understanding of these aspects to create a list of threats priori- tized by how important each asset is to the organization.

It is essential that all stakeholders conduct periodic management reviews. The first focus of management review is asset inventory. On a regular basis, management must verify the completeness and accuracy of the asset inventory. In addition, organizations must review and verify the threats and vulnerabilities that have been identified as dangerous to the asset inventory, as well as the current controls and mitigation strategies. The cost effectiveness of each control should be reviewed as well and the decisions on deployment of controls revi- sited. Furthermore, managers at all levels must regularly verify the ongoing effectiveness of every control that’s been deployed. For example, a sales manager might assess control proce- dures by going through the office before the workday starts and picking up all the papers from every desk in the sales department. When the workers show up, the manager could inform them that a fire drill is underway—that all their papers have been destroyed and that each worker must now follow the disaster recovery procedures. The effectiveness of the pro- cedures can then be assessed and corrections made.

Risk Identification A risk management strategy calls on information security professionals to identify, classify, and prioritize the organization’s information assets. Once that has been done, the threat iden- tification process begins. Each information asset is examined to identify vulnerabilities, and when vulnerabilities are found, controls are identified and assessed regarding their capability to limit possible losses should an attack occur. The components of this process are shown in Figure 1-3.

Asset Identification and Value Assessment The iterative process of identifying assets and assessing their value begins with the identification of the elements of an orga- nization’s systems: people, procedures, data/information, software, hardware, and net- works. The assets are then classified and categorized, with details added as the analysis goes deeper.

Information Asset Classification In addition to identifying the assets, it is advisable to classify them with respect to their security needs. For example, data could be classified as confi- dential data, internal data, and public data. Likewise, the individuals authorized to view the data could be classified using a personnel security clearance structure.

No matter how an organization chooses to classify the components of its system, the com- ponents must be specific enough to allow the creation of various priority levels. The com- ponents then can be ranked according to criteria established by the categorization. The categories themselves should be comprehensive and mutually exclusive. Comprehensive means that all the information assets should fit in the list somewhere; mutually exclusive means that each information asset should fit in only one category. For example, when

14 Chapter 1 An Overview of Information Security and Risk Management

using a purely technical standard to classify a certificate authority used in a PKI system, an analysis team could categorize the certificate authority in the asset list as software but within the software category as either an application or a security component. It is a mat- ter of professional judgment. To add consistency and simplify the categorization of ele- ments when there is ambiguity, it is essential to establish a clear and comprehensive set of categories.

Information Asset Valuation As each asset is assigned to a category, the following questions should be asked:

● Is this asset the most critical to the organizations’ success? ● Does it generate the most revenue? ● Does it generate the most profit? ● Would it be the most expensive to replace? ● Will it be the most expensive to protect? ● If revealed, would it cause the most embarrassment or greatest damage? Does the law

or other regulation require us to protect this asset?

Risk identification

Risk assessment

Plan and organize the process.

Categorize system components.

Inventory and categorize assets.

Identify threats.

Specify vulnerable assets.

Assign value to attack on assets.

Assess likelihood of attack on

vulnerabilities.

Calculate relative risk factor for assets.

Review possible controls.

Document findings.

Figure 1-3 Components of risk identification

Overview of Risk Management 15

The answers to these questions help determine the weighting criteria used for information asset valuation and information impact evaluation. Before beginning the inventory process, the organization should decide which criteria are best suited to establish the value of the information assets.

In addition to the criteria just listed, company-specific criteria should be identified, documen- ted, and added to the process. To finalize this step of the information asset identification pro- cess, the organization should assign a weight to each asset based on the answers to the vari- ous questions.

Once the process of inventorying and assessing value is complete, you can calculate the rela- tive importance of each asset using a straightforward process known as weighted factor anal- ysis, which is shown in Table 1-3. In this process, each information asset is assigned a score for each critical factor. In the example shown, these scores may range from 0.1 to 1.0 In addition, each criterion is assigned a weight (ranging from 1 to 100) to show its assigned importance for the organization.

Data Classification and Management Corporate and military organizations use a variety of data classification schemes, which are procedures that require organizational data to be classified into mutually exclusive categories based on the need to protect the confidenti- ality of each category of data. For example, at one time Georgia-Pacific, an American pulp and paper company, used a data classification scheme in which information owners through- out the company were expected to classify the information assets for which they were respon- sible. At least once a year, they would review these classifications to ensure that the informa- tion was still classified correctly and the appropriate access controls were in place.

The military has specialized classification ratings ranging from “Public” to “For Official Use Only” to “Confidential“ to “Secret” to “Top Secret.” Most organizations do not need the detailed level of classification used by the military or federal agencies, but most organizations may find it necessary to classify their data to provide protection. A simple classification scheme would allow an organization to protect such sensitive information as its marketing or

Information Asset

Criterion 1: Impact on Revenue

Criterion 2: Impact on Profitability

Criterion 3: Impact on Image

Weighted Score

Criterion Weight (1–100 must total 100) 30 40 30

EDI Document Set 1—Logistics BOL to outsourcer (outbound)

0.8 0.9 0.5 75

EDI Document Set 2—Supplier orders (outbound) 0.8 0.9 0.6 78

EDI Document Set 2—Supplier fulfillment advice (inbound)

0.4 0.5 0.3 41

Customer order via SSL (inbound) 1.0 1.0 1.0 100

Customer service request via e-mail (inbound) 0.4 0.4 0.9 55

Table 1-3 A weighted factor analysis worksheet © Cengage Learning 2014

16 Chapter 1 An Overview of Information Security and Risk Management

1 research data, its personnel data, its customer data, and its general internal communications. Alternatively, a scheme such as the following could be adopted:

● Public—Information for general public dissemination, such as an advertisement or public release

● For Official Use Only—Information that is not particularly sensitive but is not for public release, such as internal communications

● Sensitive—Information important to the business that could embarrass the company or cause loss of market share if revealed

● Classified—Information of the utmost secrecy to the organization, disclosure of which could severely affect the well-being of the organization

As mentioned earlier, personnel can also be classified with respect to information security, resulting in various levels of security clearance. In organizations that require security clear- ances, each user of data is assigned an authorization level that indicates the data he or she is authorized to view. This is usually accomplished by assigning each employee a named role— such as data entry clerk, development programmer, information security analyst, or even CIO—and a security clearance associated with that role. Overriding one’s security clearance, however, is the fundamental principle of need to know. Employees are not simply allowed to view any and all data that falls within their level of clearance. Before someone can access a specific set of data, the need-to-know requirement must be met. This extra level of protection ensures that the confidentiality of information is properly maintained.

Threat Identification After identifying and performing a preliminary classification of an organization’s information assets, the analysis phase moves to an examination of the threats facing the organization. An organization faces a wide variety of threats; the realistic ones need to be investigated further, while the unimportant threats are set aside. Otherwise, the project’s scope can overwhelm the organization’s ability to plan.

Each of the threat categories identified in Table 1-1 must be assessed regarding its potential to endanger the organization. This is known as a threat assessment. Each threat can be assessed using a few basic questions:

● Which threats present a danger to the organization’s assets in the given environment? ● Which threats represent the most danger to the organization’s information? ● Which threats would cost the most to recover from if there was an attack? ● Which threats require the greatest expenditure to prevent?

By answering these questions, you can establish a framework for discussing threat assessment. The list may not cover everything, however. If an organization has specific guidelines or poli- cies, these may require the posing of additional questions. The list is easily expanded to include additional requirements.

Vulnerability Identification Once you have identified the organization’s information assets and documented some criteria for assessing the threats they face, you should review each information asset and each threat it faces to create a list of vulnerabilities. You should then examine how each of the threats could be perpetrated. Finally, you should list the organization’s assets and its vulnerabilities. The list shows all the vulnerabilities of all the

Overview of Risk Management 17

information assets and can be quite long. Some threats manifest themselves in multiple ways, yielding multiple vulnerabilities for that threat. The process of listing vulnerabilities is somewhat subjective and draws on the experience and knowledge of the people creating the list. Therefore, it works best when groups of people with diverse backgrounds work itera- tively in a series of brainstorming sessions. For instance, the team that reviews the vulner- abilities for networking equipment should include the networking specialists, the systems management team that operates the network, the information security risk specialist, and even technically proficient users of the system.

At the end of the risk identification process, you will have a list of all the information assets and their respective vulnerabilities. This list, along with any supporting documentation, is the starting point for the next step, risk assessment.

Risk Assessment Now that you have identified the organization’s information assets and the threats and vul- nerabilities of those assets, it’s time to assess the relative risk for each vulnerability. This is accomplished through a process called risk assessment. Risk assessment assigns a risk rating or score to each information asset. Although this number does not mean anything in absolute terms, it is useful in gauging the relative risk to each vulnerable information asset and facili- tates the development of comparative ratings later in the risk control process. Figure 1-4 shows the factors that go into the risk-rating estimate for each of the vulnerabilities.

The goal at this point is to create a method for evaluating the relative risk of each of the listed vulnerabilities. There are many detailed methods for determining accurate and detailed costs of each of the vulnerabilities. Likewise, there are models that can be used to estimate expenses for the variety of controls that can be used to reduce the risk for each vulnerability. However, it is often more useful to use a simpler risk model (such as the one shown in Figure 1-4) to evaluate the risk for each information asset. The following sections pres- ent the factors used to calculate the relative risk for each vulnerability.

Likelihood The probability that a specific vulnerability within an organization will be successfully attacked is referred to as likelihood.10 In risk assessment, you assign a numeric value to the likelihood of a vulnerability being successfully exploited. A likelihood

Risk is the likelihood of the occurrence of a vulnerability

multiplied by the value of the information asset

minus the percentage of risk mitigated by current controls

plus the uncertainty of current knowledge of the vulnerability.

Figure 1-4 Factors of risk

18 Chapter 1 An Overview of Information Security and Risk Management

1 vulnerability could be assigned a number between 0.1 (for low) and 1.0 (for high), or it could be assigned a number between 1 and 100, but 0 is not used because vulnerabilities with a zero likelihood have been removed from the asset/vulnerability list. Whatever rating system is used, you should bring all your professionalism, experience, and judgment to bear, and you should use the rating model you selected consistently. Whenever possible, use external references for likelihood values that have been reviewed and adjusted for your spe- cific circumstances.

Many asset/vulnerability combinations have sources for determining their likelihoods. For example, the likelihood of a fire has been actuarially estimated for each type of structure (such as a building). Likewise, the likelihood that a given e-mail contains a virus or worm has been researched. Finally, the number of network attacks can be forecast based on how many network addresses the organization has been assigned.

Valuation of Information Assets Using the information obtained during the infor- mation asset identification phases, you can assign weighted scores for the value to the organi- zation of each information asset. The actual numbers used can vary with the needs of the organization. Some groups use a scale of 1 to 100, with “100” reserved for those information assets that, if lost, would cause the company to stop operations within a few minutes. Other scales assign weights in broad categories, assigning all critical assets a value of 100, all low- critical assets a value of 1, and all others a value of 50. Still other groups use a scale of 1 to 10 or assigned values of 1, 3, and 5 to represent low-valued, medium-valued, and high-valued assets. You can also create weight values for your specific needs. To be effective, the values must be assigned by asking the questions described in the “Threat Identification” section.

After re-asking these questions, you should use the background information from the risk identification process to pose one additional question: Which of these questions is most important to the protection of the organization’s information? This helps you set priorities in the assessment of vulnerabilities. Additional questions may also be asked. Again, you are looking at threats the organization faces in its current state; however, this information will be valuable in later stages as you begin to design the security solution. Once these questions are answered, you move to the next step in the process: examining how current controls can reduce the risk faced by specific vulnerabilities.

If a vulnerability is fully managed by an existing control, it no longer needs to be considered for additional controls and can be set aside. If it is partially controlled, you need to estimate what percentage of the vulnerability has been controlled.

It is impossible to know everything about each vulnerability, such as how likely it is to occur or how great an impact a successful attack would have. The degree to which a current control can reduce risk is also subject to estimation error. You must apply judg- ment when adding factors into the equation to allow for an estimation of the uncer- tainty of the information.

Risk Determination For the purpose of making relative risk assessments, we can say that risk equals the likelihood of a vulnerability occurring times the value (or impact) of that asset to the organization minus the percentage of risk that is already being con- trolled plus an element of uncertainty. For example, consider an information asset A that has a value of 50 and one vulnerability with a likelihood of 1.0 and no current controls; furthermore, it’s estimated that the assumptions and data are 90 percent

Overview of Risk Management 19

accurate (that is, there’s a 10 percent uncertainty). Therefore, asset A’s vulnerability is rated as 55, which is derived from the following calculation:

(50 [being the value] × 1.0 [being the likelihood of occurrence]) – 0 percent [being the percent of risk currently controlled] + 10 percent [being the uncertainty of our assumptions]

Or, using just numbers:

55 = (50 × 1.0) – ((50 × 1.0) × 0.0) + ((50 × 1.0) × 0.1)

55 = 50 – 0 + 5

Qualitative Risk Management Now that this formula has been carefully explained, you need to keep in mind that virtually every number used in it has been estimated by someone, somewhere. Insurance companies may have reliable values for physical disasters (fire, floods, etc.), but a different approach may be preferred when considering the substantial portion of an organization’s budget that goes for informa- tion security as well as the budget for IR, DR, and BC planning and preparation. Some organizations prefer more qualitative approaches in which more general categories and ranking are used to evaluate risk. One such approach—the Factor Anal- ysis of Information Risk (FAIR) strategy promoted by CXOWARE, a company focusing on enterprise risk management. (http://riskmanagementinsight.com)—is flexible yet robust.

For each threat and its associated vulnerabilities that have residual risk, you need to create a preliminary list of control ideas. Residual risk is the risk that remains to the information asset even after the existing control has been applied.

Identify Possible Controls Controls, safeguards, and countermeasures are terms used to represent security mechanisms, policies, and procedures that reduce the risk of operating information systems. The three general categories of controls, according to the CNSS model discussed earlier, are policies, programs (education and training), and technologies.

Policies are documents that specify an organization’s approach to security. There are three types of security policies: the enterprise information security policy, issue-specific policies, and systems-specific policies. The enterprise information security policy is an executive-level docu- ment that outlines the organization’s approach and attitude toward information security and relates to the strategic value of information security within the organization. This document, typically created by the CIO in conjunction with the CEO and CISO, sets the tone for all sub- sequent security activities. Issue-specific policies address the specific implementations or appli- cations of which users should be aware. These policies are typically developed to provide detailed instructions and restrictions associated with security issues. Examples include policies for Internet use, e-mail, and access to the building. Finally, systems-specific policies address the particular use of certain systems. This could include firewall configuration policies, systems access policies, and other technical configuration areas.

Programs are activities performed within the organization to improve security. These include security education, training, and awareness programs. Security technologies are implementa- tions of the policies defined by the organization using technology-based mechanisms, such as firewalls or intrusion detection systems.

20 Chapter 1 An Overview of Information Security and Risk Management

1 Risk Control Strategies When management has determined that the risks from information security threats are unac- ceptable, or when laws and regulations mandate such action, they empower the information technology and information security communities of interest to control the risks. Once the project team for information security development has created the ranked vulnerability work- sheet, it must choose one of the following five approaches for controlling the risks that result from the vulnerabilities:

● Defense ● Transferal ● Mitigation ● Acceptance ● Termination

Defense The defense approach attempts to prevent the exploitation of the vulnerability. This is the preferred approach and is accomplished by means of countering threats, remov- ing vulnerabilities in assets, limiting access to assets, and adding protective safeguards. This approach is sometimes referred to as avoidance.

There are three common methods of risk defense: defense through application of policy, defense through application of training and education programs, and defense through applica- tion of technology. The application of policy allows management to mandate that certain pro- cedures are always followed. For example, if the organization needs to control password use more tightly, a policy requiring passwords on all IT systems can be implemented. Note that policy alone may not be enough and that effective management always couples changes in policy with training and education and/or the application of technology. Policy must be com- municated to employees. In addition, new technology often requires training. Awareness, training, and education are essential if employees are to exhibit safe and controlled behavior.

In the real world of information security, technical solutions are usually required to assure that risk is reduced. To continue the earlier example, system administrators may not configure systems to use passwords unless required by policy. Without the policy to mandate the use of passwords, the system administrator may choose not to implement them.

Risks may be avoided by countering the threats facing an asset or by eliminating the exposure of a particular asset. Eliminating the risk posed by a threat is virtually impossible, but it is possible to reduce the risk to an acceptable level. Another method of risk management that falls under the defense category is the implementation of security controls and safeguards to deflect attacks on systems and therefore minimize the probability that an attack will be successful. An organization with an FTP access vulnerability, for example, may choose to implement a control or safeguard for that service, or the organization may choose to eliminate the FTP service to avoid the potential risk.

Transferal The transferal approach attempts to shift the risk to other assets, other pro- cesses, or other organizations. This may be accomplished through rethinking how services are offered, revising deployment models, outsourcing to other organizations, purchasing insurance, or implementing service contracts with providers.

Overview of Risk Management 21

When an organization does not have the correct balance of information security skills, it should consider hiring or making outsourcing arrangements with individuals or firms that provide such expertise. This allows the organization to transfer the risks associated with the management of these complex systems to another organization that has experience in dealing with those risks. A side benefit of specific contract arrangements is that the provider is respon- sible for disaster recovery and, through service-level agreements, can be made responsible for guaranteeing server and Web site availability.

However, outsourcing is not without its own risks. It is up to the owner of the information asset, IT management, and the information security team to ensure that the disaster recovery requirements of the outsourcing contract are sufficient and have been met before they are needed for recovery efforts. If the outsourcer fails to meet the contract terms, the consequences may be far worse than expected.

Mitigation The mitigation approach attempts to reduce the impact caused by the exploitation of vulnerability through planning and preparation. This approach includes contingency planning and its four functional components: the business impact analysis, the incident response plan, the disaster recovery plan, and the business continuity plan. Each of these components of the contingency plan depends on the ability to detect and respond to an attack as quickly as possible and relies on the existence and quality of the other plans. Mitigation begins with the early detection that an attack is in progress and the ability of the organization to respond quickly, efficiently, and effectively. Each of these is described later in this chapter and explored in depth in later chapters of the book.

Acceptance Acceptance is the choice to do nothing to protect an information asset and to accept the outcome of its potential exploitation. This may or may not be a conscious business decision. The only industry-recognized valid use of this strategy occurs when the organization has done the following:

● Determined the level of risk ● Assessed the probability of attack ● Estimated the potential damage that could occur from an attack ● Performed a thorough cost-benefit analysis ● Evaluated controls using each appropriate type of feasibility ● Decided that the particular function, service, information, or asset did not justify the

cost of protection

This control, or rather lack of control, is based on the conclusion that the cost of protecting an asset does not justify the security expenditure. In this case, management may be satisfied with taking its chances and saving the money that would normally be spent on protecting this asset. If every vulnerability identified in the organization is handled through acceptance, it may reflect an organization’s inability to conduct proactive security activities and an apa- thetic approach to security in general.

Termination Like acceptance, termination is based on the organization’s need or choice to leave an asset unprotected. Here, however, the organization does not wish the informa- tion asset to remain at risk and so removes it from the environment that represents risk. Sometimes, the cost of protecting an asset outweighs its value. In other cases, it may be too

22 Chapter 1 An Overview of Information Security and Risk Management

1 difficult or expensive to protect an asset, compared to the value or advantage that asset offers the company. In either case, termination must be a conscious business decision, not simply the abandonment of an asset, which would technically qualify as acceptance.

Contingency Planning and Its Components A key role for all managers is planning. Managers in IT in general and information security in particular usually provide strategic planning for an organization to ensure the continuous availability of information systems. Unfortunately for managers, the probability that some form of damaging event will occur, whether it be from inside or outside, intentional or acci- dental, human or nonhuman, annoying or catastrophic, is very high. Thus, managers from each community of interest within the organization must be ready to act when a successful attack occurs.

There are various types of plans for events of this type, and they all fall under the general def- inition of contingency planning. A contingency plan is used to anticipate, react to, and recover from events that threaten the security of information and information assets in the organiza- tion; it is also used to restore the organization to normal modes of business operations.

Contingency planning (CP) typically involves four subordinate functions:

● Business impact analysis (BIA) ● Incident response planning (IRP) ● Disaster recovery planning (DRP) ● Business continuity planning (BCP)

Each of these is described in the following sections and discussed in greater detail in later chapters. You will notice that contingency planning has many similarities with the risk man- agement process. The contingency plan is a microcosm of risk management activities, and it focuses on the specific steps required to return all information assets to the level at which they were functioning before the incident or disaster. As a result, the planning process closely emulates the process of risk management.

Business Impact Analysis The entire planning process begins with an assessment of the risks associated with these contingencies. The first function in the development of the CP process is the business impact analysis (BIA). A BIA is an investigation and assessment of the impact that various attacks can have on the organization. The BIA takes up where the risk assessment process leaves off. It begins with the prioritized list of threats and vulnerabilities identified in the risk management process and adds critical information. The BIA is a crucial component of the initial planning stages, as it provides detailed scenarios of the potential impact each attack could have on the organization.

Incident Response Plan The actions an organization can, and perhaps should, take while an incident is in progress are defined in a document referred to as the incident response plan (IR plan). An incident is any clearly identified attack on the organization’s information assets that would threaten the

Contingency Planning and Its Components 23

assets’ confidentiality, integrity, or availability. The IR plan deals with identifying, classifying, responding to, and recovering from an incident. It provides answers to questions victims might pose in the midst of an incident, such as “What do I do now?” In this chapter’s opening sce- nario, the IT organization was ready to respond to the events that had alerted JJ to an unusual situation. There, a simple process was used, based on documented procedures that were prepared in advance. Another example would be a systems administrator who notices that someone is copying information from the server without authorization, signaling a violation of policy by a potential hacker or unauthorized employee. What should the administrator do first? Whom should be contacted? What should be documented? The IR plan supplies the answers.

In the event of a serious virus or worm outbreak, the IR plan may be used to assess the likelihood of imminent damage and to inform key decision makers in the various communities of interest (IT, information security, organization management, and users). The IR plan also enables the organization to take coordinated action that is either predefined and specific or ad hoc and reactive. The intruders who, in some instances, cause these incidents, constantly look for new weaknesses in operating systems, network services, and protocols.

According to a report released by the Software Engineering Institute at Carnegie Mellon Univer- sity, “[Intruders] actively develop and use sophisticated programs to rapidly penetrate systems. As a result, intrusions, and the damage they cause, are often achieved in a matter of seconds.”11

Another report released by the Software Engineering Institute states that organizations “will not know what to do in the event of an intrusion if the necessary procedures, roles, and responsibilities have not been defined and exercised in advance.” The absence of such proce- dures, the report adds, can lead to the following:

● Extensive damage to data, systems, and networks due to not taking timely action to contain an intrusion. This can result in increased costs, loss of productivity, and loss of business.

● The possibility of an intrusion affecting multiple systems both inside and outside your organization because staff did not know who else to notify and what addi- tional actions to take

● Negative exposure in the news media that can damage your organization’s stature and reputation with your shareholders, your customers, and the community at large

● Possible legal liability and prosecution for failure to exercise an adequate standard of due care when your systems are inadvertently or intentionally used to attack others.12

Source: Carnegie Mellon University

Disaster Recovery Plan The most wisely implemented form of mitigation strategy is the disaster recovery plan. A disaster recovery plan (DR plan) deals with the preparation for and recovery from a disaster, whether natural or man-made. Although media backup strategies are an integral part of the disaster recovery plan, the overall program includes the entire spectrum of activities used to recover from an incident. The DR plan can include strategies to limit losses before and during the disaster. These strategies are fully deployed once the disaster has stopped. DR plans usually include all preparations for the recovery process, strategies to limit losses during the disaster, and detailed steps to follow when the smoke clears, the dust settles, or the floodwaters recede.

24 Chapter 1 An Overview of Information Security and Risk Management

1 The DR plan and IR plan development processes overlap to a degree. In many regards, the DR plan is an extension to the IR plan that covers disastrous events. The IR plan is also flex- ible enough to be useful in situations that are near disasters but still require coordinated, planned actions. Although some DR plan and IR plan decisions and actions are the same, their urgency and results can differ dramatically. The DR plan focuses more on preparations completed before the incident and actions taken after the incident, whereas the IR plan focuses on intelligence gathering, information analysis, coordinated decision making, and urgent, concrete actions.

Business Continuity Plan The third type of planning document that’s part of the mitigation strategy is the business con- tinuity plan (BCP). A business continuity plan (BC plan) is a document that describes how, in the event of a disaster, critical business functions will continue at an alternate location while the organization recovers its ability to function at the primary site—as supported by the DR plan. The BC plan is the most strategic and long term of the three plans. It encom- passes the continuation of business activities if a catastrophic event occurs, such as the loss of an entire database, building, or operations center. The BC plan development process includes planning the steps necessary to ensure the continuation of the organization when the scope or scale of a disaster exceeds the ability of the DR plan to restore operations. Many companies offer services as a contingency against disastrous events such as fires, floods, earthquakes, and most natural disasters.

A related tool that is being used more and more often in contingency planning is the busi- ness resumption plan (BR plan). The phrase itself reflects the fact that disaster recovery and business continuity are closely related functions, and it is used here to describe an approach that merges the capabilities of both subsets of contingency planning. In a grow- ing number of organizations, all the subordinate functions of the contingency plan may be handled as a single planning process, resulting in a single document. In large, complex organizations, all these plans may represent separate but related planning functions that differ in scope, applicability, and design. In a small organization, the security administra- tor (or systems administrator) may have one simple plan that consists of a straightforward set of media backup and recovery strategies and a few service agreements from the com- pany’s service providers. However, the sad reality is that many organizations have a level of planning that is woefully deficient.

Contingency Planning Timeline Here is a brief review of the steps involved in CP:

● The IR plan focuses on immediate response, but if the event escalates or is disastrous (such as a fire, flood, earthquake, or total blackout), the process moves on to disaster recovery and the BCP.

● The DR plan typically focuses on restoring systems at the original site after disasters occur and, as such, is closely associated with the BC plan.

● The BC occurs concurrently with the DR plan when the damage is major or long term, requiring more than simple restoration of information and information resources. The BCP establishes critical business functions at an alternate site.

Contingency Planning and Its Components 25

Some organizations treat the DR plan and BC plan as so closely linked that they are indistin- guishable. However, each has a distinct role and planning requirement. The following sections describe the tasks necessary for each of these three types of plans. You can also further distinguish among the three types of planning by examining when each comes into play during the life of an incident. Figure 1-5 shows a sample sequence of events and the overlap when the plans come into play. Disaster recovery activities typically continue even after the organization has resumed operations at the original site.

The major project work modules (described later in this book) that are performed by the contingency planning project team are shown in Figure 1-6. Although the figure does not explain these modules in full detail, it provides a useful overview of the process. Many of the sections of upcoming chapters correspond to the steps depicted in this diagram.

There are seven steps in NIST SP 800-34, Revision 1, where CP involves much more than the IRP, DRP, and BCP.13 Here are the seven steps:

1. Develop the contingency planning policy statement. The CP Policy is the formal pol- icy that will guide the efforts of the subordinate teams in developing their plans, and the overall operations of the organization during contingency operations.

2. Conduct the business impact analysis (BIA). The BIA, described later in this chapter, helps identify and prioritize organizational functions, and the information systems and components critical to supporting the organization’s mission/business processes.

3. Identify preventive controls. Assess those countermeasures and safeguards that mitigate the risk and impact of events on organizational data, operations, and personnel.

Incident recovery

Incident resolved Operations restored End IRP

Disaster recovery (Restore operations at primary site)

IRP

DRP

BCP

Pr im

ar y

O pe

BRP

at io

ns R

es to

re d

En d

D RP

/B C

Event occurs Post-event (hours) Post-event (days)

Incident detection

Incident reaction

Disaster reaction

Continuity reaction

Alternate site operations

(If incident classified as disaster)

(If event is classified as an incident)

(If disaster requires off-site operations)

Figure 1-5 Contingency planning timeline

26 Chapter 1 An Overview of Information Security and Risk Management

4. Create contingency strategies. The CPMT, with input from the subordinate team leaders will evaluate and invest in strategies that will support the IR, DR, and BC efforts should an event affect business operations. These include data backup and recovery plans, off-site data storage and alternate site occupancy strategies.

5. Develop subordinate plans. For each subordinate area develop a plan to handle the corresponding actions and activities necessary to (1) respond to an incident, (2) recover from a disaster, and (3) establish operations at an alternate site follow- ing a disruptive event.

6. Ensure plan testing, training, and exercises. Ensure each subordinate plan is tested and the corresponding personnel are trained to handle any event that escalates into an incident or a disaster.

7. Ensure plan maintenance. Manage the plan, ensuring periodic review, evaluation, and updating.

Source: NIST, SP 800-34, Revision 1

These seven stages are illustrated in Figure 1-7.

Before the event, the organization should form the CPMT. That is, they should assemble the management team that will guide CP planning and execution. This includes representatives from business management, operations, and the projected subordinate teams. After the con- tingency plan is drafted, the subordinate teams, policies, and plans are developed.

Form the CP team.

Determine mission/business

processes & recover criticality.

Develop the CP policy statement.

Identify recovery priorities for

system resources.

Form subordinate planning teams

(IR/DR/BC).

Develop subordinate

planning policies (IR/DR/BC).

Integrate the business impact analysis (BIA).

Identify preventive controls.

Organize response

teams (IR/DR/BC).

Create response strategies (IR/DR/BC).

Develop subordinate plans

(IR/DR/BC).

Ensure plan testing, training, and

exercises.

Ensure plan maintenance.

Conduct the business impact analysis (BIA).

Identify resource requirements.

Figure 1-6 Major steps in contingency planning

Contingency Planning and Its Components 27

The NIST plans that support these processes are summarized in Table 1-4.

Develop Contingency

Planning Policy

• Identify statutory or regulatory requirements for contingency plans • Develop IT contingency planning policy statement • Obtain approval of policy • Publish policy

• Develop test objectives • Develop success criteria • Document lessons learned • Incorporate into the plan • Train personnel

• Review and update plan • Coordinate with internal/external organizations • Control distribution • Document changes

• Identify critical IT resources • Identify outage impacts and allowable outage times • Develop recovery priorities

• Implement controls • Maintain controls

• Identify methods • Integrate into system architecture

• Document recovery strategy

Conduct Business Impact

Analysis

Identify Preventive Controls

Develop Recovery Strategies

Develop Contingency

Plan

Plan Testing, Training, and

Exercises

Plan Maintenance

Source: NIST, SP 800-34, Revision 1

Figure 1-7 Stages of contingency planning

Plan Purpose Scope Plan Relationship

Business Continuity Plan (BCP)

Provides procedures for sustaining mission/business operations while recovering from a significant disruption

Addresses mission/business processes at a lower or expanded level from COOP MEFs

Mission/business process- focused plan that may be activated in coordination with a COOP plan to sustain non-MEFs

Continuity of Operations (COOP) Plan

Provides procedures and guidance to sustain an organization’s MEFs at an alternate site for up to 30 days; mandated by federal directives

Addresses MEFs at a facility; information systems are addressed based only on their support of the mission essential functions

MEF focused plan that may also activate several business unit-level BCPs, ISCPs, or DRPs, as appropriate

Crisis Communications Plan

Provides procedures for disseminating internal and external communications; means to provide critical status information and control rumors

Addresses communications with personnel and the public; not information system-focused

Incident-based plan often activated with a COOP or BCP, but may be used alone during a public exposure event

Critical Infrastructure Protection (CIP) Plan

Provides policies and procedures for protection of national critical infrastructure components, as defined in the National Infrastructure Protection Plan

Addresses critical infrastructure components that are supported or operated by an agency or organization

Risk management plan that supports COOP plans for organizations with critical infrastructure and key resource assets

Cyber-Incident Response Plan

Provides procedures for mitigating and correcting a cyber-attack, such as a virus, worm, or Trojan horse

Addresses mitigation and isolation of affected systems, cleanup, and minimizing loss of information.

Information system- focused plan that may activate an ISCP or DRP, depending on the extent of the attack

Disaster Recovery Plan (DRP)

Provides procedures for relocating information systems operations to an alternate location

Activated after major system disruptions with long-term effects

Information system- focused plan that activates one or more ISCPs for recovery of individual systems

Table 1-4 Types of NIST contingency-related plans (continues) Source: NIST, SP 800-34, Revision 1

28 Chapter 1 An Overview of Information Security and Risk Management

Figure 1-8 shows how the various plans referenced in SP 800-34 relate to one another.

Role of Information Security Policy in Developing Contingency Plans

Much of what must be done in CP should be guided by, and reinforce, organizational information security policies. In fact, the outcome of the typical CP process is often new policy. This reinforces the need for proactive planning for the employees and the organi- zation. It also indicates that policy is needed to enforce certain requirements for the protection of information before, during, and after any situation requiring a contingency

Plan Purpose Scope Plan Relationship

Information System Contingency Plan (ISCP)

Provides procedures and capabilities for recovering an information system

Addresses single information system recovery at the current or, if appropriate alternate location

Information system- focused plan that may be activated independent from other plans or as part of a larger recovery effort coordinated with a DRP, COOP, and/or BCP

Occupant Emergency Plan (OEP)

Provides coordinated procedures for minimizing loss of life or injury and protecting property damage in response to a physical threat

Focuses on personnel and property particular to the specific facility; not mission/ business process or information system-based

Incident-based plan that is initiated immediately after an event, preceding a COOP or DRP activation

Table 1-4 Types of NIST contingency-related plans (continued) Source: NIST, SP 800-34, Revision 1

ORGANIZATION

Crisis Communications Plan

OEP

DRP

ISCP** CIR P

COO PBCP*

Plans may be implemented in coordination with one another * One or more BCPs could be activated. ** One or more ISCPs could be activated. = Business/mission process-focused pan = Assets/personnel-focused plan = Information system-focused plan

CIP

Source: NIST, SP 800-34, Revision 1

Figure 1-8 Interrelationship of emergency preparedness plans

Role of Information Security Policy in Developing Contingency Plans 29

plan. To better understand this relationship, a brief review of the key elements of the policy-making process is in order.

Quality security programs begin and end with policy.14 Because information security is primarily a management problem, not a technical one, policy obliges personnel to function in a manner that adds to the security of information assets rather than as a threat to those assets. Security policies are the least expensive control in that they involve only the time and effort of the management team to create, approve, and communicate, but they are the most difficult to implement properly. Shaping policy is difficult because it must never conflict with laws, must stand up in court if challenged, and must be properly administered through dissemination and documented acceptance.

Key Policy Definitions Before examining the various types of information security policies, it is important to under- stand exactly what policies and standards are and how they should be used.

A policy is a plan or course of action used by an organization to convey instructions from its senior management to those who make decisions, take actions, and perform other duties on behalf of the organization. Policies are organizational laws in that they dictate acceptable and unacceptable behavior within the context of the organization’s culture. Like laws, poli- cies must define what is right, what is wrong, what the penalties are for violating policy, and what the appeal process is.

Standards, which have the same compliance requirements as policies, are more detailed state- ments of what must be done to comply with policy. Standards may be casually accepted; these are referred to as informal or de facto standards. Alternatively, they may be published, scrutinized, and ratified by a group; these are referred to as formal or de jure standards. Finally, there are practices, procedures, and guidelines, which explain how to comply with policy. Figure 1-9 shows policies as the force that drives standards, which in turn drive practices, procedures, and guidelines.

Policies are sanctioned by senior management.

DRIVE

Standards are built on sound policy and carry the weight of policy.

Practices, procedures, and guidelines include detailed steps required to meet the requirements of standards

Policies

Standards

DRIVE

Practices Procedures Guidelines

Figure 1-9 Policies, standards, and practices

30 Chapter 1 An Overview of Information Security and Risk Management

1 Policies are written to support the mission, vision, and strategic planning of an organization. The mission of an organization is a written statement of an organization’s purpose. The vision of an organization is a written statement about the organization’s goals—where will it be in five years? In 10 years? Strategic planning is the process of moving the organization toward its vision.

To be effective, a policy must be disseminated by all means possible, including printed per- sonnel manuals, organization intranets, and periodic supplements. All members of the organi- zation must read, understand, and agree to the policies. At the same time, policies should be considered living documents, in that they require constant modification and maintenance as the needs of the organization evolve.

In general, a security policy is a set of rules that protect an organization’s assets. An informa- tion security policy provides rules for the protection of the information assets of the organi- zation. According to NIST SP 800-14, management must define three types of security policy: the enterprise security policy, issue-specific security policies, and systems-specific security policies.

Enterprise Information Security Policy An enterprise information security policy (EISP) is also known as a general security policy, IT security policy, or information security policy. The EISP is based on and directly supports the mission, vision, and direction of the organization and sets the strategic direction, scope, and tone for all security efforts. The EISP is an executive-level document, usually drafted by, or in cooperation with, the chief information officer of the organization. This policy is usu- ally two to 10 pages long and shapes the philosophy of security in the IT environment. The EISP does not usually require continuous modification, unless there is a change in the strate- gic direction of the organization.

The EISP guides the development, implementation, and management of the security program. It contains the requirements to be met by the information security blueprint or framework. It defines the purpose, scope, constraints, and applicability of the security program in the orga- nization. It also assigns responsibilities for the various areas of security, including systems administration, maintenance of the information security policies, and the practices and responsibilities of the users. Finally, it addresses legal compliance. According to NIST, the EISP typically addresses compliance by documenting the organizational structures put into place, describing the programs that have been developed, and reviewing the assignment of responsibilities and/or the use of specified penalties and disciplinary actions.15

When the EISP has been developed, the CISO (or chief information security officer) begins forming the security team and initiating the necessary changes to the information security program.

Issue-Specific Security Policy As an organization executes various technologies and processes to support routine opera- tions, guidelines are needed to instruct employees to use these technologies and processes properly. In general, the issue-specific security policy (ISSP) addresses specific areas of tech- nology and contains a statement on the organization’s position on a specific issue. It requires frequent updating.16

Role of Information Security Policy in Developing Contingency Plans 31

There are several approaches to creating and managing ISSPs, each with its own set of ISSP documents. Here are the three most common ones:

● Independent ISSP documents, each tailored to a specific issue ● A single comprehensive ISSP document covering all issues ● A modular ISSP document that unifies policy creation and administration while main-

taining each specific issue’s requirements

Table 1-5 shows a sample ISSP, which can be used as a template to enable an organization to address all the key points of such a policy. An organization should add to this structure the specific details that dictate security procedures not covered by these general guidelines.

1. Statement of policy

a. Scope and applicability

b. Definition of technology addressed

c. Responsibilities

2. Authorized access and usage of equipment

a. User access

b. Fair and responsible use

c. Protection of privacy

3. Prohibited usage of equipment

a. Disruptive use or misuse

b. Criminal use

c. Offensive or harassing materials

d. Copyrighted, licensed, or other intellectual property

e. Other restrictions

4. Systems management

a. Management of stored materials

b. Employer monitoring

c. Virus protection

d. Physical security

e. Encryption

5. Violations of policy

a. Procedures for reporting violations

b. Penalties for violations

6. Policy review and modification

a. Scheduled review of policy and procedures for modification

7. Limitations of liability

a. Statements of liability or disclaimers

Table 1-5 Sections of an issue-specific security policy17 Source: NIST, SP 800-34, Revision 1

32 Chapter 1 An Overview of Information Security and Risk Management

1 Each of the areas presented in Table 1-5 is discussed in the following sections. Even though the details may vary from policy to policy and some sections of a modular policy may be combined, it is essential for management to address and complete each section.

Statement of Policy The policy should begin with a clear statement of purpose that answers the following questions: What is the scope of this policy? Who is responsible and accountable for policy implementation? What technologies and issues does it address?

Authorized Access and Usage of Equipment This section of the policy statement addresses who can use the technology governed by the policy and what it can be used for. It defines “fair and responsible use” of equipment and other organizational assets, and it addresses key legal issues, such as protection of personal information and privacy.

Prohibited Usage of Equipment Whereas the previous section described what the issue or technology can be used for, this section outlines what it cannot be used for. Unless a par- ticular use is clearly prohibited, the organization cannot penalize its employees for misuse. The following can be prohibited: personal use, disruptive use or misuse, criminal use, use of offensive or harassing materials, and infringement of copyrighted, licensed, or other intellectual property.

Systems Management This section focuses on the users’ relationship to systems man- agement. It is important to designate all responsibilities to either the systems administrator or the users; otherwise, both parties may infer that the responsibility belongs to the other party.

Violations of Policy This section contains not only the specifics of the penalties for each category of violation but also instructions on how individuals in the organization can report observed or suspected violations without fear of recrimination or retribution.

Policy Review and Modification The policy should contain procedures and a time- table for periodic review. This section contains a specific methodology for the review and modification of the policy to ensure that users do not begin circumventing it as it grows obsolete.

Limitations of Liability This final section describes the limitations of the company’s liability. It should state that if employees violate a company policy or any law using com- pany technologies, the company will not protect them, and that the company is not liable for their actions.

Systems-Specific Policy Whereas issue-specific policies are formalized as written documents, distributed to users, and agreed upon in writing, systems-specific security policies (SysSPs) are frequently codified as standards and procedures to be used when configuring or maintaining systems. SysSPs can be organized into two groups:

● Access control lists (ACLs)—Lists, matrices, and capability tables governing the rights and privileges of particular users to particular systems

● Configuration rules—The specific configuration codes entered into security systems to guide the execution of the system when information is passing through it

Role of Information Security Policy in Developing Contingency Plans 33

ACL Policies Most modern operating systems (OSs) translate ACLs into sets of config- urations that administrators use to control access to their respective systems. ACLs allow a configuration to set restrictions for a particular user, computer, time, duration—even a particular file. In general, ACLs regulate the who, what, when, and where of access:

● Who can use the system ● What authorized users can access ● When authorized users can access the system ● Where authorized users can access the system from

In some systems, these lists of ACL rules are known as capability tables, user profiles, or user policies. They specify what the user can and cannot do with the system’s resources.

Rule Policies Rule policies are more specific to the operation of a system than ACLs and may or may not deal with users directly. Many security systems require specific configura- tion scripts that tell the systems what actions to perform on each set of information they process. Examples of these systems are firewalls, intrusion detection systems, and proxy servers.

Policy Management Policies are living documents that must be nurtured, given that they are constantly changing and growing. They must be properly disseminated (distributed, read, understood, and agreed to) and managed. To remain viable, security policies must have the following:

● An individual (such as a policy administrator) responsible for the creation, revision, distribution, and storage of the policy; this individual should solicit input from all communities of interest in policy development.

● A schedule of reviews to ensure currency and accuracy, and to demonstrate due diligence

● A mechanism by which individuals can comfortably make recommendations for revi- sions, preferably anonymously

● A policy and revision date and possibly a “sunset” expiration date ● Optionally, policy management software to streamline the steps of writing the policy,

tracking the workflow of policy approvals, publishing the policy once it is written and approved, and tracking when individuals have read the policy

Chapter Summary ● The Committee on National Security Systems (CNSS) has defined information security

as “the protection of information and its critical elements, including the systems and hardware that use, store, and transmit that information.” The industry standard for computer security since the development of the mainframe, the C.I.A. triangle, is used to illustrate the three most critical characteristics of information used within informa- tion systems: confidentiality, integrity, and availability.

34 Chapter 1 An Overview of Information Security and Risk Management

1 ● In general, a threat is an object, person, or other entity that is a potential risk of loss

to an asset. A threat-agent is a specific and identifiable instance of a general threat that exploits vulnerabilities set up to protect the asset. A vulnerability is a flaw or weakness in a system that could be exploited, resulting in a security breach.

● The identifiable threats to information security are espionage or trespass, software attacks, human error or failure, theft, compromises of intellectual property, sabotage or vandalism, technical software failures or errors, technical hardware failures or errors, forces of nature, deviations in quality of service from service providers, technological obsolescence, and information extortion. Other sources for types of threats are also possible.

● Risk management is the process of identifying and controlling the risks to an organiza- tion’s information assets. All managers are expected to play a role in the risk management process, but information security managers are expected to play the largest roles. Risk management consists of two major undertakings: risk identification and risk control.

● Risk identification requires managers to identify, classify, and prioritize the organization’s information assets. The process continues with threat identification, in which each informa- tion asset is examined to identify vulnerabilities, and to identify existing and possible controls.

● Those responsible for risk control can use a ranked vulnerability worksheet to choose one of the five approaches for controlling the risks that result from the vulnerabilities: defense, transferal, mitigation, acceptance, or termination. The defense approach attempts to pre- vent the exploitation of the vulnerability. The transferal approach attempts to shift the risk to other assets, other processes, or other organizations. The mitigation approach attempts to reduce the impact caused by the exploitation of vulnerability through planning and preparation. Acceptance is the choice to do nothing to protect an information asset and to accept the outcome of its potential exploitation. Termination is based on the organization’s need or choice to leave an asset unprotected without the information asset to remain at risk by removing it from the environment that represents risk.

● Contingency planning is a strategic process to ensure the continuous availability of infor- mation systems. A contingency plan is used to anticipate, react to, and recover from events that threaten the security of information and information assets in the organization; it is also used to restore the organization to normal modes of business operations. Contingency planning involves four subordinate functions: business impact assessment (BIA), incident response planning (IRP), disaster recovery planning (DRP), and business continuity plan- ning (BCP). Contingency planning has many similarities to the risk management process.

● Business impact analysis (BIA) is an investigation and assessment of the impact that vari- ous attacks can have on the organization. The BIA takes up where the risk assessment process leaves off. It begins with the prioritized list of threats and vulnerabilities identified in the risk management process and appends critical information. The incident response (IR) plan deals with identifying, classifying, responding to, and recovering from an inci- dent. The disaster recovery (DR) plan deals with the preparation for and recovery from a disaster, whether natural or man-made. A business continuity (BC) plan is a document that describes how, in the event of a disaster, critical business functions will continue at an alternate location while the organization recovers its ability to function at the primary site.

● Information security policy has a role in developing contingency plans. Much of what must be done in CP should be guided by, and reinforce, organizational information secu- rity policies. Information security is primarily a management problem, not a technical

Chapter Summary 35

one. Policy obliges personnel to function in a manner that adds to the security of infor- mation assets rather than as a threat to those assets. Policies are written to support the mission, vision, and strategic planning of an organization. An enterprise information security policy is based on and directly supports the mission, vision, and direction of the organization and sets the strategic direction, scope, and tone for all security efforts.

● As an organization executes various technologies and processes to support routine operations, guidelines are needed to instruct employees in how to use these technologies and processes properly, with issue-specific policies to address specific areas of technol- ogy. Whereas issue-specific policies are formalized as written documents, distributed to users, and agreed upon in writing, systems-specific security policies are frequently codi- fied as standards and procedures to be used when configuring or maintaining systems

Review Questions 1. What is information security?

2. How is the CNSS model of information security organized?

3. What three principles are used to define the C.I.A. triangle? Define each in the context in which it is used in information security.

4. What is a threat in the context of information security?

5. What is an asset in the context of information security?

6. What is a vulnerability in the context of information security?

7. What is risk management?

8. What are the component parts of risk management?

9. Who is expected to be engaged in risk management activities in most organizations?

10. What are the basic strategies used to control risk? Define each.

11. What is a contingency plan?

12. List and describe the four subordinate functions of a contingency plan.

13. In general terms, what is policy?

14. What is the enterprise information security policy, and how is it used?

15. Why is shaping policy considered difficult?

16. What are standards? How are they different from policy?

17. What is an issue-specific security policy?

18. List the critical areas covered in an issue-specific security policy.

19. What is a systems-specific security policy?

20. When is a systems-specific security policy used?

36 Chapter 1 An Overview of Information Security and Risk Management

1Real-World Exercises Exercise 1-1 Using a Web browser, search for any information security policies used at your academic institution. Compare them to the ones discussed in this chapter. Are there sections missing? If so, which ones?

Exercise 1-2 Using a Web browser, go to www.gocsi.com and download the latest CSI Computer Crime and Security Survey. What threats are currently the most dangerous? Which threats represent problems for your home computer? For your lab computer?

Exercise 1-3 Using a Web browser, go to http://cve.mitre.org. What type of site is this, and what information can it provide? Change the URL to http://cve.mitre.org/cve, click Search, and enter IP Validation Vulnerability in the search field. Click Search again. What information are you provided with? How would this be useful? Go to the URL noted in the CVE description for the Microsoft refer- ence. What additional information are you provided? How would this be useful?

Exercise 1-4 Using a Web browser, go to www.securityfocus.com. What information is provided under the BugTraq tab? Under the Vulnerabilities tab? On the Vulnerabilities tab, select Microsoft as the Vendor and Windows Messenger as the title. Look for a PNG Buffer Overflow vulnerability. What information is provided under the Exploit tab? What does it mean? How could an attacker use this information? How could a security manager?

Exercise 1-5 Using a Web browser, go to http://csrc.nist.gov. Click the Special Publications (800 Series) link. Find SP 800-100. Review the HTML version. What critical information could a security administrator or manager gain from this document? What other documents would be of value to the security manager or technician?

Hands-On Projects

In this chapter, instead of taking you through a “hands-on” project, we will discuss two things that are needed for all the projects you will be doing in later chapters. One is how we will use virtualization in the rest of the projects.

The other The other is a discussion of the ethical dimension of using information security tools and techniques that many consider to be from the “dark side.”

Virtualization Virtualization is the ability to create a virtual, as opposed to a physical, representation of a computing device, such as a network, a computing system, or a storage system. Virtualization is primarily used to create a virtual image of a functioning computer. This virtual image (also

Hands-On Projects 37

referred to as a guest) mimics the behavior of a physical system in almost every way, without the requirement of actually having to purchase or otherwise obtain the hardware needed to run it. Guest images reside on a host system and can run at the same time as the host. The host system may run multiple guest images at the same time, if it has enough resources to do so. Virtual systems typically make higher demands on CPU and memory, so the host must be robust enough to handle the increased demand. These demands come on top of the usual demand needed to run the host, exclusive of any virtual images.

Before you can actually use virtual images, you must install some type of virtualization software. This software will allow you to create, maintain, and control each of your guest images. Virtualization software can be integrated with an operating system, so that the only functionality provided by the host system is virtualization. Alternatively, some virtualization software can be installed on top of an existing host system that already has an operating system installed. There are multiple vendors providing virtualization software, such as VMware, Oracle, Microsoft, Apple, various Linux distros, IBM, and Novell. Some of these software packages are available at no charge, whereas others are available for a fee.

The Hands-On Projects for this textbook were developed using VMware Player, a free offering from VMware. VMware Player is not as robust or feature-rich as some of the other VMware offerings, but it is robust enough to meet the needs for this textbook. VMware offers licensing agreements with universities, colleges, and schools that may allow you to download and install more robust versions of VMware software. Check with your instructor to see if this is possible.

The primary tool to be used in the Hands-On Projects is Security Onion. Although it may be possible to do the projects using other virtualization software, Doug Burks, the primary lead on the Security Onion project, recommends using VMware. In his experience, some of the applications installed in the Security Onion do not function well in other virtualization environments.

Ethical Considerations in the Use of Information Security Tools Using the “tools of the trade” in information security can put a student (and a teacher, too) in a position where the software and techniques designed to break the rules and allow bad acts to occur are at hand. Because each academic community sets certain stan- dards, you need to be aware of how this might play out in your specific circumstance.

Conforming to standards and exhibiting ethical behavior is required to ensure the unhin- dered pursuit of knowledge and the free exchange of ideas. Academic integrity means that you respect the right of other individuals to express their views and opinions, and that you, as a student or faculty member, do not engage in plagiarism, cheating, illegal access, misuse or destruction of college property, or the falsification of college records or academic work.

As a member of the academic community, you are expected to adhere to these standards of ethical behavior. You are expected to read, understand, and follow the code of conduct as outlined in your organization’s policy and expressed in graduate and undergraduate catalogs and/or the student handbook. You need to be aware that if you violate these standards you will be subject to certain penalties as outlined in the university judiciary pro- cedures. These penalties likely range from grade penalties to permanent expulsion.

Read the following Academic Integrity Statement and White Hat Agreement, and then fol- low your teacher’s instructions for acknowledging your understanding and agreement. You

38 Chapter 1 An Overview of Information Security and Risk Management

1 are required to abide by these ethical standards while you are a student. Your agreement indicates that you understand the ethical standards expected of you in this academic com- munity and that you understand the consequences of violating these standards. For those of you in information security programs, the standard is even higher, given that you will be functioning as one of the guardians of the organization’s data.

Are You a White Hat? As part of this course, you may be exposed to systems, tools, and techniques related to information security. With proper use, these components allow a security or network administrator to better understand the vulnerabilities and security pre- cautions used to defend an organization’s information assets. If misused, either intentionally or accidentally, these components can result in breaches of security, damage to data, or other undesirable results.

Because these projects will sometimes be carried out in a public network that is used by peo- ple for real work, you must agree to the following before you can participate. If you are unwilling to sign this form, then you cannot participate in the projects.

The White Hat Agreement If you have questions about any of these guidelines, please contact your instructor. When in doubt, ask your instructors. This document may be changed from time to time by your instructor, who will notify you of such changes and may ask you to reaffirm your understanding and agreement.

Just because you can do something, doesn’t mean you should.

1. As you engage in projects, you will be granted access to tools and training that have the potential to do harm even when they are used to determine or investigate the security of an information system. Use these tools with care and consideration of their impact, and only in the ways specified by your instructor.

2. If any question arises in your mind about whether you can or should perform an activity or use a tool in a particular way, stop and ask your instructor for clarification. In information security, it is most definitely NOT easier to ask for forgiveness than for permission.

3. Students are allowed to use the tools and exercises only if they are currently registered for a grade in the course. An instructor always has the right to ask for appropriate iden- tification if a question arises about the identity of a student.

4. Any instance of suspected misconduct, illegal or unauthorized use of tools or exercises, or any action by a student that can be construed as being outside the guidelines of the course syllabus and instruction will be investigated by the instructor and may result in severe academic and/or legal penalties. Just because you are a student does not exempt you from consequences if you commit a crime.

5. We expect all students to follow the Information Security Practice Code of Ethics included later in this chapter.

6. By acknowledging this document, you agree that you WILL:

� only perform those actions specified by the course instructor in using security tools on assigned systems

� report any findings to the course instructors or in specified reporting formats and not disclose them to anyone else

� maintain the confidentiality of any private information learned through course exercises

Hands-On Projects 39

� manage assigned course accounts and resources with the understanding that their contents may be viewed by others

� hold harmless the course instructors and your academic institution for any conse- quences or actions should you choose to use course content outside the physical or virtual confines of the specified laboratory or classroom

� abide by the computing policies of your academic institution and by all laws governing use of computer resources on campus, and legal jurisdictions to which I am subject

7. By acknowledging this document you agree that you WILL NOT:

� attempt to gain unauthorized access or attempt to increase privileges on any system or access any data without proper authorization

� disclose any information that you discover as a direct or indirect result of this course exercise

� take actions that will modify or deny access to any system, data, or service except those whose administrative control to which you have been duly delegated

� attempt to perform any actions or use utilities presented in the laboratory outside the confines and structure of the projects or classroom

� utilize any security vulnerabilities beyond the target accounts in the course or beyond the duration of the course exercise

� pursue any legal action against the course instructors or the university for any con- sequences or actions should you choose to use what you learn in the course outside the physical or virtual confines of the laboratory or classroom

8. Further, you will abide by the following code of ethics:

Safety of the commonwealth, duty to our principals, and to each other requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior.

Information Security Practice Code of Ethics It is the responsibility of each person to:

● Seek always to protect the interests of society while engaged in the protection of the information assets you own or those of the principals who engage your services.

● Work to maintain and enhance the trust placed with organizations by the public who increasingly rely on information that is stored and processed in information systems that you are engaged to protect.

● Advance the understanding of information owners and other stakeholders in organizations using information systems that information assets require as reasonable and prudent security controls and control systems.

● Maintain and enhance the integrity of the public information handling infrastructure, including systems, networks, and control processes.

● Lead others to better understand the need to eliminate unsafe information processing practices and the development or deployment of vulnerable, unprotected information systems.

40 Chapter 1 An Overview of Information Security and Risk Management

1 ● Pursue personal and commercial activities with honor and integrity, interacting

with other persons and organizations responsibly and within all applicable legal and regulatory requirements.

● Deliver honest and timely reports of actions you have taken and of any exposures to loss that may be known or discovered to the stakeholders who would be affected by such knowledge.

● Operate within the accepted framework of contract law and binding performance agreements, whether expressly executed or implied by your actions.

● Treat others fairly, including principals and stakeholders of the information assets you are engaged to protect.

● Resolve conflicts fairly to the benefit of all, first in the interests of public integrity, then in the interests of principals with whom you are engaged, then in the interests of individuals involved, and then in the interest of the information security profession, in that order.

● Seek to give prudent advice without engendering undue alarm or promoting unjustified comfort.

● When faced with conflicting legal requirements from multiple jurisdictions, promote actions consistent with the jurisdiction where services are provided or from which the principals have engaged your services.

● Deliver value to principals through diligent and competent service. ● Offer advice and take actions to preserve the value of the systems you are engaged

to protect, including the information, applications, systems, and networks on which such information resides.

● Act in ways that reflect the trust and privileges that have been granted to you by the principals who have engaged your services.

● Avoid in all ways any appearance of a conflict of your interests for yourself and the principals who have engaged your services.

● Render only those services for which you are fully competent and qualified. ● Seek to advance the information security profession and work to help your

colleagues in the discipline. Offer generous parts of your time, attention, and talent to develop the capabilities of skill and knowledge in others.

● Avoid association with those who may not subscribe to or support ethical behavior in the information security discipline, or whose actions may work against the best interest of the discipline.

● Be sensitive to the professional reputation of others. ● Maintain your technical and managerial skills and knowledge so as to always be

able to deliver value to the principals who engage your services.

Example of a Student Agreement to Comply The following text is from a Student Agreement that some are using. Your instructor may use something very like this or another of his or her own choosing. In any case, it is meant to assure your teachers and administrators of your institution that you have been informed of the rules and will follow them.

Hands-On Projects 41

This agreement has been explained to me to my satisfaction. I have read, understood, and agree to comply with the terms and conditions of this agreement. I agree to abide by the conditions of the Code of Ethics and of the White Hat Agreement. Fur- ther, I consent for my course accounts and systems to be examined for security and privacy vulnerabilities by other students in the course, with the understanding that this may result in information about me being disclosed, if applicable.

If directed by your instructor, complete this form and submit it to the instructor, OR perform whatever other action your instructor specifies to acknowledge your understanding and willingness to comply. _______________________________________________________________________________ Student Printed Name, Signature, and Date

Example

Established in June 1999, Hierarchical Access LTD (HAL) provides basic Internet access, fast Internet access, and Web registration and hosting alternatives for small office/ home office (SOHO) individuals and organizations. It is a privately owned company managed by its founder and CEO, Alan Hake. (See Figures 1-10 and 1-11.)

Closing Case Scenario: Pondering People

Alan Hake CEO

Rachel Xieng CFO

Richard Xavier COO

Amanda Wilson CIO

Marie LeFleur Senior Exec. Asst.

Jamie Roma Intern

Figure 1-10 Organization chart for HAL’s high-level positions

42 Chapter 1 An Overview of Information Security and Risk Management

The CIO, Amanda Wilson, has 15 years of technical experience and 10 years of experi- ence as a senior IT manager. (See Figures 1-12 and 1-13.) Shortly after taking the position as CIO, Amanda hired Paul Alexander as manager of information security. A reorganization in 2003 resulted in an enhanced recognition of the role of informa- tion security at HAL; it also resulted in Paul being named chief information security officer. Along with this increased recognition came a group of dedicated personnel and a budget of approximately $500,000 for equipment, personnel, and training. As shown in Figures 1-12 and 1-13, Paul currently has two full-time security technician positions (one of which is unfilled) and an intern.

Richard Xavier COO

Pantoja Martina Exec. Asst.

Juan Vasquez Mgr. Help Desk

Roberta Briscoe Mgr. Corp. Security

Cecilia Thompson

Mgr. Networking

Thomas Harden Mgr. Marketing

Melinda Hixon HR Consultant

Wendy Binder Admin. Asst.

Constance Beignet

Admin. Asst. Vincent Disalvo Network Architect

Penny Dodd Senior Network Tech.

Barry Zubler Network Tech.

Margarito Fletcher Admin. Asst.

Vicki Webb Intern

Tina Witherly Senior Help Desk

Administrator

David Schwab Senior Help Desk

Administrator

Walter Chen Senior Help Desk

Administrator

Vijay Patel Admin. Asst.

Teresa Steward Help Desk Tech.

Juanita LaSalle Help Desk Tech.

Kekunda Grey Help Desk Tech.

Karen Morrow Help Desk Tech.

Leonard Leibowitz Help Desk Tech.

Carlos Mendez Help Desk Tech.

Pamela Allen Help Desk Tech.

Mark Sinclair Help Desk Tech.

John Neidler Help Desk Tech.

Figure 1-11 Organization chart for HAL’s operations unit

Hands-On Projects 43

Two years ago, HAL began a major organization-wide effort to implement contingency planning. Although Amanda is primarily responsible for developing the IR plan, she has appointed the systems manager, William Freund, as the lead for the IR team. Paul was chosen as a consultant for all three teams (incident response, disaster recovery and business continuity), his assignment being to assist in their development and implemen- tation. The disaster recovery and business continuity teams are the responsibility of the chief operations officer, Robert Xavier, who appointed Cecilia Thomson as lead for the disaster recovery team and Juan Vasquez as lead for the business continuity team. Under their leadership, the teams have been formed and the planning documents have been created.

Amanda Wilson CIO

Paul Alexander CISO

Harold Fry Security Tech.

Lewis Mableton Intern

Scotty Doohan Mgr. Applications

William Freund Mgr. Systems

Vacant Security Tech.

Jonathon Jasper Senior Systems

Admin.

Tsung Ye Senior Systems

Developer

Sy Truman Systems Admin.

Tina Mann Senior Network

Admin.

Okekula M’buta Network Admin.

Edward Michaels Second Shift Supv.

Susan Carter Third Shift Supv.

Osugi Tokumata Systems Dev.

Susan Lampe Systems Dev.

Robert James Intern

Debbie Sims Admin Asst.

Sonny Warren Admin. Asst.

Figure 1-12 Organization chart for HAL’s IT unit

44 Chapter 1 An Overview of Information Security and Risk Management

Endnotes 1. “Internet Usage Statistics: The Internet Big Picture: World Internet Users and Population

Stats.” Internet World Stats. Accessed December 17, 2012 @ www.internetworldstats. com/stats.htm.

2. “Lessons of First WTC Bombing.” BBC News February 26, 2003. Accessed April 20, 2005 @ http://news.bbc.co.uk/2/hi/americas/2800297.stm.

Discussion Questions 1. Other than Tina and JJ, whom should Paul invite to attend this meeting?

2. Why is JJ so concerned about the number of failed login attempts? After all, it seems like no one successfully got into Paul’s account.

3. What other information can Paul and his team use to track down what caused this incident?

4. How does the exchange between JJ and Paul indicate that this company has thought about contingency planning?

Rachel Xieng CFO

Gary Fischer Controller

Vijay Patel Exec. Asst.

Gary Fischer Mgr. Marketing

Eddie Dias Marketing Spec.

Shelly Reece Public Relations

Coordinator

Jeffrey Kruse Auditor

Jesse Eckerd Auditor

Morrie Pitkin Sr. Auditor

Angela Fowler Auditor

Anton Zgambo Admin. Asst.

Romeo Nance Mgr. Accounting

Mark Grisham Audit Supv.

Ken Miller Auditor

Samuel Prout Accountant

Donna Massey Accountant

Su Lee Accountant

Ron Rocca Accountant

Kathy Vasser Senior

Accountant

Figure 1-13 Organization chart for HAL’s financial unit

Endnotes 45

3. Witty, Roberta. “2005–2008 Business Continuity Management Survey Results.” Gartner. Accessed June 6, 2011 @ www.gartner.com/it/content/897800/897814/ks_sd_ mar.pdf.

4. “SME Recruitment Agencies Invited by AXA to Star in Business Oscars” Onrec.com March 9, 2005. Accessed April 20, 2005 @ www.onrec.com/news/news-archive/sme- recruitment-agencies-invited-by-axa-to-star-in-business-oscars.

5. Stoneburger, Gary, Alice Goguen, and Alexis Feringa. NIST SP 800-30, Risk Manage- ment Guide for Information Technology Systems. NIST, July 2002.

6. Whitman, Michael E., and Herbert J. Mattord. “Threats to Information Security Revisited.” Journal of Information Systems Security (2012).

7. “Intellectual Property,” FOLDOC (Free On-Line Dictionary of Computing) March 27, 1997. Accessed February 15, 2004 @ http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query =intellectual+property.

8. Richardson, Robert. “CSI Computer Crime & Security Survey” 2000–2009. Computer Security Institute. Accessed July 5, 2012 @ www.gocsi.com.

9. Sun Tzu. The Art of War. Trans. Samuel B. Griffith. Oxford: Oxford University Press, 1988, p. 84.

10. National Institute of Standards and Technology (NIST). An Introduction to Computer Security: The NIST Handbook (SP 800-12). Gaithersburg, MD: NIST, 2002.

11. Firth, Lisa, Gary Ford, Barbara Fraser, John Kochmar, John Richael, Derek Simmel, and Suresh Konda. “Detecting Signs of Intrusion.” Software Engineering Institute, Car- negie Mellon University 1998. Accessed August 19, 2012 @ www.sei.cmu.edu/reports/ 98sim001.pdf.

12. “Responding to Intrusions” Carnegie Mellon University, 2000. Accessed February 17, 2005 @ www.cert.org/security-improvement/modules/m06.html.

13. Swanson, Marianne, Pauline Bowen, Amy Phillips, Dean Gallup, and David Lynes. NIST SP 800-34 Rev. 1., Contingency Planning Guide for Federal Information Systems. NIST May 2010. Accessed June 6, 2011 @ http://csrc.nist.gov/publications/nistpubs/ 800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

14. Wood, Charles C., “Integrated Approach Includes Information Security.” Security 37 (February 2000): 43–44.

15. National Institute of Standards and Technology (NIST). An Introduction to Computer Security: The NIST Handbook (SP 800-12). Gaithersburg, MD: NIST, 2002.

16. Swanson, Marianne, Bowen, Pauline, Phillips, Amy, Gallup, Dean, and David Lynes. “NIST SP 800-34 Rev. 1., Contingency Planning Guide for Federal Information Systems.” NIST May 2010. Accessed June 6, 2011 @ http://csrc.nist.gov/publications/ nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

17. Aalberts, Robert J., Townsend, Anthony M., and Michael E. Whitman. “Considerations for an Effective Telecommunications-Use Policy.” Communications of the ACM 42 (June 1999): 101–109.

46 Chapter 1 An Overview of Information Security and Risk Management

chapter2

Planning for Organizational Readiness

In preparing for battle, I have always found that plans are useless, but planning is indispensable. —Dwight D. Eisenhower

Upon completion of this material, you should be able to: ● Discuss why an individual or group needs to be appointed to create a contingency policy

and plan ● Describe the elements needed to begin the contingency planning process ● Define business impact analysis and describe each of its components ● List the steps needed to create and maintain a budget used for the contingency planning

process

It was Friday night. All the employees had long left for the day except for a select group of senior staff who were crowded around the conference table with binders open and index cards in hand. Paul, who was facilitating the contingency planning training exercise, turned to JJ, who was the acting incident manager for this meeting, and said, “It’s your turn.”

JJ looked at the next index card in his deck. He read two words that made him gri- mace: “Power out.”

JJ looked to Paul and asked, “How widespread and for how long?” “Beats me,” Paul replied. “That’s all I know.” JJ flipped through his now tattered copy of the disaster recovery plan, finally set-

tling on a page. He looked up, scanning the room for the communications coordina- tor, Susan Lampe. Susan, a more experienced systems developer, was assigned responsibility for all communications during this disaster recovery practice session.

“Susan,” he said, “please call the power company and ask how widespread the outage is.”

Susan, who was reading the same page as JJ, looked up. “Okay, I’ll let you know as soon as I have an answer,” she said. “Anything else?”

“Uh, yes,” JJ said, “just a minute.” As he was searching his binder for the next step to perform, Ed Michaels, the second shift supervisor, started reading aloud from his binder. “We’ve got about 45 minutes of battery time,” he said, “but the generators need to be manually started. I’m going to need power to the servers to keep Web and network operations up.”

“Right! “ JJ said. He then turned to Fred Finebaum, who was representing the building management company that leased space to HAL. “Can you get a team to the generator and get it going?”

Looking up from his binder, Fred said, “Okay. I’m on it.” “We already turned on the heaters,” he added. “It takes 10 to 15 minutes to bring

up from a cold start, and in this weather it’s a very cold start. We need five to seven more minutes before we can crank the motor, and three to four minutes after that before we can generate power.”

Everyone at the table laughed. Even though the weather outside was 92 degrees and humid, the disaster scenario they were rehearsing was focused on a massive snowstorm affecting operations.

“How long will the generators run?” JJ asked.

Opening Case Scenario: Proper Planning Prevents Problems

48 Chapter 2 Planning for Organizational Readiness

Introduction Planning for contingencies is a complex and demanding process. Like any such undertaking, it is improved by approaching it with a methodology that systematically addresses each chal- lenge an organization might face during an incident, disaster, or other crisis. Developing a contingency plan (CP) like the one used in the opening scenario of this chapter means taking the time and effort to organize the planning process, prepare the detailed and complete plans, commit to maintaining those plans at a high state of readiness at all times, rehearse the use of the plans with a rigor and diligence usually seen only in military organizations, and then maintain the processes necessary to keep a high state of preparedness at all times.

All this must happen amid the pressures of day-to-day operational demands and the give-and-take of resource allocations common to all organizations. Note that the rehearsal occurred after nor- mal working hours; an organization and its employees should expect to make such a commitment to contingency planning. Unfortunately, few organizations can maintain a proper degree of readi- ness over an extended period of time. This chapter explores some of the preparatory and founda- tional steps to ensure that the contingency planning process gets off to a solid start.

Beginning the Contingency Planning Process To begin the process of planning for contingencies, an organization must first establish an entity that will be responsible for the policy and plans that will emerge from the process. In a small- to-medium-sized organization, this may be an individual; in large organizations, it may be a team. Some organizations use their own employees; others hire consultants or contractors. Prior to any meaningful planning, those assigned responsibility must define the scope of the planning project and identify the resources to be used. Many times, a CP management team is assembled for that purpose. A contingency planning management team (CPMT) is the collec- tion of individuals responsible for the overall planning and development of the contingency planning process, including the organization of subordinate teams and oversight of subordinate plans. The CPMT is responsible for a number of functions, including the following:

● Obtaining commitment and support from senior management ● Managing and conducting the overall CP process ● Writing the master CP document ● Conducting the business impact analysis (BIA), which includes:

� Assisting in identifying and prioritizing threats and attacks � Assisting in identifying and prioritizing business functions

Fred flipped a page in his binder. “Days,” he said. “If we have to, we can siphon gas from your new truck! With the reserve tank supplemented by gas from employee vehicles, we have plenty of fuel, provided the generator doesn’t break down.”

“Whew! That’s a relief,” JJ said, smiling as he leaned back in his seat. “Okay, what’s our next step?” Then he glanced over at Paul.

“Good job, everybody,” Paul said. “JJ, flip the next card.”

Beginning the Contingency Planning Process 49

● Organizing and staffing the leadership for the subordinate teams:

� Incident response � Disaster recovery � Business continuity � Crisis management

● Providing guidance to and integrating the work of the subordinate teams.

A typical roster for the CPMT may include the following positions:

● A champion—As with any strategic function, the CP project really should have a champion. This should be a high-level manager with influence and resources that can be used to support the project team, promote the objectives of the CP project, and endorse the results that come from the effort. In a CP project, this could be the chief information officer (CIO), chief operations officer (COO), or ideally the chief execu- tive officer (CEO). It is most common, however, for the COO to take overall respon- sibility for overseeing CP activities.

● A project manager—A champion provides the strategic vision and the linkage to the power structure of the organization, but someone has to manage the project. A project manager, possibly a midlevel manager or even the CISO, must lead the project and make sure a sound project planning process is used, a complete and useful project plan is developed, and project resources are prudently managed to reach the goals of the project.

● Team members—The team members for this project should be the managers or their representatives from the various communities of interest: business, information tech- nology, and information security.

● Representatives from other business units—Other areas of the business, such as human resources, public relations, finance, legal, and/or physical plant operations, should also be represented. This can include:

� Business managers—Those familiar with the operations of their functional areas, who can supply details on their activities and provide insight into the criticality of their functions to the overall sustainability of the business

� Information technology managers—Those familiar with both the systems that could be at risk and with the incident response plans (IRPs), disaster recovery plans (DRPs), and business continuity plans (BCPs) that are needed to provide technical content within the planning process

� Information security managers—Those who can oversee the security planning of the project and provide information on the threats, vulnerabilities, and recovery requirements needed in the planning process

● Representatives from subordinate teams—Team leaders from the subordinate CPMTs, including the incident response (IR), disaster recovery (DR), and business continuity (BC) teams, should also be included in the CPMT. Additionally, if the organization has a crisis management team, it should also be represented. Teams other than the core members of the CPMT have key functions that are components of the overall contin- gency planning effort. These teams should be distinct entities, with one or more repre- sentatives on the CPMT—usually the team leaders. The reason these teams are distinct

50 Chapter 2 Planning for Organizational Readiness

is that their individual functions are very different and may be activated at different times, or they may be activated concurrently. The subordinate teams may include:

� The incident response team, which manages and executes the IRP by detecting, evaluating, and responding to incidents

� The disaster recovery team, which manages and executes the DRP by detecting, evaluating, and responding to disasters and by reestablishing operations at the pri- mary business site

� The business continuity team, which manages and executes the BCP by setting up for and starting off-site operations in the event of an incident or disaster

� The crisis management team, which manages and mitigates the impact of personal loss and distress on the organization by minimizing the loss of life, ensuring the quick and accurate accountability of personnel, and ensuring the quick and accu- rate notification of key personnel through alert rosters

The relationship between the CPMT and the subordinate teams is shown in Figure 2-1.

Among the most critical start-up tasks of the CPMT is aligning support. This is explored in greater detail in the following paragraphs.

Commitment and Support of Senior Management Like any major project or process within an organization, the CP process will fail without the clear and formal commitment of senior executive management. Only when the executive leader- ship emphasizes the importance of this process, preferably through personal involvement by the top executive (or by the leadership of a champion) will subordinate managers and employees provide the necessary time and resources to make the process happen. Support should then be gained from the communities of interest mentioned in the preceding section.

For our purposes, a community of interest is a group of individuals within an organization who are united by shared interests or values and who have a common goal of making the organization function to meet its objectives. An organization then develops and maintains its

Contingency planning management team

Organizational champion Chief operations officer

CPMT team lead/ project manager

Crisis management team leader

Business manager(s)

IT manager(s) InfoSec

manager(s)

Other reps: HR, PR, fin, legal, plant ops, etc.

Incident response

team leader

IR team members

DR team members

BC team members

CM team members

Disaster recovery

team leader

Business continuity

team leader

Figure 2-1 CPMT organization and structure

Beginning the Contingency Planning Process 51

own values, and that leads to the evolution of a unique organizational culture. Within the context of this discussion, there are three communities of interest with roles and responsibili- ties in information security:

● Managers and professionals in the field of information security ● Managers and professionals in the field of information technology ● Managers and professionals from general management

In theory, each role (and the community of interest fulfilling that role) must complement the others; in practice, this is often not the case.

Information Security Management and Professionals These job functions and organizational roles focus on protecting the organization’s information systems and stored infor- mation from attacks. In fulfilling this role, these individuals are often tightly focused on protect- ing the integrity and confidentiality of systems, and they sometimes lose sight of availability. It is important for this community to remember that ultimately all the members of the organization are focused on meeting the strategic and operational objectives of the organization.

Information Technology Management and Professionals Others in the organization are oriented toward designing, building, or operating information systems. This community of interest is made up of IT managers and various groups of skilled professionals in systems design, programming, networks, and related disciplines usually categorized as IT, or information technology. This community has many of the same objectives as the information security community. However, it focuses more on costs of system creation and operation, ease of use for system users, timeliness of system creation, as well as transaction response time. The goals of the IT community and the information security community do not always completely align, and depending on the organizational structure, this may cause conflict.

Organizational Management and Professionals The organization’s general management team and the rest of the resources in the organization make up the other major community of interest. This large group is almost always made up of other subsets of interest as well, including executive management, production management, human resources, accounting, and legal, to name just a few. The IT community often categorizes these groups as users of information technology systems, whereas the information security community often categorizes them as security subjects. The reality is that they are much more than this categorization implies. It is important for you to focus on the fact that all IT systems and information security objectives are created to implement the objectives of the broader organizational community and safeguard their effective use and operation. The most efficient IT systems operated in the most secure fashion ever devised are of no value if they do not bring value to the broad objectives of the organization as a whole.

Elements Required to Begin Contingency Planning The elements required to begin the CP process are a planning methodology; a policy environ- ment to enable the planning process; an understanding of the causes and effects of core pre- cursor activities, known as the business impact analysis (BIA); and access to financial and other resources, as articulated and outlined by the planning budget. Each of these elements

52 Chapter 2 Planning for Organizational Readiness

is explained in the sections that follow. Once the CPMT has been organized and staffed, it begins the development of CP policies and plans.

The CP methodology expands the four elements just noted into a multistep contingency pro- cess that an organization may apply to develop and maintain a viable contingency planning program. The master CP planning document serves as the focus and collection point for the deliverables that come from the subsequent steps.

For the complete CP development methodology, we have adapted NIST’s Special Publications 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems (2010) and Special Publications 800-61, Rev. 2, Computer Security Incident Handling Guide (2012) to include the prerequisite steps of organizing the CPMT and intermediate steps of formulating subordinate teams and plans. Here is the complete process:

1. Form the CPMT. Assemble the management team that will guide CP planning and exe- cution. This includes representatives from business management, operations, and the projected subordinate teams.

2. Develop the contingency planning policy statement. The CP policy is the formal policy that will guide the efforts of the subordinate teams in developing their plans, and the overall operations of the organization during contingency operations.

3. Conduct the business impact analysis (BIA). The BIA, described later in this chapter, helps identify and prioritize organizational functions, and the information systems and components critical to supporting the organization’s mission/business processes.

4. Form subordinate planning teams. For each of the subordinate areas, organize a team to develop the IR, DR, and BC plans. These groups may or may not contain individuals responsible for implementing the plan.

5. Develop subordinate planning policies. Just as the CPMT developed an overall CP pol- icy, the newly formed IR, DR, and BC planning teams will begin by developing an IR, DR or BC planning policy, respectively.

6. Integrate the BIA. Each of the subordinate planning teams will independently review and incorporate aspects of the BIA of importance to its planning efforts. As different teams may need different components, the actions and assessments of each team may vary.

7. Identify preventive controls. Assess those countermeasures and safeguards that mitigate the risk and impact of events on organizational data, operations, and personnel.

8. Organize response teams. Specify the skills needed on each subordinate response team (IR/DR/BC), and identify personnel needed. Ensure personnel rosters are exclusive (no personnel on two different teams) and that all needed skills are covered. These are the individuals who will be directly called up if a particular plan is activated in response to an actual incident or disaster.

9. Create contingency strategies. The CPMT, with input from the subordinate team lea- ders, will evaluate and invest in strategies that will support the IR, DR, and BC efforts should an event impact business operations. These include data backup and recovery plans, off-site data storage, and alternate site occupancy strategies.

10. Develop subordinate plans. For each subordinate area, develop a plan to handle the corre- sponding actions and activities necessary to (a) respond to an incident, (b) recover from a disaster, and (c) establish operations at an alternate site following a disruptive event.

Elements Required to Begin Contingency Planning 53

11. Ensure plan testing, training, and exercises. Ensure each subordinate plan is tested and the corresponding personnel are trained to handle any event that escalates into an inci- dent or a disaster.

12. Ensure plan maintenance. Manage the plan, ensuring periodic review, evaluation, and updating.

The discussion of the CP policy and the BIA occupies the balance of this chapter. The other stages are referred to throughout the remainder of the text.

Contingency Planning Policy Effective contingency planning begins with effective policy. Before the CPMT can fully develop the planning document, the team must receive guidance from the executive management, as described earlier, through formal contingency planning policy. The purpose of policy is to define the scope of the CP operations and establish managerial intent with regard to timetables for response to incidents, recovery from disasters, and reestablishment of operations for conti- nuity. This policy also establishes responsibility for the development and operations of the CPMT in general, and it may provide specifics on the constituencies of all CP-related teams.

The CP policy should, at a minimum, contain the following sections:

● An introductory statement of philosophical perspective by senior management as to the importance of contingency planning to the strategic, long-term operations of the organizations

● A statement of the scope and purpose of the CP operations, specifically stating the requirement to cover all critical business functions and activities

● A call for periodic (e.g., yearly) risk assessment and business impact analysis by the CPMT, to include identification and prioritization of critical business functions

● A specification of the major components of the CP to be designed by the CPMT, as described earlier

● A call for, and guidance in, the selection of recovery options and business continuity strategies

● A requirement to test the various plans on a regular basis (e.g., semiannually, annu- ally, or more often, as needed)

● Identification of key regulations and standards that impact CP planning and a brief overview of their relevancy

● Identification of key individuals responsible for CP operations—for example, establishment of the COO as CPMT champion, the deputy COO as CPMT team lead/project manager, the CISO as IR team lead, the deputy CIO as DR team lead, the manager of business operations as BC team lead, and the legal counsel as crisis management team lead

● A challenge to the individual members of the organizations, asking for their support, and reinforcing their importance as part of the overall CP process

● Additional administrative information, including the original date of the development of the document, dates of any formal revisions, and a schedule for periodic review and maintenance

Here is an example of a high-level policy:

54 Chapter 2 Planning for Organizational Readiness

Issue Statement

The XX Agency Automated Information Systems Security Program (AISSP) Handbook and the Office of Management and Budget Circular A-130, Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources require a contingency plan be developed and tested for each major Auto- mated Information System (AIS) facility and application. All systems that contain, use, or process Large Service Applications (LSA) data must have a documented plan on how the organization would continue its mission and provide continuity of data processing if service, use, or access was disrupted for an extended period of time.

Organization’s Position

XX Agency has been entrusted with sensitive, private data to accomplish its goals. For the success of XX Agency programs, LSA data must be available in the event of disrup- tions. A contingency plan includes preparatory measures, response actions, and restora- tion activities planned or taken to ensure continuation of the mission-critical functions.

Applicability

These procedures apply to data contained in the LSA system.

Roles and Responsibility

Director, Federal Systems shall publish and maintain policy guidelines for preparing and testing the LSA contingency plan, and assist in identifying the mission-critical applications.

Information systems security officer (ISSO) shall prepare policy guidelines for devel- oping the LSA contingency plan, review the contingency plan, and ensure the LSA contingency plan is updated and tested annually.

Supervisors shall assist in the development, review, and testing of the LSA contin- gency plan, determine which applications can revert to manual processing and which applications are mission critical and need priority automated processing, and provide the personnel needed for scheduled testing of the procedures.

LSA security officer shall work with security personnel to develop the LSA contin- gency plan, and coordinate LSA contingency plan development, updating, and test- ing with XX Agency personnel.

A Sample Generic Policy and High-Level Procedures for Contingency Plans1

Contingency Planning Policy 55

Contingency Plan Policy ● A contingency planning committee composed of the LSA security officer and

XX Agency personnel will develop, test, and maintain the LSA contingency plan. The plan should contain the following:

� All mission-critical applications shall be identified and ranked according to priority and the maximum permissible outage for each critical application.

� An inventory of all equipment and supplies and floor plan of the current operating facility shall be maintained.

� Specify how frequently applications, data, software, and databases are backed up and where the backups are stored off site.

� List the location of the alternate backup site. � Prepare alternate site operating procedures. � List the arrangement for delivery of backup data and software. � Identify the personnel designated to run the applications at the backup site;

travel arrangements, lodging, and per diem should be addressed if the backup site is not local.

● Prepare recovery procedures. ● Prepare testing procedures for the contingency plan. ● Contingency plan shall be marked, handled, and controlled as sensitive

unclassified information. ● Each page of the plan shall be dated. ● The plan shall be tested annually or when a significant change occurs to the application.

Compliance The requirement for each facility that processes applications critical to the performance of the organizational mission is contained in the XX Agency AISSP Handbook, and in the Office of Management and Budget Circular A-130, Management of Federal Information Resources, Appendix III, Security of Federal Automated Information Resources.

Supplementary Information XX Agency AISSP Handbook, May 1994

NIST Special Publication 800-100, Information Security Handbook: A Guide for Man- agers, Chapter 9, “Information Technology Contingency Planning.” January 1999.

Points of Contact Information Systems Security Officer LSA Security Officer – XX Agency Site

(This document was written for a large application. It can be modified to serve as a chapter in an organization’s information security manual by replacing any reference to one application with the words “all systems.”)

Source: http://csrc.nist.gov/groups/SMA/fasp/archive.html

56 Chapter 2 Planning for Organizational Readiness

Once the CPMT has the policy from the responsible senior executive, the CPMT lead calls a meeting to begin the planning process in earnest. Each CP meeting should be documented, both to provide guidance for future meetings and to track progress and deliverables set by the committee. The next major step is to conduct a business impact analysis.

Business Impact Analysis The business impact analysis (BIA) is an investigation and assessment of the impact that vari- ous events or incidents can have on the organization. A crucial component of the initial plan- ning stages, it also provides a detailed identification and prioritization of critical business func- tions, which would require protection and continuity in an adverse event.

The BIA, therefore, adds insight into what the organization must do to respond to adverse events, minimize the damage from such events, recover from the effects, and return to normal operations. One of the fundamental differences between a BIA and the risk management processes discussed in Chapter 1 is that the risk management processes identify the threats, vulnerabilities, and attacks to determine what controls can protect the information. The BIA assumes that these controls have been bypassed, have failed, or were otherwise ineffective in stopping the attack, and that the attack has been successful. In other words, it takes up where the risk assessment process leaves off.

The BIA begins with the prioritized list of threats and vulnerabilities that were identified in the risk management process, then enhances the list by adding some critical information. The ques- tion asked at this point is, “If an attack succeeds, what do you do next?” Obviously, the orga- nization’s security team does everything in its power to stop these attacks, but as you have seen, some adverse events, such as natural disasters, deviations from service providers, acts of human failure or error, and deliberate acts of sabotage and vandalism, may be unstoppable.

When undertaking the BIA, Zawada and Evans have noted the following five “Keys to BIA success” that an organization should consider:

1. Set the scope for the project carefully. Be sure to consider the functional and administrative units to include, the categories of risks to be addressed, and the range of impacts to be considered.

2. Initiate a data-gathering process that will find the information senior managers need to make informed decisions.

3. Seek out objective rather than subjective data. Subjective data can be useful when used by experienced analysts, but facts are important.

4. Determine the needs of higher management prior to the data collection. The final reported risk assessment and BIA must address those needs to be of value.

5. Gain validation of the results derived from the risk assessment and BIA from the owners of the business processes being examined, or else the final product may not have their support.2

Source: Zawada and Evans

The CPMT conducts the BIA in three stages, which are shown in Figure 2-2 and briefly described next. They will be more thoroughly covered in the following sections.

1. Assessing mission/business processes and recovery criticality

2. Identifying resource requirements

3. Identifying recovery priorities3

Business Impact Analysis 57

Determine Mission/Business Processes and Recovery Criticality The first major BIA task is to analyze and prioritize the organization’s business processes based on their relationships to the organization’s mission. Each business department, unit, or division must be independently evaluated to determine how important its functions are to the organization as a whole. For example, recovery operations would probably focus on the IT Department and network operation before turning to the Personnel Department’s hiring activ- ities. Likewise, recovering a manufacturing company’s assembly line is more urgent than recovering its maintenance tracking system. This is not to say that personnel functions and assembly-line maintenance are not important to the business, but unless the organization’s main revenue-producing operations can be restored quickly, other functions are irrelevant.

Note that the term “mission/business process” is used throughout this chapter, given that some organizations that conduct BIAs aren’t businesses and, thus, don’t have business pro- cesses per se. Don’t let the term, which is preferred by NIST, confuse you. It’s essentially another way of saying business process, which is a task performed by an organization or organizational subunit in support of the organization’s overall mission.

It is important to collect critical information about each business unit before beginning to prioritize the business units (see the section titled “BIA Data Collection” later in this chapter). The important thing to remember is that the focus of this stage is to avoid “turf wars” and select those business functions that must be sustained in order to continue business operations. Although individual managers or executives might feel that their function is the most critical to the organization, those functions might prove to be less critical in the event of a major incident or disaster.

A weighted analysis table can be useful in resolving the issue of which business function is the most critical to the organization. Putting together such a table begins by identifying the

From the CP team

Conduct the business impact analysis (BIA)

Determine mission/business

processes & recover criticality

Develop the CP policy statement

Identify resource requirements

Identify recovery priorities for

system resources

Form subordinate planning teams

(IR/DR/BC)

Develop subordinate

planning policies (IR/DR/BC)

Integrate the business impact analysis (BIA)

Identify preventive controls

Organize response teams (IR/DR/BC)

Create response strategies (IR/DR/BC)

Develop subordinate plans

(IR/DR/BC)

Ensure plan testing, training, and

exercises

Ensure plan maintenance.

Figure 2-2 Major stages of CP: BIA © Cengage Learning 2014

58 Chapter 2 Planning for Organizational Readiness

categories that matter most to the organization. For Hierarchical Access Ltd (HAL), the com- pany featured in this book’s case scenarios, typical functions might include:

● Enrolling new customers ● Managing customer accounts ● Providing Internet access ● Providing Internet services ● Providing help desk support ● Advertising services ● Supporting public relations

Once categories have been identified, weights can be assigned to each category. Typi- cally, the assigned weights add up to a value of 1 (or to 100 percent). Table 2-1 shows an example of a weighted factor analysis table. Here, the impact on profitability is assessed at 40 percent of the value brought to the organization, the contribution to stra- tegic objectives is assessed at 30 percent, and so on. As you can see in the right-most column, the percentages add up to 100.

Once the criteria have been weighted, the various business functions are identified. For each business function, an importance value is assessed on a scale of 1 to 10. After that, the weights are multiplied by the scores in each category. They are then summed to obtain that business function’s overall value to the organization. In Table 2-1, providing Internet services is determined to have a 9-out-of-10 impact on profitability and a 4-out-of-10 impact on internal operations. Overall, this business function is given a score of 8.2. Although the

(Note this is a partial table of functions and as such is only presented as an example.)

Business Function

Impact on Profitability (40 percent)

Contribution to Strategic Objectives (30 percent)

Impact on Internal Operations (20 percent)

Impact on Public Image (10 percent)

Total Weights (100 percent)

Enrolling new customers

8 8 3 6 6.8

Managing customer accounts

8 7 6 7 7.2

Providing Internet access

10 8 4 8 8

Providing Internet services

9 10 4 8 8.2

Providing help desk support

5 6 6 8 5.8

Advertising services 6 9 4 9 6.8

Supporting public relations

4 6 2 10 4.8

Table 2-1 Function-weighted prioritization © Cengage Learning 2014

Business Impact Analysis 59

number 8.2 does not mean anything in the abstract, it is the highest number for any of the business functions, which means that providing Internet access is the most important business function to this organization, based on the assumptions and evaluations made in this weighted factor analysis.

A useful tool in identifying and collecting information about business functions is the BIA questionnaire, which is discussed later in this chapter. The BIA questionnaire allows func- tional managers to directly enter information about their functions, the impacts the functions have on the business and other functions, and the dependencies that exist for the function from specific resources and outside service providers.

NIST Business Process and Recovery Criticality NIST Special Publication 800-34 Rev. 1 states the following:

FIPS 199 requires organizations to categorize their information systems as low impact, moderate impact, or high impact for the security objectives of confidentiality, integrity, and availability (RMF Step 1). The FIPS 199 category for the availability security objective serves as a basis of the BIA. Further identification of additional mission/business processes and impacts captures the unique purpose of the system.4

Source: NIST

Note that large quantities of information are needed and a BIA data collection process has to be done if the BIA process is to be made available for use in the overall CP development pro- cess. Data collection will be discussed later in this chapter, after each of the BIA investigation stages has been discussed. NIST has provided a BIA process and the data collection activities for a sample information system (see Figure 2-3).

Key Downtime Metrics When organizations consider recovery criticality, they usually think in terms of how much of a particular asset must be recovered within a specified time frame. The terms most commonly used are:

● Maximum tolerable downtime (MTD)—“The MTD represents the total amount of time the system owner/authorizing official is willing to accept for a mission/business

Stakeholder input

Business Process

Potential Impacts

Max Tolerable Downtime*

System Components

Recovery Time Objective*

FIPS 199

Process invoice 72 hours

30 hours

36 hours

Interdependencies *Notional Times

36 hours L

Confidentiality Integrity Availability

M od

er at

24 hours

12 hours

30 hours

Prepare report

Create budget

Respond to inquiries

Application server

Web server

Database server

Desktop computers

Operations - more than 1,000 staff affected

Reputation - media outlets announce concerns

Reputation - congressional insight

Customer Service - over 500 customer complaints

Figure 2-3 BIA process for a sample information system © Cengage Learning 2014

60 Chapter 2 Planning for Organizational Readiness

process outage or disruption and includes all impact considerations.”5 For example: “We can only have these systems down for 4 hours per month before negatively affecting operations.”

● Recovery time objective (RTO)—“The period of time within which systems, applica- tions, or functions must be recovered after an outage. RTOs are often used as the basis for the development of recovery strategies and as a determinant as to whether or not to implement the recovery strategies during a disaster situation. A similar term is maximum allowable downtime.”6 For example, “We can only be down for 3 hours after an incident before negatively affecting operations.”

● Recovery point objective (RPO)—“The point in time to which lost systems and data can be recovered after an outage as determined by the business unit.”7 Also referred to as maximum acceptable data loss. For example, “After an incident, we should only have to reload no more than the last 6 hours of data or processing to restore opera- tions to current status after the most recent data backup is restored.”

NIST Special Publication 800-34 Rev. 1 explains maximum tolerable downtime (MTD) this way:

The total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption, [including] all impact considerations. Determining MTD is important because it could leave contingency planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content.”8

Source: NIST

The recovery time objective (RTO), according to NIST, is “the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD.” It goes on to say that “determining the information system resource RTO is important for selecting appropriate technologies that are best suited for meeting the MTD.”9

Reducing RTO requires mechanisms to shorten start-up time or provisions to make data available online at a failover site.

The recovery point objective (RPO), according to NIST, is “the point in time, prior to a dis- ruption or system outage, to which mission/business process data can be recovered (given the most recent backup copy of the data) after an outage. Unlike RTO, RPO is not considered as part of MTD. Rather, it is a factor of how much data loss the mission/business process can tolerate during the recovery process.”10 Reducing RPO requires mechanisms to increase the synchronicity of data replication between production systems and the backup implementations for those systems.

Because of the critical need to avoid exceeding MTD, the RTO must be shorter than the MTD. Planners should determine the optimum point at which to recover the information sys- tem to meet BIA-mandated recovery needs while balancing the cost of system inoperability against the cost of resources required for restoring systems. This must be done in the context of the BIA-identified critical business processes and can be illustrated with a simple chart (see Figure 2-4).

Business Impact Analysis 61

The longer an interruption to system availability continues, the more impact it will have on the organization and its operations. When plans require a short RTO, the solutions will usually be more expensive to design and use. For example, if a system must be recovered immediately, it will have an RTO of 0. These types of solutions will require fully redundant alternate processing sites, which will have much higher costs. However, a longer RTO would be able to make use of a less expensive recovery system. Plotting the cost balance points will show an optimal point between disruption and recovery costs. The intersecting point, labeled the “Cost balance point” in Figure 2-4, will be dif- ferent for every organization and system, based on the financial constraints and operat- ing requirements.11

Prioritize Information Assets As the CPMT conducts the BIA, placing priorities and values on mission/business processes, it is helpful to understand the information assets used by those processes. The presence of high-value information assets may influence the valua- tion of a particular business process. Normally, this task is performed as part of the risk- assessment function of risk management. The organization identifies, classifies, and priori- tizes its information assets, placing classification labels on each collection or repository of information in order to better protect it. If the organization has not performed this task, then this is the appropriate time during the BIA to accomplish this task.

Identify Resource Requirements Once the organization has created a prioritized list of its mission and business processes, it can determine what resources would be needed to recover those processes and the assets associated with those processes. Some processes are resource intensive—for exam- ple, IT functions. Supporting customer data, production data, and other organizational information requires extensive sets of information processing, storage, and transmission (through networking). Other business production-oriented processes require complex or expensive components to operate. For each process (and information asset) identified in the previous BIA stage, the organization should identify and describe the relevant resources needed to provide or support the process. A simplified method for organizing this information is to put it into a resource/component table like the one shown in Table 2-2.

Cost balance point

Length of disruption time

Cost

Cost to recover (system mirror)

Cost of disruption (business downtime)

Cost to recover (tape backup)

Figure 2-4 Cost balancing © Cengage Learning 2014

62 Chapter 2 Planning for Organizational Readiness

Identify System Resource Recovery Priorities The last stage of the BIA is prioritizing the resources associated with the mission/busi- ness processes, which brings a better understanding of what must be recovered first, even within the most critical processes. With the information from Table 2-2 in hand, the organization can create additional weighted tables of the resources needed to support the individual processes. By assigning values to each resource—for example, using one of the schemes listed below—the organization will develop a custom-designed “to-do” list for when recovery commences. Whether it is an IR or DR scaled recovery or the implementation of critical processes at an alternate site during business continuity, this list will prove invaluable to those who are tasked with establishing (or reestablishing) critical processes quickly.

In addition to the weighted tables described earlier, a simple valuation scale such as Primary/ Secondary/Tertiary or Critical/Very Important/Important/Routine can be used. What is important is to avoid getting so bogged down in the process as to lose sight of the objective. A team that finds itself spending too much time developing and completing weighted tables may find a simple classification scheme more suited to its task. However, in a complex pro- cess with a large number of resources, a more sophisticated valuation method like the weighted tables may be more appropriate. One of the jobs of the CPMT, while preparing to conduct the BIA, is to determine what method of valuating processes and their supporting resources should be used.

Mission/Business Process Required Resource Component

Additional Resource Details Description

Provide customer support (help desk)

Trouble ticket and resolution application software

Application server w/LINUX OS, Apache server, and SQL database

Each help desk technician requires access to the organization’s trouble ticket and resolution software application, which is hosted on a dedicated server.

Provide customer support (help desk)

Help desk network segment

25 Cat5e network drops, gigabit network hub

The help desk applications are networked and require a network segment to access.

Provide customer support (help desk)

Help desk access terminals

1 Laptop/PC per technician, with Web-browsing software

The help desk applications require a Web interface on a laptop/PC.

Provide customer billing Customized accounts receivable application software

Application server w/LINUX OS, Apache server, and SQL database

Accounts receivable requires access to its customized AR software and customer database to process customer billing.

Table 2-2 Processes and required resources arranged in a resource/component table © Cengage Learning 2014

Business Impact Analysis 63

BIA Data Collection Although the BIA data collection process is not a discrete step in the BIA process, it should have been used along the way to document the efforts accomplished in earlier steps. To effec- tively perform the BIA, a large quantity of information specific to various business areas and functions is needed. There are a number of methods for collecting this information. Thus, a data collection plan should be established early on to make the overall process more effective. Methods to collect data include:12

● Online questionnaires ● Facilitated data-gathering sessions ● Process flows and interdependency studies ● Risk assessment research ● IT application or system logs ● Financial reports and departmental budgets ● BCP/DRP audit documentation ● Production schedules

Online Questionnaires As an aid in collecting the information necessary to identify and classify the business func- tions and the impact they have on other areas of the organization, an online or printed ques- tionnaire can collect and provide useful information to answer these and other critical ques- tions. This enables a structured method to collect the information directly from those who know the most about a business area and its functions.

As discussed under “Business Continuity Impact Analysis” on the Web site for the Texas State Office of Risk Management, the BIA questionnaire should cover the following areas:

● Function description: A brief description of the function being performed ● Dependencies: A brief description of the dependencies of the function; what has to

happen or needs to be available before the function can be performed? ● Impact profile: Is there a specific time of day, day of the week, week of the month,

or month of the year that the function is more vulnerable to risk/exposure or when the impact to the business would be greater if the function is not performed?

● Operational impacts: When would the operational impact to the business be real- ized if the function was not performed? Describe the operational impact.

● Financial impacts: When would the financial impact to the business be realized if the function was not performed? Describe the financial impact.

● Work backlog: At what point does the backlog of work start to impact the business? ● Recovery resources: What kind of resources are needed to support the function, how many

are needed, and how soon are they needed after a disruption (phones, desks, PC, etc.)? ● Technology resources: What software and/or applications are needed to support the function? ● Stand-alone PCs or workstations: Does the function require a stand-alone PC or

workstation? ● Local area networks: Does the function require access to the LAN?

64 Chapter 2 Planning for Organizational Readiness

● Work-around procedures: Are there currently manual work-around procedures in place that enable the function to be performed in the event that IT is unavailable? If so, how long can these work-arounds be used to continue the function?

● Work at home: Can the function be performed from home? ● Workload shifting: Is it possible to shift workloads to another part of the business

that might not be impacted by the disruption ● Business records: Are certain business records needed to perform the function? If

so, are they backed up? How? With what frequency? ● Regulatory reporting: Are regulatory documents created as a result of the function? ● Work inflows: What input is received, either internally or externally, that is needed

to perform the function? ● Work outflows: Where does the output go after it leaves the functional area, or in

other words, who would be impacted if the function were not performed? ● Business disruption experience: Has there ever been a disruption of the function?

If so, give a brief description. ● Competitive analysis: Is there a competitive impact if the function is not performed? When

would the impact occur? When would the company potentially start losing customers? ● Other issues and concerns: Any other issues relevant to the success of performing

the function13

Source: Texas State Office of Risk Management

In the completion of the BIA, the organization should also address the RTO, RPO, and the dependencies between the BIA and other areas.

The BIA questionnaire presented below, which is derived from a number of sources,14 is organized into two major parts. Part I, presented in Table 2-3, is designed to evaluate the entire business area and identify the critical functions contained within that area. Part II, pre- sented in Table 2-4, is designed to evaluate each specific function for impact, dependencies, and other critical information necessary for the BIA process and eventually the CP plan.

Part I: Business Area Impact

This questionnaire must be filled out for each business area within ABC Co.

(Note: Excess form blanks compressed to save space)

Function:

Business area:

Departments contained within this area:

Area manager:

Overall functional priority (to be added by CPMT):

Date of BIA questionnaire:

Questionnaire completed by:

Table 2-3 Sample BIA questionnaire, Part 1 (continues) © Cengage Learning 2014

BIA Data Collection 65

Area Description: Describe the corporate mission of this area.

What functions are conducted within this area?

What changes have occurred within this area since the last BIA review?

What changes are expected within this area before the next BIA review?

Impact Assessment

Select the statement that best describes the effect on this business area should there be an unplanned interruption of normal operations:

ABC Co. will feel an impact within:

[ ] 8 hours of an interruption [ ] 24 hours of an interruption [ ] 3 days of an interruption [ ] 5 days of an interruption [ ] 10 days of an interruption [ ] 30 days of an interruption

What is the estimated recovery time objective (RTO) for this area (time after interruption before operations are critically impacted)?

[ ] Tier 1 (0–12 hours) This business area is vital.

[ ] Tier 2 (12–24 hours) This business area is critical.

[ ] Tier 3 (24–48 hours) This business area is essential.

[ ] Tier 4 (48–72 hours) This business area is important.

[ ] Tier 5 (72–96 hours) This business area is noncritical.

[ ] Tier 6 (more than 96 hours) This business unit/cost center is deferrable.

What is the estimated recovery point objective (RPO) for this function (point in time by which function must be recovered to support operations)?

[ ] Point 1 (less than 6 hours) [ ] Point 2 (less than 24 hours)

[ ] Point 3 (less than 48 hours) [ ] Point 4 (less than 72 hours)

[ ] Point 5 (more than 72 hours)

Identify the extent of exposure that would be incurred by the business area and/or ABC Co. should an unplanned interruption occur.

Additional expense

Table 2-3 Sample BIA questionnaire, Part 1 (continues) © Cengage Learning 2014

66 Chapter 2 Planning for Organizational Readiness

Assets

Customer service

Revenue loss per day

Productivity loss per day

Financial exposure

Goodwill

Regulatory/legal

What is the estimated dollar loss for the company from this business area should an interruption occur for a period of more than: (select one range)

<$20,000 $20,000 to < $50,000

$50,000 to <$100,000

$100,000 to <$250,000

$250,000 or more

1 business day

2 business days

3 business days

4 business days

5 business days

2 weeks

3 weeks

4 weeks

2 months

3 months

Dependencies

List key functions that define the functionality of this business unit/cost center. Identify input, source, input frequency (F1), how manipulated, output, recipient, and output frequency (F2) for each.

Frequency (F): H Hourly W Weekly Q

Quarterly

D Daily M Monthly A Annually

Function Input Source F1 Manipulated Output Recipient F2

BIA Data Collection 67

Identify any networks (LAN, intranet, or Internet) or network-based applications or data sources the business areas depends on:

Network Application/data source

Identify any service bureaus or external vendors the business areas depends on:

SB/vendor Purpose

Table 2-3 Sample BIA questionnaire, Part 1 (continued)

Part II: Functional Impact

This questionnaire must be filled out for each major function within ABC Co.

Function:

Business area:

Department:

Senior manager:

Functional manager:

Overall functional priority (to be added by CPMT):

Date of BIA questionnaire:

Questionnaire completed by:

Function Description: Describe the processes necessary to support the function:

Function Deliverables: Describe the output of this function as it supports the organization:

Dependencies:

Input: From what process does this function receive input to initiate its process? Include source name, location, and method of receipt.

What effect is there on this function if the input were not available?

What work-around is required to continue this function if the input were not available?

Table 2-4 Sample BIA questionnaire, Part 2 (continues)

68 Chapter 2 Planning for Organizational Readiness

Output: What process receives the deliverable from this function? Include client name, location, and method of receipt.

What effect is there on the client if this function were not available?

What work-around is required to provide the deliverable if this function were not available?

Resources: What personnel resources are required to support this function?

What internal information is needed to support this function?

What external information is needed to support this function?

What application(s) is/are used by this function, and who provides support?

What hardware is used by this function, and who provides support?

What network resource(s) is/are used by this function, and who provides support?

Impact:

For each of the following items, rate the function’s impact on the corresponding criteria:

1 (no impact) 2 (low) 3 (moderate) 4 (high) 5 (very high)

Activity:

Additional expense:

Assets:

Revenue loss per day:

Productivity loss per day:

Customer service:

Goodwill:

Regulatory/legal:

Table 2-4 Sample BIA questionnaire, Part 2 (continues) © Cengage Learning 2014

BIA Data Collection 69

For each of the following activities, identify the extent to which the corresponding procedure or plan is implemented for this function:

Activity None exist Present but not implemented

Implemented but not rehearsed

Rehearsed but not tested

Fully implemented, rehearsed, and tested

Manual procedures

Briefly describe the manual procedures for this function:

Risk Mitigation Plans

Briefly describe the risk mitigation plans for this function:

Incident Response Plans

Briefly describe the incident response plans for this function:

Disaster Recovery Plans

Briefly describe the disaster recovery plans for this function:

Business Continuity Plans

Briefly describe the business continuity plans for this function:

What is the estimated recovery time objective (RTO) for this function (time after interruption before operations are critically impacted)?

[ ] Tier 1 (0–24 hours) [ ] Tier 2 (24–48 hours)

[ ] Tier 3 (48–72 hours) [ ] Tier 4 (72–96 hours)

What is the estimated recovery point objective (RPO) for this function (point in time by which function must be recovered to support operations)?

[ ] Point 1 (less than 6 hours) [ ] Point 2 (less than 1 business day)

[ ] Point 3 (less than 2 business days) [ ] Point 4 (less than 3 business days)

[ ] Point 5 (3 or more business days)

Interdependencies

What is the relative importance of the following support functions to maintain this function in the event of a disaster?

Support Function Not important Somewhat important Important Very important

Extremely important

Telephones

Cell phones

Fax

Radio

Table 2-4 Sample BIA questionnaire, Part 2 (continues) © Cengage Learning 2014

70 Chapter 2 Planning for Organizational Readiness

This questionnaire, although not as comprehensive as may be needed by some organizations, provides the core of the information needed to complete the BIA. This type of questionnaire could be administered as an HTML document on the company intranet, allowing ease of access and data collection and evaluation.

Facilitated Data-Gathering Sessions A focus group, also known as a facilitated data-gathering session, is a commonly used tech- nique for collecting information directly from the end users and business managers. Time per- mitting, individuals from throughout a particular business area, along with their managerial team, are brought together to brainstorm the answers to the questions posed by the BIA pro-

Data network

Other network

Wireless data

Internet

Intranet

Other: ____________

What interdependencies exist between this function and each of the following functions?

Supply chain

Environmental health & safety

Human resources

Major vendors & suppliers

Other:

Do your current IR/DR/BC plans have recovery strategies that meet your RTO for this function?

Does this function include an emergency response plan?

Date of last BIA assessment:

Have there been any changes to the business function since your last BIA assessment? If so describe:

Table 2-4 Sample BIA questionnaire, Part 2 (continued) © Cengage Learning 2014

BIA Data Collection 71

cess. Unless steps are taken to ensure a relaxed, productive session, these meetings may not yield the quantity or quality of information desired. Providing a clear structure to the ses- sions, encouraging dialog, and restricting the managers’ ability to take control are important ways to ensure that the end-user representatives have an opportunity to contribute to the process.

Process Flows and Interdependency Studies Systems diagramming is a common approach in the discipline of systems analysis and design. It is used to understand the ways systems operate and to chart process flows and interdependency studies for both manual and automated systems. Common diagramming techniques, such as use case diagrams and supporting use cases, are specifically designed to help understand the interactions between entities and business functions. The sample use case diagram showing the interactions between a company’s Web commerce functions and its customers is shown in Figure 2-5. Table 2-5 provides descriptions of the ways the business functions are used.

Print client list *

* *

* **

Caedee hannah

Walker

Client

KoKo’s canine pet club

Print walk schedule

Invoice client

Figure 2-5 Example of a use case diagram

Use Case Description

Project name: KoKo’s Canine Pet Club Date prepared: 11/21/04

Use case name: Register New Client ID: 1 Importance level: High

Primary actor: Client Use case type: Detail, Essential

Stakeholder and interest:

Client: Wants to get registered in order to use the dog-walking service

Employees: Want more business so they can keep their job

Table 2-5 Descriptions for sample use case diagram (continues) © Cengage Learning 2014

72 Chapter 2 Planning for Organizational Readiness

Other modeling techniques drawn from systems analysis and design include Uniform Model- ing Language models such as class diagrams, sequence diagrams, and collaboration diagrams. Other modeling techniques such as traditional systems analysis and design approaches, including workflow, functional decomposition, and dataflow diagrams, may also be useful. Many of these are quite complex, and creating them with the requisite level of detail may be beyond the abilities or resources available to the BIA team. However, if the organization already prepares these types of models as a function of ongoing systems development activities, then these modeling approaches may provide an excellent way to illustrate how the business functions. Figure 2-6 shows a simplified class diagram drawn from the object classes used to support the use case documented earlier.

Caedee Hannah: Wants as many customers as she can get to increase profit

Brief description:

This use case describes the process by which a new client and pet is registered with the pet club.

Trigger: A new client comes into the store to register.

Trigger type: External

Relationships:

Association: Client

Include:

Extend:

Generalization:

Normal flow of events:

1. A client comes into the store and requests to register with the service.

2. Ms. Hannah sits down with the client to discuss the service.

3. Basic information is collected and entered directly into the system.

4. Fees are negotiated and agreed upon.

5. Preferred walk time and walker are entered into the system.

6. Client and pet are issued a customer number to uniquely identify them.

Subflows:

None documented

Alternatives/exceptional flows:

None documented

Table 2-5 Descriptions for sample use case diagram (continued) © Cengage Learning 2014

BIA Data Collection 73

Figure 2-7 shows a simplified sequence diagram used to document the ways that the actors and object classes shown in Figure 2-6 interact.

-Name -Address -City -State -Zip -Phone -Emergency Phone -Customer ID -Comments

-Name -PetID -Weight -Temperment -Quoted Price -Preferred Walk Time -Preferred Walker

-Day -Month -Year -Time

-Name -Employee ID -Cell Number -Home Number1 1..*

0..*

0..* 0..*

0..*

Client Pet

Walker

Walk Times

Figure 2-6 Example of a class diagram

Caedee Walker Client

GetClients( )

CollectsInfo

FinalizeClient

WalksPets( )

Clients: List Schedule: List RegisterClient Walk: PET

GetWalkSchedule( )

RequestRegistration

NegotiatesPrice

Figure 2-7 Example of a sequence diagram © Cengage Learning 2014

74 Chapter 2 Planning for Organizational Readiness

Figure 2-8 documents the way in which the object classes as described in Figure 2-6 interact as the system operates.

Risk Assessment Research As described earlier, an organization’s risk assessment and risk management effort can pro- vide a wealth of information that can be used in the BIA. Although some modification may be necessary, the risk management process is in fact the primary starting point for the BIA. If the organization has not performed this activity, some alternative efforts are required. Additionally, the teams may collect information from outside sources on risk assessment.

IT Application or System Logs When completing the many weighted tables used in the BIA, an IT staff may prove particu- larly valuable in determining categorical data on frequency of occurrence, probability of suc- cess, and so on by providing information from the various logs their equipment maintains. These logs collect and provide reports on failed login attempts, probes, scans, denial- of-service attacks, and malware detected, to name a few. This can provide a much more accurate description of the attack environment that the organization faces. In some cases, the BIA team may be able to ask the IT Department to collect information from these sys- tems that it is currently not collecting.

Financial Reports and Departmental Budgets Running a business requires great attention to financial detail. As a normal part of the administration of an organization, a number of financial documents are created that can pro- vide insight into the operations of the business, including the costs and revenues provided by

Client Caedee Hannah

1: Requests Membership 2:CollectInfo 5:Fix Price

6:SetWalkTime 7:SetWalker

ClientDatabase

PetDatabase

Walker

WalkTimes

3:E nte

rCli ent

info

4:Enter Pet Info

8:Add Appointment 9:Fill Time Slot

Figure 2-8 Example of a collaboration diagram © Cengage Learning 2014

BIA Data Collection 75

each functional area. This information is useful in determining the prioritization of business areas and functions within those areas. It provides insight into the contribution of each to the organization’s profitability and revenues.

The most common method of calculating business impact is to review financial reports and budgets. Lost sales, idle personnel costs, and other opportunity costs are easily obtained using these documents.

Audit Documentation As is often the case in larger organizations, especially publicly traded firms, the organization has paid external consultants to audit their functions for compliance with federal and state regula- tions, with national or international standards, or as part of a proactive ongoing improvement program. These audit reports can provide additional information for the BIA process.

Production Schedules Finally, information gained from production schedules, marketing forecasts, productivity reports, and a host of other business documents can also prove valuable in the completion of the BIA. Although the organization may neither have all these sources available nor desire to include all of them, it is advantageous to include information collected from multiple sources rather than redundantly re-collecting it from the same sources for this process. The important thing to remember is to make sure the information you use, if it is not collected directly by the BIA team, is current and accurate. If it is used to make decisions that affect the organization’s ability to react and recover from attacks, undated information may often be worse than no information at all, as it adds to confusion.

Budgeting for Contingency Operations As a final component to the initial planning process, the CPMT must prepare to deal with the inevitable expenses associated with contingency operations. Although some areas (such as inci- dent response) may not require dedicated budgeting, other areas (such as disaster recovery and business continuity) do require ongoing expenditures, investment, and service contracts to sup- port their implementation. The ugly reality is that many organizations are “self-insured” against some types of losses, such as theft of technology, equipment, or other resources. Ide- ally, this means that in lieu of payments to an outside insurance organization, the organization puts a set amount each fiscal cycle into an account it can then draw upon should replacements be required. With tight budgets and drops in revenues, however, some organizations forego these investments, instead betting on the probability that such losses, if they occur, will be minimal and can be funded out of normal budgets. Should a disastrous expense occur, how- ever, the organization is at risk of complete failure and possible closure. Some of the budget- ing requirements of the individual components of CP planning are presented in the sections that follow.

Incident Response Budgeting To a large extent, IR capabilities are part of a normal IT budget. It is customary for the CIO to have his or her managers ensure that data protection and response, as well as backup and recovery methods (described in later chapters), are part of normal operations. In addition,

76 Chapter 2 Planning for Organizational Readiness

uninterruptible power supplies (UPSs) are part of normal equipment expenditures of the IT operations. Other items frequently purchased that have an IR role are antivirus/antispyware/ antimalware software, redundant arrays of independent disks (RAID), and network-attached storage (NAS) or storage area networks (SANs), the latter two for storing critical user files in a common area that can be included in the backup and recovery schemes. The inclusion of such items as part of normal controls or safeguards for IT operations will most often fall within the normal information security function for the IT Department. Where additional expenses might arise is in the protection of user data outside the common storage areas. If end users want to back up their individual data, additional equipment, such as tape drives or writeable DVD systems, is needed. With the death of the floppy disk and the increase in popularity of its successor, the USB flash drive, the burden of protecting removable media has shifted. Now that modern systems are capable of booting from USB flash drives and external USB hard drives, the protection burden is focused on these tools.

The only area in which additional budgeting is absolutely required is the maintenance of redundant equipment if there are equipment failures resulting from incidents. The so- called “rule of three” is quite useful in preparing for this inevitability. According to this rule, an organization should keep three levels of computer system environments available: an online production system, an online or very nearly online backup system with a quality assurance system to serve as a ready reserve for the production systems, and an offline testing and development system to stage software nearing the end of the change manage- ment process.

In most organizations, critical equipment has redundancy incorporated into the systems. Online “hot” servers like domain controllers, Web servers, database servers, and e-mail ser- vers frequently have a backup or “warm” server providing redundant functions that are standing by in a near-online state. Should the hot server go down, the warm server steps up to become the hot server and provides the functions needed to the clients. In case the hot server goes down and the warm server is now the hot server, the rule of three requires an organization to maintain a cold server or other equipment to allow the timely creation of a new warm server to provide needed redundancy. The hot server can be taken offline and repaired as needed while there’s still redundancy in the system. Some common components, such as network cards and small hubs, may only require a few “shelved” items to provide redundancy for a larger number of in-use items. The key is to ensure that any offline cold server is equipped and configured exactly like the hot and warm versions. In fact, many orga- nizations use the cold server as a test server to ensure that any added patches or upgrades do not negatively affect other applications or services.

Disaster Recovery Budgeting The number one budgetary expense for DR is insurance. Insurance policies provide for the capabilities to rebuild and reestablish operations at the primary site. Should fire, flood, earth- quake, or other natural disaster strike, the insurance carrier oversees the funding of replace- ment structures and services until the primary site is restored. It is, therefore, essential that the insurance policies be carefully scrutinized to ensure that effective coverage is provided, with the understanding that more comprehensive coverage costs more. Most insurance poli- cies have deductibles, and larger deductibles provide lower monthly premiums. Setting aside a fund specifically dedicated to cover these deductibles ensures that they do not cause finan- cial problems while the organization is getting reestablished.

Budgeting for Contingency Operations 77

One problem with insurance is that much of the damage from electronic attacks is not cov- ered in policies. Although some forward-thinking insurance companies are starting to roll out data loss policies, many organizations are not able to afford them.15 Natural disasters are familiar to insurance adjustors, but losses from, say, a distributed denial-of-service attack (DDoS) are not so familiar, despite the fact that DDoS attacks on Amazon, eBay, E*TRADE, Dell, Yahoo!, and a host of other companies resulted in lost revenues of over $1.7 billion during a 4-hour period in 2000.16 Although this attack did not require relocating employees and equipment, it did require extensive reconfiguration of network connections, activation of backup carrier services and circuits, and a host of other DR procedures.

Insurance was not available at the time. Today, it is; however, some companies are finding it difficult to estimate exactly how much they will need in order to cover expected losses. In 2009, Heartland Payment Systems took out a $30 million dollar “cyber insurance policy” specifically designed to cover losses in online commerce. So, the good news is that they were covered when they suffered a data breach, later that year. The bad news is that the breach resulted in losses estimated at over $145 million. Their insurance company paid the claim—$30 million dollars, as insured.17

How do you decide if hacker insurance is needed?

● Is your potential liability big enough to justify concern about the possibility of a loss whether from loss of an asset, loss of access, or loss of prestige?

● Are your online activities a significant part of the business? ● Do you have electronic assets that are valuable proprietary information that are

reachable over public networks and might be stolen? ● Would you lose a significant amount of money if your systems are denied access to

the Internet?

Many expenses are not covered by insurance—loss of water, loss of electricity, loss of data, and the like. It is important to include all the items the organization will need to support operations in the BIA and then determine which of them are covered by insurance and which are not.

Business Continuity Budgeting In contingency planning operations, business continuity requires the largest budget expenditure. As will be described in later chapters, maintaining service contracts to cover all the contingencies that the organization faces can be quite expensive. The service level agreements (SLAs) for hot sites, for example, require a dedicated duplicate facility complete with servers, networking devices, telephony devices—essentially everything except data and personnel. The cost to main- tain such a high level of redundancy can be staggering. Every level of the continuity plan includes expenses, even mobile services, whose providers are capable of rolling out specially con- figured tractor-trailers equipped so that the organization can inhabit them until it is ready to move its operations back to the primary site. Unless the organization budgets and contracts for these services well in advance, it may find itself in a financial bind when it finally needs them.

The organization should have a “war chest” of funds set aside to purchase items as they are needed during the continuity operations. It could establish safety deposit boxes at a local bank with corporate credit cards, purchase orders, and even cash. Just the expenses associ- ated with office supplies can be quite staggering if the organization has to purchase sufficient stock to maintain operations for an extended time.

78 Chapter 2 Planning for Organizational Readiness

Another expense not normally budgeted for is employee overtime. Having to reestablish operations at another location inevitably includes extensive overtime for nonsalaried employ- ees. Unless a reserve fund is prepared in advance, the expenses associated with late nights and early mornings can quickly mount, unbalancing the organization’s precarious finances at such a hectic time.

Crisis Management Budgeting The last item to plan a budget for is crisis management. Although the details of crisis management are covered in later chapters, it is important to know that the fundamentals of crisis management are focused on the potential for physical and psychological losses associated with catastrophic disasters, like the World Trade Center attacks of September 11, 2001. The primary budget items here are employee salaries, should the employees be unable to come to work. The organization may wish to establish a minimum (such as a 30-day) budget for paid leave as employees wait at home to see if they in fact have a job to come back to.

Companies may also want to consider budgeting for contributions to employee loss expenses, such as funeral and burial expenses, as well as for counseling services for employees and loved ones, if these are not specifically covered in the current benefits packages.

Chapter Summary ● Contingency planning (CP) is improved by approaching it with a systematic

methodology addressing the challenges facing organizations during an incident, disaster, or other crisis. To begin, an organization must establish an entity that will be responsible for contingency policy and plans, such as a contingency plan- ning management team (CPMT), which is the collection of individuals responsible for the overall planning and development of the contingency planning process. The CPMT is responsible for obtaining commitment and support, managing the overall process, writing documents, conducting the business impact analysis (BIA), organizing and staffing the leadership for subordinate teams, and providing guid- ance to and integrating the work of the subordinate teams. A typical roster for the CPMT may include: a champion, a project manager, and a number of addi- tional team members as well as representatives from other business units.

● Effective CP begins with effective policy. The CPMT must receive guidance from executive management through formal CP policy. CP policy should contain: an intro- ductory statement of philosophical perspective; a statement of the scope and purpose of the CP operations; a call for periodic risk assessment and business impact analysis; a specification of the major components of the CP; a call for, and guidance in, the selection of recovery options and business continuity strategies; a requirement to test the various plans on a regular basis; identification of key regulations and standards that affect CP planning and a brief overview of their relevancy; identification of key individuals responsible for CP operations; and a challenge to the individual members of the organizations, asking for their support and reinforcing their importance as part of the overall CP process; additional administrative information.

Chapter Summary 79

● A BIA is an investigation and assessment of the impact that various events or inci- dents can have on the organization. It also provides a detailed identification and pri- oritization of critical business functions, which would require protection and continu- ity in an adverse event. The BIA adds insight into what the organization must do to respond to adverse events, minimize the damage from such events, recover from the effects, and return to normal operations. A BIA is conducted in three stages: assessing mission/business processes and recovery criticality, identifying resource requirements, and identifying recovery priorities. When organizations consider recovery criticality, they usually think in terms of maximum tolerable downtime, recovery time objective, and recovery point objective. A key element is placing priorities and values on mis- sion/business processes. Once the organization has created a prioritized list of its mis- sion and business processes, it can determine what resources would be needed to recover those processes and the assets associated with those processes.

● The number-one budgetary expense for DR is insurance. Most insurance policies have deductibles, and larger deductibles provide lower monthly premiums. Setting aside a fund specifically dedicated to cover these deductibles ensures that they do not cause financial problems while the organization is getting reestablished. In CP operations, business continuity requires the largest budget expenditure. Another expense not normally budgeted for is employee overtime. Crisis management budgets consist mostly of employee salaries. Companies may also want to consider budgeting for contributions to employee loss expenses, such as funeral and burial expenses, as well as for counseling services for employees and loved ones.

Review Questions 1. What is the first step in beginning the contingency planning process?

2. What are the primary responsibilities of the contingency planning management team (CPMT)?

3. What four teams may be subordinate to the CPMT in a typical organization?

4. The CP process will fail without what critical element?

5. What are the three communities of interest, and why are they important to CP?

6. What are the elements needed to begin the CP process?

7. What are the major sections in the CP policy document?

8. What is a business impact analysis (BIA), and why is it important?

9. What major objectives should be considered when conducting the BIA?

10. What are the usual stages in the conduct of the BIA?

11. What is a business process?

12. When confronted with many business functions from many parts of the organization, what is a useful tool that can be used to determine what the organization considers the most critical?

80 Chapter 2 Planning for Organizational Readiness

13. What are the most common downtime metrics used to express recovery criticality?

14. What is maximum tolerable downtime (MTD)?

15. What is recovery time objective (RTO)?

16. What is recovery point objective (RPO), and how does it differ from recovery time objective?

17. What are the primary means for collecting data for the BIA?

18. What is a facilitated data-gathering session?

19. What are some items usually included in routine IT operations budgets that can be considered part of CP requirements?

20. Beyond those items that are funded in the normal course of IT operations, what are the additional budgeting areas for CP needs?

Real-World Exercises Exercise 2-1 Using a Web browser and a search engine, search the terms “BP deepwater disaster plan failure.” You will find many results. Select one article and iden- tify what that article considers a shortcoming in BP’s planning. What part of

the contingency planning process came up short (IR, BP, or CP)? How could the shortcoming have been prevented?

Exercise 2-2 Using a Web browser and a search engine, search the terms “CitiBank backup tapes lost.” You will find many results. Select one article and identify what that article considers a short- coming in CitiBank’s planning. What part of the contingency planning process came up short (IR, BP, or CP)? How could the shortcoming have been prevented?

Exercise 2-3 Using a Web browser and a search engine, search the terms “I-35 bridge collapse and response.” You will find many results. Select at least three articles to skim through for the impact on human life, then answer this question: Did contingency planning save lives in this disaster?

Exercise 2-4 Visit the article abstract at www.ncjrs.gov/App/publications/Abstract.aspx?id=246582. Read the abstract, and then answer this question: Do you think having a simulator for training and readiness would help or hinder the quality of response to contingencies? Why or why not?

Real-World Exercises 81

Hands-On Projects

In this exercise, we will set up a virtual system running Security Onion, an open source intrusion detection and network monitoring application. We will use Security Onion in future Hands-On Projects, so it’s important to get it set up and running now. You will need to download the ISO from http://source forge.net/projects/security-onion/files. We will use the security-onion-live- 20120125.iso file to build our virtual image.

We will build the virtual image using VMware Player, a free virtualization application. VMware Player can be downloaded from www.vmware.com/products/player. Installing and configuring VMware Player is outside the scope of this textbook but is a relatively simple process to complete.

1. Start VMware Player and select the Create a new Virtual Machine link.

2. Choose the Installer disc image file (iso) option, and click Browse.

3. When the navigation window opens up, navigate to the folder where you saved the Security Onion ISO and double-click the file.

4. Once the navigation window closes, click Next.

5. Give your virtual image a name, such as “Security Onion for IRDR.”

6. Verify that the location being used is appropriate. If it is not, change it to an appropri- ate location.

7. Click Next.

8. Set the maximum disk size to 20 GB, then click Next.

9. Click Customize Hardware….

10. In the left window, click Memory and change the memory to 2048 MB.

11. In the left window, click Network Adapter, change the Network connection setting from NAT to Bridged, then click Close.

12. Click Finish to finish configuring the features of your virtual system, which will now power on.

13. Once the start-up menu appears, select the install option and press Enter.

14. Choose the appropriate language and click Forward.

15. Choose the appropriate region and time zone, then click Forward.

16. Examine the suggested option for your keyboard. If the suggestion is not correct, click the Choose your own radio button and select the appropriate option.

17. Click Forward.

Now, we will format the 20 GB virtual drive we assigned earlier in the setup, and we will install Security Onion to the space. Make sure the “Erase and use the entire disk” option is selected, and that the VMware drive is selected. This should be the default option. Your screen should look similar to the one shown in Figure 2-9.

82 Chapter 2 Planning for Organizational Readiness

18. Click Forward. You may experience a delay while the drive space is formatted.

19. Once the drive space is formatted, Security Onion will begin the actual installation process. Enter your name, username, password, and computer name in the appropriate fields, and then click Forward. The username and password you create here are for the admin account, so take note of them for use in future exercises and do not forget or lose them. Your screen should look similar to what is shown in Figure 2-10 before you click Forward.

Figure 2-9 Security Onion disk formatting Source: Security Onion

Figure 2-10 Admin user setup Source: Security Onion

Hands-On Projects 83

20. Click Install. You will experience a delay while Security Onion completes the installa- tion process into the virtual system.

21. After the installation process completes, click Restart Now.

22. When prompted, press Enter.

23. After the virtual image reboots, you will be taken to the login screen. Use the credentials you created earlier to authenticate. Your screen should look similar to what is shown in Figure 2-11. Click Log In.

24. Double-click the Setup icon on the desktop. When prompted, enter the password you created on initial setup.

25. Click Yes, Continue!

26. Click Yes, use Quick Setup!

27. Enter the username you wish to use for the Sguil and Squert applications. Your screen should look similar to the one shown in Figure 2-12. Click OK.

Figure 2-11 Security Onion login screen Source: Security Onion

Figure 2-12 Sguil username Source: Security Onion

84 Chapter 2 Planning for Organizational Readiness

28. Enter an e-mail address to use for logging into Snorby, then click OK.

29. Enter the password you wish to use for the Sguil, Squert, and Snorby applications. Your screen should look similar to the one shown in Figure 2-13. Click OK.

30. Retype the password you entered in Step 29, then click OK.

31. Click Yes, proceed with the changes!

32. After a brief delay while the changes are made, you are done with setup. Your screen should look similar to the one shown in Figure 2-14. Click OK to complete Sguil setup.

Figure 2-13 Sguil password Source: Security Onion

Figure 2-14 Security Onion setup complete Source: Security Onion

Hands-On Projects 85

Endnotes 1. Federal Agency Security Practices (FASP). “Sample Generic Policy and High-Level Pro-

cedures for Contingency Plans.” National Institute of Standards and Technology (NIST). Accessed May 11, 2005 @ http://csrc.nist.gov/fasp.

2. Zawada, B., & L. Evans, L. “Creating a More Rigorous BIA.” Proceedings of the Con- tingency Planning & Management West Conference, Vol 7, 7, p. 24 (2002).

3. Swanson, M., Bowen, P., Phillips, A., Gallup D., and D. Lynes. NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems. May 2010. Accessed April 26, 2011 @ http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34- rev1_errata-Nov11-2010.pdf.

4. Ibid.

“And the next event in this scenario is …” JJ made a dramatic pause. “The power came back on 27 minutes after it was terminated,” JJ then read from

the card. He looked up at the team, ready to continue the rehearsal.

Discussion Questions ● In the opening scenario, the group was practicing for a snow emergency. Other

than power outages, what incident cards would you expect to see? For each of the incident cards you listed, what would be the proper response of the organization?

● How often should an organization rehearse its contingency plans? ● Who should coordinate rehearsal of the contingency plans? Why would that be

the appropriate person? ● What degree of cross-training between the various roles in the plans is most

effective? Identify the advantages and disadvantages of such a cross-training plan. What trade-offs do you think exist between extensive and minimal cross-training?

● Notice that Amanda Wilson was not at this rehearsal. Do you think it is impor- tant that the CIO, or even the CEO, participate in this kind of readiness exer- cise? Why or why not?

● How can you make progress in contingency planning in the face of resistance from upper management?

Closing Case Scenario: Outrageously Odd Outages

86 Chapter 2 Planning for Organizational Readiness

5. “Maximum Tolerable Downtime (Definition).” Albion Research Ltd. Accessed Novem- ber 6, 2012 @ www.riskythinking.com/glossary/maximum_tolerable_downtime.php.

6. Swanson, M., Bowen, P., Phillips, A., Gallup D., and D. Lynes. NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems. May 2010. Accessed April 26, 2011 @ http://csrc.nist.gov/publications/nistpubs/800-34-rev1/ sp800-34-rev1_errata-Nov11-2010.pdf.

7. “Business Continuity Glossary by Disaster Recovery Journal.” DRI International. Accessed April 20, 2005 @ www.drj.com/glossary/drjglossary.html#r.

8. Swanson, M., Bowen, P., Phillips, A., Gallup D., and D. Lynes. NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems. May 2010. Accessed April 26, 2011 @ http://csrc.nist.gov/publications/nistpubs/800-34-rev1/ sp800-34-rev1_errata-Nov11-2010.pdf.

9. Ibid.

10. Ibid.

11. Ibid.

12. Ibid.

13. “Business Continuity Impact Analysis.” Texas State Office of Risk Management. Accessed April 10 2005 @ www.sorm.state.tx.us/Risk_Management/Business_Continuity/bus_impact.php.

14. The material, which was reorganized and rewritten by the authors of this text, is drawn from the following sources:

Mohr, G. “Canadian Center for Emergency Preparedness Business Impact Analysis Questionnaire.” Tibbett & Britten Group. Accessed June 22, 2005 @ www.ccep.ca/ccepbcp3.html.

Rychalski, J. “Business Impact Analysis Questionnaire.” AuditNet November 2002. Accessed June 22, 2005 @ www.auditnet.org/docs/BIAQuestionnaire.doc.

Krause, M. and H. Tipton. “BIA Questionnaire Construction.” CCCure Hand- book of Information Security Management. Accessed June 22, 2005 @ www. cccure.org/Documents/HISM/290-291.html.

“Business Continuity Impact Analysis” Texas State Office of Risk Management. Accessed June 22, 2005 @ www.sorm.state.tx.us/Risk_Management/Business_ Continuity/bus_impact.php.

“Generally Accepted Practices For Business Continuity Practitioners.” Disaster Recovery Journal and DRI International. Accessed June 22, 2005 @ www.drj. com/GAP/gap.pdf.

15. Armin, Jart. “Hackers Take Note: Cyber-Insurance Is on the Rise.” Hostexploit June 27, 2011. Accessed August 20, 2012 @ http://news.hostexploit.com/cyber-security- news/4926-hackers-take-note-cyber-insurance-is-on-the-rise.html.

16. “‘Mafiaboy’ Hacker Jailed.” BBC News September 13, 2001. Accessed May 5, 2004 @ http://news.bbc.co.uk/1/hi/sci/tech/1541252.stm.

17. Wood, Lamont. “Is Hacking Insurance Worth It?” Computerworld UK October 24, 2011. Accessed August 24, 2012 @ www.computerworlduk.com/advice/it-business/ 3312969/is-hacking-insurance-worth-it.

Endnotes 87

chapter 3

Contingency Strategies for IR/DR/BC

Men at some time are masters of their fates. The fault, dear Brutus, is not in our stars, but in ourselves. —William Shakespeare (1564–1616), Julius Caesar (Act I, Scene ii).

Upon completion of this material, you should be able to: ● Discuss the relationships between the overall use of contingency planning and the

subordinate elements of incident response, business resumption, disaster recovery, and business continuity planning

● Describe the techniques used for data and application backup and recovery ● Explain the strategies employed for resumption of critical business processes at alternate

and recovered sites

Bobby was not having a good day. He had started the morning by oversleeping and had clocked in 15 minutes late. Rushing through the mailroom doors, Bobby splashed coffee from his cup into a full cart of mail someone had left standing close by the door. Only heroic blotting kept him from ruining a couple of dozen incoming envel- opes. It looked like important stuff, too. As he hurriedly gathered the mail and scooped it out of the cart, one of the thick yellow envelopes slipped from his hand and fell to the floor, exploding into a cloud of white powder over the mail cart.

“Ooof” was the noise Bobby made as he puffed all the air out of his lungs, mouth, and nose while backing away from the cart and out the mailroom door. Having just gone through the refresher training for emergency procedures in the mailroom, he knew to exhale quickly and get out as rapidly as possible. Everyone else in the mail- room did the same; this was the exact maneuver the team had rehearsed just a week before. Exhale, exit, and hit the big red button that turns off the ventilators to the room and sets off the emergency alarm. Bobby stopped once he got out in the hallway and waited, with the rest of the mailroom team, for the turmoil he knew would follow.

Two hours later, Alan Hake, CEO of HAL, sat with his incident team at the coffee shop across the street. As outlined in the incident response (IR) plan, the team con- sisted of COO Richard Xavier, CFO Rachel Xieng, CIO Amanda Wilson, plus Roberta Briscoe, manager of corporate security, and Pantoja Martina, supervisor of the administrative staff and the mailroom. They were reviewing the response plan in place for contaminated mail, along with the supporting DR and BC plans, when a man in a fireman’s dress uniform walked up to their table and said, “Hi. I am Deputy Fire Chief Corbett. Are you the folks from HAL?”

“Yes,” said Alan. “Please, have a seat.” He gestured to an empty chair at their impromptu conference table. Deputy Chief Corbett sat down and said, “The field test, within its limited test range, shows that the white powder in the mailroom is not a pathogen or a contaminant. We sent a sample to the forensics lab, and they are expediting processing. We should have an answer back by 2:00 p.m.”

Alan and the team had watched the deputy chief carefully as he spoke. Now, they relaxed a little.

“What about the mailroom staff?” Alan asked. “What’s their status?” “They seem none the worse for wear,” Deputy Chief Corbett replied. “We isolated

them and ran them through the standard biochemical decontamination protocol. Not very pleasant, nor a very modest activity, but the team is clean and dry and standing by in isolation suits waiting for the final lab results. If they were contaminated, we can’t do any more until we know what the contaminant is.”

Opening Scenario: Panicking over Powder

90 Chapter 3 Contingency Strategies for IR/DR/BC

3Introduction As discussed in Chapters 1 and 2, contingency planning (CP) encompasses everything done by an organization to prepare for the unexpected. This includes something as trivial as evaluating an alarm from an intrusion detection system or responding to the never-ending stream of new viruses and worms in e-mail systems, but it can also include an outright catastrophe like the one that befell HAL in this chapter’s opening scenario. The incident response (IR) process focuses on detecting, evaluating, and reacting to an incident, the later phases of the process focusing on keeping the business functioning even if the physical plant is destroyed or unavailable. When the IR process cannot contain and resolve an incident, the company turns to the business resumption plan to help resume normal operations quickly or expedite continuity plans to quickly initiate operations at an alternate site until normal operations can resume at the primary site. The rela- tionships between the various elements of the continuity plan were shown in Figure 1-5.

A business resumption plan (BR plan) usually has two major elements: the disaster recovery plan (DR plan), which lists and describes the efforts to resume normal operations at the primary places of business, and the business continuity plan (BC plan), which contains the steps for implement- ing critical business functions using alternate mechanisms until normal operations can be resumed at the primary site (or elsewhere) on a permanent basis. The primary site is the location or group of locations at which the organization executes its functions. The BC plan occurs con- currently with the DR plan when the damage is major or long term. As shown in Figure 3-1, a large-scale distributed denial-of-service (DDoS) attack may require the activation of both the DR plan (to restore the primary site) and a BC plan (to enable critical functions to be undertaken elsewhere until normal operations can resume). Because of the complexity of the business resumption planning process, the remaining chapters of this book are devoted to the topic.

He smiled and then added, “I suggest a long lunch while you to make your plans. If the test comes back with a contaminant, your office space will probably be off- limits for three to four weeks—maybe longer.”

Attack occurs; depending on scope, may be classified as incident or disaster

Denial-of- service attack

(incident)

Distributed denial- of-service attack

(disaster)

Zombies or bots

Figure 3-1 Incident response and disaster recovery

Introduction 91

Some experts argue that the two components of business resumption planning (BRP)—disaster recovery planning (DRP) and business continuity planning (BCP)—are so closely linked that they are indistinguishable. However, each has a distinct place, role, and planning requirement. (A quick review of Figure 1-6 will reinforce this notion.) Figure 3-2 shows how the components of business resumption fit together.

Each of the components of CP (the IR, DR, and BC plan) also comes into play at a specific time in the life of an event. (Figure 1-5 illustrates this sequence and shows the overlap that may occur.) How the plans interact and the ways in which they are brought into action are discussed throughout this chapter and the following chapters.

Regardless of the type of response needed (IR, DR, or BC), organizations require a reliable method of restoring information and reestablishing all operations, both IT operations and other business functions. Whether the objective is to recover a backup of a file that has been accidentally deleted or involves transferring an entire application’s database to an alternate facility, there are five key procedural mechanisms that facilitate the restoration of critical information and the continuation of business operations:

● Delayed protection ● Real-time protection ● Server recovery ● Application recovery ● Site recovery

The first four of these mechanisms are discussed in the following section; the fifth is covered in a later section.

Business continuity moves operations to

Staff implements DR plan

Alternate site

Disaster recovery works to reestablish operations at

Primary business site

Organizational disaster occurs

Figure 3-2 Business resumption

92 Chapter 3 Contingency Strategies for IR/DR/BC

Data and Application Resumption There are a number of methods for data protection and management. It is important to first understand the difference between a backup and an archive. Data backup is typically a snap- shot of the data from a specific point in time. The data is considered volatile and subject to change. An archive is a long-term storage of a document or data file, usually for legal or reg- ulatory purposes. For recovery from an incident, backups are the most common solutions. For recovery from disasters that threaten on-site backups, archives are used.

The most commonly used varieties of data backup include online backup, disk backup, and tape backup, which are discussed here. It is important to use backup methods that are based on an established policy. In general, data files and critical system files should be backed up daily, with nonessential files being backed up weekly. Equally important is determining how long data should be stored. Both data backups and archives should be based on a retention schedule that guides the frequency of replacement and the duration of storage. Some data is required by law to be retained and stored for years. Other data isn’t covered by laws or regu- lations and may even be in the organization’s best interest to quickly destroy. Management should create a formal plan that includes recommendations from legal counsel for conforming to the applicable laws, regulations, and standards. For routine data backups of critical data, the organization only needs to retain the one or two most recent copies (daily backups) and at least one off-site copy. (Note that more copies stored at redundant locations are better.) For full backups of entire systems, at least one copy should be stored in a secure location, such as a bank vault, security deposit box, or remote branch office.

As suggested by NIST SP 800-34, Rev 1, Contingency Planning Guide for Federal Informa- tion Systems, alternatives should be considered when designing backup and recovery strate- gies. Each possible option should include planning for the total cost of operation, including establishing and operating costs, downtime estimates, estimates of the security provided by the option, how the option affects the sequence of recovery based on the relative priority of included systems, and how the option fits into the broader organizational planning efforts. The information in Table 3-1 can assist in identifying the backup and recovery strategies asso- ciated with various system priorities.1

Information System Target Priority Backup/Recovery Strategy

Low priority—Any system the damage to or disruption of which would cause little impact, damage, or disruption to the organization

Backup: Tape backup Strategy: Relocate or cold site

Important or moderate priority—Any system the damage to of disruption of which would cause a moderate problem to the organization and possibly other networks or systems

Backup: Optical backup, WAN/ VLAN replication Strategy: Cold or warm site

Mission critical or high priority—Any system the damage to or disruption of which would cause the most serious impact on the organization, mission, and other networks and systems

Backup: Mirrored systems and disc replication Strategy: Hot site

Table 3-1 Backup and recovery strategies based on system priority2 Source: NIST Special Publication 800-43 Rev.1

Data and Application Resumption 93

Online Backups and the Cloud One of the newest forms of data backup is online backup to a third-party data storage ven- dor. Several backup software and service providers now offer multi-terabyte online data stor- age available to anywhere, from anywhere. Even for the home user, companies such as Memeo (www.memeo.com), Dropbox (www.dropbox.com), and Google (through Google Drive @ http://drive.google.com) offer data storage ranging from free accounts with minimal amounts of storage to low-cost multi-gigabyte and terabyte solutions.

For the corporate user, this online data storage is sometimes referred to as data storage “in the cloud” and is commonly associated with the leasing of computing resources from a third party—as in cloud computing. Cloud computing is usually described in three ways:

● Software as a Service (SaaS), in which applications are made available on the Internet (and over the World Wide Web)

● Platform as a Service (PaaS), in which development platforms are made available to developers

● Infrastructure as a Service (IaaS), in which hardware and operating systems resources are made available for whatever the organization desires to implement

Organizations can lease SaaS services, which often include online backup services, and then have data storage needs serviced as part of the package.

Clouds are deployed in the following three ways (or a combination of the three):

● Public cloud—The most common implementation, in which a service provider makes computing resources available over the Internet (and World Wide Web) to whoever needs them

● Community cloud—An implementation in which several organizations with common interests share computing resources; it can be managed by a third party or by the organizations themselves, and can be hosted internally or externally

● Private cloud—An implementation in which the computing resources are operated solely by a single organization; an extension of an organization’s intranet into the cloud

From a security perspective, the leasing of services from a third party is always a challenge. If you don’t own the hardware, software, and infrastructure, you can’t guarantee effective secu- rity, so you must scrutinize the service agreement and insist on minimal standards of due care.

Every month, Backup Review, a Web site devoted to providing information about online backup and storage services, presents a list of the “Top 100 Online Backup Companies.” To see the latest list, go to www.backupreview.info.

Disk to Disk to Other: Delayed Protection With the decrease in the costs of storage media, including hard drives and tape backups, more and more organizations are creating massive arrays of independent, large-capacity disk drives to store information at least temporarily. In fact, many home users are using similar

94 Chapter 3 Contingency Strategies for IR/DR/BC

methods, adding external USB-mounted SATA drives in the 1–2 terabyte range and simply copying critical files to these external, portable devices for their routine backups. The avail- ability of these devices not only precludes the time-consuming nature of tape backup but avoids the costs and implementation challenges of tape at the individual-user level. It also allows quick and easy recovery of individual files and directories, avoiding the tedious method of extracting the same from tape. Applications like Memeo (www.memeo.com) even allow real-time backup of data, with multiple archived older versions.

Disk to Disk to Tape Individuals and organization alike can then build libraries of these devices—massively connected storage area networks—to support larger-scale data backup and recovery. The problem with this technology is the lack of redundancy if both the online and backup versions fail, because of a virus or hacker intrusion. This is why the secondary data disk series should be periodically backed up to tape—thus, the development of disk-to-disk-to-tape methods. The use of the secondary disk series avoids the need to take the primary set offline for duplication, and it reduces the resource usage on the primary sys- tems. The disk-to-disk initial copies can be made efficiently and simultaneously with other system processes.

The following sections provide an overview of the use of complex disk drive storage media using various levels of redundancy. To better understand what goes on during IR or DR data restoration, you need to understand how system backups are created. Data backup is a com- plex operation that involves selecting the backup type, establishing backup schedules, and even duplicating data automatically using a variety of redundant array of independent disks (RAID) structures.

Disk to Disk to Cloud Like online data storage, disk-to-disk-to-cloud (also called disk- to-disk-to-online) backup strategies are rapidly gaining acceptance in the consumer and corporate areas. An organization may not need or desire to go directly from disk to cloud; it may want to aggregate all local backups to a central repository and then back up that repository to an online vendor.

From a security standpoint, allowing only a trusted backup server or service to access a com- pany’s online data storage reduces the risk of corruption (and, therefore, threats) to the confi- dentiality, integrity, and availability of stored online data. Individual users can be allowed to back up their data to a central location using inexpensive software, and then the organization can periodically upload a backup to the online cloud storage repository. Another benefit of cloud data backup comes from the fact that most commercial backup providers use an encryption process prior to data being transmitted to the cloud storage location. The data is not transmitted in plaintext across the Internet, thus it cannot be read by unauthorized parties. Because cloud backup data is available via the Internet, organizations can also easily access that data to restore it to another system in a relatively quick time frame, thus minimizing downtime when systems have to be rebuilt or data has to be reloaded. Another benefit is the ability to automate the cloud backup process, thus removing the need to constantly have employees changing tapes or replacing drives in an array. Automation also allows organizations to back up much more frequently, thus minimizing the potential amount of data lost between backups. Organizations should ensure that their data is being retained in multiple geographical locations so as to minimize the risk of data loss from natural disaster or hardware failure.

Data and Application Resumption 95

Types of Backup There are three basic backup options: full, differential, and incremen- tal. A full backup is just that, a full and complete backup of the entire system, including all applications, operating systems components, and data. The advantage of a full backup is that it takes a comprehensive snapshot of the organization’s system. The primary disadvan- tages are that it requires large media to store such a large file and that the backup can be time-consuming.

A differential backup is the storage of all files that have changed or been added since the last full backup. The differential backup works faster and uses less storage space than the full backup, but each daily differential backup is larger and slower than that of the day before. For example, if you conduct a full backup on Sunday, then Monday’s backup contains all the files that have changed since Sunday, and Tuesday’s backup contains all the files that have changed since Sunday as well, including Monday. By Friday, the file size has grown sub- stantially. If one backup is corrupt, the previous day’s backup contains almost all the same information.

An incremental backup only archives the files that have been modified since the last backup and thus requires less space and time than the differential to create. The downside to incre- mental backups is that if an incident occurs, multiple backups need to be restored to restore the full system. In general, incremental backups are designed to complete the backup in the shortest amount of elapsed time. An incremental backup will also be economical in the amount of room needed to store the backup data. Differential backups yield the shortest elapsed time needed to restore files when they must be recreated from the backup media.

A copy backup is a backup of a set of specified files, regardless of whether they have been modified or otherwise flagged for backup. This allows a systems administrator to make sure all files are backed up, but only by a subset of them at a time. It could be considered a partial full backup. A daily backup backs up only files that were modified on that day—a date- specific incremental backup.

Regardless of the strategy employed, all on-site and off-site storage must be secured. It is com- mon practice to use fireproof safes or filing cabinets to store tapes and to use encryption to protect online or cloud data storage. The off-site storage, in particular, must be in a safe loca- tion, such as a safety deposit box in a bank or a professional backup and recovery service. The trunk of the administrator’s car is not considered secure off-site storage. It is also impor- tant to provide a conditioned environment for off-site physical media, preferably an airtight, humidity-free, static-free storage container. Each off-site media unit must be clearly labeled and write protected. Because tapes wear out, it is important to retire them periodically and introduce new media.

Tape Backups and Recovery: General Strategies Traditionally, tape has been able to store larger quantities of data in smaller containers, and it is still a cost-effective method for organizations to maintain large quantities of data. The most common types of tape media for small organizations and individual users are digital audio tapes (DATs), quarter-inch cartridge (QIC) drives, 8-mm tape, and digital linear tape (DLT). Today, StorageTek T10000C tapes are capable of holding over 5 terabytes of data on a single reel or cartridge, with a data rate of approximately 240 megabytes per second. Each type of tape has its restrictions and advantages.

96 Chapter 3 Contingency Strategies for IR/DR/BC

The first stage of a tape-based backup and recovery process is the scheduling of the backups, coupled with the arrangement for the storage of the media. The most common schedule is a daily on-site backup, either incremental or differential, with a weekly off-site full backup. Most backups are conducted during off-shift hours, when systems activity is lowest and the probability of user interruption is limited.

When addressing the selection of files to back up, a popular method is the six-tape rotation method, in which six sets of media are used in rotation. It uses five media sets per week and offers roughly two weeks of recovery capability, as shown in Table 3-2.

When it comes to the recovery stage of the process, the organization first attempts to recover the file(s) using the Monday through Thursday tapes, if they are on hand. If the file that needs to be restored is not contained within the backups that are on hand, the last full backup that was stored off-site is retrieved and the file(s) recovered from that media. For additional ease of use and for redundancy, an organization may choose to make two copies of each full backup so that an on-site version can be kept in the data center and an off-site set of full backup (Friday) tapes can be sent to the secure storage location. This will avoid the need to retrieve the off-site set unless the needed file(s) are not able to be recovered from the backup media that is available on-site.

Another option is the Grandparent/Parent/Child method, which is similar to the six-tape rota- tion method but retains four full weekly (Friday) backups and adds a full monthly backup, retaining 12 monthly backups. This is considered the most common method of tape rotation. Once the monthly backup is created, the four (or five) Friday tapes are reused.

Primary drawbacks of tape backups include the cost of the specialized equipment as well as the media and time required to store and retrieve information. Individual storage tapes can cost hundreds of dollars. With incremental and differential backup times ranging from 1 to 2 minutes per gigabyte, a large data repository can take hours to back up and recover. With the dramatically faster and less-expensive options of external and internal disk-to-disk data back- ups, the market for consumer-grade tape backups has dwindled to a fraction of its former popularity in the last decade.

Week Monday Tuesday Wednesday Thursday Friday

1 Incremental BU Tape #1

Incremental BU Tape #2

Incremental BU Tape #3

Incremental BU Tape #4

Full BU Tape #5 stored off-site

2 Incremental BU Tape #1

Incremental BU Tape #2

Incremental BU Tape #3

Incremental BU Tape #4

Full BU Tape #6 stored off-site

3 Incremental BU Tape #1

Incremental BU Tape #2

Incremental BU Tape #3

Incremental BU Tape #4

Full BU Tape #5 stored offsite

4 Incremental BU Tape #1

Incremental BU Tape #2

Incremental BU Tape #3

Incremental BU Tape #4

Full BU Tape #6 stored off-site

Table 3-2 Six-tape rotation method © Cengage Learning 2014

Note: Differential or full backups can certainly be used on Monday through Thursday.

Data and Application Resumption 97

Redundancy-Based Backup and Recovery Using RAID Another form of data backup is that of online disk drives used for redundancy. The usage of redundant array of independent disks (RAID) systems can overcome some of the limits of magnetic tape backup systems; and as discussed later in this chapter, RAID systems provide enhanced capabilities. Unlike tape backups, RAID uses a number of hard drives to store information across multiple drive units. For operational redundancy, this can spread out data and, when coupled with checksums, can eliminate or reduce the impact of a hard drive failure. There are nine established RAID configurations, which are described in the following paragraphs, and even though some of these offer capabilities that are discussed later in this chapter, all are presented together in the next section. Some approaches offer more than sim- ple data redundancy—for example, providing complete application-level redundancy by using a process that mirrors entire servers or by using a form of server fault tolerance, such as SFTIII (from Novell). Although RAID does not address the need for off-site storage like tape-based backups, it does deal with the most common need for restoring from backup, which is the recovery from hard-drive failure.

RAID vendors have come to use a standardized classification model that identifies three types of RAID implementations:

● Failure Resistant Disk Systems (FRDSs), which protect against data loss due to disk failure and its enhancement, FRDS+

● Failure Tolerant Disk Systems (FTDSs), which protect against loss of data access because of failure of any single component

● Disaster Tolerant Disk Systems (DTDSs), which consist of two or more independent zones, either of which provides access to stored data

The parameters established for these classification models are shown in Table 3-3.

Failure-Resistant Disk Systems (FRDS)

Failure-Tolerant Disk Systems (FTDS)

Disaster-Tolerant Disk Systems (DTDS)

Protection against data loss and loss of access to data due to disk drive failure

Disk automatic swap and hot swap Protection against loss of access to data due to host and host I/O bus failure

Reconstruction of failed drive content to a replacement drive

Protection against data loss due to cache failure

Protection against loss of access to data due to external power failure

Protection against data loss due to a “write hole”

Protection against data loss due to external power failure

Protection against loss of access to data due to component replacement

Protection against data loss due to host and host I/O bus failure

Protection against data loss due to a temperature out of operating range

Protection against loss of data and loss of access to data due to multiple disk failure

Table 3-3 RAID classification model (continues) © Cengage Learning 2014

98 Chapter 3 Contingency Strategies for IR/DR/BC

The following sections discuss the RAID configurations that are most commonly used in the IT industry.

RAID Level 0 This is not a form of redundant storage. RAID 0 creates one larger logical volume across several available hard disk drives and stores the data using a process known as disk striping, in which data segments, called stripes, are written in turn to each disk drive in the array. When this is done to allow multiple drives to be combined in order to gain large capacity without data redundancy, it is called disk striping without parity. Unfortu- nately, failure of one drive may make all data inaccessible. In fact, this level of RAID does not improve the risk situation when using disk drives; instead, it rather increases the risk of losing data from a single drive failure.

RAID Level 1 Commonly called disk mirroring, RAID 1 uses twin drives in a computer system. The computer records all data to both drives simultaneously, providing a backup if the primary drive fails. This is a rather expensive and inefficient use of media. A varia- tion of mirroring is called disk duplexing. With mirroring, the same drive controller man- ages both drives; with disk duplexing, each drive has its own controller. Mirroring is often used to create duplicate copies of operating system volumes for high-availability systems. Using this technique, a plan can be developed that mirrors and then splits disk pairs to create highly available copies of critical system drives. This can make multiple copies of critical data or programs readily available when needed for high-availability computing environments.

RAID Level 2 A specialized form of disk striping with parity, RAID 2 is not widely used. It uses a specialized parity coding mechanism known as the Hamming code to store stripes of data on multiple data drives and corresponding redundant error correction on separate error-correcting drives. This approach allows the reconstruction of data if some of the data or redundant parity information is lost. There are no commercial implementa- tions of RAID 2.

Failure-Resistant Disk Systems (FRDS)

Failure-Tolerant Disk Systems (FTDS)

Disaster-Tolerant Disk Systems (DTDS)

Protection against data loss due to replaceable unit failure

Replaceable unit and environmental failure warning

Protection against loss of access to data due to zone failure

Replaceable unit monitoring and failure indication

Protection against loss of access to data due to device channel failure

Long-distance protection against loss of data due to zone failure

Protection against loss of access to data due to controller module failure

Protection against loss of access to data due to cache failure

Protection against loss of access to data due to power supply failure

Table 3-3 RAID classification model (continued) © Cengage Learning 2014

Data and Application Resumption 99

RAID Levels 3 and 4 RAID 3 uses byte-level striping of data, and RAID 4 uses block- level striping of data. These approaches use a process in which the data is stored in segments on dedicated data drives, and parity information is stored on a separate drive. Similar to RAID 0, one large volume is used for the data, but the parity drive operates independently to provide error recovery.

RAID Level 5 RAID 5 is most commonly used in organizations that balance safety and redundancy against the costs of acquiring and operating the systems. It is similar to RAID 3 and 4 in that it stripes the data across multiple drives, but there is no dedicated parity drive. Instead, segments of data are interleaved with parity data and are written across all the drives in the set. RAID 5 drives can also be hot swapped, meaning they can be replaced without taking the entire system down.

RAID Level 6 A combination of RAID 1 and RAID 5, this provides block-level striping with double-distributed parity and allows systems so protected to recover from two simulta- neous drive failures.

RAID Level 7 This is a proprietary variation on RAID 5 in which the array works as a single virtual drive. RAID 7 is sometimes performed by running special software over RAID 5 hardware.

RAID Level 0+1 This is a combination of RAID 0 and RAID 1. Raid 0 is used for its performance, and RAID 1 is used for its fault tolerance. This model creates a second striped set to mirror a primary striped set (striping, then mirroring).

RAID Level 1+0 This is a combination of RAID 1 and RAID 0. Raid 0 is used for its performance, and RAID 1 is used for its fault tolerance. This model creates a striped set from a mirrored set (mirroring, then striping).

RAID Level 5+1 This is a combination of RAID 5 and RAID 1. Raid 5 is used for its robustness, but then the method adds a separate data parity drive not found in RAID 5. (Some vendors market this technique as RAID 53.)

Some of the more common implementations of RAID are illustrated in Figure 3-3.

Database Backups Systems that make use of databases, whether hierarchical, relational, or object-oriented, require special considerations when backup and recovery procedures are being planned. Depending on the type of database and the software vendor, the database may or may not be able to be backed up with the utilities that are provided with the operating systems of the servers on which the database is run. A further consideration is whether or not system backup procedures can be used without interrupting the use of the database. With some rela- tional databases, a system backup can work correctly only if all user access to the database is stopped. For these databases to be used while they are being backed up, additional backup tools are needed. Other things to consider for properly safeguarding a database include mak- ing sure the system administrators know whether there are special journal file requirements used by the database management software, such as run-unit journals or after-image

100 Chapter 3 Contingency Strategies for IR/DR/BC

journals, which enable database concurrency functions. If these file systems and the files they use are not backed up properly, the backup tapes or disk images may be unusable when attempting to restore the prior state of the system.

There are new applications designed to protect databases in near real time. These protect data in one of the following ways:

● Legacy backup applications—The traditional “lock and copy” approach, this requires the database to be inaccessible while a backup is created to a local drive.

● Online backup applications—Also a “lock and copy” approach, this provides back- ups to an online (or cloud) vendor.

● Continuous database protection—This copies data in near real time to a second stor- age location using an application interface. Data is stored to within a one-second tolerance. Currently, only R1Soft claims to provide this level of protection.

Application Backups Some applications use file systems and databases in ways that invalidate the customary way of doing backup and recovery. In some cases, applications write large binary objects as files and manage pointers, and they handle internal data structures in ways that make routine backups unable to handle the concurrency or complexity of the application. Make sure that

Block 4

Block 3

Block 2

Block 1

Disk 1

Block 4

Block 3

Block 2

Block 1

Disk 2

Block 7

Block 5

Block 3

Block 1

Disk 1

Block 8

Block 6

Block 4

Block 2

Disk 2

Block 7

Block 5

Block 3

Block 1

Disk 3

Block 8

Block 6

Block 4

Block 2

Disk 4

Parity 4

Block 3a

Block 2a

Block 1a

Disk 1

Block 4a

Parity 3

Block 2b

Block 1b

Disk 2

Block 4b

Block 3b

Parity 2

Block 1c

Disk 3

Block 4c

Block 3c

Block 2c

Parity 1

Disk 4

RAID 0 Striping

RAID 1 Mirroring

RAID 01 (0+1) Striping and mirroring

RAID 5 Striped parity

Block 7

Block 5

Block 3

Block 1

Disk 1

Block 8

Block 6

Block 4

Block 2

Disk 2

Figure 3-3 Common RAID implementations

Data and Application Resumption 101

members of the application support and development teams are part of the planning process when these systems’ backup plans are made and that these team members are included in training, testing, and rehearsal activities.

Note that the advances in cloud computing have opened a new field in application redun- dancy and backup. Because organizations that lease SaaS are in effect using a preconfigured set of applications on someone else’s systems, it is reasonable to ask that the service agree- ment include contingencies for recovery. If a particular server goes down, the service organi- zation providing the SaaS should guarantee recovery in a specified time, with a comparable (if not identical) set of applications.

Backup and Recovery Plans Even the best backups are inadequate unless they can be used to successfully restore systems to an operational state. Each backup and recovery setting should be provided with complete recovery plans. The plans need to be developed, tested, and rehearsed periodically.

Developing Backup and Recovery Plans Backup and recovery plans should include at a minimum answers to the following:

● How and when will backups be created? ● Who will be responsible for creation of the backups? ● How and when will backups be verified so that they are known to be

correct and reliable? ● Who is responsible for the verification of the backup? ● Where will backups be stored and for how long? ● How often will the backup plan be tested? ● When will the plan be reviewed and revised? ● How often will the plan be rehearsed, and who will take part in the rehearsal?

Real-Time Protection, Server Recovery, and Application Recovery Some strategies that are employed seek to improve the robustness of a server or system in addition to, or instead of, performing backups of data. One approach that provides real- time protection as well as data backup is the use of mirroring. Mirroring provides duplica- tion of server data storage by using multiple hard-drive volumes, as was described in the section on RAID level 1. RAID level 1 can be achieved with software or hardware, writing data to other drives, even if they are located on other systems. Mirroring can be extended to the point of vaulting and journaling, which are discussed in later sections.

One strategy for implementing server recovery and redundancy through mirroring servers uses hot, warm, and cold servers. In this strategy, the online primary server (i.e., domain con- troller) is the hot server, and it provides the services necessary to support operations. The warm server serves as an ancillary or secondary server (i.e., domain controller), and it ser- vices requests when the primary is busy or down. The cold server is the administrator’s test platform and should be identically configured to the hot and warm servers. Before a patch, upgrade, or new application is applied to the hot and warm servers, it is first tested on the cold server. Should the hot server go down, the warm server automatically takes over as the

102 Chapter 3 Contingency Strategies for IR/DR/BC

hot server, and the cold server can be added as the new warm server while the hot server is taken offline for repair.

Recent advances in server recovery have developed bare metal recovery technologies designed to replace operating systems and services when they fail. These applications allow you to reboot the affected system from a CD-ROM or other remote drive and quickly restore your operating system by providing images backed up from a known stable state.

Although Linux and UNIX versions of bare metal implementations abound, the Windows versions are more difficult to come by, as Linux and UNIX kernels run easily from small storage locations, but Windows is only just developing a stand-alone bootable CD platform. Under Windows 7, you can create a system repair disk to use in the event of a corrupted Windows 7 installation. Most Windows operating systems can use the setup disk to facilitate recovery and restoration. Use of bare metal recovery applications, in conjunction with rou- tine backups, allows the recovery of entire servers quickly and easily. There are many options, including Knoppix and Helix, for Linux/UNIX users to choose from. The LiveCD List provides several (see www.livecdlist.com).

The next level of recovery is application recovery or clustering plus replication. The use of software replication can provide increased protection against data loss. Clustering services and application recovery work is similar to the hot, warm, and cold redundant server model described earlier. It is common practice for system administrators to install applications on multiple servers so that if one fails to provide the service, a secondary system steps up and takes over the role. Application recovery expands on this premise for applications: rather than simple services providing fail-over capabilities for critical applications, it uses software to detect the failure of the primary application server and to then activate the secondary application server to begin accepting and servicing requests.

As noted earlier, mirroring of data, whether through the use of RAID 1 or alternative tech- nologies, can increase the reliability of primary systems and enhance the effectiveness of busi- ness resumption strategies. The techniques of vaulting and journaling dramatically increase the level of protection; they are discussed in the following sections.

Electronic Vaulting The bulk transfer of data in batches to an off-site facility is called electronic vaulting (see Figure 3-4). This transfer is usually conducted via leased lines or data communications services provided for a fee, although recent developments in online/cloud backup are quickly taking over this market. The receiving server archives the data as it is received. Some DR companies specialize in electronic vaulting services. The primary criteria for selecting an electronic vaulting (e-vaulting) solution are the costs of the service, the required and available bandwidth, the security needs for the stored data, and the needed ser- vice level for recovery and continuity.

Because e-vaulting means transferring data off site, one must ensure that the organization has the capability to do so without affecting other operations. If the organization does not cur- rently have enough bandwidth to support e-vaulting, it must obtain the additional bandwidth through a vendor. It may be advantageous to get the extra bandwidth, whether or not your organization feels it is necessary.3

E-vaulting used to be more expensive than tape backup and slower than data mirroring; however, the explosion in the online/cloud market has changed this. Solutions under a few hundred dollars/month are now available, with most services based on capacity needs as

Data and Application Resumption 103

measured in gigabytes or terabytes of storage. This allows organizations to scale their pur- chases according to their needs. Organizations should consider using specialized e-vaulting applications for data that warrants the additional expense, such as critical transactional data and customer databases. If the organization already has a data classification or prioritization scheme, it may already know what data is most critical. These means of categorizing data assets may have been put in place during the BIA or in the development of the risk assessment processes. While e-vaulting can be performed over public infrastructure using VPNs, the data must be encrypted while in transition, which can slow the data transfer rate.

For managed solutions from vendors, a software agent is typically installed on all servers and included in the e-vaulting process. Once installed, the software initiates a full backup of data to the remote vault and then prepares to continuously copy data as it is created or modified. The vendor is then responsible for the maintenance and protection of the data. Access to the data can be obtained through a Web interface or by using installed software to facilitate resto- ration or validation of transferred data. Vendors like Amazon, Rackspace, Carbonite, and Intronis have facilities and services designed to support an organization’s online data backup in this capacity. If the organization desires to transfer data to its own vault, different applica- tions can facilitate the transfer between organizationally owned equipment over public or

Online transfer to vault

Restoration to servers

Public/private carrier

Remote electronic vault

Primary site

Business continuity site

Figure 3-4 Electronic vaulting

104 Chapter 3 Contingency Strategies for IR/DR/BC

private communications links. In either case, the routine transfer of data should not have an impact on the organization’s networks; however, those organizations with network connec- tions below 2–3 Mbps should consider upgrading to higher-speed Internet connections, given that the average U.S. internet speed is currently approximately 6 Mbps.4

Remote Journaling Remote journaling (RJ) is the transfer of live transactions to an off-site facility. Developed by IBM in 1999 for its OS/400 V4R2 operating system, it differs from e-vaulting in that only transactions are transferred, not archived data, and the transfer is performed online, much closer to real time. Although e-vaulting is much like a traditional backup, with a dump of data to the off-site storage, RJ involves online activities on a systems level, much like server fault tolerance, in which data is written to two locations simultaneously. However, this can be performed asynchronously, if preferred. RJ facilitates the recovery of key transactions in near real time. Figure 3-5 shows an overview of the RJ process.

When journaling is enabled for a given object, the operating system initiates a process that creates a record of the object’s behavior. All changes are recorded by the journal in a journal entry, which is stored in a journal receiver, similar to storing a record in a database file. Once the journal receiver is full or reaches a preset level, a new journal receiver is linked to the jour- nal, and the full receiver is available for storage to tape, for example. For recovery, the stored receivers can be pulled from tape and applied to the data in the production database, restoring the data to a known stable point. Remote journaling involves the transference of journal entries to a remote journal, which in turn stores them to a remote journal receiver. This remote journal receiver is then transferred to remote tape or other storage when full, creating a virtual real-time backup of the entries.

Users

Journal receivers

Journal Public/private

carrier

SaveJournalreceiversSave

Journal Remotejournal

Real time Daily

Save

Figure 3-5 Remote journaling

Data and Application Resumption 105

Database Shadowing Database shadowing, also known as databank shadowing, is the storage of duplicate online transaction data, along with the duplication of the databases, at the remote site to a redundant server. It combines e-vaulting with RJ, writing multiple copies of the database simultaneously in two separate locations. This technology can be used simply, with multiple databases on a single drive in a single system, or using databases in remote locations, across a public or private carrier, as shown in Figure 3-6. Shadowing techniques are generally used for organizations needing immediate data recovery after an incident or disaster. The “shadowed” database is available for reading as well as writing and thus serves as a dynamic off-site backup. Database shadowing also works well for read-only functions, such as the following:

● Data warehousing and mining ● Batch reporting cycles (quarterly and year-end reports, and so on) ● Complex SQL queries ● Local online access at the shadow site ● Load balancing

Database shadowing is performed by having each transactional event written simultaneously to multiple databases. In its original incarnation, database shadowing could only be done to a secondary partition or database on the original drive, or to a secondary drive in the same machine (disk mirroring or duplexing). However, with the introduction of third-party software, these same transactions can be buffered, transmitted across a network, and stored in a shadow database on a remote server.

Users

Save

Journal receivers

Journal

Public/private carrier Remote

journal

Real time Daily

Journal receivers

Save

Figure 3-6 Database shadowing

106 Chapter 3 Contingency Strategies for IR/DR/BC

As each transaction occurs, the primary database and shadowed database both receive the transaction entry, update, or deletion request. Only the primary database responds to the transaction application, but both databases make the requested entry, modification, or dele- tion. Once a problem occurs with the primary database, the secondary database can be accessed to serve as a redundant copy. If the redundant copy is on the same system, the trans- actions can continue without interruption. If the copies are on a remote system, the copy must be read back to the original system, restoring the data to provide a local copy, in order to pre- vent latency in the transaction process.

Database replication is a similar strategy, focusing on the backup of multiple copies of the database for recovery purposes, where other solutions offer the immediate availability of dynamic redundant data. There are three types of database replication:

● Snapshot replication—Copying data from one database to another ● Merger replication—Merging data from multiple databases into a separate database ● Transaction replication—Using a master database for regular operations but

periodically copying new and updated entries to a backup

E-vaulting, RJ, and database shadowing are quickly becoming functions of various backup applications rather than services unto themselves. Organizations are increasingly focusing on availability of data rather than on how it is stored. Selecting online or local backup applica- tions that support the storage of real-time versus batched data is more prevalent than examin- ing e-vaulting or RJ methodologies. However, it is important for the organization to select a backup regime that allows it to meet its availability needs without sacrificing its confidentiality and integrity requirements.

Network-Attached Storage and Storage Area Networks Two other advances in data storage and recovery are network-attached storage (NAS) and storage area networks (SANs). Though similar in name, the two have unique implementations and configurations. Unlike direct-attached storage, NAS is commonly a single device or server that attaches to a network and uses common communications methods—such as Windows file sharing, NFS, CIFS, HTTP directories, or FTP—to provide an online storage environ- ment. Commonly implemented as additional storage space, NAS is configured to allow users or groups of users to access data storage. It does not work well with real-time applica- tions because of the latency of the communication methods.

SANs are similar in concept but differ in implementation. Whereas NAS uses TCP/IP-based protocols and communications methods, SANs use fiber-channel direct connections between the systems needing the additional storage and the storage devices themselves. This difference is shown in Figure 3-7 and described in Table 3-4.5

For general file sharing or data backup use, NAS tends to provide a more compatible solution. For high-speed and higher-security solutions, SANs may be preferable. With SANs, only those devices connected to the SAN can access it. With NAS, anyone who can intercept the IP address can access (or attempt to access) it.

Virtualization Critical to any discussion of server or application recovery is the recently prolific technology known as virtualization. Virtualization is the development and deploy- ment of virtual rather than physical implementations of systems and services. A virtual

Data and Application Resumption 107

system is a computer operating environment that operates within another environment, allowing developers and organizations to develop and deploy a multitude of different appli- cations and environments without requiring a separate hardware platform for each environ- ment or operating system. Using virtualization, an organization can take its existing hard- ware and deploy any other operating system and/or application using specialized virtualization technologies. When using virtualization, it is commonplace to use the term “virtual machine” to refer to a virtualized environment operating in or on a host platform. The host platform (i.e., host machine) is the physical server (and operating system) that the

Servers

TCP/IP LAN

NAS RAID array

Servers

Fiber-channel switch

SAN RAID array

Figure 3-7 NAS versus SANs

NAS SAN

Connectivity Any machine that can connect to a LAN and use standard protocols (such as NFS, CIFS, or HTTP)

Only server-class devices with SCSI fiber channel; a topology limit of 10 km

Addressing, identification, and file transfer

By file name, with NAS handling security, including permissions, authentication, and file locking

By disk block number, with no individual security control

OS support Greater sharing, especially between differing OSs

OS dependent and not compatible with all OSs

File system Managed by NAS head unit Managed by servers

backups and mirrors Done on files to save time and bandwidth

Done on blocks, requiring destination to be greater than source volumes

Table 3-4 NAS versus SANs Source: NIST Special Publication 800-43 Rev.1

108 Chapter 3 Contingency Strategies for IR/DR/BC

virtualization application and all virtual machines run on. The virtual machine (also known as the guest) is the hosted operating system or platform running on the host machine. The virtualization application, known as the hypervisor or virtual machine monitor, is the spe- cialized software that enables the virtual machine to operate on the host platform.

Virtualization can occur in a variety of ways:

● Hardware-level virtualization—In this setup, a virtual machine acts like an indepen- dent computer with its own operating system. Hardware virtual machines also allow the development and deployment of simulated hardware components, not just the OS (including network cards). At this level, the physical host’s resources (CPU, RAM, HDD) are divided between the virtual machines and the host itself. This is currently the most common and popular implementation.

● Operating system-level virtualization (also known as software virtualization)—In this approach, only one OS is used: the host’s OS. The virtualization offers multiple virtual sessions of the OS, and thus each application can be independent of the others. This allows increased controls over resource utilization (CPU, RAM, HDD).

● Application-level virtualization—This is a broad term that describes a virtualization approach designed to improve portability and compatibility of applications. The virtualization layer appears to the application as the expected OS, answering all necessary application programming interface (API) calls made by the application. The application perceives that it is interacting with the host OS and the resources managed by it. This approach allows an application to run on a computer that otherwise could not support the application. For example, a Linux OS can support certain Windows applications using a visualization program called Wine.

Within these virtualization environments, memory, storage, data, and networking resources can be virtualized, allowing a differentiation between the physical implementation of the resources and the logical use. For example, virtual machines commonly need multiple net- working addresses separate from the host application’s physical network interfaces. The phys- ical host and virtual hypervisor provide these by mapping them within the host’s equipment.

Although virtualization’s roots can be traced back to the 1960s with the development of IBM’s CP-40, a virtual machine/memory time-sharing operating system, only in the last 15 years or so has it become commercially prevalent and available. SoftPC was developed and introduced in 1988, Virtual PC was developed in 1997, and VMware was patented in 1998. Currently, three applications dominate the virtualization market:

● Microsoft’s Virtual Server ● VMware’s VMware Server ● Oracle VM VirtualBox

Interestingly enough, most of these applications can be traced back to developments by two companies: Innotek GmbH and Connectix Corporation. They were recognized as industry pioneers in virtualization technologies and were acquired by Sun and Microsoft, respectively.

What makes virtualization important to contingency planning is the ability to easily and accu- rately back up an entire system and then port it to another hardware platform, usually within minutes. In addition to specialized backup applications that are available with the virtualiza- tion technology (e.g., VMware’s consolidated backup), virtualization allows administrators to

Data and Application Resumption 109

create snapshot backups, copying the collection of files that support the particular virtual machine to another location, including online, disk, or tape. That image can then be loaded into a new host that’s running the same virtualization application. Then, the image only needs to be mounted to be up, running, and available, all within a much shorter time frame than would be expected if a system had to be built from scratch, then the data reloaded. Addition- ally, because multiple virtual systems can run on a single host, organizations do not have to worry about quickly purchasing and setting up multiple pieces of hardware. This quick response and ease of backup is another reason organizations are moving toward virtualization.

Site Resumption Strategies Five key procedural mechanisms were introduced in the introduction to this chapter. Up to this point, the chapter has focused on the first four of these: delayed protection, real-time protection, server recovery, and application recovery. The fifth of these key procedures, site recovery, is covered next. This section presents the steps needed to plan for and execute the procedure to quickly establish critical capabilities at an alternate site when the organiza- tion’s primary site or sites are not available.

Providing alternate processing capability may be necessary either to implement a disaster recovery plan when the primary site is temporarily unavailable or as a business continuity strategy to institute operations at an alternate site. In either case, it is sometimes necessary to quickly put a computing environment into operation and make sure it can meet the expected needs. Resumption of IT services, whether at a site under the exclusive control of a responding organization or at a site using shared resources, is discussed in the following sections.

A contingency management planning team (CPMT) can choose from several strategies when planning for business resumption. The determining factor is usually cost. In general, the exclu- sive control options are hot sites, warm sites, cold sites, and the three popular shared-use options are timeshare, service bureaus, and mutual agreements.

Exclusive Site Resumption Strategies When an organization wants its operations to resume at a location over which it has exclusive control, it can select from the options shown in Table 3-5, which compares these options.

Site Cost Hardware Equipment

Telecomm- unications Setup Time Location

Cold site Low None None Long Fixed

Warm site Medium Partial Partial/full Medium Fixed

Hot site Medium/high Full Full Short Fixed

Mobile site Dependent Dependent Dependent Dependent Not fixed

Mirrored site High Full Full None Fixed

110 Chapter 3 Contingency Strategies for IR/DR/BC

Hot Sites Although the actual specifics will vary from vendor to vendor, a hot site is gener- ally a fully configured computer facility, with all services, communications links, and physical plant operations, which is capable of establishing operations at a moment’s notice. Hot sites duplicate computing resources (servers, appliances, and support computers), peripherals, phone systems, applications, and workstations. Essentially, it is a duplicate facility that needs only the latest data backups and the personnel to function. Some versions can even be staffed around the clock to transfer control of the data processing almost instantaneously. To do so, the organization must use e-vaulting, RJ, or data shadowing This creates a virtual mirroring of the core IT functions. It is also the most expensive alternative. Other disadvantages include the need to provide maintenance for all the systems and equipment at the hot site, as well as physical and information security. However, if the organization requires a round-the-clock capability for near-real-time recovery, the hot site is the optimum strategy.

Prices for hot sites are based on a number of included options, such as personnel costs, and can total tens of thousands of dollars per month, depending on the speed of changeover needed. The ultimate in hot sites is a mirrored site, which is identical to the primary site and includes live or periodic data transfers. Thus, it is capable of immediate operation. Some orga- nizations may choose to build essential redundancy into the functional specifications of their plant and equipment. This ensures that their environment includes redundant capabilities in locations that are sufficiently isolated to avoid coincidental loss and has sufficient capacity to meet all critical needs, even if one facility is removed from service.

Figure 3-8 provides a conceptual representation of a hot site.

Warm Sites A warm site provides some of the same services and options as a hot site, but software applications are typically not included, not installed, or not configured. A warm site does frequently include computing equipment and peripherals with servers, but not client workstations. It also has connections or access to data backups or off-site storage to facilitate quick data recovery. A warm site has some of the advantages of a hot site, but at a lower cost. The downside is that it may require several hours, perhaps days, to make a

Figure 3-8 Hot site

Site Resumption Strategies 111

warm site fully functional. Prices for warm sites are customized to the needs of the customer but typically range upward of several thousand dollars per month. It is possible for an orga- nization to make contractual arrangements with an equipment provider that maintains stocks of critical equipment in a central facility to reprovision an entire data center with as little notice as 12 hours.

Figure 3-9 provides a conceptual representation of a warm site.

Cold Sites A cold site provides only rudimentary services and facilities. No computer hardware or peripherals are provided. All communication services must be installed after the site is occupied, and frequently there are no quick recovery or data duplication functions to the site. A cold site is an empty room with standard heating, air conditioning, and electri- cal service. Everything else is an added cost option. Despite these disadvantages, a cold site may be better than nothing. The primary advantage is cost. The most useful feature of this approach is to reduce contention for suitable floor space if a widespread disaster strikes, but some organizations are prepared to struggle to lease new space rather than pay mainte- nance fees on a cold site. A cold site can typically cost a few thousand dollars per month and is therefore not a trivial investment.

Figure 3-10 provides a conceptual representation of a cold site.

Mobile Sites and Other Options In addition to these basic strategies, there are some specialized alternatives available, such as a rolling mobile site. Another alternative is storing resources externally; for example, a rental storage area containing duplicate or second-generation equipment can be used. These alternatives are similar to the Preposition- ing of Overseas Materiel Configured to Unit Sets (POM-CUS) sites of the Cold War era, in which caches of materials were stored in case of an emergency or war. An organization might arrange with a prefabricated building contractor for immediate, temporary facilities (mobile offices) on site in the event of a disaster.

Figure 3-9 Warm site

112 Chapter 3 Contingency Strategies for IR/DR/BC

Shared-Site Resumption Strategies When an organization needs to plan for resumption and cannot justify the expense of an exclusive-use strategy, there are three shared-use options that can be chosen from.

Time-Share The first of these shared-use options is the time-share. A time-share operates like one of the hot/warm/cold sites described earlier, but it is leased in conjunction with a business partner or sister organization. The time-share allows the organization to provide a DR/BC option while reducing the overall cost. The primary disadvantage is the possibility that more than one organization involved in the time-share will need the facility simulta- neously. Other disadvantages include the need to stock the facility with the equipment and data from all the involved organizations, the complexity of negotiating the time-share with the sharing organizations, and the possibility that one or more parties will exit the agree- ment or sublease their options. It is much like agreeing to co-lease an apartment with a group of friends. One can only hope the organizations remain on amicable terms, given that they could potentially gain physical access to one another’s data.

Service Bureaus A service bureau is a service agency that provides a service for a fee. In the case of DR/CP, the service is the provision of physical facilities in the event of a disaster. These agencies also frequently provide off-site data storage for a fee. Contracts with service bureaus can specify exactly what the organization needs under what circumstances. A ser- vice agreement usually guarantees space when needed, even if this means that the service bureau has to acquire additional space in the event of a widespread disaster. It is much like the rental car provision in your car insurance policy. The disadvantage is that service con- tracts must be renegotiated periodically and rates can change. This option can also be quite expensive.

Mutual Agreements A mutual agreement is a contract between two organizations for each to assist the other in the event of a disaster. It stipulates that each organization is obligated to provide the necessary facilities, resources, and services until the receiving

Figure 3-10 Cold site

Site Resumption Strategies 113

organization is able to recover from the disaster. This arrangement can be a lot like moving in with relatives or friends. It doesn’t take long for an organization to wear out its welcome. Many organizations balk at the idea of having to fund (even in the short term) duplicate ser- vices and resources. Additional irritants can be the need to allow access to a partner’s employees and contractors as well as the provisioning of office space.

Still, mutual agreements between divisions of the same parent company, between subordinate and senior organizations, or between business partners, may be a cost-effective solution when both parties to the agreement have a mutual interest in each other’s continued operations and they both have similar capabilities and capacities. When an organization finds itself relying on a mutual agreement for its alternate processing needs, it should use a memorandum of under- standing (MOU) to make sure that as many issues as possible are resolved before the need materializes.

Planners should require a memorandum of agreement (MOA), an MOU, or a service-level agreement (SLA) to define the expectations and capabilities for the alternate site. Because this is most often part of a contract for services, counsel for each party must review and approve such agreements. At minimum, such an agreement should include the following:

● Duration ● Costs and fee structures for initiation and use, including fees for occupancy, mainte-

nance, testing, ,and transportation support costs (and all other fees) as well as pay- ment terms and conditions for payment

● Parameters for declaration of activation ● A priority-setting process for when multiple clients claim access at the same time, to

include a listing of other clients subscribing to same resources and site, and the total number of site subscribers, as applicable

● How the contract/agreement can be modified or terminated ● Performance and compatibility guarantees ● System requirements for all computing and network devices and channels as well as

hardware and software ● Full description of change management and notification requirements for hardware,

software, and infrastructure ● Security requirements ● Complete description of support services provided ● Description of support services provided in the facility, such as use of on-site office

equipment, cafeteria, and others ● Testing procedures, including scheduling, availability, and duration ● Provision for records management, both on-site and off-site, as well as use of elec-

tronic media and hardcopy ● Service-level management (performance measures and management of quality of IT

services provided) ● Workspace requirements (chairs, desks, telephone, PCs) ● Supplies provided or not provided (office supplies)

114 Chapter 3 Contingency Strategies for IR/DR/BC

● Additional costs not covered elsewhere ● Other contractual issues, as applicable ● Other technical requirements, as applicable

Service Agreements Whether an organization is making arrangements for an exclusive-use location or a shared- use location, the terms and conditions of that site should be known to all parties by negotiat- ing and executing a service agreement. Service agreements are the contractual documents guaranteeing certain minimum levels of service provided by vendors. It is imperative that ser- vice agreements be reviewed and, in some cases, mandated to support incident, disaster, and continuity planning. If a service provider makes no legal assurances as to the level of perfor- mance, the organization will be unable to require replacement, redundant, or alternative forms of services if the primary is compromised by the contingency.

An effective service agreement should contain information on:

● What the provider is promising ● How the provider will deliver on those promises ● Who will measure delivery and how ● What happens if the provider fails to deliver as promised ● How the SLA will change over time

A typical SLA should include the following sections, as illustrated in the Sample Service Agreement that appears at the end of the chapter (and discussed next):

● Definition of applicable parties ● Services to be provided by the vendor ● Fees and payments for these services ● Statements of indemnification ● Nondisclosure agreements and intellectual property assurances ● Noncompetitive agreements (covenant not to compete)

Definition of Applicable Parties The introductory paragraph in any legal document serves to identify to whom the document applies. Service agreements, as contractual legal documents, are no different. Note that in many documents the long formal names of the two parties are replaced with abbreviated names—for example, “the Client,” “the Vendor,” or “the Service Provider.”

Services to be Provided by the Vendor In this section, the vendor or service pro- vider must specify exactly what the client is to receive in exchange for the payments identi- fied in the following section. Because this service agreement is a legal document, if a service is not explicitly identified in this section, the vendor will not be required to provide it. Any verbal agreements, compromises, or special arrangements must be fully documented. The critical elements of this section should include the specifications of the services expected from the vendor for the protection and restoration of services if an incident or disaster

Site Resumption Strategies 115

occurs. Some organizations also include contingency operations, such as “for a nominal fee the Vendor agrees to provide additional services to an alternate location within X amount of time following an incident or disaster requiring relocation of the Client’s primary business.” However, this type of arrangement typically requires a separate agreement, usually called a business continuity service agreement or contract.

In the Sample Service Agreement that appears toward the end of this chapter, there are state- ments specifically indicating that the vendor agrees to: (a) protect the content of the client, (b) back up the client’s content, and (c) indicate as to restoration of services after internal (system or software failure) or external events. This information is important in determining whether a separate agreement is needed to ensure compliance with the special needs of the organization for data backup and recovery agreements. Without these specific statements, there is no warrantee that the vendor will protect anything but its own software and hard- ware, and the client is required to conduct its own data backup and restoration.

Fees and Payments for These Services This section indicates what the vendor receives in exchange for the services rendered. Although the most common exchange is financial, it is not unusual to see an exchange of services, goods, or other securities. The terms of contract and any special fees, such as late fees, returned check fees, or discounts for early payment, could be specified here. A common inclusion is “2/10 net 30,” indicating a 2 percent discount if paid within 10 days, with the net payment due in 30 days, usually for shipped goods paid by invoice, unlike the annual contract indicated here.

Statements of Indemnification Frequently found in legal documents of this type are statements that the vendor is not liable for actions taken by the client. If the vendor incurs any financial liability based on the use of the vendor’s services (in other words the vendor gets sued because of the use of the services), then the client is responsible for those costs. So, if a client was to put up an insulting Web site that got the client and the vendor sued, the client would be responsible for any fees or expenses incurred by the vendor. Failure to include such statements may result in additional legal fees from both parties, as the vendor sues to recoup its losses.

Nondisclosure Agreements and Intellectual Property Assurances It is important for both parties to understand the level of agreement as to the protection and disclo- sure of the intellectual property of the client. The nondisclosure agreement covers the confidenti- ality of information from everyone unless disclosure is mandated by the courts. Vendors are expected to certify the validity of these documents and then provide the information as required. However, they are prohibited from providing information based on the personal or professional requests of individuals, including law enforcement, without warrant or subpoena.

If the client does not want the vendor to view the contents of its directory, it can ask for that agreement. If the vendor wants to restrict the type of business performed on its systems, it can ask for that agreement. The two parties must formalize the expectations on both sides with regard to the protection of confidentiality of the services and business information to be shared. Even in a breach of contract, the clause stipulating that a breach of one clause (such as the fees paid, as in a late or missing payment) does not negate the legality of another clause (the disclosure of informa- tion); this prevents the vendor from selling off information to recoup financial losses.

Federal law and most state laws permit a service provider to view the contents of its clients’ systems in the routine conduct of business and maintenance on those systems. This means

116 Chapter 3 Contingency Strategies for IR/DR/BC

that the vendor can review the contents of the directory, but it does not mean it can review the contents of the files within the directory. These same laws permit network administrators to review the headers of packets but not the packet data contents. Just because one has access to information does not give one authorization to review the contents. Any expectation or requirement of monitoring should be stipulated in the agreements as well.

Noncompetitive Agreements (Covenant Not to Compete) Although not essential to a service agreement, it is customary for the client to agree not to use the vendor’s services to compete directly with the vendor, and for the client not to use vendor informa- tion to gain a better deal with another vendor. In the early days of MCI and Sprint, federal regulation required (and still requires) such common carriers to offer services even to com- panies that would use those services to compete with them. MCI and Sprint leased services from AT&T to establish their start-ups and then moved to their own networks. However, outside of the telecommunications and cable television industries, where court orders can mandate specific arrangements between competitive organizations, there is no requirement that an organization allow subleases that can create an advantage for a competitor.

The following example illustrates what should be included in a service agreement.

SAMPLE SERVICE AGREEMENT

CONTRACT FOR SERVICES

BETWEEN

SEQUENTIAL LABEL AND SUPPLY, hereafter referred to as the “Client,” and HIERARCHICAL ACCESS LTD, hereafter referred to as the “Vendor.”

The Client and the Vendor hereby agree to the following terms and conditions regarding Web hosting and related services, hereafter referred to as the “services.”

1. VENDOR’s RESPONSIBILITIES

The Vendor will arrange and manage a Web site and Web domain hosting for the Client. The Vendor will lease the agreed amount of up to 2 GB of Web storage space on its servers and, on the Client’s behalf, register a domain name of “SequentialLabel.com” and host this domain name on its primary and secondary name servers. The Vendor will support ongoing maintenance and support of the hardware hosting the virtual presence of the Client, and warrantee the following:

• 24/7 availability with less than one hour per month downtime due to maintenance, to be performed with advanced warning and at a time suited to the needs of the Client (e.g., between 2 a.m. and 4 a.m. on Sundays) • 24/7 access to the directory for the purposes of populating and modifying the contents of the Web directory • 24/7 technical support for equipment and Web hosting issues to the Client • A dedicated account manager who will guarantee return of communications (phone, fax or e-mail) within one hour during normal business hours or within 1 hour of start of business day for after-hours communications

Site Resumption Strategies 117

• Weekly backup of all Client content, with 24/7 access to archived copies, and with Vendor agreeing to retain two newest versions for Client access • Restoration of Web presence due to down equipment caused by equipment or soft- ware failure within two hours • Restoration of Web presence due to natural disasters, power failure, or other incidents or disasters as quickly as possible, depending on the extent and damages of these acts

The Vendor will not be responsible for the contents of the Web directory, including the creation, modification, or technical support of the Web documents, except as they pertain to the operation of the underlying hardware and software. The Vendor reserves the right to inspect said contents for technical support of the systems housing the content, and to warrantee that no illegal or illicit activities or commerce is transpiring. The Vendor does not permit the use if its facilities for adult-oriented commerce or recreations, or for illegal activities.

2. COSTS AND TERMS

a. Basic Service: The Client agrees to compensate the Vendor for providing those ser- vices expressed in this agreement for the price of $10,000.00.

b. Term: The initial term of this agreement will be 12 months and will commence from the date of this agreement. Unless terminated as provided by this agreement, the agreement shall thereafter automatically renew for successive 12-month terms.

c. Taxes: The Vendor will pay for any and all sales and use taxes, duties, or levies imposed by any authority, government, or government agency in connection with the Web services, including property taxes and the Vendor’s income taxes.

3. INDEMNIFICATION

The Client hereby agrees to protect, hold free and harmless, defend and indemnify the Vendor from any and all claims or demands of any kind and from all liability, penal- ties, costs, losses, damages, expenses, claims, or judgments (including attorney’s fees) resulting from legal issues arising from the conduct of electronic commerce or the dis- play of the Client’s Web content. Any and all fees associated with legal proceedings against the Vendor as a direct consequence of the display or hosting of the Client’s material will be covered totally and in full by the Client. Liability for any services or fees incurred by the Vendor as a result of this contract will be paid for by the Client, including but not limited to notary public, arbitration, mediation, legal, and court fees.

4. GENERAL

a. The Vendor shall not assign or transfer any rights or obligations under this agreement without the Client’s prior written approval.

b. Breach of any contract provision by the Vendor can only be waived in writing.

c. Waiver of any breach by the Vendor shall not be deemed to be a waiver of any other breach.

d. This agreement constitutes the entire agreement between the parties with respect to Web services and cannot be modified without the express written consent of all parties.

118 Chapter 3 Contingency Strategies for IR/DR/BC

e. Neither the Client nor the Vendor has made any promise, representation, or warranty, explicit or implied, not set forth in this contract.

f. If any portion of this agreement is held by a court of competent jurisdiction or mutually agreed on authority, to be invalid, void, or unenforceable, the remainder will nevertheless continue in full force without impairment or invalidation.

g. This agreement shall be governed and interpreted by the laws of this state applica- ble to such contracts entirely made and performed in said jurisdiction and venue.

5. NONDISCLOSURE AND INTELLECTUAL PROPERTY

The Vendor hereby acknowledges and agrees that all information disclosed to the Ven- dor by the Client, whether written or oral, relating to the Client’s business activities; its customer names and addresses; all operating plans; information relating to its existing services, new or envisioned; the Client’s products or services and the development thereof; scientific, engineering, or technical information; the Client’s marketing or prod- uct promotional material, including brochures, product literature, plan sheets, and any and all reports generated to customers or to the Vendor with regard to customers; unpublished lists of names; and all information relating to the Client’s order processing, pricing, cost, and quotations; and any and all information relating to the Client’s rela- tionship with customers and the Vendor, is considered confidential information and is proprietary to, and is considered the invaluable trade secret of the Client(collectively “Confidential Information”).

The Vendor retains the right to review the contents of its directories in the normal course of business and as part of the ongoing maintenance of the systems and software supporting the Client’s intellectual property.

The Vendor understands that the Client desires to keep such Confidential Information in the strictest confidence, and that the Vendor’s agreement to do so is a continuing condition of the receipt and possession of Confidential Information, and a material provision of this agreement, and a condition that shall survive the termination of this agreement. Consequently, the Vendor shall use Confidential Information for the sole purpose of performing its obligations as provided herein. The Vendor agrees:

i) Not to disclose Confidential Information to future or existing competitors

ii) To limit dissemination of Confidential Information to only those of the Vendor employees who have a need to know such Confidential Information in order to perform their duties as set forth herein

iii) To return Confidential Information, including all copies and records thereof, to the Client upon receipt of a request from the Client, or termination of the agreement as provided herein, whichever occurs first

6. NONCOMPETITION

a. The Vendor covenants and agrees that the Vendor will not directly or indirectly, own, manage, operate, join, control, work for, or permit the use of its name by, or be connected in any manner with, any business activity which is directly competitive with

Site Resumption Strategies 119

Chapter Summary ● The umbrella term contingency planning (CP) addresses everything done by an

organization to prepare for the unexpected as well as later parts of the information- security process, which are focused on keeping the business alive.

● A business resumption (BR) plan has two major elements: the disaster recovery (DR) plan, for resuming normal operations at the primary sites, and the business continuity (BC) plan, for activating critical business functions at an alternate site.

● Each of the components of BR planning (the DR plan and the BC plan) comes into play at a specific time in the life of an incident, and overlap between them may occur.

● There are five key procedural mechanisms that facilitate the restoration of critical information and the continuation of business operations: delayed protection, real-time protection, server recovery, application recovery, and site recovery.

● A backup plan is essential; data files and critical system files must be backed up fre- quently, and nonessential files can be backed up less frequently. Equally important is the determination of how long data should be stored. There are three basic types of

any aspect of the business of the Client, (as set forth in the business plan delivered to the Vendor herewith), which is the same business of the Client, as previously conducted, and as said business may evolve in the ordinary course between the date of this agreement and its termination whether said business is conducted by the Client or any successor or assign.

b. The Client covenants and agrees that the Client will not directly or indirectly, own, manage, operate, join, control, work for or permit the use of its name by, or be connected in any manner with, any business activity which is directly competitive with any aspect of the business of the Vendor, (as set forth in the business plan delivered to the Client herewith), which is the same business of the Vendor, as previously conducted, and as said business may evolve in the ordinary course between the date of this agreement and its termination whether said business is conducted by the Vendor or any successor or assign.

c. The parties hereto agree that the provisions of this agreement extend to the employees and officers of their respective companies/businesses. Said principals further agree to provide the requisite internal security of the subject data within their respective organizations and with respect to any and all additional sources who may be parties to the transactions or proposed transactions.

IN WITNESS WHEREOF, the parties hereto, agreeing to be bound hereby, execute this agreement on this day of .

President & CEO, President & CEO, Sequential Label and Supply, Inc. Hierarchical Access Limited. on behalf of the client on behalf of the vendor

120 Chapter 3 Contingency Strategies for IR/DR/BC

backups: full, differential, and incremental. A full backup is a full and complete backup of the entire system, including all applications, operating systems components, and data. A differential backup is the storage of all files that have changed or been added since the last full backup. An incremental backup only archives the files that have been modified that day and thus requires less space and time than a differential backup.

● Another form of data backup is that of online disk drives used for redundancy. The usage of RAID systems can overcome some of the limits of magnetic tape backup systems and provide enhanced capabilities. Many organizations are creating massive arrays of independent but large-capacity disk drives to store information and copy critical files to these devices as routine backup.

● Cloud backups are becoming a popular way to back up and store data in remote locations while ensuring that it is available for quick restoration, if necessary. Cloud computing is a popular way to lease computing resources. It comes in three offerings: Software as a Service (SaaS), in which applications are provided at a fee and hosted over the Internet; Platform as a Service (PaaS), in which development platforms are made available to developers and hosted by third parties; and Infrastructure as a Service (IaaS), in which the hardware and operating systems resources made available to an organization are hosted by a third party. Clouds can be public, community, private, or a hybrid of these three.

● When systems make use of databases, whether hierarchical, relational, or object oriented, they require special considerations when planning backup and recovery procedures. Some applications use file systems and databases in ways that invalidate the customary way of doing backup and recovery. In some cases, applications write large binary objects as files and manage pointers, and create internal data structures in ways that make routine backups unable to handle the concurrency or complexity of the application.

● Even the best backups are inadequate unless they can be used to successfully restore systems to an operational state. Each backup and recovery setting should be provided with complete recovery plans, including testing and rehearsal.

● To provide real-time protection, also known as replication, a popular feature used in server support is the use of mirroring and duplication of server data storage with RAID techniques.

● The bulk transfer of data in batches to an off-site facility is called electronic vaulting (e-vaulting) and is usually conducted with the receiving server archiving the data as it is received.

● Remote journaling is the transfer of live transactions to an off-site facility so that all changes are recorded.

● Database shadowing, also known as databank shadowing, is the storage of duplicate online transaction data, along with the duplication of the databases at the remote site to a redundant server.

● Several strategies are possible when planning for business resumption, including: hot sites, warm sites, cold sites, time-share, service bureaus, and mutual agreements. A hot site is a fully configured computer facility, with all services, communications links, and physical plant operations, capable of establishing operations at a moment’s

Chapter Summary 121

notice. A warm site provides some of the same services and options as the hot site, but software applications are typically not included or not installed and configured. A cold site provides only rudimentary services and facilities, and no computer hardware or peripherals are provided. A time-share operates like one of the three sites just mentioned, but it is leased in conjunction with a business partner or sister organization. A service bureau is a service agency that provides a service for a fee, such as the provision of physical facilities in the event of a disaster. A mutual agreement is a contract between two organizations for each to assist the other in the event of a disaster.

● Service agreements are the contractual documents guaranteeing certain minimum levels of service provided by vendors. An effective service agreement should contain a definition of applicable parties, a list of services to be provided by the vendor, fees and payments for these services, a statement of indemnification, nondisclosure agree- ments and intellectual property assurances, and noncompetitive agreements.

Review Questions 1. What purpose does business resumption planning serve?

2. What are the two major component parts of a BRP plan, and how are they related?

3. What is the primary site?

4. What is the difference between a backup and an archive?

5. What is a retention schedule?

6. How have cloud computing architectures affected the backup options available for organizations?

7. What are the major types of backups?

8. What is encompassed in a full backup?

9. What is encompassed in a differential backup?

10. What is encompassed in an incremental backup?

11. What is a redundant array of independent disks (RAID), and what are its primary uses? How can it be used in a backup strategy?

12. What is disk striping, and how might it be considered the opposite of disk mirroring?

13. In what way are the backup needs of systems that use databases different from the backups used to safeguard nondatabase systems?

14. Beyond simply identifying what to back up, when to back it up, and how to restore it, what should a complete backup recovery plan include?

15. What is bare metal recovery?

16. What is electronic vaulting, and how is it used in a backup strategy?

17. What is remote journaling, and how is it used in a backup strategy?

122 Chapter 3 Contingency Strategies for IR/DR/BC

18. What is database shadowing?

19. What is virtualization?

20. Explain the site resumption strategy known as exclusive use and how it uses hot sites, warm sites, and cold sites.

21. Explain these shared-use strategies: time-share, service bureau, and mutual agreement.

Real-World Exercises Exercise 3-1 This chapter’s opening scenario illustrates a specific type of incident/disaster. Using a Web browser, search for information related to preparing an organiza- tion against terrorist attacks. Look up information on (a) anthrax or another

biological attack (like smallpox), (b) sarin or another toxic gas, (c) low-level radiological con- tamination attacks.

Exercise 3-2 Using a Web browser, search for available commercial applications that use various forms of RAID technologies, such as RAID 0 through RAID 5. What is the most common implemen- tation? What is the most expensive?

Exercise 3-3 Not too long ago, tape backup was the industry standard. Is it still? Using a Web browser or your local library’s electronic-journal search tool, review the popular trade press journals to determine whether tape, disk, or drive backups are more prevalent now and which is pre- dicted to be the new standard in the near future.

Exercise 3-4 Using a Web browser, search for vendors that provide alternate site strategies, such as hot sites, warm sites, and cold sites. How prevalent are they? What about mobile sites?

Exercise 3-5 This chapter provides one example of a service agreement. Using a Web browser, search for other examples. How do they differ? What areas are common to all?

Hands-On Projects

In the following projects, we will examine two different ways to make a backup of the Security Onion virtual image we already created. In the first method, we will make a backup from within Security Onion, using command- line tools. In the second method, we will copy the virtual image files themselves.

Hands-On Projects 123

Hands-On Project 3-1: Command-line Backup Using rdiff-backup In this project, you will use the rdiff-backup command to make a backup of the Security Onion system. To successfully complete this project, you will need to have a second system available for use as a storage solution. Setup of this storage solution is outside the scope of this project, but any system that has rdiff-backup installed, allows ssh login, and has suffi- cient disk space to handle the backup will be fine. In addition, you will need credentials to log into the backup system before we begin the exercise.

1. On the Security Onion desktop, double-click the Terminal icon. This will open up a command-line terminal.

2. Rdiff-backup is not installed by default, so you will have to install it now. Type sudo apt-get install rdiff-backup, as shown in Figure 3-11. Press Enter.

3. When asked if you want to continue, type Y, as shown in Figure 3-12. If prompted, enter your administrator password to allow the installation to continue. You will expe- rience a brief delay and see output on the screen as the necessary packages install.

Source: Security Onion

Figure 3-11 Security Onion terminal

124 Chapter 3 Contingency Strategies for IR/DR/BC

4. Type sudo rdiff-backup –v5 [source directory] [username]@[remote host]::[destination directory]. Then press Enter. This replaces the source directory, username, remote host, and destination directory values with the appropriate data. To make a full backup of the entire drive, you would use the forward slash (/) as the source directory. To speed up the exercise, use /var instead. Your screen should look similar to what is shown in Figure 3-13. Press Enter.

Source: Security Onion

Figure 3-12 rdiff-backup install

Source: Security Onion

Figure 3-13 rdiff-backup command

Hands-On Projects 125

5. If prompted, enter your password.

6. If asked whether you want to continue connecting, type yes. Your screen should look similar to what is shown in Figure 3-14. Press Enter.

7. After a brief delay, the backup is now complete.

Hands-On Project 3-2: Copying Virtual Images Next, we will look at how to copy the actual virtual hard disk and configuration files cre- ated by VMware Player during setup to a different location for local backup purposes.

1. If the Security Onion virtual image is running, use the VMware player controls to stop it.

2. Open Windows Explorer on your host system, and navigate to the folder where VMware Player stored the files associated with the Security Onion image. Windows Explorer should look similar to Figure 3-15.

Source: Security Onion

Figure 3-14 rdiff-backup ssh connect

126 Chapter 3 Contingency Strategies for IR/DR/BC

3. To safely back up the VMware image, we are interested in two files: the Virtual Machine disk and the VMware configuration file. These files have .vmdk and .vmx as their respective extensions. Press CTRL and click both of these files to select them. Your screen should look similar to the one shown in Figure 3-16. Right-click and select the Copy option.

4. Within Windows Explorer, navigate to a folder where you would like to save your backup.

Source: Microsoft Windows

Figure 3-15 VMware directory

Source: Microsoft Windows

Figure 3-16 Copy VMware files

Hands-On Projects 127

5. Right-click in the main window. Your screen should look similar to the one shown in Figure 3-17. Select the Paste option.

6. The files should now be copied into your designated backup folder. During the actual copying process, your screen should look similar to the one shown in Figure 3-18.

Source: Microsoft Windows

Figure 3-17 Paste VMware files

Source: Microsoft Windows

Figure 3-18 VMware files copied

128 Chapter 3 Contingency Strategies for IR/DR/BC

Endnotes 1. Swanson, M., Bowen, P., Phillips, A., Gallup D., and Lynes D. NIST Special Publication

800-34 Rev.1: Contingency Planning Guide for Federal Information Systems. NIST May 2010. Accessed August 26, 2012 @ http://csrc.nist.gov/publications/nistpubs/800- 34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

2. Ibid.

3. Cook, Rick. “Deciding on Electronic Vaulting.” SearchStorage 22 January 2002. Accessed August 26, 2012 @ http://searchstorage.techtarget.com/tip/1,289483, sid5_gci797551,00.html?bucket=ETA.

4. Emerson, R. “The World’s Top 9 Countries With The Fastest Internet Speeds.” The Huffington Post 28 October 2011. Accessed August 26, 2012 @ www.huffingtonpost. com/2011/10/27/fastest-internet-countries-akamai_n_1051651.html.

5. “Technology Overview.” NAS-SAN.com. Accessed August 26, 2012 @ www.nas-san. com/differ.html.

6. Swanson, M., Bowen, P., Phillips, A., Gallup D., and Lynes D. NIST Special Publication 800-34 Rev.1: Contingency Planning Guide for Federal Information Systems. NIST May 2010. Accessed August 26, 2012 @ http://csrc.nist.gov/publications/nistpubs/800- 34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf.

Deputy Chief Corbett stood up and returned to the command vehicle that was parked in the street outside the office building.

Alan breathed a sigh of relief, then flipped open his master contingency planning binder.

“At least we don’t have to make up a plan,” he said. “Let’s review our next steps in case our offices are closed for the next month.”

Discussion Questions 1. What other crises or catastrophes can happen in a mailroom that could prompt an

emergency procedure like the one illustrated here?

2. What goals should be included when planning for the resumption of critical busi- ness functions at an alternate site for four weeks? What would be different if the planning horizon were 30 weeks instead?

3. When the organization makes a plan like the one described here, what parts of the plan should be from the contingency planning management team (CPMT) and what parts should come from the subject area experts?

Closing Case Scenario: Disaster Denied

Endnotes 129

chapter 4

Incident Response: Planning

If you can keep your head when all about you are losing theirs and blaming it on you, if you can trust yourself when all men doubt you, … yours is the Earth and everything that’s in it. —Rudyard Kipling

Upon completion of this material, you should be able to: ● Describe the process used to organize the incident response planning process ● Describe the activities and deliverables used to develop an incident response policy, including

how policy affects the incident response planning process and how policy can be implemented to support incident response practices

● Explain the techniques that can be employed when forming a security incident response team

● List the skills and components required to devise an incident response plan ● Discuss some of the concerns and trade-offs to be managed when assembling the

final incident response plan

131

It was two o’clock in the morning when Paul’s cell phone began to buzz. He turned in his bed once, then twice, before finally grabbing for the phone. Seeing the Net- work Operations Center’s number lit up on the display, he answered.

“Sorry to wake you, Paul.” It was Susan Carter, the third shift supervisor. Now that everything was back to normal operation after the fire, she was working her usual hours again.

“What’s up, Susan?” Paul replied groggily. “We’re getting slammed by a DDoS again,” Susan said. She sounded worried. “I thought these were pretty routine,” Paul said. “Don’t you just reconfigure the

outside firewall?” “I did that already,” Susan said. “Now it’s coming in on a different port. This is the

third one in about 10 minutes. That makes it seem like a live attack rather than a scripted attack, which is significant to us because a scripted attack can usually be stopped cold, at least for a while, by filtering out the port or network address. I think this means that the attack is being executed in real time by a human attacker. We need you to make some decisions.”

“Uh oh,” Paul said. Wide awake now, he began to go over in his mind what he knew about DDoS attacks and what Susan just told him.

“Okay,” Paul replied while reaching for the laptop computer on his nightstand. “Give me a minute to get logged in.”

For the next few minutes, he carefully scanned the logs on the firewall and border gateway over his VPN connection. He had seen that all the attacks seemed to be within a certain range. “Susan,” he finally said, “try adding a rule to filter ports 1400 through 2200.”

As she clicked away on her end, something from the back of Paul’s mind nagged at him. What was it? Something to do with a new vulnerability he read about in the last few days.

“Yes!” Susan exclaimed. “I think that did it!” “Okay, pull all the logs and print them out, and we’ll go over them when I come

in—” Paul leaned over to look at the clock, “in just under an hour.” “Okay, I’ll have the coffee ready!” Susan laughed. Paul leaned back in bed. “Maybe just a few more minutes of shuteye,” he

thought. Then his cell phone went off again.

Opening Case Scenario: DDoS Dilemma

132 Chapter 4 Incident Response: Planning

Introduction Contingency planning (CP) addresses everything done by an organization to prepare for the unexpected. Incident response (IR), one of the elements of CP, focuses its efforts on detecting and evaluating the severity of emerging unexpected events. Whenever possible, the IR process should attempt to contain and resolve incidents according to the IR plan. When incidents arise that cannot be contained or resolved, other elements of the CP process are activated, using the documented escalation processes as noted throughout the plan. The overall IR process is made up of several phases: preparation, detection and analysis, containment, eradication and recov- ery, and post-incident activity.1 Because of the complexity of the IR process, this chapter will address the initial preparation phase. Later chapters will cover the planning functions of IR, organization and preparation efforts, detection aspects, response strategies, recovery from inci- dents, and the remaining components of the IR process. This chapter focuses on creating the IR plan used by organizations to effectively respond to incidents.

The IR Planning Process When the contingency planning management committee (CPMT) completes each component of the business impact analysis (BIA), it begins to transfer the information gleaned from the organization to the various subordinate committees. To assist in their subordinate planning, the IR committee, disaster recovery (DR) committee, and the business continuity (BC) commit- tee each get overlapping information on the attacks they could face, the prioritization of those attacks, and the attack scenario end cases. In fact, each committee gets as much of the overall contingency plan as the CPMT has prepared. Once committee members have this information, they begin their subordinate plans. In the case of incident planning, the group follows these general stages:

● Form the IR planning committee. ● Develop the IR planning policy. ● Integrate the BIA. ● Identify preventive controls. ● Organize the Computer Security Incident Response Team (CSIRT; covered in

Chapter 5). ● Create IR strategies and procedures (covered in Chapter 7). ● Develop the IR plan. ● Ensure plan testing, training, and exercises. ● Ensure plan maintenance.

To gain an overview of the ways that IR planning is performed at other organizations, two examples of the IR planning life cycle are shown in Figures 4-1 and 4-2. Figure 4-1 shows how the U.S. National Institute of Standards and Technology (NIST) defines the IR planning process. As can be seen from the figure, this book follows the NIST approach very closely. Figure 4-2 provides a slightly broader perspective, inspired by the CERT Coordinating Center (CERT/CC) approach to IR planning fits into its overall IR model.

The IR Planning Process 133

Organizing the IR planning process begins with staffing the IR planning committee. Much of the preliminary organizing effort was done by the CP team, but the IR team needs to be organized as a separate entity, and that process begins by identifying and engaging a collection of stakeholders, meaning a representative collection of individuals with a stake in the successful and uninterrupted operation of the organization’s information infrastructure. These stakeholders are used to collect vital information on the roles and responsibilities of the CSIRT. Typical stakeholders often include:

● Communities of interest, such as:

� General management needs to understand what the CSIRT is and what it does. It also needs to preauthorize interaction between CSIRT and key business functions, should certain actions be necessary to arrest the spread and impact of an incident.

� IT management needs to understand the specific demands the CSIRT will place on IT, and what resources and access they will require to successfully respond to an incident. It also needs to preapprove certain CSIRT actions when those actions affect existing systems, networking functions, and connections.

� InfoSec management needs to understand the on-hand requirements of the CSIRT should the team be called into action on short notice.

Triage

Help desk

IDPS

Other

Report of vulnerability

Request for information

Incident report Resolve

Triage Analyze/coordinate/respond

Source: Handbook for Computer Security Incident Response Teams (CSIRTs)

Figure 4-2 CERT incident-handling life cycle3

Preparation Detection and

analysis

Containment eradication

and recovery Post-incident

activity

Source: NIST SP 800-61, R.2

Figure 4-1 NIST incident response life cycle2

134 Chapter 4 Incident Response: Planning

● Organizational departments, such as:

� The Legal Department needs to review the procedures of the CSIRT and under- stand the steps the CSIRT will perform to ensure it is within legal and ethical guidelines for the municipal, state, and federal jurisdictions. The Legal Department can provide guidance on developing contracts and service-level agreements for auxiliary and redundant services, on developing nondisclosure agreements for business partners and other nonemployee associations, and on reviewing policy and plan documents for liability issues.

� The Human Resources Department (HR) helps InfoSec staff acquire personnel not already on hand to complete the CSIRT team. The organization may not currently employ individuals with IR experience. Those who are developing job descriptions and interviewing and eventually hiring candidates will benefit from close coordi- nation with HR.

� The Public Relations (PR) Department needs to be briefed on what information can be and should be disclosed to the public if and when an incident occurs. Pre- defined public notices can be drafted and reviewed by PR to ensure the proper amount of information is provided to the appropriate agencies, law enforcement, and the media when the need arises.

� Depending on the organization of the company, some departments with an infor- mation security overlap will also need to be consulted, including:

● Physical security ● Auditing and risk management ● Insurance

● Other interest groups, such as:

� General end users need to know what transpires when the CSIRT swings into action and how to respond to best assist in the development and testing of proce- dures and policies. These stakeholders are also most familiar with the functions of the business and can provide additional insight into these areas.

� Others stakeholders, including key business partners, contractors, temporary employee agencies, and, in some cases, consultants.4

Forming the IR Planning Team From the communities of interest and the CPMT, the executive leadership of the organization should begin building the team responsible for all subsequent IR planning and development activities. This team, the Incident Response Planning team (IRP team), should consist of indi- viduals from all relevant constituent groups that will be affected by the actions of the front- line response teams, most notably the CSIRT, discussed in Chapter 6. As a result, the IRP team will typically be composed most heavily of information technology (IT) and information security professionals, with representatives from the CPMT and organizational management. In any case, the IRP team leader, selected from within the team, will serve as liaison between the IR team and the CPMT.

The IRP team will work together to build the IR policy, plan, and procedures that the CSIRT will follow during the IR actions themselves. Just as with any organizational team, the group

The IR Planning Process 135

will require a champion, typically the chief information officer (CIO) or vice president of IT, as well as a selected or elected group leader to manage the team. The group should meet reg- ularly to initially build the IR policy, then complete development of the IR plan. This group is also responsible for the structuring, development, and training of the CSIRT at the appro- priate juncture in the planning process.

Developing the Incident Response Policy One of the first deliverables prepared by the IRP committee should be the IR policy. As the planning committee forms a CSIRT, key representatives from that team should join the IRP committee in the development of policy to define the operations of the team, articulate the orga- nizational response to various types of incidents, and advise end users on how to contribute to the effective response of the organization rather than contributing to the problem at hand.

The IR policy is similar in structure to other policies used by the organization. Just as the enterprise information security policy defines the roles and responsibilities for information security for the entire enterprise, the IR policy defines the roles and responsibilities for IR for the CSIRT and others who will be mobilized in the activation of the plan. Table 4-1 provides an overview of a typical IR policy.

IR policy, like all well-written policies, must gain the full support of top management and be clearly understood by all affected parties. It is especially important to gain the support of those communities of interest that will be required to alter business practices or make changes to their IT infrastructures. For example, if the CSIRT determines that the only way to stop a massive denial- of-service (DoS) attack is to sever the organization’s connection to the Internet, it should have a signed document locked in an appropriate filing cabinet preauthorizing such action. This prevents any perception of the CSIRT team performing actions outside its level of authorization and protects both the CSIRT team members and the organization from misunderstanding and potential liability.

Statement of management commitment

Purpose and objectives of the policy

Scope of the policy (to whom and what it applies and under what circumstances)

Definition of information security incidents and their consequences within the context of the organization

Organizational structure and delineation of roles, responsibilities, and levels of authority; should include the authority of the IR team to confiscate or disconnect equipment and to monitor suspicious activity, and the requirements for reporting certain types of incidents

Prioritization or severity ratings of incidents

Performance measures (as discussed in later chapters)

Reporting and contact forms

Table 4-1 Incident response policy elements5 Source: NIST SP 800-61

136 Chapter 4 Incident Response: Planning

Table 4-2 provides additional attributes of the policy, beyond its content.

Policy Attribute

Objective

Support All strategic directives must be supported by the entire senior management team. This encompasses the vision statement, the mission statement, and all enterprise-wide policies.

Clarity Each person expected to comply with policy must be able to understand the policy as it is written. This includes all of the affected groups including various levels of management, technical staff and administrative staff. Writing should be free from technical terms when possible, and avoid ambiguity in phrasing and usage. A best practice is to write using short sentences and a restricted vocabulary. When consistent with your classification and disclosure policies, invite representative groups outside the security team to read drafts and specifically comment on readability. Revise and rewrite as indicated until the prose is understandable by the intended audiences.

Length As often quoted from Shakespeare, brevity is the soul of wit. This is also true when writing policy. Policy that is longer than absolutely required is either poorly designed, poorly written, or is, in fact, a procedure (which is not really part of policy). Regrettably, security policies of improper length are frequently implemented because they confuse the real intent of communicating management intent with the distraction of encouraging the operational processes. Those detailed process directives are procedures, not policies, and while they are important and need to be written, they are not part of the policy.

Required and sufficient

Written policies must include only what is required and must include all that is required. Redundancy is not an objective in creating policy documents but may be referenced in the supporting procedures and other parts of the managerial process.

Functional Use concrete language that directs behavior and avoid statements that are subject to individual interpretation. Pleasant phrases that state truisms like “we will always provide world-class security services” serve little purpose to inform policy adherents of how they should act. It may be neccessary on occasion to include truisms if they lead to concrete actions, such as “stakeholders and customers will be treated with respect,” but this only serves its purpose when those expected to follow the policy know what the phrases mean.

Realistic Unless a policy is realistic in the cultural context of the intended organization, it will fail before it is implemented. In the “respect” example above, additional guidance about how to reach that objective is needed. This might be a directive to provide regular training to all staff to understand how to deal with customers. Unless a policy can be followed to achieve the objective intended by that policy, it is not realistic.

Enforceable Unless a policy has sufficient detail and concrete requirement to aid in its enforcement, it is of limited or no value. Enforceable policies are accompanied by measurement criteria and assessment guidance for those criteria such that compliance can be evaluated. These criteria and how they are used to assess performance may often be labeled as standards. An example of a contradictory policy would be one that claims data security as a first priority and also requires complete privacy for all stakeholders. The second requirement will preclude any possibility of achieving the first.

Table 4-2 Additional IR policy elements6 Source: Carnegie Mellon University, Software Engineering Institute

Just as in developing other policies, the involvement of those who will actually use the policies is critical in their development. In addition, interaction and review by the other CP teams (DR and BC) will aid in the development of clear, consistent, and uniform policy elements and structure. It is useful to look at published policies from other agencies and organizations in developing the policy.7 Other sources of information for the policies include:

● Organization charts for the enterprise and specific business functions ● Topologies for organizational or constituency systems and networks

Developing the Incident Response Policy 137

● Critical system and asset inventories ● Existing DR or BC plans ● Existing guidelines for notifying the organization of a physical security breach ● Any existing IR plans ● Any parental or institutional regulations ● Any existing security policies and procedures8

Building the Computer Security Incident Response Team In some organizations, the CSIRT may simply be a loose or informal association of IT and Info- Sec staffers who would be called up if an attack was detected on the organization’s information assets. In other, more formal implementations, the CSIRT (also referred to as a Security IRT or Computer IRT) is the team of people and their supporting policies, procedures, technologies, and data necessary to prevent, detect, react, and recover from an incident that could potentially damage the organization’s information. At some level, all members of an organization are mem- bers of the CSIRT team, as every action they take could potentially cause or avert an incident.

Development and structure of the CSIRT is covered in detail in a later chapter.

Incident Response Planning An incident response plan (IR plan) is a detailed set of processes and procedures that anticipate, detect, and mitigate the effects of an unexpected event that might compromise information resources and assets. In an organization, unexpected activities occur periodically; these are referred to as adverse events. In contingency planning, an adverse event that threatens the security of the organization’s information is called an incident. An incident occurs when an adverse event (natural or human made) affects information resources and/or assets, causing actual damage or other disruptions. Incident response (IR), then, is a set of procedures that commence when an incident is detected. IR must be carefully planned and coordinated, because organizations heavily depend on the quick and efficient containment and resolution of incidents. The IR plan is usually activated when an incident causes minimal damage—according to criteria set in advance by the organization—with little or no disruption to business operations. Adverse events causing damage beyond this threshold would be classified as disasters.

When one of the threats identified in Chapter 1 turns into a valid attack, it is classified as an information security incident, but only if it has all of the following characteristics:

● It is directed against information assets owned or operated by the organization. ● It has a realistic chance of success. ● It threatens the confidentiality, integrity, or availability of information resources

and assets.

The prevention of threats and attacks has been intentionally omitted from this discussion because guarding against such possibilities is entirely the responsibility of the Information Security Department. It is important to understand that IR procedures are reactive measures and, excluding the efforts taken to prepare for such actions, are not considered a preventive control.

138 Chapter 4 Incident Response: Planning

The responsibility for creating an organization’s IR plan often falls to the chief information security officer (CISO). With the aid of other managers and systems administrators on the IRP team, the CISO should select members from each community of interest to form the CSIRT that will execute the IR plan. The roles and responsibilities of the members of the IRP team and the CSIRT should be clearly documented and communicated throughout the organi- zation. The IR plan also includes an alert roster that lists certain critical agencies to be con- tacted during the course of an incident. Planning for an incident and the responses to it requires a detailed understanding of the information systems and the threats they face. The IRP team and the CSIRT seek to develop a series of predefined responses that will guide the team and information security staff through the IR steps. Predefining incident responses enables the organization to react to a detected incident quickly and effectively, without confu- sion or wasted time and effort.

As part of the multistep CP process discussed in detail in Chapter 2, the IR team creates the IR plan, and from there the IR procedures that are integral to the plan can begin to take shape. For every potential attack scenario, the IR team creates the incident plan, which is made up of three sets of incident-handling procedures. These procedures address steps to be taken during, after, and before an incident:

● During the incident—The planners develop and document the procedures that must be performed during the incident. These procedures are grouped and assigned to individuals. Systems administrators’ tasks differ from managerial tasks, so members of the planning committee must draft a set of function-specific procedures.

● After the incident—Once the procedures for handling an incident are drafted, the planners develop and document the procedures that must be performed immediately after the incident has ceased. Again, separate functional areas may develop different procedures.

● Before the incident—The planners draft a third set of procedures, which are those tasks that must be performed to prepare for the incident. These procedures include the details of the data backup schedules, DR preparation, training schedules, testing plans, copies of service agreements, and BC plans, if any. At this level, the BC plan could consist of just additional material on a service bureau that stores data off site via electronic vaulting, with an agreement to provide office space and to lease equipment as needed.

Although it may not seem logical to prepare the documentation of the IR plan in the order just described, this is a practical consideration. When the members of the IR team reach for the documentation, the primary concern is what is to be done now, during the incident. This is followed by the need to access documented procedures on the follow-up activities. The final section on the procedures used for IR readiness and the steps needed to maintain the plan are included in the final section. That section of the IR plan is used only when an incident response is not underway. Each of these is discussed in detail in the following sections.

For each incident plan, the IRP team will also begin to add other information as identified in the adjoining Example box. This information (to be discussed in detail later in this chapter) includes the trigger, the notification method, and response time. The notification method describes the manner in which the team receives its notification that an incident has occurred and the plan is to be executed. This could be by phone, pager, e-mail, loudspeaker, or word of mouth. The response time represents the time that the team should optimally respond by; it

Incident Response Planning 139

typically ranges from 30 minutes to 48 hours, depending on the incident. Malware attacks, for example, would require a very quick response (30 minutes to 1 hour), whereas e-mail-spoofing attacks may be deferred for 24 to 48 hours, depending on the actions of the attacker.

Planning for the Response During the Incident Beginning with the end in mind is useful in most planning activities. However, in the specific case of IR, you begin with the middle in mind, the actual incident response. The most impor- tant phase of the IR plan is the reaction to the incident, depicted here as “during the incident.” When an event escalates to an incident, the team needs quick and easy access to the specific procedures necessary to identify, contain, and terminate the incident. Although

Attack type:

Trigger:

Reaction force and lead:

Notification method:

Response time:

Actions to be taken during this response:

….

Incident is ended and actions cease when:

Actions to be taken after incident response is ended:

…

Incident follow-up is ended and actions after the incident are complete when:

Preparation actions to be integrated into IR plans before IR plan is needed:

….

Information for attack success end case

140 Chapter 4 Incident Response: Planning

the specifics of these actions are covered in other chapters, an overview here can assist in understanding the mechanics of developing this phase of the IR plan.

Triggering the IR Plan Each viable attack scenario end case is examined in turn by the IR team. As indicated earlier, representatives from the CSIRT assist as part of this team, once the CSIRT has been formed. The IR team discusses the end cases and begins to under- stand the actions that must be taken to react to the incident. The discussion begins with the trigger, the circumstances that cause the IR team to be activated and the IR plan to be initi- ated. This trigger could be any number of situations or circumstances, including the following:

● A phone call from a user to the help desk about unusual computer or network behavior

● Notification from a systems administrator about unusual server or network behavior ● Notification from an intrusion detection device ● Review of system log files indicating an unusual pattern of entries ● Loss of system connectivity ● Device malfunctions

There are many indicators that an intrusion may be occurring. Once an indicator has been reported, the IR team leader or the IR duty officer makes the determination that the IR plan must be activated. The IR duty officer is a CSIRT team member, other than the team leader, who is currently performing the responsibilities of the team leader in scanning the organiza- tion’s information infrastructure for signs of an incident. Once this individual detects a poten- tial incident, he or she notifies the necessary team members and moves forward with the IR plan.

The Reaction Force For each type of incident, a specific set of skills is needed. There- fore, each attack scenario end case requires the IRP team to determine what individuals are needed to respond to each particular end case. For example, different skills are probably needed to respond to a physical security threat as compared to a DoS attack or an internal virus infestation. Each unique combination of skills can then be added to the IR plan section dedicated to this particular attack. In addition, the IR plan should specify who the team leader is for that particular incident. Should the incident begin to escalate, the CSIRT team leader continues to add resources and skill sets as necessary to continue to attempt to con- tain and terminate the incident. In addition to specifying the leader, the IR plan should also specify the scribe (also known as the archivist or historian) for the incident. This individual is responsible for developing and maintaining a log of events for use in reviewing actions during the after-action review, which is described later. The resulting team represents the CSIRT reaction force for that particular incident.

Actions Taken “During the Incident” The next planning component is the deter- mination of what must be done to react to this particular incident. In the event of a malware infestation, for example, the first action is to verify the presence of the virus by examining the antivirus software, system logs, and other monitoring systems. The help desk also queries users to determine if others have reported strange or unusual system or network behavior. Once it is determined that there is in fact a malware (virus or worm) infestation,

Incident Response Planning 141

the next step is performed: determining the extent of exposure. Is the infestation limited to one workstation, or has it already spread?

Once the extent is determined, the team begins to attempt to quarantine the infestation—in this example, by first disconnecting infected systems from the network, then by looking for evidence of continued spread, in case the malware has already jumped quarantine. Should iso- lating infected machines not contain the spread, then additional measures may be necessary, such as isolating network segments, terminating server sessions, disconnecting the Internet connection, and even shutting down the network servers. Once the infection is contained, the team continues to look for “flare-ups,” which are small pockets of infestation that arise or activate once the primarily infected systems have been isolated. Only after all infected machines or systems have been isolated can the team begin the next phase: decontamination.

In the last phase of “actions during” this example incident, the team begins disinfecting systems by running anti-malware software, searching for spyware, and so on. Should anti-malware software be functional and up to date, the presence of new malware should be documented. Once all signs of contamination are eliminated, the “actions during” phase is complete.

Planning for “After the Incident” Once the incident has been contained, the “actions after” phase begins. During this phase, lost or damaged data is restored, systems are scrubbed of infection, and essentially everything is restored to its previous state. Thus, the IR plan must describe the stages necessary to recover from the most likely events of the incident. It should also detail other events needed for the “actions after” phase, such as the protection from follow-on incidents, forensics anal- ysis, and the after-action review.

Follow-on incidents are highly probable when infected machines are brought back online or when other infected computers, which may have been offline at the time of the attack, are brought back up. Such incidents are also likely in the event of a hacker attack, when the attacker retreats to a chat room and describes in specific detail, to associates, the method and results of this latest conquest. Therefore, the identification of potential follow-on attacks should be of great concern. By identifying and resolving the avenues of attacks from the for- ensics analysis, the organization can prevent these incidents from reoccurring.

Forensic analysis is the process of systematically examining information assets for evidentiary material that can provide insight into how the incident transpired. Information on which machine was infected first or how a particular attacker gained access to the network provides insight about unknown vulnerabilities or exploits. Care must be taken to use an individual trained in forensic analysis, as the information found during the analysis may be potential evidence in civil or criminal proceedings. Forensic analysis is covered in additional detail later in this textbook.

Before returning to routine duties, the IR team must conduct an after-action review (AAR). An AAR is a detailed examination of the events that occurred, from first detection to final recovery. All key players review their notes and verify that the IR documentation is accurate and precise. All team members review their actions during the incident, and identify areas where the IR plan worked, didn’t work, or should be improved. This allows the team to update the IR plan. The AAR can serve as a training case for future staff. It also brings to a close the actions of the IR team.

142 Chapter 4 Incident Response: Planning

The Second Armored Cavalry Regiment (ACR) is the oldest cavalry regiment on continuous active duty, starting in 1836. It served as the vanguard of the 1st Armored Division in the sweep of Iraqi forces during the 1991 Gulf War. Before the Gulf War, it was responsible for the patrol and protection of the West German/East German/ Czechoslovakian border. The regiment9, which consisted of three cavalry squadrons, a tank company, a howitzer battalion, and an air-cavalry squadron, carried out this mis- sion by placing one troop (a company-sized element) from each of the three front-line squadrons (a battalion-sized element) in various border patrol camps along the border for a 30–45-day rotation. Each of these border troops conducted constant surveillance of the border, ready to give early warning of potential border violations, political inci- dents, and even hostile invasions. Within the border camp, the border troop consisted of either a cavalry troop with 12 M3A1 Bradley Fighting Vehicles (BFVs) and 9 M1A1 Abrams Main Battle Tanks, or a tank company with 14 M1A1s. Occasionally, units from outside the regiment took a shift on the border, but it was ultimately the 2nd ACR’s responsibility to guard this stretch of territory.

The unit occupying the border camp was required to organize a series of elements capable of deploying in reaction to an incident on the border—be it a border crossing by a political defector or an invasion by a military force. The smallest such element was the “reaction force” made up of 8 to 10 soldiers manning two armored vehicles (M3A1s or M1A1s). It was required to be ready to deploy to an area outside the base within 15 minutes to combat a foe or report on the incident. Whereas the routine patrols were conducted in HMMWVs (Hum-Vees), the reaction elements had to deploy in battle vehicles. The next larger element was the “reaction platoon,” the remainder of the reaction force’s platoon (two additional Abrams, or four additional BFVs, and 8 to 20 additional troops), which had to be ready to deploy within 30 minutes. Had the incident warranted it, the entire troop had to be prepared to depart the base within 1 hour. This deployment was rehearsed daily by the reaction force, weekly by the reaction platoon, and at least twice during border camp by the entire troop.

What does this scenario illustrate? An incident is an incident. The employees in an organization responding to a security incident are of course not expected to deploy fully armed to engage in combat against a physical threat. The preparation and plan- ning required to respond to an information security incident is not entirely different from that required to respond to a military incident, however. The same careful atten- tion to detail must be paid, each potential threat scenario must be examined, and a number of responses commensurate with the level of the incident must be developed.

Reaction!Reaction!

Incident Response Planning 143

Planning for “Before the Incident” Planning for “before the incident” or “before actions” calls on the planners to implement good IT and information security practices. However, specific incidents may have unique characteristics requiring special prevention methods. “Before actions” include preventive measures to manage the risks associated with a particular attack as well as the preparations of the IR team. As described in the “Reaction!” sidebar, it is only through routine rehearsal that a team can maintain a state of readiness to respond to attacks. This process includes training the CSIRT, testing the IR plan, selecting and maintaining the tools used by the CSIRT, and training users of the systems and procedures controlled by the organization. Risk management was covered in Chapter 1.

Training the CSIRT One of the primary responsibilities of the IRP team is to ensure that the CSIRT is prepared to respond to each incident it may face. This requires a large number of ongoing training and rehearsal activities.

Training IR personnel can be conducted in a number of ways. There are several national training programs that focus on IR tools and techniques. The SANS Institute offers a number of national conferences specifically designed to train the information security professional (see www.sans.org). SANS even has a set of conferences—SANSFIRE (Forensics and Incident Response Education)—that is specifically focused on IR. Unlike other conferences, SANSFIRE is not designed for the hacker first and everyone else second. Vendors such as Microsoft, Cisco, and Sun also provide IR training to IT professionals. For government employees, the Department of Homeland Security (DHS) and the US CERT cohost a conference for IR train- ing (www.fbcinc.com/gfirst).

In addition to formal external training, an organization can set up its own training program in which senior, more experienced staff members share their knowledge with newer, less experi- enced employees. An ongoing training program should include this mentoring-type training to prevent specific organizational knowledge from leaving when certain employees depart.

Other training methods include a professional reading program, which is a self-created list of trustworthy information sources to read on a regular basis. There are a host of high-quality information security journals and magazines that have articles and columns on IR topics, including:

● SANS Information Security Reading Room (www.sans.org/rr)—Individuals seeking advanced SANS certification are required to write a practicum paper. Several of these papers include CP topics.

● Computer Security Officer (www.csoonline.com) ● SC Magazine (www.scmagazine.com) ● Information Security Magazine (http://informationsecurity.techtarget.com)

Unfortunately (at the time of this writing), there are no dedicated IR journals or magazines. However, many of the DR journals identified in later chapters have occasional articles on IR. There are a number of online resources for IR, including:

● Forum of Incident Response and Security Teams (FIRST): www.first.org ● U.S. Computer Emergency Readiness Team (US CERT): www.us-cert.gov ● CERT Coordination Center (CERT CC) at Carnegie Mellon University: www.cert.org

144 Chapter 4 Incident Response: Planning

● NIST Computer Security Resource Center (CSRC): http://csrc.nist.gov ● Honeypots.net: www.honeypots.net

IR Plan Testing A key part of training the CSIRT is testing the IR plan. An untested plan is no plan at all. Very few plans are executable as initially written; they must be tested to identify vulnerabilities, faults, and inefficient processes. Once problems are identified during the testing process, improvements can be made, and the resulting plan can be relied on in times of need. Some strategies that can be used to test contingency plans are:10

● Desk check ● Structured walk-through ● Simulation ● Parallel testing ● Full interruption ● War gaming

Desk Check The simplest kind of validation involves distributing copies of the IR plan to each individual that will be assigned a role during an actual incident. Each individual performs a desk check by reviewing the plan and creating a list of correct and incorrect components. Though not a true test, this is a good way to review the perceived feasibility and effectiveness of the plan.

Structured Walk-Through In a structured walk-through, all involved individuals walk through the steps they would take during an actual event. This can consist of an on-site walk-through, in which everyone discusses their actions at each particular location and junc- ture, or it may be more of a “chalk talk,” in which all involved individuals sit around a con- ference table and discuss, in turn, their responsibilities as the incident would unfold.

Simulation In a simulation, each potential participant individually (rather than in a confer- ence) simulates the performance of each task. The simulation stops short of the actual physi- cal tasks required, such as installing the backup or disconnecting a communications circuit. The major difference between a walk-through and a simulation is that, in a walk-through, individuals work on their own tasks and are responsible for identifying the faults in their own procedures.

Parallel Testing In a parallel test, individuals act as if an actual incident has occurred, per- forming their required tasks and executing the necessary procedures without interfering with the normal operations of the business. Great care must be taken to ensure that the proce- dures performed do not halt the operations of the business functions, creating an actual incident.

Full Interruption In full-interruption testing, the individuals follow each and every proce- dure, including the interruption of service, restoration of data from backups, and notification of appropriate individuals. In organizations that cannot afford to disrupt or simulate the

Incident Response Planning 145

disruption of business functions, this is often performed after normal business hours. Although full-interruption testing is the most rigorous, it is unfortunately too risky for most businesses.

War Gaming A favorite pastime of information security professionals is war gaming, which is a simulation of attack and defense activities using realistic networks and informa- tion systems, with the exercise of IR plans being an important element. This valid, effective training technique is so popular that there are national competitions at conferences like Black Hat (http://blackhat.com) and DEFCON (www.defcon.org).11 War gaming competition at the collegiate level includes one held at the University of California Santa Barbara (ictf.cs.ucsb.edu) as well as the National Collegiate Cyber Defense Competition (www.nationalccdc.org). There are a number of methods that the IRP team can use in training the CSIRT as well as testing the IR plan. These are only valid if the CSIRT team acts as defenders, using their own equipment or a duplicate environment, and follows the IR plan in the performance of the training. There is little to be gained from simply “going at it.”

Common war-gaming variations include:

● Capture the flag—In this variation, a “flag” (token file) is placed on each team’s system. The teams are given a predetermined amount of time to protect the systems, short of encrypting the flag, and then both defend their flag and attempt to capture the opponent team’s or teams’ flag(s). This can be executed on a one-on-one basis or in a larger scope, with multiple teams in a free-for-all.

● King of the hill—In this variation, similar to “capture the flag,” one team is designated as king of the hill (KOTH) and has a flag planted in its systems. One or more other teams work independently to breach the KOTH security and obtain the file. This method may be better suited for CSIRT training and testing, as it allows the KOTH team to focus exclusively on defensive tactics and IR plan implementation rather than splitting the team between offensive and defensive operations.

● Computer simulations—In this variation, individual users or teams of users work to defend their systems and networks from simulated attacks. Although there are not many of these types of computer simulations currently available, some organizations develop their own as a training technique, customizing them to their own systems and configurations.

● Defend the flag—In this combination of KOTH and computer simulations, a number of systems are set up to continually attack or simulate attacks on the target system. The defensive team must react to an escalating level of attacks to successfully defend its systems. The software to create the attacking systems is easily found by searching the Web, and reputable companies such as Cisco use these tools in training their students how to properly configure firewalls, IDSs, and routers. The CCDC events described in the following Example Box are one example of Defend the Flag competitions.

● Online programming-level war games—For the technically advanced programmers, there are online information security education and training war games like those at www.hackthissite.org. At this site, users can go on different “missions” that are designed to help improve skill sets in various areas, like client-side attacks, application attacks, and Web site attacks, to name a few.

146 Chapter 4 Incident Response: Planning

Even the CIA and the U.S. military use war games to train and test their troops in information security and information warfare tactics.12 Unfortunately, hackers also have their own war games (http://roothack.org), which allow them to practice prior to conducting their attacks.

At a minimum, organizations should conduct a periodic walk-through (or chalk talks) of each of the CP component plans. A failure to update each of these plans as the business and its information resources change can erode the team’s ability to respond to an incident, or possibly cause greater damage than the incident itself.

Note: These testing methods will be referred to in other sections, as they can be applied to all CP training and testing efforts. If this sounds like a military training effort, note that in his book Designation Gold, author Richard Marcinko, a former Navy SEAL, recommends the following:13

In an effort to help facilitate the development of a regular, national-level cyber- security exercise, the Center for Infrastructure Assurance and Security at the Univer- sity of Texas at San Antonio hosted the first Collegiate Cyber Defense Competition (CCDC) for the Southwestern region in May 2005. In June 2005, members of the Ken- nesaw State University Center for Information Security Education attended a presen- tation by UTSA faculty members and recognized the value of the program. They immediately volunteered to create a similar event at KSU in 2006, to provide a regional competition to recognize the best team in the Southeast, and to work to sponsor that team to the national competition hosted by UTSA. KSU has hosted the Southeast Collegiate Cyber Defense Competition (SECCDC) every year since.

Though similar to other computer security competitions in many aspects, the SECCDC, as part of the CCDC, is unique in that it focuses on the operational aspect of managing and protecting an existing network infrastructure. Unlike “capture- the-flag” exercises, which incorporate both offensive and defensive actions on the part of the teams, this competition is exclusively a real-world defensive competition. Students design, configure, and protect a network over the course of the competition and focus on the task of assuming administrative and protective duties for an exist- ing “commercial” network. Teams are scored based on their ability to (1) detect and respond to outside threats (from a professional penetration-testing “red team”), (2) maintain the availability of existing services, such as mail servers and Web servers, (3) respond to business requests, such as those for the addition or removal of additional services, and (4) balance security needs against business needs.

There is a regional (and, in many cases, state) competition for the entire United States. For more information, visit www.nationalccdc.org.

The CCDC

Incident Response Planning 147

The more you sweat in training, the less you bleed in combat.

Training and preparation hurts.

Lead from the front, not the rear.

You don’t have to like it, just do it.

Keep it simple.

Never assume.

You are paid for your results, not your methods.

Tools for the CSIRT Table 4-3 shows the tools recommended by NIST for use by incident handlers.

Incident Handler Communications and Facilities

Contact information for team members and others within and outside the organization (primary and backup contacts), such as law enforcement and other incident response teams; information may include phone numbers, e-mail addresses, public encryption keys (in accordance with the encryption software described below), and instructions for verifying the contact’s identity

On-call information for other teams within the organization, including escalation information

Incident reporting mechanisms, such as phone numbers, e-mail addresses, online forms, and secure instant messaging systems with which users can report suspected incidents; at least one mechanism should permit people to report incidents anonymously

Issue tracking system for tracking incident information, status, etc.

Smartphones to be carried by team members for off-hour support, on-site communication

Encryption software to be used for communication among team members, within the organization and with external parties; software must use a FIPS-validated encryption algorithm

War room for central communication and coordination; if a permanent war room is not necessary, the team should create a procedure for procuring a temporary war room when needed

Secure storage facility for securing evidence and other sensitive materials

Incident Analysis Hardware and Software

Digital forensic workstations and/or backup devices to create disk images, preserve log files, and save other relevant incident data

Laptops for activities such as analyzing data, sniffing packets, and writing reports

Spare workstations, servers, and networking equipment, or the virtualized equivalents, which may be used for many purposes, such as restoring backups and trying out malware

Blank removable media

Portable printer to print copies of log files and other evidence from non-networked systems

Packet sniffers and protocol analyzers to capture and analyze network traffic

Table 4-3 Tools and resources for incident handlers (continues) Source: NIST SP 800-6114

148 Chapter 4 Incident Response: Planning

Training the Users Training the end user to assist in the IR process is primarily the responsibility of those individuals who provide security education training and awareness (SETA) for the organization. As part of the ongoing employee training program, SETA trai- ners should instruct end users on the following tasks:

● What is expected of them—What is expected of the members of the organization’s security team

● How to recognize an attack—Each user is instructed on what to look for in an attack, broken down by category, including the key indicators.

● How to report a suspected incident, and whom to report it to—By e-mail or phone to the help desk, information security hotline, [email protected], or other designated mechanism

● How to mitigate the damage of attacks on the desktop—By disconnecting the system from the network if they suspect an attack is in progress and by reporting incidents promptly

● Good information security practices—Tasks that prevent attacks on the desktop, such as:

� Keeping your antivirus/anti-malware software up to date � Using spyware detection software � Working with systems administrators to keep operating system and applications

up to date with patches and updates

� Not opening suspect e-mail attachments

Digital forensic software to analyze disk images

Removable media with trusted versions of programs, to be used to gather evidence from systems

Evidence gathering accessories, including hard-bound notebooks, digital cameras, audio recorders, chain of custody forms, evidence storage bags and tags, and evidence tape, to preserve evidence for possible legal actions

Incident Analysis Resources

Port lists, including commonly used ports and Trojan horse ports

Documentation for OSs, applications, protocols, and intrusion detection and antivirus signatures

Network diagrams and lists of critical assets, such as database servers

Current baselines of expected network, system, and application activity

Cryptographic hashes of critical files to speed incident analysis, verification, and eradication

Incident Mitigation Software

Access to images of clean OS and application installations for restoration and recovery purposes

Table 4-3 Tools and resources for incident handlers (continued) Source: NIST SP 800-6114

Incident Response Planning 149

� Avoiding social engineering attacks by not providing critical information over the phone or through e-mail to untrusted sources

� Not downloading and installing unauthorized software or software from untrusted sources

� Protecting passwords and classified information Although the specifics of developing a training program are beyond the scope of this text, you will want to develop training for general users, managerial users, and technical users.

Training for General Users One method of ensuring that IR is understood by general users is to provide training on the plan. This allows users to ask questions and receive spe- cific guidance, and it allows the organization to emphasize key points. These general users also require training on the technical details of how to do their jobs securely, including good security practices, password management, specialized access controls, and violation reporting.

A convenient time to conduct this type of training is during employee orientation. During this critical time, employees are educated on a wide variety of organizational policies and proce- dures and on the expectations the organization has for its employees. Because employees haven’t yet established preconceived notions or methods of behavior, they are more likely to be receptive to this instruction. This is balanced against the fact that they are not yet familiar with the systems or their jobs; therefore, any particular issues that they might have questions about won’t have arisen.

Training for Managerial Users Management may have the same training requirements as the general user; however, managers expect a more personal form of training, with smaller groups and more interaction and discussion. In fact, managers often resist organized training of any kind. This is another area in which a champion can exert influence; support at the executive level can convince managers to attend training events, which in turn reinforces the entire training program.

Training for Technical Users Technical training for IT staff, security staff, and techni- cally competent general users is more detailed than general user or managerial training, and it may therefore require the use of consultants or outside training organizations, as described earlier.

Training Techniques and Delivery Methods Good training techniques are as essential to successful training as is a thorough knowledge of the subject area. As explained by Charles Trepper in an article titled “Training Developers More Efficiently”:

Using the wrong method can actually hinder the transfer of knowledge and lead to unnecessary expense and frustrated, poorly trained employees. Good training programs, regardless of delivery method, take advantage of the latest learning technologies and best practices. Recent developments include less use of central- ized public courses and more on-site training. Other best practices include the increased use of short, task-oriented modules and training sessions, available dur- ing the normal work week, that are immediate and consistent. Newer concepts in

150 Chapter 4 Incident Response: Planning

training also provide students with the training they need when they need it—a practice often called just-in-time training.15

Source: InformationWeek.com

Selection of the training delivery method is not always based on the best outcome for the trainee. Often, other factors come first, like budget, time frame, and the needs of the organiza- tion. The most common delivery methods are shown in Table 4-4.

Method Advantages Disadvantages

One-on-one A dedicated trainer works with each trainee on the areas specified.

● Informal ● Personal ● Customized to the needs of

the trainee ● Can be scheduled to fit the

needs of the trainee

Resource intensive, to the point of being inefficient

Formal class A single trainer works with multiple trainees in a formal setting.

● Formal training plan, efficient ● Trainees can learn from each

other. ● Interaction with trainer is

possible. ● Usually considered cost

effective

● Relatively inflexible ● May not be sufficiently

responsive to the needs of

all trainees ● Difficult to schedule,

especially if more than one

session is needed

Computer-based training (CBT) Prepackaged software provides training at the trainee’s workstation.

● Flexible, no special scheduling

requirements ● Self-paced, can go as fast or

as slow as trainee needs ● Can be very cost effective

● Can be very expensive ● Content not always

customized to the needs of

the organization

Distance learning and Web seminars Trainees receive a seminar presentation at their computers. Some models allow teleconferencing for voice feedback; others have text questions and feedback.

● Can be live, or can be archived

and viewed at trainee’s

convenience ● Can be low or no cost

● If archived, can be very

inflexible, with no

mechanism for trainee

feedback ● If live, can be difficult to

schedule

User support group When support is available from a community of users, it is commonly facilitated by a particular vendor as a mechanism to augment the support for products or software.

● Allows users to learn from

each other ● Usually conducted in an

informal social setting

● Does not use a formal

training model ● Centered around a specific

topic or product

Incident Response Planning 151

Assembling and Maintaining the Final IR Plan Draft plans can be used for the preliminary training of staff and for evaluating the effective- ness of the plan. Any errors or difficulties discovered during training or testing can then be remedied as the draft plans mature. Once the desired level of plan maturity is achieved and the drafts have been suitably reviewed and tested, the final assembly can commence.

Note that the testing process does not stop once the final plan is created. As indicated earlier, each scenario of the IR plan should be tested at least semiannually by performing at least a structured walk-through test and a more realistic type of test, when possible. Obviously, if the IR plan was executed in response to an actual incident, then those sections that have seen actual use may not require the same degree of periodic retesting, assuming of course that no changes were made to the plan in the after-action review. Any plans that are modified should be scheduled for additional testing at the earliest opportunity.

Once all the individual components of the IR plan have been drafted and tested, the final IR plan document can be created. Every organization has its own preferences for the format and content of the IR plan. The most important thing is that the IR plan is developed, tested, and placed in an easy-to-access location. The following list of recommended practices describes the design and implementation of the physical IR plan to be deployed in such a manner as to make it easy to locate and use in an emergency.

1. Select a uniquely colored binder. Red or yellow is recommended, as organizations are inundated with white binders.

2. On the spine of the binder, place red and yellow (or red and white) reflective tape. Why? Some incidents involve a loss of power. In a low-light-level environment, by emer- gency exit light or flashlight, this binder will shine like a lighthouse, making it easy to identify and use.

Method Advantages Disadvantages

On-the-job training Trainees learn the specifics of their jobs while working, using the software, hardware, and procedures they will continue to use.

● Very applicable to the task

at hand ● Inexpensive

● A sink-or-swim approach in

which the trainee usually

experiences no formal

training program ● Can result in substandard

work performance until

trainee gets up to speed

Self-study (noncomputerized) Trainees study materials on their own, usually when not actively performing their jobs.

● Lowest cost to the organization ● Places materials in hands of

the trainee ● Trainees able to select the

material they need to focus

on the most ● Self-paced

● Shifts responsibility for

training onto the trainee,

with little formal support

152 Chapter 4 Incident Response: Planning

3. Under the front slipcover, place a classified document cover sheet. This identifies the book as an element that has been evaluated as nonpublic by the organization’s data classification scheme. If the document were to fall into the wrong hands, knowing how an organization responds to a particular attack could reveal procedural vulnerabilities.

4. Place an index on the first inside page, preferably one with a color-coded bar corre- sponding to a set of tabs.

5. For each category of attack, place the corresponding IR plan documents under a common tab and label the index.

6. Organize the contents so that the first page contains the “during attack” actions, fol- lowed by the “after attack” actions and, finally, the “before attack” actions. In an emer- gency, you want to be able to see the information most important to you first.

7. Attach copies of any relevant documents in the back, under a separate tab—e.g., copies of service agreements for the ISP, telephone, water, power, gas, and so on.

8. Add additional documents as needed.

9. Store in a secure but easily reachable location.

Figure 4-3 presents an example of pages from an IR plan.

1. Don’t put suspicious diskettes in system. Check your system before booting for disketters. 2. Don’t download free games or utilities on your system without authorization from the technology Services department. 3. Don’t open attachments in unsolicited e-mail. Make sure all attachments are from the sending party by confirming the origin in a seperate e-mail. 2. Don’t forward messages that ask you to warn others of a virus or threat.

1. Ensure virus protection software is installed,, properly configured, and updated 2. Automate whenever possible. Provide awareness and training to all users on proper uses of the e-mail and antivirus software.

Before an Attack Users

Technology Services

1. Scan your computer thoroughly for any additional viruses. 2. Review e-mail (TITLES ONLY, DO NOT REOPEN attachments) for suspicious viruses. 3. Write down everything you were doing before you detected the virus. 4. Verify that your antivirus software and definitions are up-to-date.

1. Conduct an incident recovery investigation. 2. Interview all users detecting the virus. 3. verify that all systems antivirus so aware an defenitions are up-to-date. 4. Reconnect quarantined users to the network. 5. Brief all infected users on proper antivirus procedures. 6. File the incident recovery investigation report. Notify all users that this particular strain. of virus has been detected, and recommend antivirus software and definitions procedure.

After an Attack

Technology Services

Users

1. If your antivirus software detects an attack, it will delete the virus or quarantine the file that carries it. Record any messages that your antivirus software displays and notify Technology Services immediately. 2. If your computer begins behaving unusually or you determine that you have contracted a virus through other means, turn your computer off immediately, by pulling the plug. Notify Technology Services immediately.

1. If users begin reporting virus attacks, record the information provided by the users. 2. Temporarily disconnect those users from the network at the switch. 3. Begin scanning all active systems for that strain of virus. 4. Deploy a response team to inspect the users’ system.

During an Attack

Technology Services

Users

Figure 4-3 Incident response plan

Assembling and Maintaining the Final IR Plan 153

Chapter Summary ● Contingency planning addresses everything done by an organization to prepare for

the unexpected and is made up of several phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

● When the contingency planning management committee (CPMT) completes each component of the business impact analysis (BIA), it identifies how information flows and how responsibility is shared among subordinate committees. This may include the incident response (IR) committee, the disaster recovery (DR) committee, and the business continuity (BC) committee. In the case of incident planning, the group fol- lows these general stages: form the IR planning committee, develop the IR policy, integrate the BIA, identify preventive controls, organize the CSIRT, create IR strate- gies and procedures, develop the IR plan, ensure plan testing, training, and exercises, and ensure plan maintenance.

● Organizing the IR planning process begins with staffing the IRP team and identifying stakeholders, such as: general management, IT management, InfoSec management, and organizational departments—for example, Legal, Human Resources, and Public Relations. The Incident Response Planning (IRP) team works together to build the IR policy, plan, and procedures that the CSIRT will follow during the IR actions themselves.

● One of the first deliverables prepared by the IRP team is the IR policy. The IR policy is similar in structure to other policies used by the organization. Specifically, it will include the roles and responsibilities for the CSIRT and others who will be mobilized in the activation of the plan. IR policy, like all well-written policies, must gain the full support of top management and be clearly understood by all affected parties.

● The CSIRT (also referred to as the Security IRT or the Computer IRT) is the team of people and their supporting policies, procedures, technologies, and data necessary to prevent, detect, react, and recover from an incident that could potentially damage the organization’s information.

● An incident response plan (IR plan) is a detailed set of processes and procedures that anticipate, detect, and mitigate the effects of an unexpected event that might compromise information resources and assets. The IR plan is usually activated when an incident causes minimal damage—according to criteria set in advance by the organization—with little or no disruption to business operations. When a threat turns into a valid attack, it is classified as an information security incident, but only if it is directed against information assets owned or operated by the organization, has a realistic chance of success, and threatens the confidentiality, integrity, or availability of information resources and assets.

● The incident plan usually includes three sets of incident-handling procedures to document the intended actions over time. These are the actions during the incident, after the incident, and before the incident.

● For each type of incident, a specific set of skills is needed. Therefore, each attack scenario end case requires the IRP team to determine what individuals are needed to respond to each particular end case.

154 Chapter 4 Incident Response: Planning

● One of the primary responsibilities of the IRP team is to ensure that the CSIRT is prepared to respond to each incident it may face. This requires a large number of ongoing training and rehearsal activities.

● A key part of training the CSIRT is testing the IR plan. Strategies that can be used to test contingency plans include: desk check, structured walk-through, simulation, parallel testing, full interruption, and war gaming.

● Once all the individual components of the IR plan have been drafted and tested, the final IR plan document can be created. A number of recommended practices describes the design and implementation of the physical IR plan to be deployed in such a manner as to make it easy to locate and use in an emergency.

Review Questions 1. What are the phases of the overall IR development process?

2. What are the general stages followed by the IRP team?

3. What are two external sources for how IRP is performed that were mentioned in this chapter?

4. What does the organizational phase of the IRP process begin with?

5. Who are the typical stakeholders of the IR process?

6. Which individuals should be assembled to form the IRP team?

7. What should be among the first deliverables created by the IR planning committee?

8. What is the primary function of the IR Policy?

9. In order to be effective, what group is it essential to gain full support from?

10. What are the essential attributes of an IR policy document?

11. What is an incident response plan (IR plan)?

12. What characteristics must be present if an adverse event is to be considered an incident?

13. What are the three sets of time-based procedures that are often part of the IR planning process?

14. What is meant by the “trigger” for an IR-related plan?

15. What is a “reaction force” in terms of IR planning?

16. What is an after-action review (AAR)?

17. What are the ways training can be undertaken for the CSIRT?

18. Briefly describe the strategies used to test contingency plans?

19. Briefly describe the possible training delivery methods?

20. When should the “final” version of the IR plan be assembled?

Review Questions 155

Real-World Exercises 1. Using a Web browser, identify at least five sources you would want to use

when training a CSIRT.

2. Using a Web browser, visit www.mitre.org. What information is provided there, and how would it be useful?

3. Using a Web browser, visit www.securityfocus.com. What is Bugtraq, and how would it be useful? What additional information is provided under the Vulnerabilities tab?

4. Using a Web browser, visit www.cert.org. What information is provided there, and how would it be useful? What additional information is provided at www.cert.org/csirts/?

5. Using a Web browser, search for other methods employed by industry or government to share information on possible incidents.

Hands-On Projects

In this project, you will use Security Onion to examine a simulated attack on a network. This exercise will help you understand the basics of how to deter- mine if an attack is taking place, as well as how to get information about the attack so that appropriate action can be taken. You will use the SQueRT tool in Security Onion to help you analyze data in a meaningful way as well as to examine packets in both individual and session contexts, giving you a deeper understanding of the overall scope of the attack.

1. Start the Security Onion virtual image and log in using the credentials you established in the initial setup.

2. To open a terminal session, double-click the Terminal icon.

3. Type pwd and press Enter. This will tell you what directory you are currently in. It should return “/home/username,” where username is what you used to log in.

4. If you are not in this directory, type cd /home/username and press Enter. Be sure to replace username with your username.

5. Type wget http://www.honeynet.org/files/attack-trace.pcap_.gz and press Enter. This will download the simulated attack traffic we will use for this project. There will be a brief delay while the file downloads. Your screen should look similar to the one shown in Figure 4-4.

6. Type gunzip attack-trace.pcap_.gz and press Enter.

7. Type exit and press Enter to close the terminal window.

8. Click the Applications button on the Desktop and select IDS Rules. Your screen should look similar to the one shown in Figure 4-5. Click Rule update.

156 Chapter 4 Incident Response: Planning

Source: Security Onion

Figure 4-4 Pcap file download

Source: Security Onion

Figure 4-5 Starting IDS rules update

Hands-On Projects 157

9. Enter your administrator password and press Enter. Your screen should look similar to the one shown in Figure 4-6, as Security Onion updates various IDS rulesets.

10. Open another terminal window by repeating Step 2.

11. Verify your location is /home/<your username>, as described earlier.

12. Before you replay the pcap file, you have to configure Snort to read the traffic. To do this, type sudo vim /etc/nsm/<hostname-interface>/snort.conf, replacing <hostname- interface> with your hostname and interface name. Your command should look similar to the one shown in Figure 4-7. Press Enter. If prompted, enter your administrator password.

13. Locate the line that contains the HOME_NET variable data. Add 192.168.0.0/8 to the list of IP addresses.

14. Save and exit the file by pressing Escape, then typing :wq. Before exiting, your screen should look similar to the one shown in Figure 4-8.

Source: Security Onion

Figure 4-6 IDS rules update process

158 Chapter 4 Incident Response: Planning

Source: Security Onion

Figure 4-8 Add network address

Source: Security Onion

Figure 4-7 Edit Snort config file

Hands-On Projects 159

15. Restart Snort by typing sudo nsm_sensor_ps-restart–only-snort-alert and pressing Enter.

16. Type sudo tcpreplay––loop=0––intf1=eth0 attack-trace.pcap_ and press Enter. This will replay the network traffic in the pcap file via the network interface card in Security Onion in a loop, so you can examine it.

17. Now that you have simulated malicious traffic being captured, let’s look at a dashboard to show what the incident looks like. Open a Web browser, type https://<IP address of Security Onion>/squert in the address window, and press Enter. Enter the SqueRT user- name and password you created during setup. Your screen should look similar to the one shown in Figure 4-9. Click submit.

18. After logging in, you are taken to the dashboard summary. We are interested in anything in the “Top Signatures” section that is malicious in nature, such as the “ET NETBIOS LSA exploit” or “GPL NETBIOS SMB-DS IPC$ unicode share access” entries. Take note of their IDs (2000032 and 2102466), as shown in Figure 4-10.

19. Click on the QUERY tab at the top of the page.

20. Select the SigID radio button on the “WHERE” line, enter the ID for the LSA exploit (2000032), and click the submit button. Your screen should look similar to the one shown in Figure 4-11.

Source: Security Onion

Figure 4-9 SqueRT login

160 Chapter 4 Incident Response: Planning

21. You are now presented with summary details on the signature of the attack. To learn more about the details, change the VIEW option from signature to event detail, and click the submit button. Your screen should look similar to the one shown in Figure 4-12.

22. Click the Timestamp entry, and a pop-up window will appear. This window will give you additional information on the attack, such as source and destination IP addresses and ports, packet header details, as well as the actual payload being sent. Figure 4-13 shows an example of what the additional output looks like. Note that clicking available links such as “SrcIP,” “DstIP,” and “Signature” will give you additional information about the source and target of the attack, as well as links to references to learn more about the specific attack.

23. Repeat Steps 18 through 21, this time using the ID for the SMB-DS IPC$ attack. Now that you have data on both of these attacks, you are ready to report attack details to the appropriate security personnel so that they can take action.

Source: Security Onion

Figure 4-11 LSA exploit summary

Source: Security Onion

Figure 4-10 Signature IDs

Hands-On Projects 161

24. In the terminal window where we started the pcap replay, press CTRL and c in the terminal simultaneously to stop the replay.

Source: Security Onion

Figure 4-13 Exploit payload details

Source: Security Onion

Figure 4-12 Exploit event details

162 Chapter 4 Incident Response: Planning

Endnotes 1. Cichonski, Paul, Tom Millar, Tim Grance, and Karen Scarfone. SP 800-61, Revision 2

(Draft), Computer Security Incident Handling Guide. National Institute of Standards and Technology, 2012.

2. Ibid.

3. West-Brown, Moira, Don Stikvoort, Klaus-Peter Kossakowski, Georgia Killcrece, Robin Ruefle, and Mark Zajicek. Handbook for Computer Security Incident Response Teams (CCSIRTs). 2003. Carnegie Mellon University, Software Engineering Institute. Accessed August 24, 2012 @ www.cert.org/archive/pdf/csirt-handbook.pdf.

4. “Creating a Computer Security Incident Response Team: A Process for Getting Started.” Carnegie Mellon University, Software Engineering Institute 2002. Accessed August 29, 2012 @ www.cert.org/csirts/Creating-A-CSIRT.html.

5. Cichonski, Paul, Tom Millar, Tim Grance, and Karen Scarfone. SP 800-61, Revision 2 (Draft), Computer Security Incident Handling Guide. National Institute of Standards and Technology, 2012.

6. West-Brown, Moira, Don Stikvoort, Klaus-Peter Kossakowski, Georgia Killcrece, Robin Ruefle, and Mark Zajicek. Handbook for Computer Security Incident Response Teams (CCSIRTs). 2003. Carnegie Mellon University, Software Engineering Institute. Accessed August 24, 2012 @ www.cert.org/archive/pdf/csirt-handbook.pdf.

Eventually, Paul made it into the office. Susan had called back to advise him that both the frequency of source address

shifting, ports being used, and volume of traffic from the DDoS attack had increased. She had decided, as on-site incident manager, to disconnect the company from the Internet.

She pulled the plug.

Discussion Questions 1. Why did the presence of a live attacker cause more concern than a scripted

attack? 2. What observations made by Susan led her to decide she had to disconnect the

company from the Internet? 3. What concrete milestones do you think will have to be met before the company

can reconnect to the Internet?

Closing Case Scenario: The Never-Ending Story

Endnotes 163

7. Hall, Mary. “Implementing a Computer Incident Response Team in a Smaller, Limited Resource Organizational Setting.” SANS (2003). Accessed August 29, 2012 @ www. sans.org/reading_room/whitepapers/incident/implementing-computer-incident-response- team-smaller-limited-resource-organizational-settin_1065.

8. “Creating a Computer Security Incident Response Team: A Process for Getting Started.” Carnegie Mellon University, Software Engineering Institute. 2002. Accessed August 29, 2012 @ www.cert.org/csirts/Creating-A-CSIRT.html.

9. A company or troop is a unit consisting of approximately 100 soldiers; a battalion or squadron consists of five or six companies or troops, totaling approximately 500–600 soldiers. A regiment or brigade consists of five or six battalions or squadrons, totaling approximately 2500–3000 soldiers.

10. Krutz, Ronald L., and Russell Dean Vines. The CISSP Prep Guide: Mastering the Ten Domains of Computer Security (New York: John Wiley and Sons, 2001), 288.

11. Although the authors emphatically denounce the actions of hackers and the criminal acts associated with hacking, these conferences typically are attended not only by hackers but also by information security professionals and representatives of law enforcement and the military. In keeping with our philosophy of “know your enemy,” one cannot pass up the opportunity to visit the enemy’s camp and observe them pre- paring for battle, learning their strategies and tactics firsthand.

12. Leyden, John. “CIA plays cyberwar game: All quiet on the silent horizon.” The Regis- ter (UK). Accessed August 29, 2012 @ http://www.theregister.co.uk/2005/05/27/cia_ cyberwar_game.

13. Marcinko, Richard, and John Weisman, Designation Gold (New York: Pocket Books, 1998), Preface.

14. Cichonski, Paul, Millar, Tom, Grance, Tim , and Scarfone, Karen. SP 800-61 Revision 2 (Draft), Computer Security Incident Handling Guide. Gaithersburg, MD: National Insti- tute of Standards and Technology, 2012.

15. Trepper, Charles. “Training Developers More Efficiently.” InformationWeek.com. Accessed August 24, 2012 @ www.informationweek.com/738/38addev.htm.

164 Chapter 4 Incident Response: Planning

chapter 5

Incident Response: Detection and Decision Making

A little fire is quickly trodden out; which, being suffered, rivers cannot quench. —William Shakespeare, King Henry VI. Part III. Act IV. Sc. 8

Upon completion of this material, you should be able to: ● Define incidents that pose a risk to the organization ● Discuss the elements necessary to detect incidents ● Explain the components of an intrusion detection and prevention system ● Describe the processes used in making decisions about incident detection and escalation

165

JJ had become quite bored with the discussion that was taking place in the confer- ence room and had let his mind wander as he stared out the window.

Paul frowned at him while repeating the question JJ had not heard. “Which sensor placement strategy do you think will get us the best network performance? For the IDPS—you know—the project we’re working on in this meeting?”

“Well,” said JJ, “truth be told, I wonder if the network approach is the right way to go. I think we should move toward a host-based model and limit the network intrusion system to a few critical subnetworks.”

Paul thought about it for a second. “Good point,” he said, then paused again before saying, “Funny, I thought you were daydreaming, but that’s a good point. I would like you to work up a new rough design based on a host-centric approach. We can review it tomorrow when we continue this meeting.”

“OK, Paul,” said JJ. Later that day, JJ came into Paul’s office. “I’ve got a couple of ideas that I’d like

your opinion on.” “Shoot,” said Paul. “I just attended a presentation where a CIO discussed ways to cut information

security spending,” JJ said. “He had some, well, radical ideas that paid off for him and his company.”

“I’m all ears,” Paul replied. The idea of going into this process with a cost-effective strategy had his undivided attention.

“Well, this CIO indicated that he had invested quite a large amount of money in proprietary security technologies—everything from firewalls to scanners to intrusion detectors. He then discovered that his maintenance and upgrade packages were costing him more than the equipment had.”

“I know that feeling,” said Paul. “Well, he discovered that there is a lot of open source software out there; you

know, the Linux and UNIX stuff,” JJ continued. “Uh, oh,” Paul said, stopping JJ in his tracks. “I see a potential problem there. We

don’t have any UNIX or Linux people on staff.” “That was his point,” JJ said, leaning over and tapping Paul’s desk for emphasis.

“With the money he could save from ending the service contracts, he was able to hire three good systems people and still save about half of his $1 million budget.”

“And if I don’t have a million-dollar budget?” “Then we just hire one or two guys, or hire one, and send one of our current

network admins off to training. I found several local places that offer open source software training. At the top of the list is Snort, right here in town.”

Opening Case Scenario: Oodles of Open Source Opportunities

166 Chapter 5 Incident Response: Detection and Decision Making

Introduction Among the earliest challenges that incident response process planners must face is to deter- mine how an organization classifies events as they occur. NIST defines an event as “any observable occurrence in a system or network” and defines an adverse event as “an event with negative consequences.”1 Note that some systems are computer based, whereas others are personnel based or organization based, so not all events are computer or network ori- ented. Some events are the product of routine system activities, whereas others are critical indicators of situations that need an urgent response. When an adverse event becomes a genu- ine threat to the ongoing operations of an organization, it is classified as an incident. Incident classification is, therefore, the process of evaluating the circumstances around organizational events, determining which adverse events are possible incidents (incident candidates) and whether a particular adverse event constitutes an actual incident. Designing the process used to make this judgment is the role of the incident response (IR) design team, but the everyday process of classifying an incident is the responsibility of the IR team.

There are a variety of sources, including reports and other documents from end users, intru- sion detection and prevention systems (IDPSs), virus management software, and systems administrators, for tracking and detecting incident candidates. Careful training in the report- ing of an incident candidate allows end users, the help desk staff, and all security personnel to relay vital information to the IR team. Once an actual incident is properly identified, the members of the IR team can effectively execute the corresponding procedures from the IR plan, including the notification of key response resources.

Although any threat category could instigate an incident, NIST SP800-61, R1 provides a five- category incident classification scheme for network-based incidents:

● Denial of service—An attack that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources

● Malicious code—A virus, worm, Trojan horse, or other code-based malicious entity that successfully infects a host

● Unauthorized access—When a person, without permission, gains logical or physical access to a network, system, application, data, or other IT resource

“I think you’re on to something,” Paul said, obviously intrigued by JJ’s suggestion. “Tell you what, I want you to write a business case by reviewing the current expendi- tures, add the projected additions from the meeting earlier today, and then balance those against the cost of a plan for an open source approach, including a new hire and training for one to two of our staff. Be brutally honest; we don’t want to chase vaporware on this one. We need solid, tested stuff and the skills to support it.”

“Can do, Paul.” JJ grinned. He liked it when Paul got behind his ideas. “And have it to me by the end of business tomorrow,” Paul added. The grin disappeared from JJ’s face.

Introduction 167

● Inappropriate usage—When a person violates acceptable use of any network or computer policies

● Multiple component—A single incident that encompasses two or more incidents2

Source: NIST

Organizations looking for a simple method of classifying their network-based incidents could use this list to prepare for and plan for incidents. Those that are not should develop their own lists to facilitate incident detection and classification.

Detecting Incidents A number of different events occurring in and around an organization signal the presence of an incident candidate. Unfortunately, these same events may occur when a network becomes overloaded, a computer or server encounters an error, or some normal operation of an infor- mation asset mimics the appearance of an identified incident candidate. An indication is a sign that an adverse event is underway and has a probability of becoming an incident, whereas a precursor is a sign that an activity now occurring may signal an incident that could occur in the future.3

To help make the detection of actual incidents more reliable, D. L. Pipkin has identified three broad categories of incident indicators: possible, probable, and definite.4 This categorization enables an organization to expedite the decision-making process of incident classification and ensure that the proper incident response plan (IRP) is activated as early as possible. The cate- gories are explored in the following sections.

Possible Indicators of an Incident Using the criteria established by Pipkin, there are four types of incident candidates considered to be possible actual incidents:

● Presence of unfamiliar files—Users might discover unfamiliar files in their home directories or on their office computers. Administrators might also find unexplained files that do not seem to be in a logical location or owned by an authorized user. (See the Technical Details box titled “Rootkits” for examples of unfamiliar files.)

● Presence or execution of unknown programs or processes—Users or administrators might detect unfamiliar programs running, or processes executing, on office machines or network servers. (For more information, see the Technical Details box titled “Processes and Services” later in this chapter.)

● Unusual consumption of computing resources—Consumption of memory or hard disk space might suddenly spike or fall. Many computer operating systems, including Windows XP, Windows Vista, Windows 7, and many Linux and UNIX variants, allow users and administrators to monitor CPU and memory consumption (see Figure 5-1). Most computers also have the ability to monitor hard drive space. In addition, servers maintain logs of file creation and storage.

● Unusual system crashes—Computer systems can crash. Older operating systems running newer programs are notorious for locking up or spontaneously rebooting whenever the operating system is unable to execute a requested process or service.

168 Chapter 5 Incident Response: Detection and Decision Making

You are probably familiar with systems error messages such as “Program Not Responding,” “General Protection Fault,” and the infamous Windows Blue Screen of Death. However, if a computer system seems to be crashing, hanging, rebooting, or freezing more frequently than usual, the cause could be an incident candidate.

Probable Indicators of an Incident Pipkin further identifies four types of incident candidates that are probable indicators of actual incidents:

● Activities at unexpected times—If traffic levels on an organization’s network exceed the measured baseline values, an incident candidate is probably present. If this activity surge occurs when few members of the organization are at work, the probability becomes much higher. Similarly, if systems are accessing drives, such as floppy and CD-ROM drives, when the end user is not using them, an incident may also be occurring.

● Presence of unexpected new accounts—Periodic review of user accounts can reveal an account (or accounts) that the administrator does not remember creating or that is not logged in the administrator’s journal. Even one unlogged new account is an incident candidate. An unlogged new account with root or other special privileges has an even higher probability of being an actual incident.

● Reported attacks—If users of the system report a suspected attack, there is a high probability that an attack has occurred, which constitutes an incident. The technical sophistication of the person making the report should be considered.

Source: Microsoft Windows

Figure 5-1 Windows Task Manager showing CPU and memory consumption

Detecting Incidents 169

The following information draws on the work of McAfee, a security company owned by Intel Corporation:

A rootkit is a software program or module of code that enables ongoing privi- leged access to a computer while actively hiding its presence from the system kernel as well as human administrators. This is accomplished by subverting standard operat- ing system functionality, common utility programs, or other applications. The term rootkit is a concatenation of root (the traditional name of the privileged account on UNIX operating systems) and the word kit (which refers to the software components that implement the tool). The term rootkit is often flagged by filtering software and e-mail scanners and has negative connotations as a form of malware.5

The Windows Sysinternals organization defines four categories of rootkits:

● Persistent rootkits—Those that become a part of the system bootstrap process and are loaded up every time the system boots. The program elements associ- ated with this type of rootkit must be stored somewhere in the infested system, either as a separate file, within another system file, or as a system configura- tion store like the Windows Registry.

● Memory-based rootkits—Those that do not install themselves to the infested computer’s file system, have no persistence, and are not reinstalled when the system is rebooted.

● User-mode rootkits—Those that insert themselves between the user and the operating system kernel, intercepting the calls to the application programming interface of the operating systems and then reinterpreting the results of all commands to display content chosen by the rootkit. For example, when the user requests a list of all running processes to see if the rootkit is running, the indication of the rootkit’s process will be deleted.

● Kernel-mode rootkits—Those that insert themselves within the operating system itself and are then able to intercept and manipulate all aspects of the kernel. This allows manipulation of communications to and from the kernel as well as between elements of the kernel. It also means that the rootkit can change the content of kernel memory structures, such as process tables and memory assignments. For example, the program files needed to reinfest the system at bootup are erased from the file system data structure and are then invisible to system users, systems administrators, and even the kernel itself6

To install a rootkit, attackers must first gain access by attacking through a port, exploiting a vulnerability, or tricking the user into installing the rootkit for them, usually through an e-mail attachment or Web site link. Once the attacker gains access, he or she installs or activates the rootkit and gains administrative privileges.

Technical Details: Rootkits

170 Chapter 5 Incident Response: Detection and Decision Making

● Notification from IDPS—If the organization has installed and correctly configured a host-based or network-based IDPS, then notification from the IDPS indicates that an incident might be in progress. However, IDPSs are seldom configured optimally and, even when they are, tend to issue many false positives or false alarms. The administrator must then determine whether the notification is real or if it is the result of a routine operation by a user or other administrator.

Unfortunately, these tools are freely available on the Web for all types of platforms. These tools—Alureon (a.k.a. TDSS), Mebroot, and Win32/Bubnix, to name a few of the Windows varieties—are also able to collect and store user login and password information; some even contain keystroke loggers. The mere presence of these tools indicates that either the system was compromised sometime in the past or the systems administrator is playing with fire. It may be possible for one attacker to piggyback on another attacker’s rootkit, so even using them on one’s own system is potentially dangerous.

How do you detect rootkits? There are utilities to find these attacker tools. Sysin- ternals has an older application named RootkitRevealer (http://technet.microsoft. com/en-us/sysinternals/bb897445) that also can detect hidden rootkits. As shown in Figure 5-2, the tool not only detects rootkits but also detects mismatches between the registry and the scan as well as other native Windows file differences between APIs, the registry, and the master file table. Thus, some degree of expertise is needed to ascertain whether a rootkit is present. The presence of files named hxdef100.exe, hxdef100.ini, or hxdefdrv.sys (among others) would be a strong indicator that the Hacker Defender Rootkit is present.

Newer versions of rootkit-detecting utilities are available—for example, Sophos Anti-Rootkit (www.sophos.com)—that provide free detection and removal of rootkits using simple graphical interfaces and work on most modern Windows operating sys- tems. With the increase in attacks that install rootkits, most modern antivirus/anti- malware utilities can detect rootkits as well.

Source: RootkitRevealer by Sysinternals.com

Figure 5-2 RootkitRevealer

Detecting Incidents 171

Definite Indicators Pipkin’s categories continue with a list of five types of incident candidates that are definite indicators of an actual incident. That is, they clearly and specifically signal that an incident is in progress or has occurred. In these cases, the corresponding IR plan must be activated immediately.

● Use of dormant accounts—Many network servers maintain default accounts, and there often exist accounts from former employees, employees on a leave of absence or sabbatical without remote access privileges, or dummy accounts set up to support system testing. If any of these accounts begins accessing system resources, querying servers, or engaging in other activities, an incident is almost certain to have occurred.

● Changes to logs—The smart systems administrator backs up system logs as well as system data. As part of a routine incident scan, systems administrators can compare these logs to the online versions to determine whether they have been modified. If they have, and the systems administrator cannot determine explicitly that an authorized individual modified them, an incident has occurred.

● Presence of hacker tools—Network administrators sometimes use system vulnerability and network evaluation tools to scan internal computers and networks to determine what a hacker can see. These tools are also used to support research into attack profiles. Too often, the tools are used by employees, contractors, or outsiders with local network access to hack into systems. To combat this problem, many organiza- tions explicitly prohibit the use of these tools without written permission from the CISO, making any unauthorized installation a policy violation. Most organizations that engage in penetration-testing operations require that all tools in this category be confined to specific systems, and that they not be used on the general network unless active penetration testing is under way.

● Notifications by partner or peer—If a business partner or another connected organi- zation reports an attack from your computing systems, then an incident has occurred.

● Notification by hacker—Some hackers enjoy taunting their victims. If an organization’s Web pages are defaced, it is an incident. If an organization receives an extortion request for money in exchange for its customers’ credit card files, an incident is in progress.

Another way to describe the definite indicators cited by Pipkin is the following list of general types of events that, when confirmed to have occurred, indicate that an actual incident is under way:

● Loss of availability—Information or information systems become unavailable. ● Loss of integrity—Users report corrupt data files, garbage where data should be, or

data that just looks wrong. ● Loss of confidentiality—You are notified of sensitive information leaks, or informa-

tion you thought was protected has been disclosed. ● Violation of policy—If organizational policies addressing information or information

security have been violated, an incident has occurred. ● Violation of law—If the law has been broken and the organization’s information

assets are involved, an incident has occurred.

172 Chapter 5 Incident Response: Detection and Decision Making

Identifying Real Incidents As was noted earlier, one of the first challenges facing IR plan designers is creating a process to collect and evaluate incident candidates to determine whether they are actual incidents (or circumstances likely to become incidents) or nonevents, also called false positive incident can- didates. This is very important because most organizations will find themselves awash in inci- dent candidates at one time or another, and the vast majority will be false positives.

Each organization must create its own processes that can be used to collect and evaluate incident candidates. Some may choose to have an “incident center,” where all incident candidates are sent from the earliest moment of recognition. Others may choose to have geographically separate review locations, perhaps based on time zones, where preliminary determinations about the status of an incident candidate can be assessed. Still other organizations may choose to isolate incident candidate evaluation based on business units, product lines, or some other criterion.

Many organizations struggle with the relationship between a false-positive incident candidate and “noise.” Noise is an event that does not rise to the level of an incident. In a properly designed sys- tem (whether human based or machine based), those candidate events that are legitimate activities wrongly reported as incident candidates are noise and should result in the activation of a feedback process that can improve the system so that these legitimate activities are suppressed by the data collection procedures or programs and are not flagged as events at all. Most data collection sys- tems are implemented with little or no formal training for the users of the process. When done properly, the training needs for incident candidate data collection should be extensive at first and then continue at a less intensive effort for the life of the system. The quality and quantity of the training, and the resulting skills of the staff involved in the data collection, will result in the removal of noise from the data collection process. Even the best-tuned incident candidate collec- tion system generates false positives; usually, they are considered to be inherent in the nature of such systems. However, the ratio of false positive events to actual events needs to be kept to a manageable level through ongoing improvements to the collection processes.

Noise or false positives result from several general causes, including:

● Placement—The incident candidate’s source is a significant factor. If an automated IDPS is placed outside the trusted subnetwork of the organization, it is likely to see a vast number of attempted attacks, which may be interpreted as incident candidates. Moving the sensor so that it is the first device inside the trusted subnetwork perimeter can reduce the number of events reported, allowing the control devices (firewall rules, in this case) to have the desired effect before sending in the alarm.

● Policy—In some situations, organizational policy may allow certain activities by employees that are later detected as incident candidates. For instance, if company policy allows network administrators within the company to use certain tools whose network signatures are classified by automated tools as network attacks (for example, Nmap, Metasploit, or any of the other tools commonly used by hackers), this will be a significant source of noise. Aligning data collection practices with policy parameters minimizes this kind of event.

● Lack of awareness—In some cases, users are not aware of policy limitations on certain activities. For example, in the previous situation, if Nmap were disallowed for use within the organization by policy, many systems administrators might not be aware of the policy and might use the tool for routine activities. An awareness pro- gram can help minimize the noise generated by this kind of activity.

Detecting Incidents 173

Many organizations do not deal well with the effort to minimize noise and the false positives it generates. There must be a procedure defined for the data collection tuning process that results in a careful analysis of the effect of each change to the data collection rules. Left to their own devices, many automated IDPS administrators would simply turn off the reporting of some classes of adverse events rather than perform an analysis of the events and determine if a change in the position of the data collector, an adjustment to policy, or increased aware- ness might be a better solution.

Although the false positive issue gets a lot of attention, it is also important to avoid the occurrence of false negative reports. A false negative occurs when an incident that deserves attention is not reported. One example of a false negative comes from the char- acter of Sherlock Holmes in Arthur Conan Doyle’s mystery “Adventure of Silver Blaze.” In the story, an expensive racehorse is stolen from its stable. Inspector Gregory of Scot- land Yard asks Holmes if there is any particular aspect of the crime calling for addi- tional study. Holmes says there is, then mentions “the curious incident of the dog in the night-time.” Inspector Gregory says, “The dog did nothing in the night-time,” to which Holmes replies, “That was the curious incident.” In this case, the failure of the dog to bark when Silver Blaze was stolen was a false negative report. If a data collection pro- cess such as an IDPS fails to warn of a valid network attack, it becomes “the dog that did nothing in the nighttime.”

Another factor to add to the tuning process is routine change. When new or modified sys- tems are placed in service, the result may be a need for additional tuning of the data collec- tion process. Newer technologies often change the way network traffic appears to both human and automated sensors. For example, some load-balancing appliances may generate significant traffic that probes the availability of the services it is attempting to balance. This traffic, if unanticipated, may be perceived as an incident candidate, when in fact it is merely noise.7

The objective of the tuning process is a mechanism whereby valid incident candidates are generated while controlling the generation of alerts based on legitimate network activities.

Intrusion Detection and Prevention Systems An intrusion detection and prevention system (IDPS) is a network burglar alarm. It is designed to be placed in a network to determine whether or not the network is being used in ways that are out of compliance with the policy of the organization. To understand the tech- nologies associated with IDPSs, you must first understand the nature of the events they are attempting to detect and possibly prevent.

An intrusion is a type of attack on information assets in which the instigator attempts to gain unauthorized entry into a system or network or disrupt the normal operations of a system or network. Whether or not this is done with the intent to steal or do harm, it remains outside the intended use of the system or network. Even when such attacks are automated or self-propagating, as in the case of viruses and distributed denial-of-service attacks, they are almost always instigated by an individual whose purpose is to harm an organization.

174 Chapter 5 Incident Response: Detection and Decision Making

In the domain of information processing, a process is a task being performed by a computing system. This is often done at the same time that the computer system is processing other tasks. Therefore, many processes may be under way at the same time, each of them being handled by the system’s processor in turn.

Computer systems are made up of hardware, software, data, and networking devices that enable support for applications programs to be used by people to solve problems. Current computer systems use a series of processes, some in a supervisory mode and others in a user mode. Each process is made up of the following:

● A set of instructions, coded in a machine language held in a state that can be run by the processor—This set of instructions is commonly called an image. It has a current state that changes over time, as the program is run. This image is usually provided with a name or label that corresponds to other versions of the program such as its source code, its compiled code, or perhaps the code library it came from.

● A set of memory locations where the image is housed, where process-specific data values are stored, where input and output buffers are placed, and where a special-purpose memory structure stores details about subroutine calls (the call stack), and a memory heap where intermediate computations are staged while the program is in a running state—This collection of memory assignments usu- ally includes physical memory as well as areas of virtual memory stored on other media, almost always hard disk drives.

● A list of allocated resources, provided from the operating system—This includes links to files and other data channels.

● A list of attributes that describe the allowable operations—This list of attributes describes the allowable operations (called permissions) that the image has been granted by the operating system.

● A table that identifies the current context of the various parts and pieces of the image—While the image is running, various registers in the central processing unit track the current processor state (kernel vs. user), point to the next execut- able instruction (the program counter), map to registers that are associated with the image and point to physical and virtual memory segments that are part of the image.

All the essential facts about an image are held in these structures, collectively called “control blocks.” Each image has a root process and then may spawn (or fork) to include subordinate processes sometimes called “daughter” processes. The kernel handles each process of the operating system as a separate element and allocates to it the resources it requests as they become available. This is done to reduce the

Technical Details: Processes and ServicesTechnical Details: Processes and Services

Intrusion Detection and Prevention Systems 175

likelihood of interprocess interference, such as deadlocking or thrashing. Data struc- tures are sometimes used between processes to facilitate communication between processes.

To view available processes provided on a Windows-based PC, use the Windows Task Manager, as shown in Figure 5-3.

Unfortunately, Windows Task Manager doesn’t reveal all processes. Apparently, Microsoft hid certain critical OS processes. However, another utility included in most versions of Windows is the System Information Utility (msinfo32.exe), located in the C:\program files\common files\microsoft shared\msinfo folder, which can detect all processes running on a particular system. Practitioners in the field have observed that the msinfo32 tool may be used to seek out Trojan programs. This can be done by listing the tasks and services that are running and then investigating any that are not recognized. Look at the paths and filenames being shown for the listed entries as well as the file properties. If there are anomalies, locate the .dll file linked to the process and run it through your virus checker. If you have reason to believe that a process is dodgy, use the Startup Programs editor in the tools menu to disable that task and then restart the system without the questionable task being started. Note, you should take a system backup before undertaking any of these steps. After restart, if your system still runs, leave the questionable process stopped and continue looking. Once you have eliminated what’s

Source: Microsoft Windows

Figure 5-3 Windows processes

176 Chapter 5 Incident Response: Detection and Decision Making

unnecessary, you will wind up with only essential processes running on your system and will have removed Trojans and also made your PC start and run more quickly.8

Source: NoHack.Net

Microsoft has documented the common Windows processes found in a system running on a typical Windows PC. A partial list of these is shown in Table 5-1.

Process Description

Csrss.exe Client/server run-time subsystem responsible for console windows, creating and/or deleting threads, and some parts of the 16-bit virtual MS-DOS environment

Dfssvc.exe Provides server-side support for NetDfsxxx APIs that configure and maintain the Distributed File System topology

Dwwin.exe The operating system client service that can report errors in user mode or kernel mode and that reports unplanned shutdown events

Explorer.exe The user shell, which includes the taskbar, desktop, and so on

Internat.exe Runs at start-up; loads the different input locales that are specified by the user. The locales to be loaded for the current user are taken from the registry key HKEY_CURRENT_USER\Keyboard Layout\Preload.

Llssrv.exe The Licensing logging service client originally designed to help customers manage licenses for Microsoft server products that are licensed in the Server Client Access License (CAL) model

Lsass.exe The local security authentication server; it generates the process responsible for authenticating users for the Winlogon service. This process is performed by using authentication packages such as the default Msgina.dll.

Msdtc.exe ODBC applications can also use the Microsoft Distributed Transaction Coordinator to include multiple Microsoft SQL Server connections in a single transaction, even when the connections are to separate servers.

Mstask.exe The task scheduler service, responsible for running tasks at a time predetermined by the user

Smss.exe The session manager subsystem, which is responsible for starting the user session. This process is initiated by the system thread and is responsible for various activities, including starting the Winlogon and Win32 (csrss.exe) processes and setting system variables.

Services.exe Services Control Manager, which is responsible for starting, stopping, and interacting with system services

Spoolsv.exe Spooler service is responsible for managing spooled print/fax jobs

Svchost A generic process that acts as a host for other processes running from DLLs; therefore, don’t be surprised to see more than one entry for this process

System.exe Most system kernel-mode threads run as the System process

Table 5-1 Common Windows processes9,10 (continues) Source: Microsoft Windows

Intrusion Detection and Prevention Systems 177

Although the complete list of processes that could run on a typical PC is too vast to share here, there are several online sites that allow the user to search the function of an identified process, including:

● File Inspect Library (www.fileinspect.com) ● Processlibrary.com (www.processlibrary.com) ● Tasklist.org (www.tasklist.org) ● Uniblue ProcessLibrary (www.liutilities.com/products/wintaskspro/processlibrary)

To view available services provided on a Windows-based PC or server, one can access the services function through the Windows Task Manager (see the Services tab in Figure 5-3) or the Administrative Tools menu in Control Panel, as shown in Figure 5-4.

More information about the services common to a Windows installation is presented in Table 5-2. Note that the Startup Type differs, depending on individual configuration, and can be changed by the user.

Process Description

System Idle Process A single thread running on each processor, which has the sole task of accounting for processor time when the system isn’t processing other threads

Taskmgr.exe The process for Task Manager itself

Winlogon.exe The process responsible for managing user logon and logoff; moreover, Winlogon is active only when the user presses CTRL+ALT+DEL, at which point it shows the security dialog box

Winmgmt.exe A core component of client management in Windows 2000; this process initializes when the first client application connects, or it can be made to respond each time management applications request its services.

Wmiprvse.exe Windows Management Instrument resides in a shared service host with several other services. To avoid stopping all the services when a provider fails, providers are loaded into a separate host process named Wmiprvse.exe. More than one process with this name can be running. Each can run under a different account with varying security.

Wsrm.exe The Windows System Resource Manager service, designed to manage multiple applications on a single computer or multiple users on a computer on which Terminal Services is in use. This supports a variety of scenarios, including consolidation, and can increase the efficiency with which physical hardware on a server is used by running applications.

Wsrmc.exe Provides administrative control of the Windows System Resource Manager (WSRM) service using the command-line interface; the command-line interface provides equivalent administrative control to the WSRM snap-in

Table 5-1 Common Windows processes9,10 (continued) Source: Microsoft Windows

178 Chapter 5 Incident Response: Detection and Decision Making

Source: Microsoft Windows

Figure 5-4 Windows services

Service Startup Type Log on As

Alerter Manual Local Service

Application Layer Gateway Manual Local Service

Application Management Manual Local System

Automatic Updates Automatic Local System

Background Intelligent Transfer Service Manual Network Service

ClipBook Manual Local System

COM+ Event System Manual Local System

COM+ System Application Manual Local System

Computer Browser Automatic Local System

Cryptographic Services Automatic Local System

DHCP Client Automatic Local System

Distributed Link Tracking Client Automatic Local System

Intrusion Detection and Prevention Systems 179

Service Startup Type Log on As

Distributed Transaction Coordinator Manual Network Service

DNS Client Automatic Network Service

Error Reporting Automatic Local System

Event Log Automatic Local System

Fast User Switching Compatibility Manual Local System

Help and Support Automatic Local System

Human Interface Device Access Disabled Local System

IMAPI CD-Burning COM Manual Local System

Indexing Service Manual Local System

Internet Connection Sharing Manual Local System

IPSec Services Automatic Local System

Logical Disk Manager Automatic Local System

Logical Disk Manager Administrative Service Manual Local System

Messenger Automatic Local Service

MS Software Shadow Copy Provider Manual Local System

Net Logon Automatic Local System

NetMeeting Remote Desktop Sharing Manual Local System

Network Connections Manual Local System

Network DDE Manual Local System

Network DDE DSDM Manual Local System

Network Location Awareness (NLA) Manual Local System

NT LM Security Support Provider Manual Local System

Performance Logs and Alerts Manual Network Service

Plug and Play Automatic Local System

Portable media serial number Automatic Local System

Print Spooler Automatic Local System

Protected Storage Automatic Local System

QoS RSVP Manual Local System

180 Chapter 5 Incident Response: Detection and Decision Making

Service Startup Type Log on As

Remote Access Auto Connection Manager Manual Local System

Remote Access Connection Manager Manual Local System

Remote Desktop Help Session Manager Manual Local System

Remote Procedure Call (RPC) Automatic Local System

Remote Procedure Call (RPC) Locator Manual Network Service

Remote Registry Automatic Local Service

Removable Storage Manual Local System

Routing and Remote Access Manual Local System

Secondary Logon Automatic Local System

Security Accounts Manager Automatic Local System

Server Automatic Local System

Shell Hardware Detection Automatic Local System

Smart Card Manual Local Service

Smart Card Helper Manual Local Service

SSDP Discovery Manual Local Service

System Event Notification Automatic Local System

System Restore Service Automatic Local System

Task Scheduler Automatic Local System

TCP/IP NetBIOS Helper Automatic Local Service

Telephony Manual Local System

Telnet Manual Local System

Terminal Services Manual Local System

Themes Automatic Local System

Uninterruptible Power Supply Manual Local Service

UPnP Device Host Manual Local System

Upload Manager Automatic Local System

Utility Manager Manual Local System

Volume Shadow Copy Manual Local System

Intrusion Detection and Prevention Systems 181

Information security intrusion detection systems (IDSs) became commercially available in the late 1990s. An IDS works like a burglar alarm in that it detects a violation (some system activity analogous to an opened or broken window) and activates an alarm. This alarm can be audible and/or visual (producing noise and/or lights), or it can be silent (an e-mail message or pager alert). With almost all IDSs, systems administrators can choose the configuration of the various alerts and the alarm levels associated with each type of alert. Many IDSs enable administrators to configure the systems to notify them directly of trouble via e-mail or pagers. The systems can also be configured—again, like a burglar alarm—to notify an external security service organization of a “break-in.” The configurations that enable IDSs to provide customized levels of detection and response are quite complex. A current extension of IDS technology is the intrusion prevention system (IPS), which can detect an intrusion and prevent that intrusion from successfully attacking the organization by means of an active response. Because the two systems often coexist, the combined term intrusion detection and prevention system (IDPS) is used to describe current anti- intrusion technologies.

A valuable source of information about IDPSs is the NIST publication SP 800-94, Guide to Intrusion Detection and Prevention Systems, written by Karen Scarfone and Peter Mell and available through NIST’s Computer Security Resource Center at http://csrc.nist.gov/publica tions/nistpubs/800-94/SP800-94.pdf. This guide distinguishes between IPS and IDS as follows:

The presence of unexpected processes and services could indicate an intrusion or other incident. It is therefore imperative that incident response and information security personnel become familiar with the services and processes that should be present to simplify the task of identifying those services and process that should not.

Service Startup Type Log on As

WebClient Automatic Local Service

Windows Audio Automatic Local System

Windows Firewall/Internet Connection Sharing Automatic Local S