Answered step by step
Verified Expert Solution
Link Copied!

Question

1 Approved Answer

Information Security Risk Management ITC6315 Assignment 2 Assignment For this exercise, read the provided case study about AcmeHealth, and rate the risk exposure for each

Information Security Risk Management ITC6315 Assignment 2 Assignment For this exercise, read the provided case study about AcmeHealth, and rate the risk exposure for each finding related to the following assets: 1. Code Repository 2. QA Server 3. Production Application Server You will need to assess the severity of each violation and also the likelihood that it would cause a breach of security. Use the severity and likelihood scales from Appendix B in the book (Tables 6.11 and 6.12) to evaluate each finding. A mapping table is provided (Figure 6.2) to calculate the Risk Exposure value for each severity/likelihood pair without taking sensitivity into account for now. Along with the ratings, describe in words why you rated the severity and likelihood this way. Review the provided example as a guideline. Next, write down 3-5 questions for each finding that you might ask the resource owner or SME to further qualify the risk. If you don't understand the technical details of any of the findings, ask the instructor to clarify. You can turn in the assignment electronically through Blackboard. Use this worksheet to capture each critical asset and describe the business value (see examples in the first row below): # 1 Code Repository Finding Severity Likelihood Exposure Resource administrators don't verify the integrity of the information resource patches through such means as comparisons of cryptographic hashes to ensure the patch obtained is the correct, unaltered patch. Resource High Low Moderate If malicious code is allowed onto the system through an application patch, this could compromise that application potentially allowing backdoor access to attackers or allow sensitive data to be sent from the application to the attackers. The malicious code may also cause the application to be unstable, causing it to crash periodically. Although it is possible for attackers to place fake application patch updates on sites that look legitimate, for most commercial software this would be more difficult and the attacker would have to be very motivated and have a high level of skill. Network connections from the offshore developers' workstations to the code repository server are not encrypted. 2 Code Repository _______ _______ _______ ____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________ Client data is copied from production servers to this server regularly for QA testing. 3 QA Server _______ _______ _______ ____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________ No one notifies the Help Desk of terminations for support personnel in order to ensure that their access is disabled. 4 Production Application Server _______ _______ _______ ____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________ Table 1 - Initial Finding Ratings Next write down your follow up questions for each finding using the space provided below. These questions should include the information you would need to better rate each of the findings: Finding 1: Are updates tested in a non-production environment prior to implementation? Where are updates downloaded from? Are systems scanned for vulnerabilities post-update? Will the system install a corrupted update? Is there a back-out procedure for bad updates? Etc. Record your follow up questions to further qualify each finding here: Finding 2: ________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ Finding 3: ________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ Finding 4: ________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ _________________________________________________________________________________________ Information Security Risk Management ITC6315 - Summer 2012 Risk Scenario Description of AcmeHealth AcmeHealth is a medium sized healthcare benefits software provider in the U.S. AcmeHealth's technology solutions reduce costs, provide market advantage, ensure compliance and improve consumer satisfaction. AcmeHealth's products and services help employers and employees manage complex decisions in an ever-changing healthcare benefits environment. AcmeHealth's Application Service Provider (ASP) solution provides integrated employee health and welfare benefits administration services for active, former and retired employees. Services include annual health plan enrollment, ongoing employee enrollment, benefits continuation, eligibility services and flexible spending accounts. Our fully integrated consumer-driven platform allows individuals to take control of their healthcare options through informative decision-making tools. AcmeHealth's applications automate business processes, reduce operating costs and provide access to accurate health information. AcmeHealth is proud of its ability to operate efficiently while responding quickly to the needs of its growing base customers located in all 50 states and 16 countries. Headquartered in Boston, MA., AcmeHealth is proud to be the fastest growing technology company in the healthcare industry. Company Details You are a software development firm that also offers an Application Service Provider (ASP) model for customers Provide employers and employees with technology for healthcare benefits management You have 150 employees in the company There are 110 software developers, project managers, and technical support staff onsite and remotely at client sites You allow the IT support team to log in to the company network from home via telnet and do file transfers via FTP to two UNIX servers in the company The development group is split between Windows and UNIX for desktops The Windows group uses Active Directory and is limited to group file share access on only the team projects they handle All windows users need to utilize a VPN client to connect to the company network remotely UNIX group use shared accounts in groups and passwords never expire There is a firewall, but the no change management process or patching going on a consistent basis There are policies and procedures in place, but the development teams rarely follow the policies due to project time constraints There are approximately twenty five people who do everything from burning application demo CD's, testing, to packaging, and shipping. They use Windows machines with generic accounts that have never changed. Access to the office area is uncontrolled and vendors are frequently wandering the area unsupervised. Everyone has Internet access and there is no content filtering. Employees go onto the Internet anytime and play games, check email, and surf the Internet. Antivirus is being run and is updated daily. Data is backed up daily, but the backups are never tested. Customer files and printouts are left out and thrown in the trash when projects are completed. Network Details \fSecurity Risk Management Building an Information Security Risk Management Program from the Ground Up This page intentionally left blank Security Risk Management Building an Information Security Risk Management Program from the Ground Up Evan Wheeler Technical Editor Kenneth Swick AMSTERDAM BOSTON HEIDELBERG LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE SYDNEY TOKYO Syngress is an imprint of Elsevier Acquiring Editor: Angelina Ward Development Editor: Heather Scherer Project Manager: Danielle S. Miller Designer: Alisa Andreola Syngress is an imprint of Elsevier 225 Wyman Street, Waltham, MA 02451, USA 2011 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher's permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility. To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein. Library of Congress Cataloging-in-Publication Data Application submitted British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library. ISBN: 978-1-59749-615-5 For information on all Syngress publications visit our website at www.syngress.com Printed in the United States of America 11 12 13 14 15 10 9 8 7 6 5 4 3 2 1 Typeset by: diacriTech, Chennai, India Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii PART I INTRODUCTION TO RISK MANAGEMENT CHAPTER 1 The Security Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 How We Got Here. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Banning Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Looking Inside the Perimeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 A Risk-Focused Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 A New Path Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 The Shangri-La of Risk Management . . . . . . . . . . . . . . . . . . . . . 7 Information Security Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Safety before Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 The Lure of Security by Obscurity . . . . . . . . . . . . . . . . . . . . . . . 9 Redefining the CIA Triad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Security Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Threats to Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 The Death of Information Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Security Team Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Modern Information Security Challenges. . . . . . . . . . . . . . . . 17 The Next Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 CHAPTER 2 Risky Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Applying Risk Management to Information Security . . . . . . . . . . 21 Mission of Information Security . . . . . . . . . . . . . . . . . . . . . . . . . 22 Goal of Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Architecting a Security Program . . . . . . . . . . . . . . . . . . . . . . . . . 24 How Does it Help?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Business-Driven Security Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Work Smarter, Not Harder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Positioning Information Security . . . . . . . . . . . . . . . . . . . . . . . . 30 Due Diligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Facilitating Decision Making. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 v vi Contents Security as an Investment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Security Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Qualitative versus Quantitative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Qualitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Quantitative Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 CHAPTER 3 The Risk Management Lifecycle . . . . . . . . . . . . . . . . . . . . . . . 43 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Stages of the Risk Management Lifecycle. . . . . . . . . . . . . . . . . . . . . 43 Risk Is a Moving Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 A Comprehensive Risk Management Workflow . . . . . . . . . . 46 Business Impact Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Resource Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A Vulnerability Assessment Is Not a Risk Assessment . . . . . . . . 50 Vulnerability Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Making Risk Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Risk Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Mitigation Planning and Long-Term Strategy . . . . . . . . . . . . . . . . . 56 Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Monitoring and Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Process Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 PART II RISK ASSESSMENT AND ANALYSIS TECHNIQUES CHAPTER 4 Risk Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 How Risk Sensitivity Is Measured . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Making a Resource List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Sensitivity, Not Exposure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Security Risk Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Profiling in Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Asking the Right Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Contents Risk Impact Categories and Examples . . . . . . . . . . . . . . . . . . . 71 Profile Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Calculating Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Assessing Risk Appetite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Assessing the C-Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Setting Risk Thresholds and Determining Tolerance Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 CHAPTER 5 Formulating a Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Breaking down a Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Finding the Risk, Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Terminology Is Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Envision the Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Finding the Risk, Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Who or What Is the Threat? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Defining Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Threat Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Threats Are Different from Risks . . . . . . . . . . . . . . . . . . . . . . 100 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 CHAPTER 6 Risk Exposure Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Qualitative Risk Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Defining Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Defining Likelihood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Qualitative Risk Exposure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Applying Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Qualitative Risk Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Quantitative Risk Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 vii viii Contents CHAPTER 7 Security Controls and Services . . . . . . . . . . . . . . . . . . . . . . 127 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Fundamental Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Security Control Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Assurance Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Access Control Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Composite Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Recommended Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Fundamental Security Control Requirements. . . . . . . . . . . . 144 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 CHAPTER 8 Risk Evaluation and Mitigation Strategies . . . . . . . . . . 147 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Risk Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Security's Role in Decision Making. . . . . . . . . . . . . . . . . . . . 148 Documenting Risk Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Calculating the Cost of Remediation . . . . . . . . . . . . . . . . . . . 153 Residual Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Risk Mitigation Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Mitigation Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Choosing Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Policy Exceptions and Risk Acceptance . . . . . . . . . . . . . . . . . . . . . 156 Exception Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Signature Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Expiration and Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 CHAPTER 9 Reports and Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Risk Management Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 A Consultant's Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Octave Allegro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Risk Assessment Engagement . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Structure of a Risk Assessment Report . . . . . . . . . . . . . . . . . 175 Executive Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Writing Audit Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Contents Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 CHAPTER 10 Risk Assessment Techniques . . . . . . . . . . . . . . . . . . . . . . . 189 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Operational Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Operational Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Assessment Approaches for Different Sized Scopes . . . . . 197 Project-Based Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Risk Assessments in the Project Lifecycle . . . . . . . . . . . . . . 198 The FRAAP Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Third-Party Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Industry Standard Assessments . . . . . . . . . . . . . . . . . . . . . . . . . 206 Improving the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 PART III BUILDING AND RUNNING A RISK MANAGEMENT PROGRAM CHAPTER 11 Threat and Vulnerability Management . . . . . . . . . . . . . . 215 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Program Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Asset and Data Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Resource Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Threat Identification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Threat Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Advisories and Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Rating Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 An Efficient Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Defining a Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 The FAIR Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Measuring Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 ix x Contents CHAPTER 12 Security Risk Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Assessing the State of Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Balancing Security and Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Qualifying the Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Implementing a Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Workflow Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Process Optimization: A Review of Key Points . . . . . . . . . . . . . . 251 The NIST Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 The NIST Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Focus of the NIST Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 CHAPTER 13 A Blueprint for Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Risk in the Development Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Analysis Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Goal of Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Developing an Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Security Architecture Principles . . . . . . . . . . . . . . . . . . . . . . . . 267 Separation by Risk Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Rules of Data Movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Information Flow Control Model . . . . . . . . . . . . . . . . . . . . . . . 269 Nontraversable Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Trust Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Patterns and Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Services (Payload) Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Management Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Infrastructure Common Services . . . . . . . . . . . . . . . . . . . . . . . . 274 External versus Internal Traffic. . . . . . . . . . . . . . . . . . . . . . . . . 274 Transitive Risk Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 274 Traversing Risk Sensitivity Boundaries . . . . . . . . . . . . . . . . . 275 Combining Security Controls. . . . . . . . . . . . . . . . . . . . . . . . . . 275 Aggregate and Partial Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Multidevice Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Front-End versus Back-End Application Tiers . . . . . . . . . . 277 Contents Public-Facing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Internal Nonstandard Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Architectural Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Detailed Risk Analysis Workflow . . . . . . . . . . . . . . . . . . . . . . 278 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 CHAPTER 14 Building a Program from Scratch . . . . . . . . . . . . . . . . . . . . 285 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Designing a Risk Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Risk Is the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Program Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Starting from Scratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Comparing the Models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Prerequisites for a Risk Management Program . . . . . . . . . . . . . . . 291 Security Policies and Standards . . . . . . . . . . . . . . . . . . . . . . . . 292 Information Resources Inventory . . . . . . . . . . . . . . . . . . . . . . . 292 Security Liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Risk at the Enterprise Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Common Risk Formula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Enterprise Risk Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Mapping Risk Domains to Business Objectives . . . . . . . . . 296 Examples of Risk Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Linking the Program Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Tying Other Security Processes to Risk . . . . . . . . . . . . . . . . 298 Risk and Exception Tracking System . . . . . . . . . . . . . . . . . . . 299 Program Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 Lessons from the Trenches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Appendix A: Sample Security Risk Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Appendix B: Qualitative Risk Scale Reference Tables . . . . . . . . . . . . . . . . . . . . . . . 309 Appendix C: Architectural Risk Analysis Reference Tables . . . . . . . . . . . . . . . . . . 313 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 xi This page intentionally left blank Preface I wish that I could start off with some fascinating story about how this book came to be, listing all my altruistic reasons for writing it, but ultimately my motivation for writing this book has been mostly practical and selfish. Several years ago, I wanted to share my own experiences with risk management, so I developed an Information Security Risk Management course for the graduate program at Clark University, and I realized that there wasn't any one book available that covered both the basics of risk assessment and how to build and manage a risk-based program. So, I set out to make my own life a little easier by writing a book that I could use in my courses. My secondary motivation for writing this book actually goes back to the original idea for my course at Clark; my goal was to address the lack of formal risk education opportunities for information security professionals. There is certainly nothing wrong with on-the-job training, but if that is the only option available to educate future risk analysts and risk managers, then we will continue to see the mishmash of risk analysis techniques and weak risk models that is casting doubt on the viability of risk management in general. There just hasn't yet been widespread adoption of comprehensive risk models specific to the information security field, and there are even fewer educational options available to get the few good models more exposure in the security community. Information security programs need to continue to evolve toward a risk-focused approach if they are going to have any chance of keeping up with the growing demands with ever-limited resources. I have seen the success that a risk-based program can produce, and my goal has been to share both my successes and lessons learned with the security community in the hopes that I can provide a solid foundation upon which others may design their own risk-focused security programs. Most information security training programs churn out security practitioners who know which static security patterns to follow or how to run a tool but, if challenged, they can't explain to you why it should be done that way and they can't adapt to situations outside the template that they learned in class. So many in the field don't see the value in taking the time to understand the principles of information security and how to apply them to a dynamic environment (sorry, the CISSP doesn't count as proof that you can apply information security principles). This constant focus on the operational and technical side of information security is creating a large percentage of security practitioners who have no idea what to do when the situation doesn't fit their static patterns or, even worse, they mistakenly apply the same checklists even if they don't address the actual risks. The next time you are interviewing for a security role, try asking the candidate not only how to implement a security control but also to explain why that control is critical at all. The scary thing is that most people can't explain why. They have just always done it that way or have been told to do it that way and they never questioned it. What if the variables change, would they know what to do? The reality is that most of these practitioners can't adapt. Maybe it is even acceptable xiii xiv Preface for someone at the practitioner level to use security checklists as a crutch, but when you start to consider those professionals who are leading and directing security programs, they need to align their initiatives with the business and adjust their approach at a moment's notice. Blindly applying a checklist or standard isn't going to cut it. Throughout this book, I try wherever possible to provide not only the guidance about how to best manage risks but also the underlying reasoning so that you can adapt the approach to your own needs. I hope that this will encourage a better fundamental understanding of why certain risks need to be prioritized over others and help the reader to think of creative solutions to reduce risk in their organization. For years, as a consultant, I helped clients to build, assess, and improve their risk management programs. I decided to leave consulting in 2008 to take on the challenge of developing an Information Security Risk Management program for a financial services company. Opportunities as a consultant had allowed a breadth of experience partnering with organizations across many industries, from the largest financial institutions to the manufacturing sector, but I was starting to feel like I needed to prove to myself that I could practice what I had been preaching as a consultant by meeting the challenges that come with managing a risk management program day in and day out. It is one thing to perform risk assessments as an outside consultant, or even to work with a client collaboratively to develop a portion of their program, but at the end of the day, you get to walk away and they are left managing the everyday challenges. This career move has given me a fresh perspective on what works, what doesn't, and how to best optimize limited resources to expand and mature the program to meet ever-increasing demands and expectations. Because of the opportunities I have had to see many different attempts to implement risk-based programs for many different consulting clients, I am confident that this book will be valuable for those who are just starting down the road of developing a program, as well as for those who have a solid understanding of assessment techniques but may not have the experience framing a program around risk. INTENDED AUDIENCE This book is intended for anyone who is analyzing new threats or vulnerabilities, performing security assessments, providing a technology audit function, or building an information security program. Even those who are familiar with performing risk assessments will benefit from the tips on how to more efficiently conduct assessments and the programmatic view of risk. Compliance and audit are such a large focus for most security teams, and I believe that anyone who is responsible for an audit function can use the information in this book to better focus their own assessments and more accurately evaluate identified risks. On the flip side, security professionals can also use the tips and techniques in this book to better interface with internal and external auditors and to improve presentation of risks to senior management. Preface The hope is that this book will help both security professionals and business managers understand how to qualify risk to the organization and make educated decisions about how to handle risk exposures. This topic bridges the gap between the subject matter experts in information security and the business executives with whom they work. Even for IT professionals, it is essential to understand the risk management lifecycle and how it will continue to impact and shape their daily responsibilities. Finally, although this book is primarily targeted as a guide for information security professionals, I have also been conscious to organize it in such a way that it could be used as a textbook for a risk management course. ORGANIZATION OF THIS BOOK This book consists of three main sections, which are as follows: Part IIntroduction to Risk Management This book begins with a brief history of how risk management has evolved in the information security field and how this organic growth has led to mixed adoption of sound risk management methodologies. After reviewing some fundamental security principles, we jump right into an introduction to the basic concepts of risk management as it is applied to information security, including the fundamental definition of terms and principles that will be used throughout. Next, we explore each phase of the risk management lifecycle, focusing on implementing assessment, analysis, and evaluation techniques that should be used to properly assess and mitigate information risk. Beyond just implementing a risk management program, we focus on how to deeply embed a risk mindset into every aspect of your security program. Chapter 1: This chapter summarizes the struggles of checklist-oriented practitioners trying to move security initiatives forward without the clear business focus and lays out a new vision for how risk management can change the dynamic. Once you understand some of the basic security principles, models, and concepts, it will help you to choose risk assessment activities that will most benefit your organization. Chapter 2: Whether you are building an entire security program or just designing a risk management function to fit into an existing security program, you will need to know how best to position it with senior management. A well-designed security program can leverage risk models to reduce some level of burden on the organization from the security and compliance requirements. There are some distinct benefits and drawbacks of both qualitative and quantitative analysis approaches that are important to understand before you choose which model to implement in your own organization. xv xvi Preface Chapter 3: Risk management is a combination of on-going profiling, assessment, evaluation, mitigation, validation, and monitoring activities throughout the lifetime of any critical resource. This chapter lays out each step of the risk management lifecycle, which should be used to keep your team focused on the areas of greatest risk for your organization. Part IIRisk Assessment and Analysis Techniques The lifecycle workflow that is introduced in the first part of the book will be used as the structure that guides the discussion of risk profiling, risk assessment approaches, analysis methods, risk decision strategies, control selection, mitigation planning, documenting risks, and processing exceptions. This part of the book takes a different spin with an insider's look at techniques for consultants performing risk assessments and essential strategies for working with auditors or regulators. A detailed walkthrough of a recommended risk assessment report and effective techniques to present risk to senior management wraps up this discussion of the risk lifecycle. As a risk manager or analyst, you will need to adapt your approach depending on the scope of the assessment, whether it be an operational, project-based, or third-party assessment. Chapter 4: The idea of profiling a resource to determine its value to the organization, or risk sensitivity, is one of the most pervasive concepts in all of risk management. It affects which resources you assess at all, how often you reassess them, how detailed the assessment needs to be, how to prioritize any risk findings, what level of risk is acceptable, and even the level of management needed to approve an exception. Looking beyond the individual asset, it is necessary to know how best to gauge the risk appetite of the organization, which really means assessing the risk tolerance of the most senior leaders. Chapter 5: This chapter starts out by focusing on how to construct a risk statement that includes all the necessary details to convey the likely consequences to senior management. Following the formulation of the risk description, it is important to review the many approaches to modeling and analyzing potential threats. A structured approach to threat modeling can provide a great insight into areas of risk that need to be prioritized, but done wrong this activity can become a huge time drain and can easily distract the security team from the imminent threats. Chapter 6: The most controversial topic in risk management by far is how to rate the risks. This chapter focuses on simple and proven models for both qualitative and quantitative risk analysis. The majority of the chapter is spent framing out a qualitative risk measure that accounts for the sensitivity of the resource, the severity of the vulnerability, and the likelihood the threat will exploit the vulnerability. The chapter wraps up with a brief review of Preface quantitative measures, highlighting several implementation challenges and a loss expectancy analysis method. Chapter 7: Risk management needs to be more than just a control selection exercise, but there is no denying that controls play an important role in managing acceptable levels of risk. There are many standards and frameworks available that will prescribe the minimal security controls that every organization should have in place, but to really understand the significance of these controls, an understanding of the fundamental security services that all these controls implement in some way is required. After reviewing the basics, some particularly universal control requirements will be introduced along with references to additional resources for further guidance. Chapter 8: Once the risks have been assessed, the next step in the risk management lifecycle is to decide how to address those risks. Even more fundamentally, a decision needs to be made about which ones are even worth reviewing and addressing at all. There is more than one way to mitigate a given risk, and the best risk managers are the ones who can get to the root of the problem and find a creative way to limit the exposure. For those risks that can't be addressed, or can only be partially mitigated, robust exception approval process is needed. Chapter 9: This chapter focuses on how to organize an effective executive summary that will highlight the most critical themes from an assessment. Especially for risk managers and consultants, or anyone who is working with auditors regularly, this chapter will become an essential reference. Crafting management responses for auditors or regulators is truly an art form and anyone can greatly benefit from the advice throughout this chapter. Chapter 10: Once you have a risk model established, you will need to choose different assessment methodologies that match the scope of your assessment. A risk assessment associated with a single project is going to require a different approach than an assessment of an entire other company that is being acquired. There will also be the everyday assessments of newly announced vulnerabilities or quick assessments of the risks discovered during an active incident investigation. This chapter reviews the most common categories of assessments and offers the most effective way to approach each. Part IIIBuilding and Running a Risk Management Program Most books and courses about risk management would have ended at this point, but it is critical to show how you can integrate these risk techniques into a comprehensive program to manage risk. To be in information security means that you are assessing and prioritizing risks, but without a structure for processing and filtering the risks, even the best assessor will get buried under the flood of risk information. Monitoring and assessing threat trends, daily vulnerability reports, deviations from security baselines, and design oversights are all critical xvii xviii Preface components of your program. The book ends by proposing a roadmap to pull the various aspects of a security program (policy, threat and vulnerability management, incident response, baseline reviews, security architecture, and vendor management) into one cohesive risk management program with a normalized view of risk across the entire organization. Chapter 11: A Threat and Vulnerability Management (TVM) program is characterized by constantly revolving short assessments of newly identified vulnerabilities and the processing and filtering of incoming threat intelligence. TVM is the umbrella for the majority of the operational risk assessments including security scanning, patch management, and monitoring of security detection controls. Without a strategy for filtering out the lower risk items quickly, you will drown yourself in information almost immediately. Chapter 12: A fundamental control for any organization is a set of security policies and standards that set the tone for how to operate the business securely. The challenge becomes how to assess the organization's current alignment with these standards and determine which gaps need to be addressed most urgently. This gap analysis is one of the fundamental on-going risk assessment activities that will help to gauge the security posture of the organization versus what controls might be documented on paper. Chapter 13: According to the experts in secure software development, there are three essential functions: code review, penetration testing, and architectural risk analysis. Of the three, the latter is the rarest, but it is also the most proactive and impactful of the three when done correctly. Security architecture is a big topic, so this chapter will focus on the highlights that risk managers and analysts need to understand in order to work with their architects to develop at least a basic risk assessment model. Chapter 14: This chapter pulls together the various risk models, assessment techniques, activities, and processes from the entire book and lays out a strategy for turning this into an actual program. As hard as it might be to assess some risks, the real challenge is integrating all these components into your existing security program and showing real value to the rest of the business. This chapter not only presents several of the prerequisites for a risk management program but also offers one possible roadmap for implementing a program with as little resistance as possible. Appendices Appendix A: Sample Security Risk Profile Throughout the book, there is a large focus on the value of rating the risk sensitivity of information resources through profiling. This appendix presents a sample security risk profile questionnaire that can be customized to fit the needs of a particular business or industry. Appendix B: Qualitative Risk Scale Reference Tables Preface Many risk analysis techniques, models, and scales are used throughout the book to demonstrate the assessment process with several case studies. This appendix pulls together the final qualitative analysis scales into one place for easy reference. Appendix C: Architectural Risk Analysis Reference Tables Chapter 13 provides an overview of the architectural risk analysis process based on a model of assessing information flows. This appendix provides a several tables that are used to determine the appropriate security requirements for each information flow. Acknowledgments For a first-time author, having a team of editors available to guide me through this process has been invaluable. Angelina Ward, Heather Scherer, and Ken SwickI couldn't have done it without you all. Writing this book has given me a chance to reflect on my own career experiences, and each success can be directly tied to the good fortune to find a mentor who saw potential and was willing to give me a chance to prove it. I would like to thank all my mentors for all the selfless hours that they have devoted to developing my career and for their positive impact on my life: Elle Douglass first showed me how to channel my passion for technology into something productive, and she set me on the path for success. I will never forget those late nights when I was working on projects, hoping someone would bring us some food. Did we ever see daylight those years? Marc Takacs gave me the confidence to take on the hard tasks and was never too busy to teach me something new. Among many things, Marc taught me that you can find the best barbecue in Alabama if you follow the dirt road to the house with the pig tied up out front, take a left, and take another left at the corner where the tree fell over back in 1981, and then follow that road until you get to the house where the Parsons used to live and take a right. It's worth it if you can find it! Bill Whittaker gave a former network engineer, but current developer, his first break into the information security field, and I haven't looked back since. More than anything, Bill taught me how to systematically troubleshoot a problem in a real way and that skill has been invaluable in my career. Finally, I have to thank my current mentor and boss, Justin Peavey. Without the opportunities that Justin has so selflessly sought out on my behalf and the knowledge he has shared with me, I don't think this book would have been possible. His trust and guidance have made it possible for me to build a risk management program that is worth sharing with the rest of the industry. We've come a long way from our early conversations at the Thirsty Bear. All these mentors have either set me on the right track or given me a push in the right direction, but the one who gives me the strength to keep challenging xix xx Preface myself everyday and inspires me to be my best is my extraordinary wife (and secret editor), Rachel. Despite her own challenging career demands, she has put up with my insane hours and inability to say no to new projects that consume our evenings and weekends, and every step of the way, she has always been my greatest supporter. Clearly, I understand what it means to take risks, but with her as my partner, I am confident that nothing is out of reach. Sorry about making you read so much about risk profiling and exception processing! About the Author Working as a security consultant in many industries for over 10 years, Evan Wheeler is accustomed to advising clients on all aspects of information assurance. Specializing in risk management, digital forensic investigations, and security architecture development, he offers an expert insight into security principles for both clients and security professionals. He brings years of hands-on experience developing a risk assessment practice for a large security services company serving a diverse client base, designing architectural risk analysis frameworks for several major financial services organizations, and performing risk assessments for organizations of various sizes. Evan has spoken to many audiences on topics ranging from building a forensic incident response infrastructure to developing security risk management programs from the ground up. He currently leads the information security risk management program as Director of Information Security for Omgeo (A DTCC, Thomson Reuters Company), and he previously spent over 6 years supporting the US Department of Defense as a security consultant. As a complement to this diverse experience in the field and his Computer Science degree from Georgia Tech, he has earned a Master of Science in Information Assurance from the National Security Agency certified program at Northeastern University. Currently, Evan continues to promote the security industry as an instructor at both Clark and Northeastern Universities and as an instructor and author of the Information Security Risk Management course for the SANS Institute. More details about his work and several free resources are available at: http://www.ossie-group.org. About the Technical Editor Kenneth Swick is a 20 year veteran of the IT industry in multiple vertical markets with much of that time involved with Risk and Security. He has multiple industryrecognized security certifications from organizations such as SANS, ISC2, and ISACA. Currently, he is a Technical Information Security Officer and Vice President of Citi, being tasked with reducing risk across the organization. His hobbies include keeping up on the latest infosec news and spending time with his family. PART Introduction to Risk Management I 1 The Security Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 03 2 Risky Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3 The Risk Management Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 This page intentionally left blank CHAPTER The Security Evolution 1 INFORMATION IN THIS CHAPTER How We Got Here A Risk-Focused Future Information Security Fundamentals The Death of Information Security INTRODUCTION Before even starting to think about the various steps required to design a program to assess and evaluate information security risks, it is important to briefly review the history of the field and take a quick look at Information Security as a discipline. Even those of you who are already familiar with some advanced risk assessment techniques can benefit from reviewing how we got here or you risk repeating the same mistakes. Information Security (or Information Assurance) needs to be viewed through the lens of business context to see the added value of basing your security program on a risk model. Risk management is by no means a ubiquitous foundation for information security programs, but many visionaries in the field recognize that the future of information security has to be focused on risk decisions if we are to have any hope of combating the ever-changing threat landscape and constantly increasing business demands. From an outsider's perspective, risk management may seem like an obvious fit for information security, but, amazingly, within the profession, there are still debates regarding its merit. HOW WE GOT HERE If you attend any industry conference or pick up any information security trade magazine, you will certainly see many references to risk assessments, risk analysis, and risk management. So, how is it possible that many security professionals are still arguing about the value of a risk-based approach to information security? Certainly, all the security products and service vendors have jumped on the risk bandwagon in full force. As a profession, have we fallen behind the vendors or are they contributing to the false perception of risk management? In fact, walking on the expo floor of any major information security conference, the number of 3 4 CHAPTER 1 The Security Evolution vendors touting their so-called \"risk management\" solutions has increased significantly compared to even 1 year prior. Hopefully, as you look at each vendor's offerings, you will start to ask yourself questions like \"is a vulnerability scanner really a risk management solution?\" The answer is no, not really; but, the vendors are positioning it that way, and many people are more than happy to follow blindly if they can cross risk management off their compliance checklist. This example highlights a great misunderstanding within the field about what risk management really is. Let's face itrisk management is not a new concept. Several other industries (for example, insurance, economics, finance) have implemented very robust and precise risk models to handle even complex scenarios. Unfortunately, the information security field itself is rather young compared with these other industries, and when you try to apply a mature discipline like risk management to an evolving practice, there will be gaps that need to be overcome. This book is focused on addressing those gaps by providing a solid foundation upon which information security professionals can build a world-class risk management program that is aligned with the business objectives of the organization. Banning Best Practices In order to start the transformation into a risk mind-set, we first have to shed some of the baggage of outdated approaches to information security and dispel several misconceptions about how an information security function should operate. A growing problem in the information security field is the emphasis and reliance on checklists and so-called \"best practices\" as the only basis for many decisions. For the sake of simplicity and consistency, the security field has evolved into a cookbooktype approach. Everyone gets the same recipe for security and is expected to implement it in the exact same way. The fundamental flaw with this strategy is that we don't live in a one-size-fits-all world. Instead of blanketly applying best practices across the board, we should be using some risk analysis techniques to identify the critical focus areas and to select the most appropriate solutions for our organizations. The motivation behind this cookbook mentality and the value of security checklists are clear when you look at how the information security field has evolved. There has always been a heavy technology focus in the field, and much of the security community got their start in an Information Technology (IT) role. As the discipline developed, implementations of security principles and concepts were inconsistent at best and the need to provide more standardized guidance to the practitioners who were battling it out in the trenches every day resulted in several generic security frameworks, some basic standards, and a lot of operationally focused training. Moreover, there are a wide variety of training options available at the practitioner level, but almost nothing focused on how to build and lead an information security program; most programs are aimed at teaching management activities, but there aren't many educational programs focused on true leadership. Let's look at a quick example of this problem in practice. A typical information security standard might be that sensitive data needs to be encrypted How We Got Here wherever it is stored. Suppose that you found a database

Step by Step Solution

There are 3 Steps involved in it

Step: 1

blur-text-image

Get Instant Access to Expert-Tailored Solutions

See step-by-step solutions with expert insights and AI powered tools for academic success

Step: 2

blur-text-image

Step: 3

blur-text-image

Ace Your Homework with AI

Get the answers you need in no time with our AI-driven, step-by-step assistance

Get Started

Recommended Textbook for

Management Fundamentals

Authors: Robert N. Lussier

10th Edition

1071891375, 978-1071891377

More Books

Students also viewed these General Management questions

Question

2. Develop a persuasive topic and thesis

Answered: 1 week ago

Question

1. Define the goals of persuasive speaking

Answered: 1 week ago