Copyright © 2022 by McGraw Hill. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written permission of the publisher, with the exception that the program listings may be entered, stored, and executed in a computer system, but they may not be reproduced for publication.

ISBN: 978-1-26-047334-6
MHID:      1-26-047334-1

The material in this eBook also appears in the print version of this title: ISBN: 978-1-26-047333-9, MHID: 1-26-047333-3.

eBook conversion by codeMantra
Version 1.0

All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where such designations appear in this book, they have been printed with initial caps.

McGraw-Hill Education eBooks are available at special quantity discounts to use as premiums and sales promotions or for use in corporate training programs. To contact a representative, please visit the Contact Us page at www.mhprofessional.com.

Information has been obtained by McGraw Hill from sources believed to be reliable. However, because of the possibility of human or mechanical error by our sources, McGraw Hill, or others, McGraw Hill does not guarantee the accuracy, adequacy, or completeness of any information and is not responsible for any errors or omissions or the results obtained from the use of such information.

TERMS OF USE

This is a copyrighted work and McGraw-Hill Education and its licensors reserve all rights in and to the work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill Education’s prior consent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these terms.

THE WORK IS PROVIDED “AS IS.” McGRAW-HILL EDUCATION AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill Education and its licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill Education nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages resulting therefrom. McGraw-Hill Education has no responsibility for the content of any information accessed through the work. Under no circumstances shall McGraw-Hill Education and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise.

To Rebekah, Nathan, and Shay.

—Peter H. Gregory

For Thomas, Lauren, and Max. I am very, very lucky.

—Dawn Dunkerley

I’d like to dedicate this book to my family, who was very understanding and patient with me while I wrote this book. To my wife Barbara; my children Greg, Sarah, and AJ; and my grandchildren, Sam, Ben, Evey, Emmy, big Caleb, and now, little Caleb: you guys are the world to me.

—Bobby E. Rogers

ABOUT THE AUTHORS

Peter H. Gregory, CRISC, CISM®, CISA®, CDPSE™, CIPM®, CISSP®, DRCE, CCSK™, is a 30-year career technologist and a security leader in a regional telecommunications company. He has been developing and managing information security management programs since 2002 and has been leading the development and testing of secure IT environments since 1990. Peter has also spent many years as a software engineer and architect, systems engineer, network engineer, and security engineer.

Peter is the author of more than 40 books about information security and technology, including Solaris Security, CISM Certified Information Security Manager All-in-One Exam Guide, and CISA Certified Information Systems Auditor All-in-One Exam Guide. He has spoken at numerous industry conferences, including RSA, Interop, (ISC)² Congress, ISACA CACS, SecureWorld Expo, West Coast Security Forum, IP3, Source, Society for Information Management, the Washington Technology Industry Association, and InfraGard.

Peter serves on advisory boards for cybersecurity education programs at the University of Washington and the University of South Florida. He was the lead instructor for nine years in the University of Washington certificate program in applied cybersecurity, a former board member of the Washington State chapter of InfraGard, and a founding member of the Pacific CISO Forum. Peter is a 2008 graduate of the FBI Citizens Academy and a member of the FBI National Citizens Academy Alumni Association. Peter is an executive member of the CyberEdBoard and the Forbes Technology Council.

Peter resides with his family in Washington state and can be found online at www.peterhgregory.com.

Dawn Dunkerley received a PhD in information systems from Nova Southeastern University in 2011 with a doctoral focus on information security success within organizations. Her research interests include cyberwarfare, cybersecurity, and the success and measurement of organizational cybersecurity initiatives. Dr. Dunkerley holds a number of professional certifications, including CRISC, CISSP, CISSP-ISSAP®, CISSP-ISSEP®, CISSP-ISSMP®, CSSLP®, and CompTIA Security+™ certifications.

Bobby E. Rogers is an information security engineer working as a contractor for Department of Defense agencies, helping to secure, certify, and accredit their information systems. His duties include information system security engineering, risk management, and certification and accreditation efforts. He retired after 21 years in the U.S. Air Force, serving as a network security engineer and instructor, and has secured networks all over the world. Bobby has a master’s degree in information assurance (IA). His many certifications include CRISC, CISSP-ISSEP, CEH™, and MCSE: Security, as well as the CompTIA A+™, Network+™, Security+, and Mobility+™ certifications.

About the Technical Editor

Matthew Webster has more than 25 years of experience in both IT and cybersecurity and is the author of Do No Harm: Protecting Connected Medical Devices, Healthcare, and Data from Hackers and Adversarial Nation States. Within his realm of experience has been multiple security officer positions, including chief information security officer. Matthew clearly has a passion for cybersecurity, which is evidenced by the fact that he has earned more than 20 IT and cybersecurity certifications, including Certified in Risk and Information Systems Control (CRISC), Certified Information Systems Auditor (CISA), GIAC Law of Data Security & Investigations (GLEG), and Certified Information Systems Security Professional (CISSP).

Matthew has worked in and around many companies throughout the northeast U.S. in a variety of capacities, and he has built many cybersecurity programs from the ground up. As a skilled professional, Matthew has spoken in a range of contexts, including in person and at online events.

CONTENTS AT A GLANCE

Chapter 1     Governance

Chapter 2     IT Risk Assessment

Chapter 3     Risk Response and Reporting

Chapter 4     Information Technology and Security

Appendix A  Implementing and Managing a Risk Management Program

Appendix B  About the Online Content

Glossary

Index

ACKNOWLEDGMENTS

From Peter:

I am immensely grateful to Wendy Rinaldi for affirming the need to have this book published on a tight timeline. My readers, including current and future risk managers, deserve nothing less.

Heartfelt thanks to Wendy Rinaldi and Janet Walden for proficiently managing this project, facilitating rapid turnaround, and equipping us with the information and guidance we needed to produce the manuscript.

Many thanks to Janet Walden and Nitesh Sharma for managing the editorial and production ends of the project and to Bart Reed for copyediting the book and further improving readability. I appreciate KnowledgeWorks Global Ltd. for expertly rendering my sketches into beautifully clear line art and laying out the pages. Like stage performers, they make hard work look easy, and I appreciate their skills.

Heartfelt thanks to Matt Webster (the author of Do No Harm and former CISO at Galway Holdings) for his invaluable tech review of the entire manuscript. Matt’s experience in security leadership and risk management resulted in many improvements in the manuscript. A thanks also to others, including Mark Adams.

Many thanks to my literary agent, Carole Jelen, for her diligent assistance during this and other projects. Sincere thanks to Rebecca Steele, my business manager and publicist, for her long-term vision and for keeping me on track.

Bobby and Dawn, thank you for including me and welcoming me to this project. The first edition of this book was entirely yours, and I’m honored to have been included in this edition. I have enjoyed working with you and on this project. But most important to me: it has been a pleasure getting to know both of you better. You both have my deepest respect.

Despite having written more than 40 books, I have difficulty putting into words my gratitude for my wife, Rebekah, for tolerating my frequent absences (in the home office) while I developed the manuscript. This project could not have been completed without her loyal and unfailing support and encouragement.

From Dawn:

I continue to be proud to call Bobby Rogers my coauthor and friend. I couldn’t ask for a better partner in crime.

Many thanks to Peter Gregory for jumping in and improving our work. Thank you, Peter, for the guidance and support!

McGraw Hill continues to provide both excellent editors and excellent people to guide our projects along the way; we could not have pulled off this project without them and their consistent support.

A big thank you to our technical editor, Matthew Webster. You did a great job keeping us on our toes.

Finally, I heartily acknowledge the contribution of my family and friends who have supported me throughout my various crazy endeavors. I could not ask for more than the love and encouragement I receive every day toward pursuing my goals. Thank you all.

From Bobby:

First, I’d like to thank all the good folks at McGraw Hill and their associates for guiding us throughout this book, helping us to ensure a quality product. Wendy Rinaldi, Caitlin Cromley-Linn, and Janet Walden were awesome to work with, making sure we stayed on track and doing everything they could to make this a wonderful experience. We’re very grateful to them for giving us the chance to write this book and believing in us every step of the way. Nitesh Sharma of KnowledgeWorks Global Ltd. was great to work with as project manager, and I’m happy to work again with Bart Reed, our copy editor on this project, who always manages to make me sound far more intelligent with his improvements to my writing.

Dawn Dunkerley has been one of my best friends for several years now, and I also consider her one of the smartest folks in our profession, so I was doubly happy to have her coauthor this book once again. She has added some fantastic insight and knowledge to this book; we couldn’t have done it without her. Thanks much, Dawn!

I would also like to offer a profound thanks to Peter for agreeing to be our coauthor on this project. Three minds are definitely better than two, and Peter brought a new insight into ISACA’s certifications and processes that we did not have for the first edition. His work in rewriting, revamping, redesigning, and rearranging the book material to make it more closely align to ISACA’s exam requirements was a critically needed improvement for this book to continue to be a great reference and study guide for the exam.

Matthew Webster deserves some special thanks because, as the technical editor, he had a difficult job, which was to make sure we stayed reasonable and technically accurate throughout the book. Matthew definitely contributed to the clarity, understanding, and technical accuracy of the text. Thanks for all your help, Matthew!

Most importantly, I would like to thank my family for allowing me to take time away from them to write, especially during the difficult times we live in right now. To my wife, Barb, my children and their families, Greg, Sarah and Sara, AJ and Audra, and my grandchildren, Sam, Ben, Evey, Emmy, and big Caleb, and now, my first great-grandson, little Caleb: I love all of you.

From Peter, Dawn, and Bobby:

We are so grateful for Matthew Webster’s contributions to the completeness and quality of this book. Through his experience in risk management and control, Matthew provided expert commentary and many suggested changes that made the book that much better. Thank you, Matthew!

INTRODUCTION

Welcome to the All-in-One Exam Guide for ISACA’s Certified in Risk and Information Systems Control (CRISC) exam! This book will help you study for, and successfully pass, one of ISACA’s premier certification exams, the CRISC exam. This exam is designed to test your knowledge of a wide variety of topics related to risk management and information systems controls. The exam focuses on business and IT risk management in enterprise infrastructure and designing and implementing IT security controls to mitigate risk.

Every day, it seems, data is breached at some of the largest organizations in the world. Recently we’ve seen breaches in the U.S. government, in the healthcare industry, and even at tech giants such as Microsoft, LinkedIn, and Facebook. Ransomware attacks alone are a plague on thousands of companies in nearly every country in the world. No organization, no matter what size, is immune to the threat of data breaches or, for that matter, data theft or loss. However, effective risk management can reduce the possibility of data breaches and strengthen business processes and IT infrastructures and even contribute to their efficient use. Information system controls reduce the likelihood of adverse events having a significant impact on the organization and should be carefully planned for and considered.

This book covers basic risk concepts, risk assessments, standards and frameworks, and information security control design and implementation. We also cover the essential concepts, terminology, and definitions that risk management practitioners and security professionals need to be effective in these areas. In the book’s four main chapters, we cover all four of the top-level domains as well as the task and knowledge statements listed in the official ISACA exam objectives. Appendix A discusses the pragmatic ways in which a security leader can successfully implement a risk management program.

While you don’t have to be an expert already in all the areas we discuss, having experience in some of these areas, such as risk concepts, helps. A good, broad background of experience and knowledge in information security will give you an advantage in your studies for this exam. Of course, you’ll get a good background in all these subjects throughout the book.

Passing the CRISC exam not only places you in a class of professionals recognized for their experience and expertise in this field, but it also serves to quantify and validate your knowledge of advanced risk management and security topics. After passing this exam, you’ll be able to show that not only are you qualified, but you are certified in these areas. This book is designed to help get you there.

Purpose of This Book

Let’s get the obvious out of the way: this is a comprehensive study guide for the information security and risk management professional who needs a reliable reference for individual or group-led study for the CRISC certification. This book contains the information that CRISC candidates are required to know. While this book is one source of information to help you prepare for the CRISC exam, it should not be thought of as the ultimate collection of all the knowledge and experience that ISACA expects qualified CRISC candidates to possess—no one publication covers all this information. The other thing you’ll need, just as important as suitable study material in our minds, is experience. There’s no substitute for practical, hands-on experience. You should make every effort to learn all aspects of the ISACA CRISC exam material we discuss in this book.

This book also serves as a reference for aspiring and practicing security and risk professionals and leaders. The content required to pass the CRISC exam is the same content that practicing security and risk professionals need to be familiar with in their day-to-day work. This book is a definitive CRISC exam study guide as well as a desk reference for those who have already earned their CRISC certification.

The pace of change in the information security and risk management industry and profession is high. Rather than contain every detail and nuance of every law, practice, standard, and technique in information security and risk management, this book shows the reader how to stay current in the profession. Indeed, the pace of change is one of many reasons that ISACA and other associations require continuous learning to retain one’s certifications. It is crucial to understand key facts and practices in security and risk management and learn how to stay current as they continue to change. However, despite the high rate of change in information security, there’s good news: the techniques for risk management itself change very slowly. The principles of risk assessments, risk management, and risk treatment are solid and time-proven. Much of this book is devoted to these practices.

This book is also invaluable for security and risk management professionals who are not in a leadership position. You will gain considerable insight into today’s security and risk management challenges. This book is also helpful for IT, privacy, and business management professionals who work with risk management professionals and need a better understanding of what they are doing and why.

Finally, this book is an excellent guide for anyone exploring a career in information security and risk management. The study chapters explain all the relevant technologies, techniques, and processes used to manage a modern risk management program. This is useful if you are wondering what the risk management profession is all about.

How to Use This Book

This book covers everything you’ll need to know for ISACA’s CRISC certification examination. Each chapter covers specific objectives and details for the exam, as defined by ISACA in its job practice areas. The chapters and their sections correspond precisely to the CRISC job practice that ISACA updates from time to time.

Each chapter has several components designed to effectively communicate the information you’ll need for the exam.

•   The topics covered in each chapter are listed in the first section to help you to map out your study.

•   Tips are included in each chapter that offer great information on how concepts you’ll study apply in a place that we like to call “the real world.” Often, they give you a bit more information on a topic covered in the text.

•   Exam Tips are included to point out areas you need to focus on for the exam. Note that they won’t give you any exam answers, but they will help you know about important topics you may see on the test.

•   Notes may be included in a chapter as well. These are bits of information that are relevant to the discussion and that point out extra information.

•   Fifteen practice questions appear at the end of each chapter and are designed to allow you to attempt some exam questions on the topics covered in the domain.

Appendix A is designed to help you understand the practical side of risk management, particularly for security leaders who need to develop or improve the risk management function in an organization. All three of us have many years of experience; this is our gift to you so that you have the greatest chance to succeed.

Appendix B contains information on how to access the online practice exam questions that accompany this book. The TotalTester engine allows you to test yourself in either Practice or Exam mode, or by narrowing down to a specific domain.

About This Second Edition

ISACA, like other certification organizations, periodically updates the job practice for CRISC and its other certifications. In 2020, we expected that ISACA would update the CRISC job practice in 2021, which prompted us to prepare to write this second edition reflecting these updates.

The first edition of this book was organized by subject matter and included a mapping from the book to the CRISC job practice. This arrangement allowed the book to tell the risk and control story logically, and the mapping table in the book helped readers understand what parts of the book corresponded to what parts of the CRISC job practice.

This second edition has been rearranged: the chapters and sections in the book now precisely correspond to the areas of the CRISC job practice, so it is no longer necessary to include a practice-to-book mapping. This new structure simplifies readers’ desire to read more about a particular topic in the job practice.

ISACA is somewhat academic in its approach to the arrangement of the CRISC job practice areas. For this reason, we added an appendix that describes the development and operation of a risk management program from a practical point of view. This appendix helps to fill the gap between the CRISC job practice and what it really takes to succeed.

Bobby and Dawn, the coauthors of the first edition, asked the publisher if Peter Gregory could be added to the writing team for the second edition. Peter’s familiarity with ISACA, its certifications, and his experience writing All-In-One Exam Guides for ISACA and IAPP certifications have helped improve this second edition. This book is the finished product of our collective service to you, our readers.

Becoming a CRISC Professional

To become a CRISC professional, you are required to pay the exam fee, pass the exam, prove that you have the necessary education and experience, and agree to uphold ethics and standards. To keep your CRISC certification, you are required to take at least 20 continuing education hours each year (120 hours in three years) and pay annual maintenance fees. This life cycle is depicted in Figure 1.

Figure 1 The CRISC certification life cycle

The following list outlines the primary requirements for becoming certified:

•   Experience A CRISC candidate must submit verifiable evidence of at least three years of professional work experience in IT risk management and IS control. Experience must be verified and gained within the ten-year period preceding the application date for certification or within five years from passing the exam. No waiver options are available.

•   Ethics Candidates must commit to adhering to ISACA’s Code of Professional Ethics, which guides the personal and professional conduct of those certified.

•   Exam Candidates must receive a passing score on the CRISC exam. A passing score is valid for up to five years, after which the passing score is void. A CRISC candidate who passes the exam has a maximum of five years to apply for CRISC certification; candidates who pass the exam but fail to act after five years will have to retake the exam if they want to become CRISC certified.

•   Education Those certified must adhere to the CRISC Continuing Professional Education Policy, which requires a minimum of 20 continuing professional education (CPE) hours each year, with a total requirement of 120 CPEs over the course of the certification period (three years).

•   Application After successfully passing the exam, meeting the experience requirements, and having read through the Code of Professional Ethics and Standards, a candidate is ready to apply for certification. An application must be received within five years of passing the exam.

Experience Requirements

To qualify for CRISC certification, you must have completed the equivalent of three years of total work experience in at least two of the CRISC domains. Additional details on the minimum certification requirements, substitution options, and various examples are discussed next.

NOTE   Although it is not recommended, a CRISC candidate can take the exam before completing any work experience directly related to information security management. As long as the candidate passes the exam and the work experience requirements are filled within five years of the exam date, and within ten years from the application for certification, the candidate is eligible for certification.

Direct Work Experience

You are required to have a minimum of three years of work experience in IT risk management and IS control. This is equivalent to 6000 actual work hours, which must be related to at least two of the CRISC job practice areas, listed next. One of these two job practice areas must be in Governance or IT Risk Assessment.

•   Governance Establish and maintain organizational governance and risk governance programs and frameworks. Determine roles and responsibilities as well as develop policies, standards, business processes, risk appetite, and risk tolerance, aligned with business culture and compliance with legal, regulatory, and contractual requirements.

•   IT Risk Assessment Establish and maintain processes to identify and analyze risk, including vulnerability management, threat modeling, risk assessments, and business impact analysis. Develop and maintain a risk register.

•   Risk Response and Reporting Establish and maintain risk treatment and risk response, controls and control ownership, third-party risk management processes, and control testing and remediation. Establish and publish metrics, key performance indicators, key risk indicators, and key control indicators.

•   Information Technology and Security Understand the principles of information technology and security, including enterprise architecture, IT operations, project management, business continuity and disaster recovery planning, data life cycle, systems development life cycle, security awareness training, and privacy.

All work experience must be completed within the ten years before completing the certification application or within five years from initially passing the CRISC exam. You will need to complete a separate Verification of Work Experience form for each segment of experience.

Substitution of Experience

Unlike most other ISACA certifications, there are no available experience waivers or substitutions. Instead, you are required to have three or more years of experience in IT risk management and IS control, as described in the preceding section.

NOTE   We recommend you also read the CRISC certification qualifications on the ISACA website. From time to time, ISACA does change the qualification rules, and we want you to have the most up-to-date information available.

ISACA Code of Professional Ethics

Becoming a CRISC professional means you agree to adhere to the ISACA Code of Professional Ethics, which is a formal document outlining those things you will do to ensure the utmost integrity and that best support and represent the organization and certification.

Specifically, the ISACA Code of Professional Ethics requires ISACA members and certification holders to do the following:

•   Support the implementation of, and encourage compliance with, appropriate standards and procedures for the effective governance and management of enterprise information systems and technology, including audit, control, security, and risk management.

•   Perform their duties with objectivity, due diligence, and professional care, in accordance with professional standards.

•   Serve in the interest of stakeholders in a lawful manner, while maintaining high standards of conduct and character and not discrediting their profession or the association.

•   Maintain the privacy and confidentiality of information obtained in the course of their activities unless disclosure is required by legal authority. Such information shall not be used for personal benefit or released to inappropriate parties.

•   Maintain competency in their respective fields and agree to undertake only those activities they can reasonably expect to complete with the necessary skills, knowledge, and competence.

•   Inform appropriate parties of the results of work performed, including the disclosure of all significant facts known to them that, if not disclosed, may distort the reporting of the results.

•   Support the professional education of stakeholders in enhancing their understanding of the governance and management of enterprise information systems and technology, including audit, control, security, and risk management.

Failure to comply with the ISACA Code of Professional Ethics can result in an investigation into a member’s or certification holder’s conduct and, ultimately, disciplinary measures, including the forfeiture of their hard-won certification(s).

You can find the full text and terms of enforcement of the ISACA Code of Professional Ethics at www.isaca.org/credentialing/code-of-professional-ethics.

The Certification Exam

The certification is offered throughout the year in several examination windows. You have several ways to register; however, we highly recommend you plan and register early regardless of your chosen method.

In early 2022, the schedule of exam fees in U.S. dollars was

•   CRISC application fee: $50

•   Regular registration: $575 member/$760 nonmember

As we write this, we’re emerging from the global COVID-19 pandemic. During the pandemic, ISACA and other certification bodies adapted and developed remotely proctored exams that permitted test-takers to sit for a certification exam from their residence. We have observed that ISACA has returned to tests administered at testing centers while continuing to offer remotely proctored exams for those who prefer remote testing. We’ll discuss both options in this section.

NOTE   We recommend you pay close attention to information on ISACA’s website regarding testing logistics and locations.

Once registration is complete, you will immediately receive an e-mail acknowledging your registration. Next, you will need to schedule your certification exam. The ISACA website will direct you to the certification registration page, where you will select a date, time, and (optionally) location to take your exam. When you confirm the date, time, and location for your exam, you will receive a confirmation via e-mail. You will need the confirmation letter to enter the test location—make sure to keep it unmarked and in a safe place until test time.

Onsite Testing Center

When you arrive at the test site, you will be required to sign in, and you may be required to sign an agreement. Also, you will be required to turn in your smartphone, wallet or purse, and other personal items for safekeeping. The exam proctor will read aloud the rules you are required to follow while you take your exam. These rules will address matters such as breaks, drinking water, and snacks.

While you take your exam, you will be supervised by the proctor, and possibly you will be monitored by video surveillance in the test center to make sure no one can cheat on the exam.

Remote Proctored Testing

If you have registered for a remote proctored exam, you need to make sure you meet all the technical requirements. ISACA has published the “Remote Proctoring Guide,” which includes all the necessary technical requirements and describes the step-by-step procedures for taking the exam.

A remote proctored exam means you’ll be taking the exam on your own computer in your residence or other location. You’ll be in live contact with an exam proctor, and your webcam will be turned on throughout the exam so that the proctor can observe you while taking the exam to ensure you are not cheating through the use of reference materials (books or online). The proctor may ask you to show them the room where you are taking the exam to ensure you do not have reference materials or information anywhere in view.

To be eligible for a remote proctored exam, you must have a supported version of Windows or macOS, a current Google Chrome or other Chromium browser (such as Brave or SRware Iron), a webcam with at least 640×480 resolution, a microphone, and a stable broadband Internet connection. You must have the ability to install the PSI Secure Browser and modify firewalls and other administrative tasks on the day of the exam (this requires you have administrative privileges on the computer you are using—which might be a problem if you are using a company-issued computer).

You’ll be required to log in to your My ISACA account when your exam is scheduled. Next, you’ll navigate to your certifications, find the exam you have scheduled, and launch the exam. You’ll be directed to perform several tasks, including installing the secure browser and closing several other programs on your computer, including other web browsers and programs like Adobe Reader, Word, Excel, and any others that could include reference material.

You are not permitted to speak or perform gestures at any time during the exam. In short, you cannot be seen to perform any action that might be an indication of aid by an accomplice or the presence of reference material.

You’ll be required to verify your ID by holding it near your webcam so that the proctor can see it to confirm that you are not having someone else take the exam for you. You will also be required to use your webcam to show the entire room to your proctor.

After all steps have been completed, the proctor will release the exam to you, and you may begin.

Exam Questions

Each registrant has four hours to take the multiple-choice question exam. There are 150 questions on the exam, representing the four job practice areas. Each question has four answer choices, of which you can select only one best answer. You can skip questions and return to them later, and you can also flag questions that you want to review later if time permits. While you are taking your exam, the time remaining will appear on the screen.

When you have completed the exam, you are directed to close it. At that time, the exam will display your pass or fail status, with a reminder that your score and passing status are subject to review.

You will be scored for each job practice area and then provided one final score. All scores are scaled. Scores range from 200 to 800; however, a final score of 450 is required to pass.

Exam questions are derived from a job practice analysis study conducted by ISACA. The areas selected represent those tasks performed in a CRISC’s day-to-day activities and represent the background knowledge required to develop and manage an information security program. You can find more detailed descriptions of the task and knowledge statements at https://www.isaca.org/credentialing/crisc/crisc-exam-content-outline.

Exam Coverage

The CRISC exam is quite broad in its scope. The exam covers four job practice areas, as shown in Table 1.

Table 1 CRISC Exam Practice Areas

Independent committees have been developed to determine the best questions, review exam results, and statistically analyze the results for continuous improvement. Should you come across a horrifically difficult or strange question, do not panic. This question may have been written for another purpose. A few questions on the exam are included for research and analysis purposes and will not be counted against your score. The exam contains no indications in this regard.

Preparing for the Exam

The CRISC certification requires a great deal of knowledge and experience from the CRISC candidate. You need to map out a long-term study strategy to pass the exam. The following sections offer some tips and are intended to help guide you to, through, and beyond exam day.

Before the Exam

Consider the following list of tips on tasks and resources for exam preparation. They are listed in sequential order.

•   Read the candidate’s guide For information on the certification exam and requirements for the current year, see the ISACA Exam Candidates Information Guide: go to www.isaca.org/credentialing/crisc and look for the Exam Candidate Information Guide download links.

•   Register If you are able, register early for any cost savings and solidify your commitment to moving forward with this professional achievement.

•   Schedule your exam Find a location, date, and time, and commit.

•   Become familiar with the CRISC job practice areas The job practice areas serve as the basis for the exam and requirements. Beginning with the 2021 exam, the job practice areas have changed. Ensure your study materials align with the current list, shown at https://www.isaca.org/credentialing/crisc.

•   Know your best learning methods Everyone has preferred learning styles, whether self-study, a study group, an instructor-led course, or a boot camp. Try to set up a study program that leverages your strengths.

•   Self-assess Run through practice exam questions available online (see Appendix B for more information). ISACA may offer a free CRISC self-assessment.

•   Study iteratively Depending on how much work experience in information security management you have already, we suggest you plan your study program to take at least two months but as long as six months. During this time, periodically take practice exams and note your areas of strength and weakness. Once you have identified your weak areas, focus on those areas weekly by rereading the related sections in this book, retaking practice exams, and noting your progress.

•   Avoid cramming We’ve all seen the books on the shelves with titles that involve last-minute cramming. Just one look on the Internet reveals various websites that teach individuals how to cram for exams most effectively. Research sites claim that exam cramming can lead to susceptibility to colds and flu, sleep disruptions, overeating, and digestive problems. One thing is certain: many people find that good, steady study habits result in less stress and greater clarity and focus during the exam. Because of the complexity of this exam, we highly recommend the long-term, steady-study option. Study the job practice areas thoroughly. There are many study options. If time permits, investigate the many resources available to you.

•   Find a study group Many ISACA chapters and other organizations have formed specific study groups or offer less-expensive exam review courses. Contact your local chapter to see whether these options are available to you. In addition, be sure to keep your eye on the ISACA website. Also, use your local network to find out whether there are other local study groups and other helpful resources.

•   Recheck your confirmation letter Do not write on or lose your confirmation letter. Put it in a safe place and note what time you will need to arrive at the site. Note this on your calendar. Confirm that the location is the one you selected and is located near you.

•   Check logistics Check the candidate’s guide and your confirmation letter for the exact time you are required to report to the test site (or log in from home if you registered for a remote proctored exam). A few days before the exam, check the site—become familiar with the location and tricks to getting there. If you are taking public transportation, be sure you are looking at the schedule for the day of the exam: if your CRISC exam is scheduled on a Saturday, public transportation schedules may differ from weekday schedules. If you are driving, know the route and where to park your vehicle.

•   Pack Place your confirmation letter and a photo ID in a safe place, ready to go. Your ID must be a current, government-issued photo ID that matches the name on the confirmation letter and must not be handwritten. Examples of acceptable forms of ID are passports, driver’s licenses, state IDs, green cards, and national IDs. Ensure you leave food, drinks, laptops, cell phones, and other electronic devices behind, as they are not permitted at the test site. For information on what can and cannot be brought to the exam site, see the CRISC exam candidate guide at https://www.isaca.org/credentialing/crisc.

•   Make a notification decision Decide whether you want your test results e-mailed to you. You will have the opportunity to consent to e-mail notification of the exam results. If you are fully paid (zero balance on exam fee) and have agreed to the e-mail notification, you should receive a one-time e-mail approximately eight weeks from the date of the exam with your results.

•   Sleep Make sure you get a good night’s sleep before the exam. Research suggests that you should avoid caffeine at least four hours before bedtime, keep a notepad and pen next to the bed to capture late-night thoughts that might keep you awake, eliminate as much noise and light as possible, and keep your room a suitable temperature for sleeping. In the morning, rise early so as not to rush and subject yourself to additional stress.

Day of the Exam

On the day of the exam, follow these tips:

•   Arrive early Check the Bulletin of Information and your confirmation letter for the exact time you are required to report to the test site. The confirmation letter or the candidate’s guide explains that you must be at the test site no later than approximately 30 minutes before testing time. The examiner will begin reading the exam instructions at this time, and any latecomers will be disqualified from taking the test and will not receive a refund of fees.

•   Observe test center rules There may be rules about taking breaks. This will be discussed by the examiner, along with exam instructions. If you need something at any time during the exam and are unsure as to the rules, be sure to ask first. For information on conduct during the exam, see the ISACA CRISC candidate guide at https://www.isaca.org/credentialing/crisc.

•   Answer all exam questions Read the questions carefully, but do not overanalyze them. Remember to select the best solution. There may be several reasonable answers, but one is better than the others. If you aren’t sure about an answer, you can mark the question and return to it later. After going through all the questions, you can return to the marked questions (and others) to read them and consider them more carefully. Above all, don’t try to overanalyze questions, and do trust your instincts. Do not try to rush through the exam, as there is plenty of time to take as much as a few minutes for each question. However, at the same time, do watch the clock so that you don’t find yourself going too slowly that you won’t be able to answer every question thoughtfully.

•   Note your exam result When you have completed the exam, you should see your pass/fail result. Your results may not be in large, blinking text; you may need to read the fine print to get your preliminary results. If you passed, congratulations! If you did not pass, do observe any remarks about your status; you will be able to retake the exam—there is information about this on the ISACA website.

If You Did Not Pass

Don’t lose heart if you did not pass your exam on the first attempt. Instead, remember that failure is a stepping stone to success. Thoughtfully take stock and determine your improvement areas. Go back to this book’s practice exams and be honest with yourself regarding those areas where you need to learn more. Reread the chapters or sections where you need to know more. If you participated in a study group or training, contact your study group coach or class instructor if you feel you can get any advice from them on how to study up on the topics you need to master. Take at least several weeks to study those topics, refresh yourself on other topics, then give it another go. Success is granted to those who are persistent and determined.

After the Exam

A few weeks from the exam date, you will receive your exam results by e-mail or postal mail. Each job practice area score will be noted in addition to the overall final score. All scores are scaled. Should you receive a passing score, you will also receive the application for certification.

Those unsuccessful in passing will also be notified. These individuals will want to closely look at the job practice area scores to determine areas for further study. They may retake the exam as many times as needed on future exam dates, as long as they have registered and paid the applicable fees. Regardless of pass or fail, exam results will not be disclosed via telephone, fax, or e-mail (except for the consented e-mail notification).

NOTE   You are not permitted to display the CRISC moniker until you have completed certification. Passing the exam is not sufficient to use the CRISC anywhere, including e-mail, résumés, CVs, correspondence, or social media.

Applying for CRISC Certification

To apply for certification, you must submit evidence of a passing score and related work experience. Keep in mind that you have five years to use this score on a CRISC certification application once you receive a passing score. After this time, you will need to retake the exam. In addition, all work experience submitted must have been within ten years of your new certification application.

To complete the application process, you need to submit the following information:

•   CRISC application Note the exam ID number as found in your exam results letter, list the information security management experience and any experience substitutions, and identify which CRISC job practice area (or areas) your experience pertains to.

•   Verification of Work Experience forms These must be filled out and signed by your immediate supervisor or a person of higher rank in the organization to verify your work experience noted on the application. You must fill out a complete set of Verification of Work Experience forms for each separate employer.

As with the exam, after you’ve successfully mailed the application, you must wait approximately eight weeks for processing. If your application is approved, you will receive an e-mail notification, followed by a package in the mail containing your letter of certification, certificate, and a copy of the Continuing Professional Education Policy. You can then proudly display your certificate and use the “CRISC” designation on your résumé, e-mail and social media profiles, and business cards.

NOTE   You are permitted to use the CRISC moniker only after receiving your certification letter from ISACA.

Retaining Your CRISC Certification

There is more to becoming a CRISC professional than merely passing an exam, submitting an application, and receiving a paper certificate. Becoming a CRISC professional is an ongoing and continuous lifestyle. Those with CRISC certification agree to abide by a code of ethics, meet ongoing education requirements, and pay annual certification maintenance fees. Let’s take a closer look at the education requirements and explain the costs involved in retaining certification.

Continuing Education

The goal of continuing professional education requirements is to ensure that individuals maintain CRISC-related knowledge to better develop and manage security management programs. To maintain CRISC certification, individuals must obtain 120 continuing education hours within three years, with a minimum requirement of 20 hours per year. Each CPE hour is to account for 50 minutes of active participation in educational activities.

What Counts as a Valid CPE Credit?

For training and activities to be utilized for CPEs, they must involve technical or managerial training that is directly applicable to information security and information security management. The following list of activities has been approved by the CRISC certification committee and can count toward your CPE requirements:

•   ISACA professional education activities and meetings.

•   If you are an ISACA member, you can take Information Systems Control Journal CPE Quizzes online or participate in monthly webcasts. For each webcast, CPEs are rewarded after you pass a quiz.

•   Non-ISACA professional education activities and meetings.

•   Self-study courses.

•   Vendor sales or marketing presentations (ten-hour annual limit).

•   Teaching, lecturing, or presenting on subjects related to job practice areas.

•   Publication of articles and books related to the profession.

•   Exam question development and review for any ISACA certification.

•   Passing related professional examinations.

•   Participation in ISACA boards or committees (20-hour annual limit per ISACA certification).

•   Contributions to the information security management profession (ten-hour annual limit).

•   Mentoring (ten-hour annual limit).

For more information on what is accepted as a valid CPE credit, see the Continuing Professional Education Policy (https://www.isaca.org/credentialing/how-to-earn-cpe/#cpe-policy).

Tracking and Submitting CPEs

Not only are you required to submit a CPE tracking form for the annual renewal process, but you also should keep detailed records for each activity. Records associated with each activity should have the following:

•   Name of attendee

•   Name of sponsoring organization

•   Activity title

•   Activity description

•   Activity date

•   Number of CPE hours awarded

It is in your best interest to track all CPE information in a single file or worksheet. ISACA has developed a tracking form for your use, which can be found in the Continuing Professional Education Policy. To make it easy on yourself, consider keeping all related records such as receipts, brochures, and certificates in the same place. Documentation should be retained throughout the three-year certification period and for at least one additional year afterward. Evidence retention is essential, as you may someday be audited. If this happens, you would be required to submit all paperwork. So why not be prepared?

For new CRISCs, the annual and three-year certification period begins January 1 of the year following certification. You are not required to report CPE hours for the first partial year after your certification; however, the hours earned from the time of certification to December 31 can be utilized in the first certification reporting period the following year. Therefore, should you get certified in January, you will have until the following January to accumulate CPEs. You will not have to report them until you report the totals for the following year, in October or November. This is known as the renewal period. During this time, you will receive an e-mail directing you to the website to enter CPEs earned over the course of the year. Alternatively, the renewal will be mailed to you, and then CPEs can be recorded on the hard-copy invoice and sent with your maintenance fee payment. CPEs and maintenance fees must be received by January 15 to retain certification.

Notification of compliance from the certification department is sent after all the information has been received and processed. Should ISACA have any questions about the information you have submitted, it will contact you directly.

Sample CPE Submission

Table 2 contains an example of a CPE submission.

Table 2 Sample CPE Submission

CPE Maintenance Fees

To remain CRISC certified, you must pay CPE maintenance fees each year. These fees are (as of early 2022) $45 for members and $85 for nonmembers each year. These fees are in addition to ISACA membership and local chapter dues (neither of which is required to maintain your CRISC certification).

Revocation of Certification

A CRISC-certified individual may have their certification revoked for the following reasons:

•   Failure to complete the minimum number of CPEs during the period.

•   Failure to document and provide evidence of CPEs in an audit.

•   Failure to submit payment for maintenance fees.

•   Failure to comply with the Code of Professional Ethics can result in investigation and ultimately can lead to revocation of certification.

If you have received a revocation notice, you will need to contact the ISACA Certification Department at certification@isaca.org for more information.

Living the CRISC Lifestyle

Being a CRISC involves a lot more than passing the exam, participating in continuous learning, and paying the annual maintenance fees. There are numerous opportunities to get involved in local, national, and global activities and events that will help you grow professionally and meet other risk management professionals.

Find a Local Chapter

ISACA has over 200 local chapters in nearly 100 countries around the world. Chances are there is a chapter near you. Peter attended many ISACA chapter meetings and other events in Seattle when he lived there, where engaging speakers spoke on new topics, and where he met many like-minded security and audit professionals over the years.

Local chapters rely entirely on volunteers, and there is room for you to help in some way. Better chapters have various programs, events, study groups, and other activities that enrich participants professionally. For us, most of our ISACA experience happens in our local chapter.

Attend ISACA Events

ISACA puts on fantastic in-person conferences with world-class keynote speakers, expert presentations, vendor demonstrations and exhibits, a bookstore, and opportunities to meet other security, risk, and audit professionals. We find ISACA conferences enriching to the point of being overwhelming. There are so many learning and networking opportunities that we find ourselves nearly exhausted at the end of an ISACA conference.

Join the Online Community

ISACA has an online community known as Engage, in which participants can discuss any topic related to security, risk, audit, privacy, and IT management. You can read and participate in online discussions, ask questions, help others with their questions, and make new professional connections. You can join Engage at https://engage.isaca.org/.

Pay It Forward Through Mentorship

If you are at the point in your career where you qualify for and have a reasonable prospect of passing the CRISC exam, chances are you have had a mentor or two earlier in your career, and maybe you have one now. As you grow in your professional stature, others will look to you as a potential mentor. Perhaps someone will come out and ask you if you would consider mentoring them.

The world needs more, and better, information security professionals and leaders. Mentoring is a great way to “pay it forward” by helping others get into the profession and grow professionally. You will also find that mentoring will enrich you as well.

Volunteer

As a nonprofit organization, ISACA relies on volunteers to enrich its programs and events. There are many ways to help, and one or more of these volunteer opportunities might be suitable for you:

•   Speaking at an ISACA event Whether you do a keynote address or a session on a specific topic, speaking at an ISACA event is a mountaintop experience. You can share your knowledge and expertise on a particular topic with attendees, but you’ll learn some things, too.

•   Serving as a chapter board member Local chapters don’t run by themselves—they rely on volunteers who are working professionals who want to improve the lot of other professionals in the local community. Board members can serve in various ways, from financial management to membership to events.

•   Starting or helping a CRISC study group Whether as a part of a local chapter or at large, consider starting or helping a group of professionals who want to learn the details of the CRISC job practice. We are proponents of study groups because study group participants make the best students: they take the initiative to take on a big challenge to advance their careers.

•   Writing an article ISACA has online and paper-based publications with articles on a wide variety of subjects, including current developments in security, privacy, risk, and IT management from many perspectives. If you have specialized knowledge on some topic, other ISACA members can benefit from this knowledge if you write an article.

•   Participating in a credential working group ISACA works hard to ensure that its many certifications remain relevant and up to date. Experts around the world in many industries give their time to ensure that ISACA certifications remain the best in the world. ISACA conducts online and in-person working groups to update certification job practices, write certification exam questions, and publish updated study guides and practice exams. Peter contributed to the first working group in 2013 when ISACA initially developed the CRISC certification exam; he met many like-minded professionals, some of whom he is still in regular and meaningful contact with.

•   Participating in ISACA CommunITy Day ISACA organizes a global effort of local volunteering to make the world a better, safer place for everyone. Learn about the next CommunITy Day at https://engage.isaca.org/communityday/.

•   Writing certification exam questions ISACA needs experienced subject matter experts who are willing to take the time to write new certification exam questions. ISACA has a rigorous, high-quality process for exam questions that includes training. Who knows—you could even be invited to an in-person workshop on writing exam items. You can find out more about how this works at https://www.isaca.org/credentialing/write-an-exam-question.

You can learn about these and many other volunteer opportunities at https://www.isaca.org/why-isaca/participate-and-volunteer.

Please take a minute to reflect on the quality and richness of the ISACA organization and its many world-class certifications, publications, and events. These are all fueled by volunteers who made ISACA into what it is today. Only through your contribution of time and expertise will ISACA continue in its excellence for future security, risk, privacy, and IT professionals. And one last thing you can only experience on your own: volunteering not only helps others but enriches you as well. Will you consider leaving your mark and making ISACA better than you found it?

Continue to Grow Professionally

Continuous improvement is a mindset and a lifestyle that is built in to IT service management and information security—it’s even a formal requirement in ISO/IEC 27001! We suggest that you periodically take stock in your career status and aspirations, be honest with yourself, and determine what mountain you will climb next. If needed, find a mentor who can guide you and give you solid advice.

While this may not immediately make sense to you, know this: helping others, whether through any of the volunteer opportunities listed previously or in other ways, will enrich you personally and professionally. We’re not talking about feathers in your cap or juicy items on your résumé, but rather the growth in character and wisdom that results from helping and serving others, particularly when you initiated the helping and serving.

Professional growth means different things to different people. Whether it’s a better job title, more money, a better (or bigger or smaller) employer, a different team, more responsibility, or more certifications, embarking on long-term career planning will pay dividends. Take control of your career and your career path—this is yours to own and shape as you will.

Summary

Becoming and being a CRISC professional is a lifestyle, not just a one-time event. It takes motivation, skill, good judgment, persistence, and proficiency to be a strong and effective leader in the world of information security management. The CRISC was designed to help you navigate the security management world with greater ease and confidence.

Each CRISC job practice area will be discussed in detail in the following chapters, and additional reference material will be presented. Not only is this information helpful in studying prior to the exam, but it is also meant to serve as a resource throughout your career as an information security management professional.

CHAPTER 1

Governance

In this chapter, you will:

•   Understand the concepts of organizational governance and how goals and objectives support it

•   Learn about structure, roles, and responsibilities

•   Analyze how organizational risk culture is facilitated through the definition of risk appetite and risk tolerance

•   Understand the concepts of enterprise risk management, associated frameworks, and the ethics of risk management

This chapter covers Certified in Risk and Information Systems Control Domain 1, “Governance.” The domain represents 26 percent of the CRISC examination.

The CRISC Task Statements relevant to this domain focus on governance and how it applies in this context to the organization, particularly executive management. The governance aspects of risk for an organization, as well as the relationships between enterprise risk and IT risk, are also explored. The chapter also examines risk management governance and how it is implemented in the organizational structure and culture. Governance also applies to overall laws, regulations, and even risk frameworks, so we will discuss those at length. In those governance discussions we will explain both external governance and internal governance, including policies and standards. Internal governance also includes management oversight, such as business process reviews, risk appetite and tolerance, as well as contractual obligations regarding risk management. Other topics related to the Task Statements we will touch on here and look at in depth in other chapters include elements of risk such as assets and their value, threats, vulnerabilities, likelihood, and impact.

Although many organizations will “do the right thing” in terms of due diligence and care, upholding their legal and ethical responsibilities and such, many other organizations either do not or don’t do it to the same standards. This is why governance is so vitally important to an organization. Governance ties all these elements together. Governance sets standards, whether they are legal, ethical, or otherwise, and attempts to “standardize” what organizations do in terms of their obligations to stakeholders and society in general. As you’ll see in this chapter, governance comes from different sources, both outside the organization and within it. It is a synthesis of enforced requirements and organizational leadership culture. Also, governance is necessary to ensure that organizations treat systems and data with care and, again, perform their due diligence and due care duties when dealing with data protection and risk.

In this chapter, we will focus on organizational governance and how it applies to all the different elements of an information security management system: mission, strategy, goals and objectives, roles and responsibilities, culture, risk, and even ethics.

Organizational Governance

Governance is the glue that holds all the different framing elements of an organization together: its mission, strategy, goals, and objectives. Governance establishes the requirements an organization must meet and consists of both internal and external governance. External governance comes in the form of laws, regulations, professional and industry standards, and other sources of requirements imposed on the organization from the outside. Internal governance typically supports external governance through policies, procedures, and processes. For example, if a law imposes requirements to protect certain sensitive data using specific controls or to a certain standard, then policies and procedures further support those requirements by formalizing and codifying them within the organization. Policies and procedures can also be independent of external governance and simply reflect the organization’s culture, needs, and values, usually established by its executive management. In any event, governance is the controlling factor for the organization; governance keeps the organization on the right focus and ensures that it is meeting its compulsory requirements, such as obedience to laws, as well as performing its due diligence and due care responsibilities.

In addition to imposing requirements on the organization, governance also refers to the structure by which the organization is led and regulated. Again, this could come from external or internal sources. External sources for governance could consist of an external board of directors or regulatory agencies. These entities ensure that the organization is led from the perspective of responsibility and accountability. Internal governance comes from internal business leaders and reflect business drivers not related to externalities. In reality, good governance typically reflects a balance between both internal and external business drivers.

The infrastructure framework of the organization—in the form of strategy, goals, objectives, mission statements, and so on—supports governance, as we will discuss further in this chapter.

Organizational Strategy, Goals, and Objectives

Businesses exist with clear missions, goals, and objectives. The organization is in business for a particular purpose, not merely because people want to come to work every day and socialize. Missions, goals, and objectives directly relate to why the organization is in business in the first place, whether that is to develop and market a product or provide a service. Organizational senior management defines the business’s mission, goals, and objectives, typically on a strategic or long-term level. Senior management also defines the levels of risk tolerance and appetite based on factors that include the market space, the operational environment, the economy, governmental regulation, and so on. These risk levels directly articulate with and support the business mission, balancing business opportunities that can generate revenue and move the business forward with potential negative events that may cause the business to fail or at least have a detrimental impact on the organization.

EXAM TIP   Remember that risk appetite and tolerance are directly related to the business mission, although different business pursuits may have varying levels of each. Senior management sets those levels based on the potential rewards from risky opportunities and the amount of loss the organization could endure if those rewards don’t materialize.

Organizational Structure, Roles, and Responsibilities

How the business is organized can help drive how it deals with risk in several ways. Most businesses are organized from a functional perspective; in other words, departments and other hierarchical structures are established to take care of specific functions that contribute to the business goals and objectives. For example, in a production-driven business, there may be a manufacturing or production department, an engineering department, a research and development department, and an assembly line. There will likely be additional departments that cover support functions, such as marketing, accounting and finance, public relations, and so on. A hospital, on the other hand, will be organized according to its specific functions, such as the emergency department, surgery, neurology, radiology, and so on. Businesses in other markets or areas will be organized differently as well. In any case, the organization of the business is structured as its mission and business purposes dictate. Certain functions can be found in any business, such as information technology, information security, and even legal compliance. These functional areas may have the primary function of dealing with risk, but an important thing to consider is that all different organizational structures, from lower-level work sections to higher-level departments and divisions, have responsibilities regarding risk.

The organization must look at its structure and decide how each individual unit will manage risk at its own level, understanding that risk management should be uniform throughout the entire organization. Another consideration is that risks tend to “roll up” or be combined at the higher levels of an organization. For example, risks that the accounting department incurs are only a part of the risks at higher organizational levels and are included in their risk management processes. Each lower-level unit in an organizational hierarchy has risks that are part of the next higher level’s risk considerations. While individual units may be responsible for only a small piece of the overall organizational risk, their parent units also bear responsibility for managing that risk, as well as the risk of other subordinate units. Another concept relating to organizational structures is that the risk incurred by one part of the organization is borne by all parts of the organization; there is almost no such thing as a risk that only affects one small part of the business. Risk ripples across the entire organization in some way.

Each individual unit, whether it is a unit in the lower levels of the business hierarchy or at the highest levels, should take steps to identify, evaluate, and assess risks at its level. Risks may be thought of as tactical, operational, and strategic. Tactical risks are those that are encountered by smaller-level production sections—those that carry out the day-to-day work of the organization. Operational risks can span several work units and relate to how the business conducts its functions, as well as how the different work units interact with each other. Strategic risk is borne at the higher levels of the organization, including senior management, and involves risks incurred by leading the business toward opportunities and away from decisions that exceed the organization’s capacity for risk appetite and tolerance. Respectively, these three types of risks also correspond to short-term, mid-term, and long-term risks as well.

Regardless of the level of risk incurred within the organization, there should be an enterprise risk management strategy and program in place to deal with the lower-tier, middle-tier, and higher-tier risks as well as ensure that the risk management strategy handles risks consistently and uniformly in alignment with the organization’s risk tolerance and appetite. Governance from the higher levels of the organization affects risk appetite and tolerance and shapes the organization’s risk management strategy throughout all the different hierarchical levels. The organizational structure must support that governance, as well as clearly define lines of authority and responsibility in terms of risk leadership and management.

Organizational Culture

Organizational culture is the term that describes how people treat each other and how people get things done. Many organizations establish a set of values that define the norms of behavior. Terms like respect, collaboration, and teamwork are often seen in these values. Some organizations will publish formal value statements and print them for display in lobbies, offices, and conference rooms.

The way that an organization’s leaders treat each other and the rest of the organization sets an example for behavioral norms. Often, these norms reflect those formal values, but sometimes they may differ. One could say that an organization’s stated culture and its actual culture may vary a little, or a lot. The degree of alignment itself is a reflection of an organization’s culture.

An organization also has a risk culture, which is essentially how the organization as an entity feels about and deals with risk. This culture is developed from several sources. First, it can come from the organization’s leadership, based on their business and management philosophies, attitudes, education, and experience. It can also come from the organization’s governance. Remember that governance is essentially the rules and regulations imposed on the organization by either external entities (in the form of laws, for example) or internally by the organization itself. In any case, the culture of the organization really defines how the organization feels about risk and how it treats risk over time. We will talk later about how two concepts, risk tolerance and risk appetite, support the organizational risk culture.

Policies and Standards

Different types of controls work together to protect an organization, many of which have a technical focus. However, while the more technical approaches are quite often the stars of the cybersecurity show, the importance of the good old policy cannot be understated. In fact, without a policy, quite often, the security program will fall flat due to a lack of governance, management involvement, and accountability. This objective covers different types of policies and how they work together to form the underlying foundation of human and process control, ensuring a balanced and effective security program.

To provide effective security, security policy and procedure creation must begin at the top of an organization with senior management that understands, supports, and holds personnel accountable to the written policies. Remember that organizational policies must articulate with external governance, such as requirements found in laws and regulations, or the management philosophies and tolerances of the organization’s leadership. These policies and procedures must then flow throughout the organization to ensure that security is useful and functional at every level of the organization. Understanding organizational security must begin with an understanding of the basic laws, regulations, and legal jurisdiction that policies must be informed by in order to protect not only the organization and its assets but also its employees and customers.

Management creates policies based on its leadership philosophies, culture, industry standards and requirements, and, most importantly, external governance. Policies articulate with all these items and represent management’s directives in upholding these requirements. Policies specific to risk governance include a body of documents that may start with the Risk Management Strategy, which details the organization’s overall strategy, methodology, and long-term desires for managing risk. Policies support the strategy, as well as governance requirements, such as those that may be found in laws or regulations that dictate that certain risk management activities must take place within the organization. An example of a risk-related policy would be a risk management or risk assessment policy, which dictates the organization’s requirements for risk management, assessment and analysis, risk treatment, and risk monitoring. This policy may be brief or detailed but will usually state roles and responsibilities, the risk management methodology adopted by the organization, and the requirement to implement detailed risk management procedures.

Business Processes

The organization’s mission is the reason that it exists, whether this is producing goods, offering services, and so on. A shoe manufacturer is in the business of making shoes; therefore, its mission is to make good quality shoes. Most businesses have a mission statement that describes their mission. While the mission is the overall reason for existence, business processes are the activities that carry out that mission. A shoe manufacturer’s business processes could be as high level as manufacturing, sales, and marketing, but even those higher-level processes are broken down into activities, such as sewing cloth and leather, developing types and styles of shoes, and selling them to retailers. These are all processes that support the business. Each of these business processes also incurs some level of business risk. There could be risks in the manufacturing process due to the types of materials or specific manner of attaching the shoe soles to the rest of the shoe. A faulty process could mean that the shoes are of lesser quality than other competitors or that the styles don’t meet the demands of consumers. This, in turn, will lead to fewer sales or more consumer returns. Regardless of whether they are higher-level processes or more detailed activities and tasks, each of these is supported by one or more systems or sets of data. These systems also incur risk, but of a different nature. The risk incurred by the systems includes the ability to effectively use those systems and data to support the different business processes. Therefore, IT (or even cybersecurity) risk directly informs business process risk since it could affect the ability of the organization to carry out its business processes and, in turn, its overall mission.

Business processes are “owned” by different managers within the organization. This means that the business process owners are responsible for both the day-to-day and long-term operations and success of the process. This also means, ordinarily, that they are the primary owners of the business risk associated with the process. Of course, higher-level management bears ownership and responsibility for both the process and risk also, but these are typically the people in charge of the business process.

Better organizations will take a formal approach with regard to the development and management of business processes. Documents that describe processes, roles and responsibilities, and key assets may be formally managed with business process change management and periodic review and be kept in official repositories to ensure that no unauthorized changes occur.

Organizations with higher maturity will develop metrics and even key performance indicators (KPIs) associated with each business process. This allows management to understand the quantity and quality of business process output, which can be used to determine tactical and strategic improvements that can make processes more effective and efficient. Risk practitioners must work hand-in-hand with business process owners to develop these KPIs, as well as associated key risk indicators (KRIs) and key control indicators (KCIs).

NOTE   KPIs, as well as KRIs and KCIs, are covered in more detail in Chapter 3, where we discuss risk response and reporting as part of Domain 3.

Organizational Assets

Company assets can include physical items, such as computer and networking equipment, office machines (for example, scanners and copiers), work facilities, and information processing centers, as well as nonphysical items, such as valuable data. Asset identification involves identifying both types of assets and determining their value. Asset values must be established beyond the mere capital costs; a true asset valuation should consider several factors. For example, a consideration should be the cost to repair or recover the asset versus simply replacing the asset outright. Often, repairing the asset may be less expensive in the short run, but the cost of the different components required to conduct a repair should be considered. Also, it’s important to remember that this might only be a temporary solution—one that could come back to haunt you (and your pockets) in the long run.

Asset management is the collection of activities used to oversee the inventory, classification, use, and disposal of assets. Asset management is a foundational activity, without which several other activities could not be effectively done, including vulnerability management, device hardening, incident management, data security, and some aspects of financial management.

In information security, asset management is critical to the success of vulnerability management. If assets are not known to exist, they may be excluded from processes used to identify and remediate vulnerabilities. Similarly, it will be difficult to harden assets if their existence is not known. What’s more, if an unknown asset is attacked, the organization may have no way of directly realizing this in a timely manner. If an attacker compromises an unknown device, the attack may not be known until the attacker pivots and selects additional assets to compromise. This time lag could prove crucial to the impact of the incident.

Asset Identification

A security management program’s main objective (whether formally stated or not) is the protection of the organization’s assets. These assets may be tangible or intangible, physical, logical, or virtual. Here are some examples of assets:

•   Buildings and property These assets include real estate, structures, and other improvements.

•   Equipment This can include machinery, vehicles, and office equipment such as copiers, printers, and scanners.

•   IT equipment This includes computers, printers, scanners, tape libraries (the devices that create backup tapes, not the tapes themselves), storage systems, network devices, and phone systems.

•   Virtual assets In addition to the tangible IT equipment cited, virtual assets include virtual machines and the software running on them.

•   Supplies and materials These can include office supplies as well as materials used in manufacturing.

•   Records These include business records, such as contracts, video surveillance tapes, visitor logs, and far more.

•   Information This includes data in software applications, documents, e-mail messages, and files of every kind on workstations and servers.

•   Intellectual property This includes an organization’s designs, architectures, patents, software source code, processes, and procedures.

•   Personnel In a real sense, an organization’s personnel are the organization. Without its staff, the organization cannot perform or sustain its processes.

•   Reputation One of the intangible characteristics of an organization, reputation is the individual and collective opinion about an organization in the eyes of its customers, competitors, shareholders, and the community.

•   Brand equity Similar to reputation, this is the perceived or actual market value of an individual brand of product or service that is produced by the organization.

Sources of Asset Data

An organization that is building or improving its security management program may need to build its asset inventory from scratch. Management will need to determine where this initial asset data will come from. Some sources include the following:

•   Financial system asset inventory An organization that keeps all of its assets on the books will have a wealth of asset inventory information. However, it may not be entirely useful: asset lists often do not include the location or purpose of the asset and whether it is still in use. Correlating a financial asset inventory to assets in actual use may consume more effort than the other methods for creating the initial asset list. However, for organizations that have a relatively small number of highly valued assets (for instance, an ore crusher in a gold mine or a mainframe computer), knowing the precise financial value of an asset is highly useful because the actual depreciated value of the asset is used in the risk analysis phase of risk management. Knowing the depreciated value of other assets is also useful, as this will figure into the risk treatment choices that will be identified later.

TIP   Financial records that indicate the value of an asset do not include the value of information stored on (or processed by) the asset.

•   Interviews Discussions with key personnel for the purposes of identifying assets are usually the best approach. However, to be effective, several people usually need to be interviewed to be sure to include all relevant assets.

•   IT systems portfolio A well-managed IT organization will have formal documents and records for its major applications. While this information may not encompass every IT asset in the organization, it can provide information on the assets supporting individual applications or geographic locations.

•   Online data An organization with a large number of IT assets (systems, network devices, and so on) can sometimes utilize the capability of online data to identify those assets. An organization with cloud-based assets can use the asset management portion of the cloud services dashboard to determine the number and type of assets in use there. Also, a systems or network management system often includes a list of managed assets, which can be a good starting point when creating the initial asset list.

•   Security scans An organization that has security scanning tools can use them to identify network assets. This technique will identify authorized as well as unauthorized assets.

•   Asset management system Larger organizations may find it more cost effective to use an asset management application dedicated to this purpose, rather than rely on lists of assets from other sources.

None of these sources should be considered accurate or complete. Instead, as a formal asset inventory is being assembled, the security manager should continue to explore other sources of assets.

Collecting and Organizing Asset Data

It is rarely possible to take (or create) a list of assets from a single source. Rather, more than one source of information is often needed to be sure that the risk management program has identified at least the important, in-scope assets it needs to worry about.

NOTE   As part of IT governance, management needs to determine which person or group is responsible for maintaining asset inventories.

It is usually useful to organize or classify assets. This will help to get identified assets into smaller chunks that can be analyzed more effectively. There is no single way to organize assets, but here are a few ideas:

•   Geography A widely dispersed organization may want to classify its assets according to their location. This will aid risk managers during the risk analysis phase since many risks are geographic-centric, particularly natural hazards.

•   Service provider An organization utilizing one or more Infrastructure as a Service (IaaS) providers can group its assets by service provider.

•   Business process Because some organizations rank the criticality of their individual business processes, it can be useful to group assets according to the business processes they support. This helps the risk analysis and risk treatment phases because assets supporting individual processes can be associated with business criticality and treated appropriately.

•   Organizational unit In larger organizations, it may be easier to classify assets according to the organizational unit they support.

•   Sensitivity Usually ascribed to information, sensitivity relates to the nature and content of that information. Sensitivity usually applies in two ways: to an individual, where the information is considered personal or private, and to an organization, where the information may be considered a trade secret. Sometimes sensitivity is somewhat subjective and arbitrary, but often it is defined in laws and regulations.

•   Regulation For organizations that are required to follow government and other legal obligations regarding the processing and protection of information, it will be useful to include data points that indicate whether specific assets are considered in scope for specific regulations. This is important because some regulations specify how assets should be protected, so it’s useful to be aware of this during risk analysis and risk treatment.

There is no need to choose which of these methods will be used to classify assets. Instead, an analyst should collect several points of metadata about each asset (including location, process supported, and organizational unit supported). This will enable the security manager to sort and filter the list of assets in various ways to better understand which assets are in a given location or which ones support a particular process or part of the business.

TIP   Organizations should consider managing information about assets in a fixed-assets application.

Risk Governance

Risk governance has several different aspects. As mentioned earlier, governance provides the overall requirements of what the organization must adhere to and could include legal, ethical, safety, and professional requirements. Risk governance, then, describes the requirements that the organization must adhere to in terms of managing both business and IT risk. Laws, regulations, and other external governance can dictate portions of risk governance, as can internal governance, which comes in the form of policy. Risk governance is also set forth by executive management in the form of risk appetite and tolerance, risk strategy, and throughout the various policies that support risk management. Risk governance includes adopting a risk assessment and analysis methodology, risk treatment and response options, risk monitoring processes, and so on. A multitude of risk governance and management frameworks have been published to assist in this process, which we will discuss next.

Enterprise Risk Management and Risk Management Frameworks

Enterprise risk management (ERM) is the practice of identifying and managing strategic risk in an organization. This includes topics such as macroeconomics, market risk, regulations, workforce, information technology, and cybersecurity. The individual risks in ERM will cite various uncertainties and scenarios that, if realized, may have a negative impact on the organization’s long-term viability.

Standards and frameworks help provide a standardized, industry-accepted approach toward managing risk. While they’re certainly not perfect, they provide a baseline for an organization to recognize the key steps toward understanding and categorizing the risks to its business, implementing the appropriate security controls to lower risk to an acceptable level, and continually monitoring the residual risk and report the status to management. Each standard and framework has its own pluses and minuses, and we will discuss two of the more commonly used: the ISACA Risk IT Framework and the National Institute of Standards and Technology (NIST) Risk Management Framework. Keep in mind that this discussion serves only to introduce you to the frameworks.

ISACA Risk IT Framework

Originally published in 2009, the ISACA Risk IT Framework is a common risk management framework you should be aware of. ISACA wanted to create a framework that merges the traditional IT models with a more risk-focused mindset. Within the ISACA model, the activities considered key are grouped into processes, which in turn are grouped into three domains: Risk Governance, Risk Evaluation, and Risk Response. You will see many of the same concepts that you’ll find within this book (and even this chapter), so it’s definitely a worthwhile model to review. The Risk Governance domain discusses risk appetite, risk tolerance, and communicating risk to leadership. The Risk Evaluation domain includes an understanding of the impacts to the business and the risk scenarios, developed through the inclusion of internal and external environmental factors, risk management capability, IT capability, and IT-related business capability. The Risk Response domain covers the risk response definition, risk response prioritization, and key risk indicators (KRIs). The framework also describes risk response options such as risk avoidance, risk mitigation, risk sharing and transfer, and risk acceptance.

NIST Risk Management Framework

NIST Special Publication 800-37, Revision 2, “Guide for Applying the Risk Management Framework to Federal Information Systems,” along with other supporting publications from NIST (part of the U.S. Department of Commerce), makes up the defining volumes of the Risk Management Framework (RMF). The RMF is composed of seven steps:

1.   Prepare.

2.   Categorize information systems.

3.   Select security controls.

4.   Implement security controls.

5.   Assess security controls.

6.   Authorize information systems.

7.   Monitor security controls.

Security categorization requires the information systems and associated information to be categorized based on an impact analysis. When selecting a set of security controls, you must take into account the security categorization as well as any previous assessments of risk. Following this step, you implement the security controls that were previously selected and then assess their effectiveness and the overall success of the controls in lowering the risk to the accepted level. Finally, the security controls need to be continually monitored so that you’re sure they continue to operate as intended. You also need to consider any changes that come into effect across the organization (think location, mission, security classification, or other underlying factors).

You will notice many additional concepts within NIST Special Publication 800-37 that are germane to the CRISC exam; for example, the early steps of the RMF discuss categorizing and selecting appropriate security controls (which we will discuss later in the book), while other steps correspond to the implementation, assessment, and continuous monitoring of controls (covered throughout this book). For these reasons alone, it’s a great idea to read this document to understand how the steps work together and how they are similar (and sometimes different) from other frameworks.

Three Lines of Defense

ISACA makes a distinction of three lines of defense in managing enterprise risk. These are operational management, risk management and compliance functions, and auditing and accountability. These lines are different events which are implemented at different levels of the organization, across business processes, as part of the wider enterprise risk management program. The personnel responsible for these three lines of defense are the risk owner, who is ultimately accountable and responsible for how risk is treated, and the risk practitioner, who is responsible for the day-to-day risk management functions.

Operational Management

Operational management refers to the tactical management activities that take place at the business unit or business process level. At this level, risk is managed on a day-to-day basis by monitoring control effectiveness as well as any risk associated with the business process itself or its supporting systems. This line of defense may be implemented by the risk practitioner, the business process owner, or even IT and cybersecurity personnel. This is the layer in which controls are operated as a part of business processes and often implemented as a part of information systems.

Risk and Compliance Management

This line of defense involves proactively monitoring and managing risk associated with IT support systems, security controls that are implemented to protect the systems, and risk associated with overall business processes. This is where the organization’s risk management program shines; implementing the activities associated with the risk governance framework is part of this critical line of defense. This includes overall risk assessment and analysis, risk response, and continuous risk monitoring.

Compliance management involves ensuring that the organization, its business processes, and the supporting IT systems comply with any governance requirements, whether they come from inside the organization or from external entities. Compliance directly leads to auditing processes and systems, discussed next.

While risk and compliance management are connected, they are separate and distinct entities. Risk can be variable in nature and changes over time, whereas compliance is typically a binary (yes/no, compliant/noncompliant) mentality. However, there is usually some overlap between these two areas, particularly in control assessments and risk analysis, as both risk management and compliance management often require control and risk assessments. Business process owners and senior managers, as well as senior risk practitioners, typically are involved with this line of defense.

Auditing and Accountability

In the world of risk management, auditing involves continuously monitoring risk levels to ensure they fall within acceptable levels of risk appetite and tolerance, as well as monitoring the controls, management processes, and responses that maintain acceptable risk levels. This could mean auditing at the process level (account management, for instance) or even at the overall organizational risk level, and every area of interest in between. Auditing ensures that processes and activities are being conducted in accordance with governance and serves to further ensure accountability.

While auditing and accountability are not exactly the same thing, they are complementary. Accountability, in terms of risk management, ensures that risk owners are both responsible and accountable for managing risk at an acceptable level within their area of responsibility. In short, accountability ensures they are doing their job. Accountability is connected to auditing in the respect that only through auditing processes and activities do we determine if those processes and activities are fulfilling the governance and risk management requirements that risk owners are responsible for meeting.

Risk Profile

A risk profile encompasses an overall asset, organization, or business process under review and includes detailed information on all aspects of those items and how they contribute to, mitigate, or influence risk. The risk profile for a system, for instance, would present detailed information on all the different characteristics of the system, its security controls, the risk assessment and analysis for the system, the risk responses for the system, and ongoing management for that risk. Risk profiles periodically change based on a variety of factors, including the criticality or sensitivity of the system, the vulnerabilities inherent to the system, the threats that may exploit those vulnerabilities, and the mitigating security controls that protect the system. Regulations and societal norms also influence risk profile, particularly in areas such as data privacy. The risk profile is used to actively manage ongoing risk and ensure that it remains within acceptable levels.

Risk Appetite and Risk Tolerance

As discussed previously, the culture of the organization really defines how the organization feels about risk and how it treats risk over time. Risk capacity is the amount of loss an organization can incur without seriously affecting its ability to continue as an organization. More resilient organizations can endure greater loss than those that aren’t as resilient. How resilient an organization is can sometimes be informed by its risk culture. As part of the organization’s risk culture, there are its risk appetite and risk tolerance. These are different terms you also need to know to understand risk. Risk appetite is, in effect, how much risk an organization is willing to deal with in any given endeavor. This is the general level of risk that an organization is willing to accept in the course of its business. An organization’s risk appetite is driven by the corporate risk culture and by the environment in which the organization exists (market, regulation, and other external factors).

Risk tolerance, on the other hand, is the acceptable level of deviation in risk for a particular endeavor or business pursuit. Risk tolerance is how much variation from the expected level of risk the organization is willing to put up with. There’s a certain amount of risk in every business enterprise or pursuit; however, the organization may not be able or willing to tolerate large deviations from what it considers its acceptable level of risk on an endeavor.

EXAM TIP   Know the differences between risk appetite and risk tolerance; risk appetite involves how much risk the organization is willing to endure, whereas risk tolerance is how much variation from that amount is acceptable to the business for a particular venture. Risk culture drives both of these factors.

Legal, Regulatory, and Contractual Requirements

Governance imposed by entities external to the organization usually takes the form of laws, regulations, professional standards and requirements, and so on. Often, it is simply enough for laws and regulations to be in place, or for a company to formally accept professional standards for these requirements to be imposed on an organization. Sometimes, however, governance is also imposed as part of contractual requirements between organizations. Including governance requirements in contracts, even if an organization would otherwise not be required to meet those requirements, makes them legally enforceable. In any event, organizations are required to fulfill their obligations imposed by these external governance sources.

Additionally, laws, regulations, and other governance sources often conflict with or even supplement each other. For example, one regulation may require a specific level of protection for sensitive data, and another law or regulation may require additional layers of protection based on the characteristics of the data, the organization, or the industry. For example, privacy data and healthcare data are often regulated by multiple sources of governance. In this event, the organization must implement internal policies and procedures to fulfill the requirements of all governance imposed on it. Even in the case of professional standards, such as those imposed by the Payment Card Industry Data Security Standard (PCI DSS), organizations must fulfill the requirements imposed on them if they have agreed to do so through contract or by virtue of their industry. In this example, organizations aren’t legally required to comply with this standard, but by virtue of the fact that they process credit card transactions, they are required by the credit card industry and can be censured or banned from processing transactions by the credit card companies if they do not comply with the requirements.

Compliance with legal and regulatory requirements is a critical factor in most organizations, and many of these requirements also impose risk management requirements as well, so risk management is often dictated, to a degree, by governance. In fact, many laws and regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), require a formalized risk management program. Risk governance frameworks, such as the NIST Risk Management Framework, also require formalized risk management. These frameworks can also be included in any other laws, regulations, contracts, or other governance requirements imposed on an organization.

Professional Ethics of Risk Management

Most organizations, particularly professional ones, have requirements for a code of conduct or professional ethics. This is especially true in the cybersecurity and risk management professions. These codes of ethics regulate the behavior of professionals and ensure that they maintain high standards of behavior. Most of the industry-recognized professional certifications also require adherence to a code of ethics, and ISACA is no exception.

ISACA’s Code of Professional Ethics can be found at https://www.isaca.org/credentialing/code-of-professional-ethics and is imposed on all organizational members and certification holders. ISACA also implements procedures for filing complaints against professionals bound to uphold those ethical standards in the event they fail to do so. The ISACA Code of Professional Ethics (paraphrased here) includes provisions for the following:

1.   Supporting and complying with standards and procedures for governance and management of information systems and technology

2.   Performing duties professionally, with due diligence and care, as required by professional standards

3.   Conducting activities in a lawful manner and maintaining the high standards of conduct and character required by the profession and ISACA

4.   Ensuring privacy and confidentiality of sensitive information obtained in the course of professional duties

5.   Maintaining competency in the professional field

6.   Full disclosure and impartiality regarding results of work performed to ensure that the results of that work are not distorted

7.   Supporting professional education in the areas of governance and management of enterprise information systems and technology, including auditing, controls, security, and risk management

Chapter Review

Organizational governance drives how an organization conducts itself within legal, regulatory, and even self-imposed constraints. Governance focuses on legal compliance, due diligence and care, and ethical behavior. This governance can come from both external and internal sources in the form of laws, regulations, professional standards, and internal policies and procedures. Risk management is often a requirement included in governance standards.

Quick Review

•   Governance guides the conduct of an organization in terms of legal and ethical behavior.

•   Governance can come from external and internal sources.

•   External governance is imposed through laws, regulations, professional standards, risk frameworks, and contract requirements.

•   Internal governance comes from internal policies and procedures.

•   The organization’s mission, goals, and objectives must include and support governance requirements.

•   Senior management defines risk appetite and tolerance for the organization.

•   Risk capacity is the amount of loss an organization can incur without its very existence being threatened.

•   Risk appetite is the amount of risk an organization is willing to take on in pursuit of its mission.

•   Risk tolerance is the level of variance from the appetite an organization is willing to permit for any particular business venture.

•   An organization’s mission, goals, and objectives are typically defined at the strategic or long-term level.

•   Organizational structure can affect an organization’s ability to deal with risk in terms of its risk culture, appetite, tolerance, and resilience.

•   Organizational business units, which consist of various business processes, must deal with both business and IT risk at the process level.

•   Business process risk contributes to the overall organizational risk and is managed at various levels, starting with the risk owner, who is responsible and accountable for risk management for a particular set of business processes or business units.

•   An enterprise risk management strategy and program must be in place to deal with lower-, middle-, and higher-tier risks. Risk governance drives the enterprise risk management program.

•   Organizational risk culture defines how an organization feels about and deals with risk and comes from the organization’s leadership and governance.

•   Organizational policies are internal governance that reflects the management philosophy, culture, and directives of senior leaders.

•   Policies are intended to articulate with external governance.

•   Organizational assets include anything of value to the organization, including physical equipment, facilities, human assets, and information.

•   Asset management is a collection of activities used to manage the inventory, classification, use, and disposal of assets.

•   The three lines of defense in managing enterprise risk are operational management, risk and compliance management, and auditing accountability.

•   The risk profile consists of detailed information on all aspects of an asset and how those aspects contribute to, mitigate, or influence risk.

•   The risk profile is used to manage risk for an asset.

•   Governance can be imposed by laws, regulations, and contracts, which are legally enforceable.

•   Codes of conduct and ethics dictate the behavior of risk management professionals.

Questions

1.   An organization is subject to healthcare regulations that govern the protection requirements of individual health data. Which of the following describes this type of governance?

A.   External

B.   Internal

C.   Regulatory

D.   Professional

2.   Your company handles credit card transaction processing as part of its business processes. Which of the following best describes the source and type of governance it may incur because of these business processes?

A.   Internal, policies and procedures

B.   External, industry standards

C.   External, laws and regulations

D.   Internal, industry standards

3.   Your organization is structured into various departments, and each of these has its own activities that support the mission, goals, and objectives of the organization. These activities are decomposed from a high level and include various tasks to support the various business units. Which the following best describes these activities?

A.   Operational management

B.   Organizational strategy

C.   Business processes

D.   Risk management functions

4.   An organizational culture that is averse to risk and change is more likely to have the following in terms of risk appetite and tolerance?

A.   High risk appetite, low risk tolerance

B.   Low risk appetite, high risk tolerance

C.   Low risk appetite, low risk tolerance

D.   High risk appetite, high risk tolerance

5.   Which of the following roles is the lowest level of responsibility in terms of risk ownership for a business process or unit?

A.   Organizational CEO or president

B.   VP for risk management

C.   Risk practitioner

D.   Business process owner

6.   Which of the following is the level of variation or deviance an organization is willing to accept for a particular business venture?

A.   Risk appetite

B.   Risk tolerance

C.   Risk acceptance

D.   Risk capacity

7.   A small business unit in the production department is incurring risk for one of its lower-level business processes. Although this risk is focused on the business process and not at the organizational level, it must be accounted for in the overall organizational risk assessment. At what level should this risk be considered?

A.   Organizational risk

B.   Operational risk

C.   Strategic risk

D.   Tactical risk

8.   An organization needs to create its internal risk management program and begins with risk governance. Which of the following should the organization create first?

A.   Risk strategy

B.   Risk management policy

C.   Risk assessment procedure

D.   Risk management methodology

9.   Which of the following describes why the organization exists?

A.   Organizational mission statement

B.   Organizational strategy

C.   External governance

D.   Organizational policy

10.   Which of the following activities is considered foundational, without which other management activities, such as vulnerability management, incident management, and data security, could not be accomplished?

A.   Configuration management

B.   Risk management

C.   Asset management

D.   Financial management

11.   Which of the following is not one of the three domains listed in ISACA’s Risk IT Framework?

A.   Risk Governance

B.   Risk Evaluation

C.   Risk Assessment

D.   Risk Response

12.   Which of the following requires that a risk practitioner perform duties professionally, with due diligence and care, as required by professional standards?

A.   Risk IT Framework

B.   NIST Risk Management Framework

C.   ISACA Code of Professional Ethics

D.   Laws and regulations

13.   A risk manager is analyzing a risk item and intends to recommend that risk acceptance be the recommended treatment. Which of the following must the risk manager consider to make this determination?

A.   Risk awareness

B.   Risk capacity

C.   Risk tolerance

D.   Risk appetite

14.   The organization’s legal counsel is considering the prospect of real estate prices, including office space leasing costs, increasing significantly in the next five years. What level of risk management should be used to manage this risk?

A.   Asset

B.   ERM

C.   Program

D.   Market

15.   All of the following are factors that influence an organization’s culture except which one?

A.   Published values

B.   Policies

C.   Leadership behavior

D.   Behavioral norms

Answers

1. A.   Laws and regulations are a form of external governance.

2. B.   This describes an external source of governance in the form of industry standards, specifically the Payment Card Industry Data Security Standard (PCI DSS).

3. C.   Business processes are the activities that support the organizational mission and can be broad or broken down into detailed activities and tasks.

4. C.   An organization that is risk averse likely has both a low risk appetite and low risk tolerance.

5. D.   Although various levels of organizational management may be responsible and accountable for risk, the lowest level of risk ownership for a business process or unit is the business process owner.

6. B.   Risk tolerance is the amount of variation or deviation an organization is willing to accept from its risk appetite that a particular business venture may incur.

7. D.   Tactical risks are those encountered by smaller production sections—those that carry out the day-to-day work of the organization. A lower-level business process may be considered to have a tactical risk.

8. A.   The risk strategy for the organization should be created first because it provides long-term direction for the risk management program. The risk management strategy also supports external governance. Policies and procedures are created afterward to support the strategy as well as implement external governance.

9. A.   The organizational mission statement is developed by the organization to describe its overall mission, which is its very reason for existence.

10. C.   Asset management is one of the foundational activities on which other activities depend (vulnerability management, configuration management, and so on) because assets must be inventoried and accounted for first.

11. C.   Risk Assessment is not one of the domains covered in the Risk IT Framework. The three domains are Risk Governance, Risk Evaluation, and Risk Response.

12. C.   The ISACA Code of Professional Ethics establishes requirements for ethical conduct and behavior that all certified professionals must adhere to, including the requirement to perform all duties professionally, with due diligence and care, as required by professional standards.

13. C.   Risk tolerance determines the amount of risk an organization will accept for any individual risk situation.

14. B.   A risk matter such as macroeconomic risk generally will be managed by an organization’s enterprise risk management (ERM) program.

15. B.   Of the available choices, an organization’s policies are the least likely to influence an organization’s culture.

CHAPTER 2

IT Risk Assessment

In this chapter, you will:

•   Understand the role of risk assessments and risk analysis in the risk management life cycle

•   Learn about the techniques used to identify various types of risks

•   Become familiar with risk identification and risk analysis techniques such as threat modeling, vulnerability analysis, control deficiency analysis, root cause analysis, and risk scenario development

•   Understand the concepts and steps taken in a risk assessment

•   Be familiar with the role and structure of a risk register

•   Understand the concepts of inherent risk and residual risk

This chapter covers Certified in Risk and Information Systems Control Domain 2, “IT Risk Assessment.” The domain represents 20 percent of the CRISC examination.

The CRISC Task Statements relevant to this domain address several key activities present in a risk management program, starting with conducting IT risk assessments and the impact of IT risks on the organization’s objectives or operations. These risk assessments should identify and evaluate threats, vulnerabilities, and risks, and they should be recorded in an IT risk register. In many organizations, the IT risk register would be integrated into an enterprise risk management program, if it exists. IT risk assessments should evaluate the existence and effectiveness of IT controls and identify the need for new or changed controls based on risk. This risk and control information should be reported to stakeholders to facilitate risk-driven decision-making, aligning with the organization’s established risk appetite and risk tolerance. IT risk personnel should periodically evaluate new and changing technologies for changes to risk. The risk management program should be aligned to industry frameworks and standards.

IT risk assessments are performed to identify risks associated with a specific scope of business operations or information technology in an organization. The purpose of identifying risks is the need for an organization to be aware of specific hazards that, if unchecked, could interrupt business operations and incur additional cost. Business executives and owners don’t want bad and unexpected things to happen; rather than stick their heads in the sand, it’s wiser to identify those risks and see what can be done about them. The alternative means flying blind and being unaware of risk scenarios, some of which may be highly likely to occur.

This chapter explores the broad picture of IT risk assessment, which is the search for—and identification of—various risks. We also explore the detailed view of risk analysis, which is the careful examination of individual risks, to better understand them in detail and explore various remedies. Conceptually, risk assessment and risk analysis are simple enough, but because there are so many ways in which risk assessments and risk analyses may occur, and many standards and techniques for each, all of this can become a clutter.

In our opinion, ISACA’s layout of this domain, IT Risk Assessment, isn’t quite right. Both the macro (risk assessment) and micro (risk analysis) are scattered throughout the two main parts of the domain. We will, however, stay true to the structure of the domain, like it or not, but we’ll be sure to clarify the context within risk management in each section.

IT risk assessments and risk analysis, covered in this chapter, are a part of the overall risk management life cycle, depicted in Figure 2-1. Risk governance, including risk profile, risk appetite, and risk tolerance, are covered in Chapter 1, while risk treatment, emerging risks, third-party risk management, controls, and risk reporting are covered in Chapter 3.

Figure 2-1 The components of risk management

IT Risk Identification

IT risk identification comprises the activities performed to identify various types of risks associated with an organization’s use of information technology. The types of IT risks that can be identified fall into these categories:

•   Strategic This category represents broad themes, including whether IT is aligned to the business and providing services required by the business, and whether IT can support and respond to changes in business strategy.

•   Operational This category represents many issues, including IT service management, service quality, production schedule, resilience, and tactical matters such as scheduling and availability.

•   Cybersecurity This represents issues related to the ability of internal and external threat actors to compromise information systems or the information stored in them.

•   Privacy This represents both cybersecurity-related risks as well as business practices related to the handling of personal information.

•   Supply chain This includes the availability of products such as laptops, servers, and components, plus services like tech support, and service providers, including SaaS, PaaS, and IaaS. Supply chain itself has both operational and cybersecurity-related risks.

•   Compliance This represents IT-related activities that an organization may be required to perform due to a regulation, policy, or contract terms.

Security professionals need to train themselves to recognize new risks. While at times they may be bold and obvious, sometimes they will be subtle and easily missed for what they are. Often, significant risks are identified when they are least expected. In many organizations, IT risks are not apparent until a threat event occurs. The activities that may lead to the realization of new risks include the following:

•   Audits An audit may identify a deficiency in a business process or system that warrants more than remediation-and-forget-it treatment. Often, this requires that a security analyst or risk manager study the audit deficiency to understand its root cause. Rather than think of the deficiency as a one-time (or repeated) mistake, perhaps the design of the control is the cause, or something even broader such as the overall design of a system or set of business processes. Where there’s smoke, there’s fire—sometimes.

•   Security and privacy incidents A security or privacy incident may reveal a latent problem that has been waiting to be discovered. The risk may not be directly related to the incident or its cause. It could be discovered by accident while an incident responder or security analyst investigates an incident more deeply.

•   Penetration tests While penetration tests can identify specific vulnerabilities, sometimes it’s essential to read between the lines and understand the overall theme or meaning of the penetration test results.

•   News and social media articles Information about breaches, cybercriminal organizations, new tools and innovations, and other cybersecurity topics can spur a risk manager to identify a risk inside their organization. We have all experienced this in our careers; an example that comes to mind is this: news of a critical website vulnerability at a competitor’s organization was widely reported. Our management contacted us to see whether we had the same or a similar exposure.

•   Security advisories Advisories on vulnerabilities and active attacks draw attention to specific actions and technologies. A formal cyberthreat intelligence or attack surface reduction program will subscribe to and consume all such advisories to determine whether the organization is vulnerable and then take action if needed. We consider these advisories to be more tactical than we would include in overall risk identification. However, sometimes an advisory will help us realize that something systemic isn’t quite right in our organization and that we want to capture that idea while it’s on our minds.

•   Networking Discussions about information technology, security, or privacy with professionals in other organizations can trigger the realization of a risk in one’s own organization. We do caution you on this point: a risk in one organization, even when similar practices or technologies are in play, does not necessarily mean that another organization has the same risk.

•   Whistleblowers A disgruntled or concerned employee may choose to remain anonymous and disclose information about a condition or practice that may represent a genuine risk to the organization.

•   Passive observation During the course of work, a risk manager or other cybersecurity staff may realize a heretofore undiscovered risk. Sometimes a risk can lie before us for an extended period of time until some conversation or thought triggers a new realization.

•   Threat modeling This is a particular type of risk assessment, typically focused on an individual information system or business process, to identify likely threat scenarios.

•   Secure configuration assessments Configurations that are insecure or out of compliance can be a source of critical risks. This can be out of compliance with configuration baselines like the Center for Internet Security. Others can be basic settings such as password strength or length.

•   Governance assessments Governance can be a huge impact on how well the process runs. For example, if there are not status checks on systems, the systems may not be configured properly, thus increasing the risk to the organization.

•   Data governance risks For some organizations, how data is used or shared can be very risky. For example, if a contract explicitly forbids the sharing of data, but data is being shared anyway, there can be legal repercussions. Reviewing the data governance process is an important part of protecting the data.

•   Privacy assessments For some companies, privacy is becoming a greater concern due to enhanced regulation. Not being aware of the laws can have a huge impact on the privacy of data and can lead to fines and lawsuits.

•   Risk-aware culture The extent to which leaders, management, and staff in an organization are trained to recognize risk will result in better outcomes, including more effective security and privacy by design, and a willingness to accept that risks are always present and can be managed. Security awareness training should include risk awareness.

•   Risk assessments This is the wide gate through which many risks will be identified and analyzed. We’re putting this last on the list for a few reasons: risk assessments generally have a specified scope and are aligned to a specific framework of controls, so risk analysts are, by design, looking only for particular types of risks in specific places. These blinders can sometimes prevent someone from seeing certain types of risks, or risks in specific contexts or places.

Our hope here is that you will realize the discovery of risk can occur in many ways. The best tool the risk manager can obtain is an open mind, which is free to explore the possibilities of IT risk in the organization.

NOTE   The context of IT risks includes on-premises and cloud and service-provider uses of information technology.

Brainstorming and Risk Identification

Brainstorming some concept or idea in front of a whiteboard with other colleagues is one of our favorite activities (and one that we miss—we write this during the COVID-19 pandemic in which most office workers are isolated in their homes). In a brainstorming session, participants each have whiteboard pens and write down ideas that come to mind on some specific topic. Alternatively, one person writes down ideas spoken by others in the room.

The rule of brainstorming is this: silly ideas are not to be rejected, because that silly idea could lead to a great idea. For example, office workers are brainstorming ideas on what color to paint the office. Let’s join the discussion.

“White.”

“Light brown.”

“Light gray.”

“Plaid.”

Wait a minute. Plaid isn’t a color. But they write it down anyway. This prompts another to say, “Let’s paint it two colors: white on interior walls to reflect light, and light gray on other walls.”

Rejecting “plaid” might not have led the team to the solution they ultimately chose, which was a bit different from what they all expected: a single color.

Thought and discussions about risk are no different. Dare to think outside the box and consider other ideas, which could lead you to new discoveries.

Risk Events

Risk events are the specific scenarios that, if they occurred, would inflict some impact on an organization’s ongoing operations. A risk event includes a description of one or more threat scenarios, the identification of the types of threat actors, statements of vulnerabilities that could enable a threat scenario to occur, the value of relevant assets, and the probability of occurrence.

The Vocabulary of Risk

Every profession has its own lexicon—big words that represent complex topics. We aren’t experts in every field, so for each of us, sometimes we overhear conversations on some professional topic that are sprinkled with words whose meaning we may not fully comprehend. Our profession, cybersecurity risk management, is no different in this regard. Those of us in the industry occasionally hear “lay” persons misuse these words. For example, we may overhear someone in IT say, “That missing patch is a serious threat.” A risk manager might hear that and think to themselves, that person is using the term threat incorrectly. However, we should not fault them for trying.

Here are the primary terms in the profession:

•   Asset A tangible or intangible possession, such as a server, device, program, database, other data, intellectual property, or equipment.

•   Vulnerability A specific weakness in a system, process, or person that could fail to prevent some unwanted event. An example of a vulnerability is an easily picked lock on a door.

•   Threat An event, should it occur, that would bring harm to some asset. An example of a threat is a person who wants to break into a building and has lock-picking tools in their possession (and the skills to use them).

•   Impact The result on an organization should a threat occur.

•   Attack An offensive action that results in potential harm to an asset.

•   Risk The possibility and impact of harm that could occur to an asset, based on the asset’s value, and any related vulnerabilities and threats.

Here are some additional terms that are often used:

•   Threat actor The person or thing that would carry out a threat if they chose to. Examples of threat actors include a lone hacker and a military-based cyberhacking unit.

•   Threat realization A threat that is carried out and causes some harm to an asset.

•   Threat modeling A specific type of analysis performed to better understand likely attack scenarios.

•   Event A more common term that is synonymous with threat realization.

•   Exploit (noun) A specific tool or method that can be used to carry out a threat.

•   Exploit (verb) The act of attacking an asset, made easier by the presence of a vulnerability.

•   Inherent risk The risk associated with a specific type of activity, before controls are considered.

•   Probability (also known as likelihood) The chance that a specific threat event would occur, generally within a period such as one year.

•   Residual risk The risk that remains after any risk reduction has been applied.

•   Risk register A listing of risks that have been identified.

•   Risk analysis The examination of one or more specific risks.

•   Risk assessment An examination of a process or system to identify and describe one or more risks.

•   Risk treatment A decision made about potential action to be taken concerning a specific risk.

•   Risk management The life-cycle process that includes risk assessments, risk analysis, and risk treatment.

These are just the basic terms used in risk management, defined briefly here. These terms, and several others, are explained in detail throughout this chapter. Figure 2-2 depicts threat agent, threat, vulnerability, impact, and risk concepts.

Figure 2-2 Threats, vulnerabilities, likelihood, and impact

Here are some statements you might overhear in a conversation with IT risk managers:

•   “A threat actor could exploit that vulnerability on Internet-facing assets, resulting in a serious incident.”

•   “Threat modeling revealed additional vulnerabilities in the new system.”

•   “The risk assessment identified new risks that have been entered into the risk register.”

Types of Risk Events

Several types of risk events can occur that are related to an organization’s uses of information technology. The potential range of risk events includes scenarios such as the following:

•   Breaches

•   Equipment failure

•   Extortion

•   Natural disasters

•   Fires and floods

•   Sabotage

•   Intrusion, data theft, and ransomware

•   New regulations

•   Regulatory fines

•   Staff turnover

•   Supplier shortages

•   Strikes, riots, and demonstrations

•   Terrorist attacks and acts of war

Threat Modeling and Threat Landscape

A common approach to assessing risk is the consideration of the universe of relevant threats that are reasonably likely to occur. Such an occurrence may compromise information or information systems, thus impacting business processes. Threat assessments and threat modeling are the primary activities used to identify relevant threats and how they may harm systems or processes.

Threat Modeling

Threat modeling is a risk identification technique that involves examining every possible threat agent, action or event, attack vector, and vulnerability for a given system, asset, or process, and then modeling or simulating how it could progress and the damage that could occur. Threat modeling has its origins in the U.S. and U.K. defense industries. A threat assessment examines how these threats could affect the particular asset, organization, or system you are looking at, in context, and it can be done on one of several levels, either simultaneously or separately. For example, you could perform a threat assessment on a new system being developed or installed. You would examine the different threat agents and threats that could affect that particular system. You could also look at an organizational process, or even the entire organization itself, and perform a comprehensive threat assessment. In addition to scaling a threat assessment, as we just described, you could look at threats from a particular perspective, performing a threat assessment specifically for technical threats, physical ones, or even external operating environment threats. This relates to the scope of the assessment. For example, you could look at the technical aspects of a given system or examine threats inherent to the processes and procedures associated with a particular business unit. Figure 2-3 shows this scoping and scaling process.

Figure 2-3 Scoping and scaling a threat assessment

As this figure illustrates, you could scale an assessment to include only specific systems within some functional regions. You could scope it by examining not only all the threats that apply to the technical aspects of systems in those particular functional areas but also threats that affect associated business or management processes. You could have any combination of scope and scale that the organization needs to fulfill its assessment goals.

Threat landscape is a term that connotates a visual metaphor for considering all the threats that have been examined and identified as relevant to a given system or process. A risk manager could be overheard as saying, “The threat landscape for our online commerce system is particularly hostile,” meaning there are many significant threats that need to be considered as controls and defenses are designed.

Table 2-1 illustrates how threat agents and threats could be categorized, given factors such as intent, relationships, skills, and so on. Note that these could affect any number or combination of elements (processes, systems, and so on) within an organization. You could categorize threats and threat agents using these characteristics and develop others that frame and define threats and threat agents for your organization.

Table 2-1 Characteristics of Threat Agents

Note that this information is only a sampling of what you may come up with in a threat assessment. You may also break down some of these elements into far more specific ones, based on your needs and the organization and systems you are focused on. For example, a defense contractor or military organization would likely have a more specific set of threats and agents in its assessment than a nonprofit, charitable organization.

NOTE   Appendixes D and E in National Institute of Standards and Technology (NIST) Special Publication 800-30, “Guide for Conducting Risk Assessments,” offer a more comprehensive list of threat agents and their related threats.

Threat modeling is sometimes easier when preceded by a vulnerability assessment. You may wish to perform a threat assessment to determine what threats and threat agents exist to exploit those vulnerabilities. These threats can be internal or external, human-made, or natural, and they should match up with a discovered vulnerability. To complete the development of a given risk scenario, you should also consider the time and location characteristics of a potential scenario. Remember that you are developing scenarios down to the most practical level of detail possible; you will have developed many different possible scenarios for an asset, each covering a particular threat–vulnerability pairing by the time you are done. You should then look at the existing controls you have in place to determine how effective they are in protecting an asset.

Organizations considering adopting new technology should include threat modeling in their analysis as a part of an evaluation. Threat modeling will give the organization a glimpse into the scenarios that could occur if proper safeguards and controls were not implemented.

TIP   Threat and vulnerability assessments are discussed a great deal in this chapter. These two assessment processes are critical to understanding the elements that formulate the risk for an asset.

Vulnerability and Control Deficiency Analysis

Vulnerability and control deficiency analysis are important parts of risk analysis. These focus on the weaknesses in a system or process that could result in a potentially serious incident if exploited by a threat actor. The basic question that a risk analyst would ask about a given asset is, “What weakness in this system or process could be exploited by a threat actor in a successful attack?”

When stated this way, a risk analyst might think only of human-initiated incidents and overlook a broad class of vulnerabilities that are not associated with a human threat actor. Examples of non-human-initiated threats include the following:

•   Lack of off-site backup media that makes disaster recovery difficult in the case of a fire or flood that damages on-site systems and backup media.

•   Excessive current load on power supply circuits that could result in overtemperature or power failure.

Vulnerability Analysis

Vulnerability analysis is a detailed examination of vulnerabilities that may exist or vulnerabilities that have been determined to exist. A vulnerability assessment can give you information about the weaknesses inherent to one or more assets. The vulnerability assessment might include examining all aspects of an asset or capability to determine any vulnerability it has, including the physical, technical, and operational vulnerabilities inherent to the asset. For example, technical vulnerabilities can be related to configuration issues or lack of hardening on a network device. Physical vulnerabilities could relate to the lack of physical protection for the network device. Operational vulnerabilities might include the lack of backup processes or configuration control exercised for the device.

Control Deficiency Analysis

In this section, we will discuss control analysis in detail. It’s essential to understand how controls fit into the overall risk analysis process; you perform a control analysis before determining risk since existing controls that are already in place may be effective to varying degrees in mitigating risk. Simply examining threats, vulnerabilities, assets, impact, and likelihood without considering existing controls and protections in place doesn’t do justice to the risk analysis process. Not accounting for existing controls would dramatically skew risk assessments and render an unrealistic risk determination. The goal here is to examine existing controls, determine how effective they are, and use that determination in analyzing the impact to assets if threats exploit vulnerabilities and the likelihood of that exploitation. Typically, results of your documentation, observation, interviews, and testing will likely also be part of your control analysis. We’ll look at different aspects of control analysis in the following sections. You’ll also receive some more in-depth information on controls in Chapter 3, focusing on various aspects of how they are designed, implemented, and used to respond to risk.

Evaluating Existing Control Effectiveness

As we stated earlier, risk analysis often involves evaluating the effectiveness of existing controls. This is because risk doesn’t exist in a vacuum filled with only threats, vulnerabilities, and assets. Almost all assets have controls that serve to protect them from harm. These controls may or may not be sufficient to protect against particular threats. In some cases, however, a control may be implemented that significantly lowers the risk to an asset by decreasing the likelihood of a threat exploiting a vulnerability or by protecting the asset sufficiently enough to reduce the impact in the event a threat is realized. This is part of the risk assessment and analysis process, which involves identifying and prioritizing assets, performing threat and vulnerability assessments, and determining what controls exist and how effective they are in protecting against identified risks.

Controls fall into broad categories: administrative, technical, and physical or operational. Controls can also be categorized based on function, classifying them as preventive, detective, and deterrent. When identifying controls that apply to a given resource, process, asset, or system, you should look at all these different categories to determine what controls exist. Administrative controls will be in the form of policies or procedures and can protect an asset by detailing requirements that users must abide by. Technical controls can protect assets by providing logical protections, including strong authentication, restrictive permissions, and other access controls. Physical and operational controls can provide asset protection in the form of operational procedures and physical barriers, which separate unauthorized persons from the asset and prevent them from physically accessing the asset. Consider all these different categories of controls when attempting to identify any controls that may be protecting assets.

Once you have identified all the different controls protecting a given asset, you should determine what functions they are required to serve and how well they’re performing those functions. Controls are designed to perform different functions (in some cases, only one function, but often many functions). Economy of use is a critical aspect of applying controls to assets; organizations that can use fewer controls to cover more security functions can reduce costs and more effectively use the resources they have.

Just as threats and vulnerabilities are often paired together, controls are often identified to counter specific threats or vulnerabilities. While we discuss the value of performing threat and vulnerability assessments, seemingly as different activities, often they are conducted simultaneously, along with control analysis, to get a better idea of how these three elements balance with each other. Threats exploit vulnerabilities; however, controls can reduce the likelihood or impact of threat realization and mitigate the weaknesses that vulnerabilities provide. So, there is a relationship among these three elements, making it valuable to sometimes look at all three of them simultaneously in a concerted effort.

In assessing control effectiveness, you should examine how well a particular control protects against a given threat or reduces a specific vulnerability. This can be a subjective process, but can be more objective if performed as part of an in-depth penetration test (discussed later in this chapter in the section, “Risk Assessment Concepts, Standards, and Frameworks”). For example, a threat assessment may give you only the potential threat events that could affect a given asset, and a vulnerability assessment may tell you only what potential vulnerabilities exist on the system. Neither tells you how effective a control may be in reducing the effects of the threat or vulnerability unless you attempt to exploit the vulnerability during penetration testing. However, by also understanding the Common Vulnerability Scoring System (CVSS) score associated with a vulnerability, you can better understand the effort required to perform an attack, and the potential harm that can result from an attack. Only then will you truly know how effective the control is; if a given vulnerability isn’t easily exploitable, then, realistically, the control may be more effective than a cursory review would indicate. Likewise, a penetration test may indicate that a control is not as effective as you might have thought initially. Vulnerability assessments describe theoretical weaknesses, whereas penetration tests attempt to exploit vulnerabilities and give more realistic estimates of how effective controls are.

When evaluating controls as part of a risk analysis, you may report them as ineffective, partially effective, or effective in reducing impact or likelihood. You also might use a semiquantitative scale that indicates control effectiveness from a range of numerical values. Each of the various control frameworks often provides guidance on assessing the effectiveness of the controls in that particular framework. For example, the catalog of controls found in NIST Special Publication 800-53, “Security and Privacy Controls for Federal Information Systems and Organizations,” is supplemented by an assessment methodology found in its companion volume, Special Publication 800-53A, “Assessing Security and Privacy Controls in Federal Information Systems and Organizations,” which describes how to assess and report the effectiveness of each control. Figure 2-4 shows an example of an NIST control from SP 800-53 R5, and Figure 2-5 shows the corresponding assessment guidance for the same control in SP 800-53A R5.

Figure 2-4 The AC-5 control from NIST SP 800-53 R5

Figure 2-5 Assessing the AC-5 control, from NIST SP 800-53A R5

EXAM TIP   Control analysis includes identifying controls, determining their required function, determining whether they are effective in meeting that function, and identifying gaps between the desired and end states of how well controls protect assets.

Control Gaps

A control gap is a situation where controls either do not exist or are not sufficient to provide adequate protection for an asset to reduce either impact or likelihood (and thereby risk) to an acceptable level. In this situation, after the lack of existence or effectiveness of the control is established, the organization must remediate the problem. We won’t go into much depth on remediation here; that’s the subject of the Risk Response and Reporting domain, which you’ll read about in Chapter 3. However, during your analysis, you must identify control gaps and make recommendations for possible response options that would close those gaps. You may identify gaps in physical, technical, or administrative controls, even when other types of controls perform some security and protection functions. For example, suppose an organization implements account management processes, such as creating accounts in a standardized fashion, verifying identities before user accounts are created, and so on. In that case, the organization has operational and technical controls in place that help provide secure account management. However, if the organization has no written policy that requires this process and dictates that it be performed consistently, how can the organization be assured that these procedures will always be followed uniformly and in a secure manner? If there is no policy, the organization leaves it up to individual account operators to perform this function as they want, regardless of how “most people do it.” In this case, a control gap would be that, although the organization is applying some level of control over this process, there is no written policy ensuring that it is standardized.

Control Recommendations

Once you’ve identified existing controls, determined how effective they are, and identified gaps between the current and desired end states of controls, you should be able to make sound, risk-based recommendations to senior managers on how controls should be supplemented, added, or changed. Recommending controls is a risk-based process; remember that there is a risk that you are trying to minimize, but you must balance this between control functionality and economy of resources. You have several considerations to keep in mind when making control recommendations:

•   What more could be done to supplement or change existing controls to close the gap between current and desired end states of risk?

•   Should new or different controls be applied to replace existing ones?

•   What are the costs involved in applying additional controls, and do they exceed the value of the asset or the costs to replace it?

•   Would additional controls require retooling or significantly changing the infrastructure, processes, or asset itself?

•   Would additional controls require new personnel or training for current personnel?

•   Can additional controls be implemented that also reduce risks in other areas (economy of use)?

The answers to these questions, at least some of them, will determine how you make the recommendations to management about closing the “control gap.” Both the cost of implementation and the return on investment (ROI) received from implementing new controls or strengthening existing ones will affect management’s acceptance of the recommendations. The asset value, or impact if it were significantly damaged or lost, will also affect how well the recommendation is received. Implementing a costly control to protect an asset worth less in terms of impact is not usually an economically sound decision. Organizational levels of risk appetite and tolerance will also affect control recommendations since any new or additional control must reduce risk enough to fall within those levels. In general, when recommending ways to close the control gap, whether it is by introducing new controls, modifying existing ones, or modifying the infrastructure to reduce likelihood or impact, you should do the following:

•   Try to leverage existing controls that can be used across the board to include additional assets.

•   Look for “quick wins” first—controls that are quickly and inexpensively implemented (such as policies, training, procedure changes, and so on).

•   Prioritize control recommendations with risk; the greater the risk, the more attention to those particular control gaps.

•   Be realistic in your recommendations: You can’t reduce risk to absolute zero, you don’t have all the resources you would like at your disposal, and you don’t have to offer a 100 percent solution. Sometimes a 70 percent solution is better than a 0 percent solution.

•   Provide alternatives to your primary recommendation for each control gap. Give management alternatives based on cost, level of risk reduction, and effectiveness.

Considering Risk and Control Ownership

Risk and control ownership are issues that must be considered during a risk analysis. Depending on how the organization is structured and the risk management strategy, risk ownership may be assigned to one or several different managers, spanning multiple functional areas. This is because the risk that affects one area likely affects other areas, so many different people may have responsibility for affected areas and be required to deal with and respond to risk. Control ownership should also be examined; often, controls that provide protections for a given asset or many systems may not fall under the operational purview of the risk owner. Some controls span the entire organization and protect multiple assets rather than only a specific system. These are referred to as common controls, and the responsible entity for these controls is the common controls provider. For example, consider physical security controls. There may be a physical security officer for the organization that oversees guards, personnel security, and access to secured areas. They may also be responsible for locks, closed-circuit televisions (CCTVs), and physical intrusion detection systems and alarms. These controls serve to protect information systems and data assets that might be in a secure data center. Risks may be presented to the person who is responsible for information systems in the data center. However, the controls that serve to protect them may belong to the physical security functional area. This will require some coordination between the different functional areas if controls managed by one functional area are insufficient to protect assets managed by another area. This may also affect organizational structures, budgets, and resource allocations.

CAUTION   Risk, asset, and control owners are not always the same person, functional area, department, or organization. It’s essential that you identify these particular owners early in the assessment process and maintain careful coordination and communication between these and other relevant stakeholders within the boundaries of your authority and assessment scope. Different types of owners can result in politically sensitive issues that revolve around resourcing, responsibility, accountability, and, sometimes, blame.

Root Cause Analysis

Root cause analysis, or RCA, is a method of problem-solving that seeks to identify the root cause of an event, situation, or problem. Often, when an event that disrupts business operations occurs, an organization wants to perform an RCA to determine what happened, why it occurred, and what changes can be made to help prevent a recurrence of the incident.

An example of RCA that is often the subject of publicity is the analysis of an airplane crash. Here, investigators carefully attempt to reconstruct the crash to determine the ultimate cause, whether it was the failure of a component, pilot error, or something else. In cybersecurity, an organization besieged by ransomware will perform an RCA to determine how and where the attack originated.

Here are the steps in a typical root cause analysis:

1.   Identification The RCA begins with a concise description of the incident or situation being analyzed. This is the starting point in an RCA.

2.   Chronology Using available event data, analysis of the incident or situation includes a detailed look at how the incident or situation unfolded.

3.   Differentiation Here, an investigator identifies all the details related to the event or situation to determine which details are causal (contributed to the event or situation) and which are non-causal (did not contribute to the event or situation). Investigators realize that many events have more than one causal factor.

4.   Causal analysis Each detail or factor is analyzed to determine the degree to which it contributed to the incident or situation. This often leads to the identification of the one causal factor, the root cause, that represents the initiation of the events that led to the incident being investigated.

5.   Identification of corrective actions For each causal action that contributed to the incident or situation, the RCA will identify corrective actions that would reduce the probability or impact of a similar incident in the future.

A simplistic approach to RCA is known as the five whys. This is an iterative technique in which the analyst looks at the incident or situation (or a causal factor) and asks, why did that occur? In the following example, a ransomware attack encrypted numerous files on a file server:

1.   First track: Focus on the end user’s PC.

•   Why? Ransomware successfully implanted itself on an end user’s PC.

•   Why? The PC’s antivirus was not up to date.

•   Why? The PC was on a new network segment not monitored by the antivirus server.

•   Why? Network engineers did not inform IT security of the new network segment (a causal factor).

2.   Second track: Focus on the file server.

•   Why? The end user had global write permissions on the file server.

•   Why? It is a standard practice to grant global write access to end users, which reduces the number of access requests (a causal factor).

•   Why? There are not enough service desk technicians to fulfill access requests in a more restrictive environment (a causal factor).

3.   Third track: Focus on the end user.

•   Why? The end user opened an attachment containing malware in an e-mail message.

•   Why? The end user believed that the e-mail was sent from an executive in the company.

•   Why? The end user did not recognize the indicators of a phishing message.

•   Why? The end user did not attend security awareness training.

•   Why? Security awareness training is not required (a causal factor).

•   Why? Company executives do not believe that employees should be required to spend time away from their duties in training.

In this situation, three broad root causes were identified: first, the end user’s PC was on a network not being monitored by central antivirus software because of a communication breakdown; second, the end user had excessive permissions on the file server because of a practice of loose permissions; third, end users are not required to attend security awareness training. Corrective actions will likely be recommended for all three tracks.

Risk Scenario Development

A risk scenario is a business-impacting event that consists of a threat, threat actor, vulnerability, and asset. You could say that a risk scenario is a statement about a hypothetical risk event that could reasonably occur, based on known facts about threats, threat actors, and an asset’s vulnerabilities. Such a description of a risk event can help risk managers and business executives better understand what would otherwise be an abstract concept.

Risk scenario development is performed during a risk assessment after assets, threats, and vulnerabilities have been tabulated. Risk scenarios are the potential real-world events identified in risk assessment data that communicate the risks that have a tangible impact on business operations.

Risk managers can approach scenario development from two perspectives: top-down and bottom-up. Both are explained here.

NOTE   Threat actors are not only human entities but also events such as natural disasters.

Top-Down Risk Scenario Development

Top-down risk scenario development associates risks with business goals and objectives. The purpose of top-down risk scenario development is to identify scenarios that, if realized, would adversely impact those business goals and objectives. Similarly, top-down risk scenario development can associate risks with key business assets. Again, top-down risk scenarios would be related to those assets. Figure 2-6 depicts the extraction of top-down risk scenarios from risk assessment results.

Figure 2-6 Extracting top-down risk scenarios from a risk assessment

Risk assessment and risk analysis are logical, analytical activities. Risk scenario development, on the other hand, particularly top-down risk scenario development, is by far an intuitive, creative activity. In pop culture, one would associate risk assessment and analysis as left-brain activity, with top-down risk scenario development as right-brain activity.

The primary benefit of using top-down risk scenarios is the ability to communicate risks more clearly to executive management. As the developers and promoters of corporate goals and objectives, senior executives should understand the various types of IT risks that could threaten to delay or increase the effort or cost required to achieve them.

Risk managers should look to outside sources to identify realistic risk scenarios. Trade journals and even mainstream media report on cybersecurity and other disruptive IT-related events. Developing a more compelling narrative than “this scenario happened to them, and it could also happen to us” can be difficult.

Bottom-Up Risk Scenario Development

Bottom-up risk scenario development focuses on specific assets (or groups of assets) or threats. Bottom-up risk scenarios are more technical than top-down scenarios and less likely to be conveyed to executive management. However, this technique can help risk managers better understand the scope and nature of various types of risks. Ultimately this may help risk managers refine their top-down risk scenario development by giving them additional information about the universe of risks they are dealing with.

Risk Scenario Development Considerations

Risk scenario development is vital in risk analysis and management, where risks that may initially be abstract are refined and translated into tangible statements of risks to business operations. Absent this transformation, risk scenarios will be little more than an intellectual exercise.

To be successful, risk managers need to ensure that the risk scenarios are:

•   Relevant to the business Risk scenarios should indicate specific relevance and impact to the organization instead of being generic.

•   Kept current An organization’s use of technology (at both the macro and micro levels) changes over time, meaning risks will vary in magnitude.

•   Communicated to management with a purpose Often, risk scenarios are the way that new risks are shared with management to proceed to risk treatment—that is, to make decisions about what to do about new risks. This is often the only time that management is informed of risks.

IT Risk Analysis and Evaluation

After a risk has been identified (which is covered in the first part of this chapter), it can next be examined. Risk analysis is the detailed examination of a risk to better understand basic factors, including the likelihood and impact of risk occurrence and the development of a measure that might be enacted to reduce probability or impact. Risk analysis helps determine the overall level of risk for a particular system, an asset, business process, or even the entire organization. Part of risk analysis involves discussions of findings with risk and control owners, as well as senior managers in the organization. During these discussions, you may discover other factors that influence the likelihood and impact levels or even affect threats, vulnerabilities, and assets. You’ll also look at the existing controls and determine how effective they are in meeting risk, as well as look at recommended additional controls. Finally, you will report risk analysis results to senior managers and generate a risk report after this process is complete. We’ll discuss these topics in more detail in this section. Figure 2-7 shows a familiar variation of the 5×5 likelihood and impact table, demonstrating how different levels of likelihood and impact are evaluated together to produce a qualitative risk level.

Figure 2-7 Likelihood and impact are evaluated together to produce a risk level.

Risk Assessment Concepts, Standards, and Frameworks

Risk assessments are performed to identify, understand, and enable organizations to make intentional decisions about individual risks. There is considerable detail within the workings of risk assessments, as discussed in this section.

Many of the terms you’ll encounter on the CRISC exam are generic and may have different definitions based on the different frameworks or standards you are using in practice. The term assessment is one such term that may confuse you. For the purposes of taking the exam, and in this book, an assessment refers to the overall combination of steps of identifying, evaluating, and analyzing risk. Remember that risk identification involves identifying the threats, vulnerabilities, assets, and existing controls. On the other hand, evaluation focuses on determining the likelihood and impact if the vulnerabilities are exploited by the threats, resulting in damage to the asset. Risk analysis puts everything together, informs the organization about the risk involved, and helps determine how effective existing controls are and the gaps between current and desired risk states.

Risk assessment processes sometimes include the risk identification piece of the process but are often separate from this part, depending on the framework or standard you are using. In general, this process includes threat source and event identification, vulnerability identification, control analysis, likelihood determination, impact analysis, risk determination, control recommendations, and results documentation; these steps follow the same pattern and path as we’re describing here for you in terms of identifying risk and then evaluating it. We’ll describe some of these generic processes here in this chapter.

NOTE   Different risk analysis methodologies and frameworks use varying terms with the same or different definitions. You should always look at a term given its context and particular framework or methodology.

Types of Assessments

Several types of assessments can be performed to determine the presence of risks, threats, or vulnerabilities in a system or process. Some of the techniques discussed here involve different ways of thinking about risk, while others employ manual or automated tools to examine information of some type.

•   Risk assessment An assessment technique used to identify and classify various risks associated with systems or processes.

•   Gap assessment An assessment of processes and/or systems to determine their compliance to policies, standards, or requirements.

•   Threat modeling Also known as a threat assessment, this is a threat-centric technique used to identify specific threat scenarios that may occur. Threat modeling is discussed in more detail earlier in this chapter.

•   Vulnerability assessment An assessment used to identify specific vulnerabilities that may be present in processes and/or systems.

•   Maturity assessment An assessment of processes or capabilities to determine their maturity, generally according to a maturity standard such as the capability maturity model integration (CMMI) or the NIST cybersecurity framework (CSF).

•   Penetration test This is an examination of systems, networks, or applications that identifies exploitable vulnerabilities. Tools used in a penetration test include port scanners, sniffers, protocol analyzers, fuzzers, password crackers, and specialized tools to identify specific vulnerabilities. A penetration test not only identifies but also validates a vulnerability by exploiting it—or demonstrating how it can be exploited if actual exploitation would bring harm to the asset (important when pen testing a production system).

•   Data discovery A manual or automated activity in which tools or techniques are used to examine the contents of a target system to determine the presence of specific types of data. Data discovery may also involve an examination of access rights to specific types of data.

•   Architecture and design review A manual activity in which the architecture or design of a process or system is examined to identify potential weaknesses.

•   Code review A manual activity in which software source code is examined for logic errors and security vulnerabilities.

•   Code scan An automated activity in which a code-scanning program or tool examines software source code to identify vulnerabilities and other defects.

•   Audit A formal inspection of a control or process to determine whether it is being followed and meets its objectives. Audits are discussed briefly in this book and fully in CISA Certified Information Systems Auditor All-In-One Exam Guide.

Scope of an Assessment

Before an assessment can begin, its scope needs to be determined. By this, we mean that the systems, processes, locations, teams, and/or time periods that are the focus of the assessment need to be formally established and communicated.

The opposing forces that influence scope are the desire to make it large enough to identify hard-to-find risks, but small enough to be efficient and complete in a reasonable period. A balance must be reached that enables the assessment to succeed.

Collecting Data for an Assessment

One of the challenges for a risk assessor is collecting and managing all the data for an assessment. On one end of the spectrum, the assessor may find it challenging to get the bare minimum of relevant data for a particular asset, including threats and threat actors, and vulnerabilities, as well as protective controls. On the other end of that same spectrum, the assessor may gather so much data that it is overwhelming to analyze and gauge its relevance to the assessment effort.

Another challenge is the source of the data. While the best data comes from authoritative sources with expertise in various areas, such as the asset or system in question, current threats, and so on, the assessor must be able to separate fact from opinion and collect truly objective data versus subjective data. Objective data is evidence that supports an assertion about an asset or risk that can be proven or verified through independent means. Subjective data, on the other hand, is data whose validity is subject to opinion. For example, auditing typically produces objective data in the form of audit logs (assuming they are secured) that detail events that occur on a system and trace those events back to individuals, thus ensuring accountability. Events in question can be verified through the audit logs. However, system administrators who assert that they regularly audit system activities but have no audit logs to prove this can’t have their claims verified. Additionally, if no policies or procedures require auditing or show how to perform those tasks, these events can’t be independently verified either.

Data can come in various forms, including performance data, statistical analysis, historical data, trends, and narrative form. The assessor should establish the relevance of data as it is collected and determine how it relates to relevant risk questions concerning threats, vulnerabilities, likelihood, impact, assets, and controls. Overwhelming amounts of data can be reduced to relevant summaries and analyzed, sometimes in aggregate, using various automated statistical analysis and database tools.

Data collection typically uses a combination of four methods designed to gather various types of qualitative and quantitative data from different sources. These collection methods complement and support one another, filling in gaps from one method and verifying information collected from another. The four main data collection methods are conducting interviews, reviewing documentation, observing systems and assets in operation, and performing technical testing on assets. They are described in more detail in the following sections.

Conducting Interviews One of the best methods to start collecting data involves interviewing key personnel, such as asset owners, system administrators, security personnel, and other people with direct knowledge of essential aspects of the asset, relevant threats and vulnerabilities, and controls. These interviews are known as walkthroughs. Interviews should be scheduled with key personnel and consist of relevant questions that answer questions relating to security posture, processes and procedures, asset characteristics, and implemented security controls. The assessor should carefully record the results of the walkthrough through concise meeting notes or recording devices for later reference. Keep in mind that while interview data should usually be considered subjective in nature, it can be used as a starting point to gather knowledge and facts about a system that can be later verified using other means, such as documentation, system observation, and testing.

Reviewing Documentation Documentation is a mainstay of a risk assessment. A well-documented process or system indicates its characteristics, security requirements, and whether the people responsible for the process or system have defined measures in place to fulfill security responsibilities. Documentation gives an assessor a wide variety of information on how the process or system is routinely used, whether a security patch program is in place, who has access to systems and data, what policies exist to define security requirements, and how the system is securely configured. Documentation can be either paper-based or electronic; it can come from spreadsheets, databases, network devices, systems, written procedures, physical access logs, and so on. Examples of documentation include organizational policies, processes and procedures, backup and restore procedures, security officer appointment letters, and so on. While not strictly documentation (unless printed), audit logs and configuration files could also be considered in this category since they provide documentary evidence that supports an assertion of how events were recorded or how a system was configured. Documentation also serves to verify data collected from other sources, such as interviews. Remember, if you don’t document something in the security assessor world, you can’t prove that you’ve done it.

Observing and Verifying Systems and Assets Sometimes it’s not enough to interview personnel and review documentation. Unfortunately, people can lie or be mistaken in interviews, and documentation can be falsified. Observing a process or system in operation can verify whether it is secure and whether its security functions and controls are working as intended to protect systems and data. The same is true for physical security controls. An assessor can easily determine whether a control is functioning by observing a system operator perform a security function or visually inspecting a control to ensure it is in place and implemented properly. Examples requiring the observation method include gates, guards, and locks; other examples are watching a system through the boot process, observing a screen lock go into effect, having a system administrator demonstrate various security features, and so on.

Performing System Testing Not all data can come from talking to people, reading system architecture documents, and watching the system administrator assign permissions to shared folders and files. Some data must come from examinations of the system’s configuration, as well as obtaining relevant data related to patching, vulnerabilities, user accounts, configuration files, registry settings, and other technical data. This data is used to determine if a system is configured properly and securely and what potential vulnerabilities might exist on the system. This is where the technical assessment portion of data collection comes into play. Since technical data can be overwhelming in size and volume, automated tools are typically used to perform system security testing. These tools include vulnerability scanners, sniffers, and other hardware and software tools described later in this chapter.

During security testing of a system, various types of host-based and network scans may be performed, along with an in-depth examination of patches and updates applied to the system, configuration settings, user accounts, and other security settings. The system’s rights, permissions, and privileges and its resources are examined and compared against security requirements and control functions to ensure they match. Network protocols and connections are studied, and the network architecture may be examined to ensure a sound network design has been implemented. Application software code reviews and testing, including fuzzing, may be performed. Authentication and encryption mechanisms are examined in depth to ensure they are strong and effective and meet governance and best-practice requirements where applicable. Physical access controls may be tested to ensure that physical separation away from systems for unauthorized users is maintained.

The results of system security assessments (usually in the form of vulnerability assessments or penetration testing, discussed in this chapter) are consolidated with the results from interviews, documentation reviews, and system observations to form a comprehensive data picture of the system or asset; these results further inform the controls analysis and impact determination aspects of risk. Table 2-2 summarizes the different data collection methods you can use during an assessment.

Table 2-2 Summary of Data Collection Methods During a Risk Assessment, with Examples

NOTE   While you may not be directly tested on data collection methods, it is a good idea to understand these methods, as in actual practice, you will likely use them extensively.

Techniques used to examine systems or processes, evidence collection, sampling, and other considerations are covered in greater detail in ISACA’s Certified Information Systems Auditor (CISA) certification and described fully in the book CISA Certified Information Systems Auditor All-In-One Exam Guide.

Risk Assessment Standards and Frameworks

Some organizations see risk assessment as one large monolithic process, but many frameworks and standards break it down into different steps. We’ll look at several important frameworks, including the National Institute of Standards and Technology (NIST) SP 800-30, OCTAVE, the ISACA Risk IT Framework, ISO/IEC 27005, and others. We will go into detail and examine them from a risk assessment perspective.

Business Alignment

One of the most important considerations for selecting standards and frameworks is business alignment. When selecting a standard, whether for risk assessment, risk management, security controls, or integrated risk management systems, the risk management leader must select a framework or standard that best aligns with the organization’s needs. Selection considerations include the following:

•   Industry sector

•   Customer expectations and requirements

•   Applicable regulations

•   Risk appetite

•   Organizational maturity

•   Current and future technology in use

Security and risk professionals who strive for business alignment will achieve better outcomes by building and selecting processes, frameworks, and standards that are more likely to succeed.

NIST Special Publication 800-30

NIST Special Publication 800-30, “Guide for Conducting Risk Assessments,” is a step-by-step guide to performing qualitative and quantitative risk assessments. The standard also briefly describes the overall risk management life-cycle process to provide context for individual risk assessments. The steps of a risk assessment are as follows:

1.   Prepare for assessment. The scope, techniques, records, personnel, schedule, and other resources are identified. We also like to consider the threat landscape, although this is not expressly a part of NIST 800-30.

2.   Conduct assessment. The following are the actual risk assessment steps performed on each target asset defined in the assessment scope:

a.   Identify threat sources and events. All reasonable threat sources, events, and actors are identified.

b.   Identify vulnerabilities and predisposing conditions. Vulnerabilities in the in-scope processes or systems are identified. Often, vulnerabilities and threats are paired and listed. For instance, a threat actor with a lock pick set is paired with an exterior door with a substandard key core.

c.   Determine the likelihood of occurrence. The probability that each specific threat will occur is determined. Often this is an estimation, as there is generally insufficient data to reliably determine an accurate probability.

d.   Determine the magnitude of impact. This is generally expressed in qualitative terms in the form of descriptions of impact on business operations. Also, this can be expressed in quantitative terms that might include response and recovery costs.

e.   Determine risk. The risk associated with each threat scenario is calculated, generally as Risk = Impact × Probability × Asset Value.

3.   Communicate results. The results of the risk assessment are tabulated as determined at the start of the assessment. The results are communicated to various stakeholders in the organization. Often, results are developed for specific audiences; for instance, an executive summary may be produced for executives, while detailed charts will be produced for lower management and those who will participate in remediation activities.

4.   Maintain assessment. This generally refers to the activity of risk monitoring, in which a risk manager will periodically re-examine the assets to determine whether any changes have occurred in threats, threat actors, vulnerabilities, impact, or probability of occurrence.

NIST SP 800-30 contains additional resources, including the following:

•   Appendix D: Threat Sources This includes taxonomies of adversarial and non-adversarial threat sources, capabilities, intent, and scale.

•   Appendix E: Threat Events This includes numerous adversarial and non-adversarial threat activities that represent reconnaissance or attack.

•   Appendix F: Vulnerabilities and Predisposing Conditions This is a taxonomy of vulnerabilities and their characteristics.

•   Appendix G: Likelihood of Occurrence This includes taxonomies related to the probability of threats occurring.

•   Appendix H: Impact This includes various types of impact on organizations when threats occur.

•   Appendix I: Risk Determination This includes taxonomies used to determine the magnitude of individual risks.

OCTAVE Methodology

As part of a U.S. government contract with Carnegie Mellon University, the Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) methodology was developed to assist organizations in identifying and assessing information security risk. The methodology was initially developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1999 and has been updated over the years to its current version, OCTAVE Allegro, in 2007. OCTAVE uses a concept called workshops, made up of members of an organization, sometimes including outside facilitators with risk management and assessment expertise. The methodology has prescribed procedures, including worksheets and information catalogs to assist organizational members, drawn from all functional areas of an organization, to frame and assess risk based on internal organizational context (infrastructure, governance, business environment, and so on). OCTAVE has three iterations: the original OCTAVE, OCTAVE-S, and OCTAVE Allegro.

OCTAVE and OCTAVE-S The original OCTAVE methodology was released in 1999 and was designed for organizations with at least 300 employees. The assumptions for using OCTAVE included that the organization operates and maintains multitiered information infrastructure and performs vulnerability assessments. While OCTAVE is flexible and allows an organization to tailor its use based on its own assessment needs, the methodology is performed as three sequential phases. The first phase covers identifying assets, threats, protection practices, vulnerabilities, and security requirements. You can see where this maps to the practices we’ve described throughout this chapter as determining threats, identifying assets and their vulnerabilities, and evaluating existing controls. In the second phase, the members of the workshop perform assessment activities and evaluate the infrastructure. In the third phase, the workshop members develop response strategies for the identified risks.

OCTAVE-S is fundamentally the same as the original OCTAVE, with a few minor differences. First, OCTAVE-S was designed to assess smaller organizations, usually with fewer than 100 people. Second, this iteration relies more on internal personnel with extensive knowledge of the organization and its infrastructure and less on outside risk experts or facilitators. The number of workshop members will also be considerably less; the team may rely on fewer than ten key experts in the organization. OCTAVE-S processes and procedure documents were also written to include more detailed security-related information. This approach does not rely on outside security experts or risk facilitators to assist the team.

OCTAVE Allegro The OCTAVE Allegro methodology, introduced in 2007, expands the previous two iterations but does not necessarily replace them. It includes a more business-centered and operational risk approach to the assessment. It is also asset-centered in its approach; it focuses on assets and their use or misuse, the environment they are used in, and how threats and vulnerabilities specifically target and affect the assets. Allegro can be used on a scaled basis; either individuals or workshop teams can use this method without requiring a high degree of risk management or assessment knowledge and experience. OCTAVE Allegro is divided into four phases, which include eight steps. These phases and steps are described next.

Phase 1: Establish Drivers Step 1: Establish risk measurement criteria. This step serves to develop and establish the organization’s methodology and measurement criteria used to assess risk. OCTAVE uses a qualitative assessment methodology and measurements but can use quantitative methods for certain aspects of the overall process, such as determining likelihood and impact.

Phase 2: Profile Assets Step 2: Develop an information asset profile. In this step, the organization develops an asset profile, which is a collection of information that describes the asset, including its characteristics, priority, impact on the organization, and value. This profile also contains security requirements the asset may have.

Step 3: Identify information asset containers. The information asset container describes how data is stored, where it is processed, and how it is transported. Containers are usually networks and systems, including those that the organization directly operates and those that it outsources.

Phase 3: Identify Threats Step 4: Identify areas of concern. In this step, potential risk factors are identified and are used to develop threat scenarios.

Step 5: Identify threat scenarios. In the context of OCTAVE, threat scenarios describe categories of actors and the relevant threats in each category. The scenarios are typically identified by using a threat tree, which simply maps actors and scenarios.

Phase 4: Identify and Mitigate Risks

Step 6: Identify risks. In this step, consequences such as impact and likelihood are identified and measured, which inform risk.

Step 7: Analyze risks. Once impact and likelihood have been identified and measured, risks are analyzed. During this step, risk scores are developed. These come from developing impact and likelihood values, emphasizing impact in particular, since this is an asset-driven assessment.

Step 8: Select mitigation approach. In this step, risk response strategies are developed, analyzed, and recommended.

EXAM TIP   OCTAVE is designed for larger organizations, while OCTAVE-S is intended for use by smaller organizations. OCTAVE Allegro is scalable for use by individuals or larger teams working in organizations of various sizes.

ISO/IEC Standards

ISO stands for the International Organization for Standardization, and IEC stands for the International Electrotechnical Commission. Together, these two organizations are responsible for a plethora of information technology and manufacturing standards used worldwide, including several that apply to information security and risk management.

ISO/IEC 27005:2018 Standards in the ISO/IEC 27000 series are all about information security, and the 27005:2018 standard (“Information technology – Security techniques –Information security risk management”) supports the common ideas promulgated in both ISO/IEC 27001 and 27002. The standard defines the entire risk management life cycle, including detailed risk assessment principles. The standard doesn’t offer specific risk management or assessment methodologies. However, it does serve to describe a formalized, structured risk management process, such as developing context, scope, methods, and so on. It also describes the two primary types of assessment methodologies: qualitative and quantitative. Additionally, it describes processes used to develop risk response strategies, communication with stakeholders, and continuous risk monitoring.

ISO/IEC 31010:2019 ISO/IEC 31010:2019 is where the meat of information regarding risk assessments is located for the ISO/IEC standards. This document, “Risk Management – Risk Assessment Techniques,” articulates and extends the risk management principles of ISO/IEC 31000:2018 and provides a concrete overview of the risk assessment process. This standard describes risk assessment as the combination of risk identification, analysis, and evaluation, with a precursor step of establishing the risk context within the organization. The standard also addresses communication and consultation with various stakeholders and management, risk treatment (response), and monitoring risk.

EXAM TIP   Of the ISO/IEC standards, ISO/IEC 31010:2019 is essential for the exam because it covers risk assessments in detail.

ISACA’s Risk IT Framework

ISACA developed the Risk IT Framework to align with its COBIT framework. While COBIT is used to manage other aspects of business infrastructure and risk, the Risk IT Framework is explicitly used to allow organizations to identify and manage IT risk. The framework is broken down into three major process areas: Risk Governance (RG), Risk Evaluation (RE), and Risk Response (RR). We discussed this framework briefly in Chapter 1, but the focus of this chapter is on the assessment process, so we will cover the Risk Evaluation portion in more depth here.

The Risk Evaluation processes in the Risk IT Framework don’t cover only assessment; they overlap with the risk identification areas. In RE processes, business impact is framed and described, and risk scenarios are also developed. Risks are assessed and analyzed as well as presented to the organization’s management. The RE processes are further broken down into three areas (numbered RE1–RE3), which we will describe in more detail.

Collect Data (RE1) The data collection process aligns with some of the risk identification processes we’ve previously described. During this process, risk management personnel develop a model for data collection, which provides for standardized data formats, measurements, and common data definitions. Data is collected on the various aspects of the organization and risk scenarios, including the business’s operating environment, risk factors, threat sources and events, vulnerability data, and asset data. Data is also collected on the effectiveness of existing controls in the organization.

Analyze Risk (RE2) In this part of the Risk IT Framework, the organization begins to assess and analyze risk. First, it defines the risk analysis scope. The scope determines how broad and deep the risk analysis efforts will be, what areas the risk analysis will cover, and which assets will be examined for risk. To complete this part of the process, you’ll need to consider all the documentation assembled up to this point: risk scenarios, asset inventories, breakdowns of business processes, prioritization of assets, and so on. This will help frame the risk analysis as well as determine scope.

During this step, IT risk is also estimated. This involves determining likelihood and impact values associated with the developed risk scenarios. You will also consider existing controls and how effective they are as currently installed and functioning. Likelihood and impact values are considered after existing controls are considered.

Although risk response is the subject of Chapter 3, you also identify and consider possible risk response options during this step of the process. The person assessing the risk may recommend several different response options, based on the identified risk. What risk options an organization will use is determined later in the process and typically with the input and approval of senior management. Risk response options should be recommended that reduce risk to an acceptable level directly based on the risk appetite and tolerance of the organization. Finally, knowledgeable peers should review risk analyses to verify that the analysis process is sound and to validate the results.

Maintain Risk Profile (RE3) A risk profile is a collection of detailed data on identified IT risks. Risk profiles can cover a single system or asset but are also often seen as describing risks on an organization-wide basis. During this risk evaluation step, a comprehensive document of identified risks and their characteristics, such as details regarding impact, likelihood, and contributing factors, is developed and maintained throughout the asset or system’s life cycle. Remember that system or asset risk profiles are usually rolled up into a more comprehensive risk document that covers systems, assets, and business processes across the entire organization.

IT assets are also mapped to the business and organizational processes they support during this step; this helps translate IT risk to corresponding business risk and allows management to see how the organization would be affected if IT risk were realized on specific assets. This also enables the organization to develop criticality estimates of IT resources from a business perspective. It’s worth noting that this is similar to the same process followed during a business impact assessment (BIA). The key to understanding how IT risk affects business operations at this point is in understanding how the capabilities of IT are provided to the business processes in question and how critical IT is to a particular business process or operation. Maintaining a risk profile also means monitoring and updating risk scenarios and analysis as conditions and risk factors change. This involves keeping the risk register up to date as well. Finally, the organization should develop key risk indicators (KRIs) during this step, specifically focusing on IT resources. While key risk indicators are discussed in Chapter 3, for now, you should know that they allow the organization to monitor changes in risk for given scenarios, enabling the organization to modify its risk profiles as these indicators change. Table 2-3 summarizes some of the different risk assessment methodologies available to you.

Table 2-3 Summary of Available Risk Assessment Methods and Frameworks

EXAM TIP   Because this is an ISACA-sponsored exam, it is a good idea to understand risk assessment terms and processes from the perspective of the ISACA framework more so than any other. The ISACA Risk IT Framework directly aligns with ISO/IEC standards as well.

Risk Ranking

When risks have been identified in a risk assessment, it generally makes sense to display these risks in an ordered list. Most often, the highest risks will appear at the top of a list, indicating the nature of the sequencing. For instance, risks with the most significant impact may appear first, or perhaps a composite risk score will be calculated for each risk (based on probability, impact, and asset value) and risk items sorted by this overall risk calculation. Risk ranking, then, helps tell the story of the most critical risks that have been identified.

Risk ranking can be portrayed visually, which helps the reader better understand the universe of risks that have been identified. Figure 2-8 shows a risk map that visually indicates the nature and severity of risks.

Figure 2-8 A risk map visually depicts the severity of risks.

Risk Ownership

To correctly manage and act on unacceptable risks, each risk is assigned a risk owner. Generally, the risk owner is the department head or business unit leader associated with the business process that is the focus of a risk. It is usually not appropriate to assign risk ownership to IT, as IT is the steward of information and information systems as well as provides services as directed by department heads and business unit leaders.

Similarly, the organization’s cybersecurity leader (often a CISO) is not the assignee of risks. Instead, the cybersecurity leader facilitates risk conversations and decisions with department heads and business unit leaders, particularly those whose business processes are associated with individual risks.

In risk management, there are usually several different “owners” associated with each risk, including the following:

•   Risk owner This is usually the department head or business unit leader associated with the business process where the risk resides. Even if a risk is related to an IT system, IT is generally not the risk owner. Rarely, if ever, is the cybersecurity leader assigned as a risk owner.

•   Risk treatment decision-maker This person makes a business decision regarding the disposition (treatment) of an individual risk. Risk treatment is discussed fully in Chapter 3.

•   Risk remediation owner This is the person responsible for any remediation that has been selected as a part of risk treatment.

An organization’s risk management program charter (or other formal document) should define the roles and responsibilities of each type of risk owner.

These and other facets of risk ownership are generally indicated in the risk register, which is discussed next.

Risk Register

A risk register is a business record containing information about business risks and their origin, potential impact, affected assets, probability of occurrence, and treatment. A risk register is the central business record in an organization’s risk management program (the set of activities used to identify and treat risks).

Together with other records, the risk register serves as the focal point of information that an organization is attempting to manage risk. Other records include information about risk treatment decisions and approvals, tracking projects linked to risks, risk assessments, and other activities that contribute to the risk register.

When new risks are identified, they are added to the risk register to be later analyzed, discussed, and decisions will be made about their disposition.

A risk register can be stored in a spreadsheet, database, or within an integrated risk management (IRM) tool—formerly known as a governance, risk, and compliance (GRC) tool—used to manage risk and other activities in the security program. Table 2-4 shows a typical risk register entry.

Table 2-4 Sample Risk Register Data Structure

Sources of Information for the Risk Register

Awareness of risks can come from many places and through a variety of events. The information in Table 2-4 provides some hints about the potential sources of information that would lead to the creation of a risk register entry. These sources include the following:

•   Internal and external risk assessment A prime source for risk register entries, a risk assessment identifies risks in the organization’s staff (for example, excessive workload, competency, and training issues), business processes, and technology.

•   Vulnerability assessment The high-level results of a vulnerability assessment (or penetration test, code review, social engineering assessment, and so on) may indicate overarching problems in staff, business processes, or technology at a strategic level.

•   Internal audit Internal audit and other internal control self-assessments can identify problems in staff, business processes, or technology.

•   External audits Audits performed by external parties can identify issues in business processes and information technology.

•   Security incident The occurrence of a security incident may reveal the presence of one or more risks that require attention. Note that a security incident in another organization may highlight risks in one’s own organization.

•   Threat intelligence Formal and informal subscriptions or data feeds on threat intelligence may reveal risks that warrant attention.

•   Industry development Changes in the organization’s industry sector, such as new business activities and techniques, may reveal or magnify risks that require attention.

•   New laws and regulations The passage of new laws, regulations, applicable standards, and private legal obligations may reveal the presence of risks that require attention. Also, note that compliance risk (that is, the possibility that regulators or others may impose fines or sanctions on the organization) may well be included in one or more risk register entries if the organization has identified such risks.

•   Consultants A visit by or conversation with an expert security consultant may reveal previously unknown risks. The consultant, who may be an auditor or assessor or may be working in the organization on a project, may or may not expect to find risks that the organization’s security manager would want to be aware of.

Updating the Risk Register

Because the risk register is a living document, it should be periodically updated as risk conditions change. Risk assessments will provide updated information that should be included in the risk register and information about ongoing risk response actions applied to the risk. Whether the risk register is in the form of an electronic database, spreadsheet, or another type of document, it should be easy to read and readily accessible by risk managers and risk owners to stay updated on the current risk posture of the organization. As mentioned previously, it also should be considered a sensitive, access-controlled document. Table 2-5 shows a risk register and some sample entries.

Table 2-5 Sample Entries in a Risk Register

Risk Analysis Methodologies

As stated earlier in this chapter, risk analysis is the detailed analysis of a risk identified in a risk assessment. In risk analysis, we examine a risk and apply techniques to better understand it from several perspectives:

•   Asset identification The asset(s) involved in a particular risk are identified. This could be an IT or IoT device, a business application, an entire IT environment (or specific parts therein), a database, a building, a procedure, or a business process.

•   Vulnerability Various weaknesses related to the asset are identified that could be exploited by a threat event.

•   Threat Various threat scenarios are considered, particularly those that are reasonably applicable to identified vulnerabilities.

•   Asset value The value of the asset is identified and considered. Various iterations of risk analysis may consider different types of asset value, including replacement cost, repair cost, lost revenue, and more. For various risk scenarios, it may be necessary to use and identify different types of asset value. For instance, one risk scenario may use replacement value while another might use repair cost.

•   Business context Because risk analysis is often an abstract mental exercise, it is necessary to define the business context for the risk. For example, risk analysis is performed on a database server; the business context is the organization’s financial accounting system that supports all of the organization’s accounting department’s business processes. Without identifying business context, a risk remains abstract, and it is more difficult to apply risk treatment later on.

•   Business impact To be relevant to the business, risk analysis needs to identify the impact of various threat scenarios on business processes and operations. For example, risk analysis focused on access controls on a database management system containing customer information would identify business interruption in scenarios involving data destruction and privacy breaches with reputation damage and fines in scenarios involving data theft.

•   Risk appetite and risk tolerance The risk analyst should be familiar with the organization’s stated risk appetite and risk tolerance to ensure that identified risks and subsequent risk analysis align with risk appetite and tolerance. Risk appetite and risk tolerance were discussed in more detail in Chapter 1.

•   Mitigation analysis Once a specific risk is examined, various mitigation scenarios can be developed. For each, the risk manager would identify the time required to perform the mitigation, cost, the changes in the probability of various threat scenarios, the changes in impact for each, and the change in risk for each.

Asset Identification, Classification, and Valuation

Identifying the different elements of risk is a necessary precursor to assessing risk. One of the goals of the identification process is the development of risk scenarios. Risk scenarios require that you identify assets, vulnerabilities, and potential threat events.

Asset identification not only requires you to inventory all of your assets; you should also determine how critical they are to your business, decide how sensitive the data they process or produce is, and characterize or classify the system or asset in terms of confidentiality, integrity, and availability. Determining criticality is an essential aspect of the overall risk management process and typically is done before any assessment takes place. The NIST RMF process requires that you perform a system categorization on assets in the first step of that framework. This system categorization later helps you to assign controls to the asset based on its criticality factors. The set of controls you assign to each asset, based on its criticality, is assessed for effectiveness in mitigating risk and compliance.

Risk managers may also want to know the value of an asset. Quantifiable risk analysis requires that some value of an asset be identified, whether based on replacement cost, salvage cost, depreciated value, or another method of calculation that represents the expenditure of resources to return an asset to a pre-threat event state.

Likelihood Determination and Impact Analysis

Evaluation is the next step of the process. You must determine the likelihood of a given threat agent initiating a threat or of an identified threat exploiting a given vulnerability, as well as the level of impact or harm to the asset if a threat has successfully exploited a vulnerability. While threats and vulnerabilities in assets are necessary ingredients to determine risk, they are static ingredients; in other words, threats, vulnerabilities, and assets don’t change much. On the other hand, likelihood and impact are variable and are the primary factors in measuring risk. People who don’t understand how risk is framed often mistakenly state risk as a result of only one individual element. You could say that the risk to an asset is high, for example, simply because the likelihood of the adverse event occurring is high. You could also say that risk is high because the level of impact if an adverse event were to occur would be high. However, neither of these statements alone really captures the sense of risk. This is because they do not convey the other dimension of risk individually since risk is a product of both likelihood and impact. Additionally, you can’t make these determinations without the background knowledge of the threat, the vulnerability, and the asset.

CAUTION   Make sure you consider controls and their effectiveness when analyzing risk since controls can help decrease likelihood or reduce impact, thereby reducing the assessed risk for an asset and the organization.

Evaluation involves the measurement of these two primary factors: likelihood and impact. We’ve already discussed how there can be different ways to measure these factors based on subjectivity or concrete values. This is where the discussion on qualitative and quantitative techniques comes into play. We’ll go into depth on those assessment techniques next.

EXAM TIP   Remember that risk assessments are composed of the steps of risk identification, evaluation, and analysis. Identification produces threat–vulnerability pairs, asset inventories, and risk scenarios. Evaluation covers likelihood and impact calculations, resulting in risk values. Analysis looks at the overall application of these factors, as well as control analysis, to produce a comprehensive picture of risk.

Quantitative and Qualitative Analysis Techniques

You could take two different security professionals, both trained in the latest standards and practices associated with risk management, and have them both assess the same system, and, chances are, they would produce similar reports. However, they would not be the same. Why is that? It’s because there are so many different methods of conducting risk assessment and analysis, depending on what governance the organization falls under, how the organization has framed its risk, and so on, that the risk would never be assessed the same; there are too many variables involved. Add to that complexity the natural subjectivity of human beings, and you may have very different risk reports. However, most risk assessment methodologies are still based fundamentally on the two primary ways to assess risk: qualitative and quantitative. Both methods have value, depending on the context of the situation, and often both methods can be combined. We discuss these techniques at length in the upcoming sections and how they can be used together.

Quantitative Quantitative risk analysis uses concrete (nonsubjective) numerical values and statistical analysis to calculate the likelihood and impact of risk. Quantitative methods use numerical values such as dollar figures, statistical numbers, and other hard-core numerical assignments. Quantitative risk assessments follow the same general pattern described previously; you must first list your assets (along with their replacement costs and exposure factors), calculate the impact of a full or partial loss of the asset, determine the likelihood of the adverse event, and come up with the overall risk to the organization. This might be calculated in terms of dollars, for example. The following is a scenario that will help you better understand quantitative risk analysis and some of the factors that can be quantified and how.

Quantitative Risk Analysis: A Scenario Let’s say you are a new employee in a small family-owned business that has no other security professionals employed. You’ve been tasked with developing a risk management strategy and program for the business. Suppose the business has a small server farm located in an older building on your small campus, with wooden walls, older wiring, no backup electrical power, and reasonably good fire detection and suppression systems. The server farm contains four servers, each performing a specific data-processing function. The data is backed up weekly, but it takes time to restore, and there is a good likelihood that some of the data would be lost because of the weekly backup schedule. Let’s also say (just for the sake of illustration) that each of these servers costs $10,000 to replace with a new server (since they don’t make your model any longer unless you were lucky enough to find a cheaper one on eBay). You’ve attempted to quantify factors for the owners, such as recovery time objective (RTO) and recovery point objective (RPO). These factors tell you how much data you could afford to lose if a disaster happened (such as a fire burning down that small wooden building) and how fast you would need to recover data to resume business operations to avoid suffering a significant loss of business.

Let’s assume that the small business is in an area prone to thunderstorms, tornadoes, and hurricanes. One of the natural incidents that could occur in these areas is a lightning strike during a thunderstorm, where lightning strikes the metal roof of the building, and one of the servers suffers a power surge that completely renders it inoperable. If, after such an event, an assessment determines that the server can’t be repaired, you decide to buy another one. The replacement cost of this server is $10,000. Let’s do some simple quantitative analysis on this scenario:

Asset value (AV) = $10,000
Exposure factor (EF) = 1 (in this case, a 100 percent loss of the server and its data)
Single loss expectancy (SLE) = Asset value (AV) × Exposure factor (EF) = $10,000

With an SLE of $10,000, you must hope this scenario never happens. However, based on analysis of historical weather patterns in the area, and given the shoddy construction and limited electrical protections of the building the server farm sits in, this seems to be a likely possibility. So, you should determine how much the organization is likely to lose, per year, in such a scenario. You can calculate this if you know a couple of other pieces of information. First, you need to know how often to expect a severe storm in the area (say, on an annual basis). This annualized rate of occurrence (ARO) could be used with the SLE value given earlier to determine your loss expectancy for one year.

SLE × ARO = Annual loss expectancy (ALE)

So, given that severe thunderstorms are historically shown to occur 15 times per year in your area (likelihood), you could conclude the following:

$10,000 (SLE) × 15 (ARO) = $150,000 in potential loss per year (ALE)

Obviously, this is a bit of a stretch. Even if there are 15 severe lightning-producing storms per year, it’s not likely that each one would produce a lightning strike on your server building every time. Even if that could happen, it’s likely that after it happens the first time, your small business owners would invest in a new facility or relocate its servers, thus reducing the possibility of the other events. So, you might also do some statistical analysis to determine the likelihood of one or more of those 15 severe thunderstorms causing a lightning strike on the server farm building. This analysis might significantly reduce the likely number of events from 15 to, say, 3. Now your ALE would be a potential loss of only $30,000 per year. Keep in mind that the numbers show you the potential risk to the organization, which is expressed as lost dollars in terms of revenue and assets.

NOTE   These formulas are based on standard basic risk analysis concepts taught in information security certification programs, such as CompTIA’s Security+ and (ISC)²’s CISSP program.

Again, the previous scenario is a simplistic (but not too unrealistic) example. Other factors could come into play that are not considered in the previous simple analysis. For example, suppose the business is losing $1,000 per day in revenue for every day this server is out of commission, which the previous calculations do not consider. This consideration is not only related to the SLE value (since it increases the SLE over time) but also influences your RTO and RPO values. You should also realize that this scenario considers only one of the servers; a better risk assessment should include the possibility of all the assets being partially or completely lost.

Additionally, it’s possible that a total loss of a server may not occur; let’s say it’s only a partial loss (say, 40 percent, or an EF of 0.4), which would reduce the SLE for that single asset ($10,000 [AV] × 0.4 [EF] = $4,000). So, you must take all of this into account when performing a quantitative risk analysis. There are so many other factors that we haven’t mentioned here that could figure into your SLE values (asset depreciation, lost labor hours to repair or replace the server, and so on). However, you can see the basics based on this simple example.

EXAM TIP   Be familiar with the elements of quantitative risk assessment techniques, such as asset value, exposure factor, single loss expectancy, annual rate of occurrence, and annualized loss expectancy.

The final piece of this puzzle is how much it would cost the organization to reduce this risk. Let’s examine all of the factors that the organization could influence. First, it could not affect the weather, so the threat agent and threat can’t be reduced or eliminated. However, the organization could address the vulnerability (the server building with its inadequate protection against bad weather, in this case), reducing it somewhat by relocating the server farm or even moving its applications and data to the cloud, for example. The organization could also reduce the likelihood for that particular threat-vulnerability pairing if it removed or changed the nature of the vulnerability itself, as described earlier.

The organization could also reduce the impact of this specific event in several ways. It could create a real-time failover cluster for the servers in another location that would instantly be available if said servers got struck by lightning, or it could at least have a hot spare server and a recent backup, if nothing else. The organization can affect the risk factors, but there is a cost for doing this. What is essential in developing risk responses is that the organization must balance the cost of mitigations (for example, acquiring another facility, moving to the cloud, using server clusters, or at least having hot spares and better backups) with how much it loses in terms of SLE and ALE and the added impact of lost revenue per day, as in this example. The bottom line is that you must find a solution that isn’t more expensive or impacts the organization to a degree worse than the risk event itself. Risk responses are covered in more detail in Chapter 3.

Qualitative A qualitative risk analysis, on the other hand, involves using subjective scales. These scales could be numeric (a scale from 1 to 10) or have subjective labels (High, Medium, and Low, for instance). Qualitative risk analysis can come from historical trend analysis, experience, expert opinion, existing internal and external environmental factors, governance, and other inputs that are not always necessarily quantifiable but exist and are important nonetheless. Qualitative risk analysis is appropriate when you must evaluate risk based on factors that can be hard to quantify, such as those not typically measured with concrete, repeatable values. For example, what numerical value could you assign to a potential impact of the loss of consumer confidence or damage to reputation? You may attempt to frame it in terms of lost revenue (an educated guess at best) or loss of business. For example, you could also survey a sample population to determine how many people would or would not do business with the organization after a data breach. However, even that would be subjective and offer only a small statistical insight into a hard-to-define measurement.

That’s not to say you couldn’t assign numerical values to different risk factors, however. Instead of values such as Low, Medium, and High, you might assign numerical values that roughly correspond to those levels. For example, you might use a type of Likert scale, which may have values such as 1 (Very Low), 2 (Low), 3 (Medium), 4 (High), and 5 (Very High). This might characterize the subjective level of impact or likelihood the organization wants to assign to a particular risk event. In assigning these subjective values, you must also decide how they relate to each other, yielding an overall risk calculation. In other words, given likelihood values of 1 (Very Low), 2 (Low), 3 (Medium), 4 (High), and 5 (Very High), and identical values for impact, what would the overall risk level be when these two dimensions of risk are viewed together? How do their values affect each other? NIST Special Publication 800-30 offers an excellent example of how risk is calculated using qualitative analysis.

NOTE   NIST SP 800-30 refers to numerical scales as semiquantitative values since they are numerical values that can be used in calculations but are still subjective in nature (in other words, they cannot be independently derived or repeated and are based on informed opinion).

In Figure 2-9, taken from NIST SP 800-30, you can see how the relationships of likelihood and impact affect different risk levels. The values of each are correlated, and a qualitative risk determination results. For example, according to this figure, a moderate level of likelihood combined with a very high level of impact results in a level of risk determined as high. Determining what constitutes a likelihood of moderate and what is required for an impact level of very high is subjective. However, it should be defined within the organization for consistency and standardization.

Figure 2-9 Qualitative assessment of risk (courtesy of NIST SP 800-30)

Combining Quantitative and Qualitative Techniques If you think that a qualitative or quantitative assessment alone may not be enough to adequately capture the different elements of risk and develop an overall risk determination, you’re right. While there are instances where each of these techniques can be used alone, they are used together to varying degrees in most situations. Each technique is good at producing a valuable piece of the puzzle, but sometimes you need both a quantitative perspective and a qualitative perspective on risk. For example, in the scenario we described earlier for quantitative risk, say you have numerical values for AV, EF, SLE, and ALE. These values account primarily for impact. However, suppose you don’t have enough solid information for a calculation of likelihood. You might have to give it a “best guess” that comes from a reasonably well-thought-out analysis, using anecdotal data or another type of data that can’t necessarily be quantified but is a reasonably accurate predictor. You may have to assign likelihood values that are semiquantitative or the subjective High, Medium, and Low values. There might also be other subjective factors contributing to these values, so you would not have a purely quantitative assessment. Suppose you added “customer confidence” or “reputation” into the discussion on impact or loss to the company, for instance. Those would almost have to be qualitative values, so the assessment couldn’t always be expressed in exact numerical terms that are easily repeatable or defendable.

In practice, most risk assessments are usually qualitative with some quantitative elements, or vice versa. There are usually few purely quantitative or entirely qualitative assessments performed. You should understand the elements and characteristics of both, however, for the exam and your profession.

Other Analysis Techniques

Now that you know the basics of qualitative and quantitative techniques, there are a few specific techniques, based on both of these methods, that we will discuss here so you are familiar with them for the exam. Note that professionals have developed dozens of different techniques over the years to assess risk; you’ll find that most of them fall into either the qualitative or quantitative methodology. The ISO/IEC 31010:2019 standard we briefly described earlier lists more than 30 such techniques in its appendixes. Some of them approach assessments from different directions, but most of them have several things in common. We’ll discuss just a few of these in the following sections.

Fault- and Event-Tree Analysis A fault-tree analysis is a method where the analyst starts with a risk event and looks for all possible causes. This is diagrammed as a tree, with the risk event at the root and the causes extending away as branches. This analysis is used to discover all of the potential causes of the event (threats and threat actors in this case) to be further analyzed for likelihood. Like the fault tree, the event-tree analysis is also diagrammed as a tree structure but takes the opposite approach (bottom-up instead of top-down). In event-tree analysis, an initiating event is at the root of the tree, with all possible consequences (impacts) diagrammed from the root as branches (as opposed to causes of the event in fault-tree analysis). Both fault tree and event tree are predictive analysis tools; in other words, they seek to predict relationships between causes, events, and consequences. Figures 2-10 and 2-11 show examples of fault-tree and event-tree analysis diagrams, respectively.

Figure 2-10 An example of a fault-tree analysis diagram

Figure 2-11 An example of an event-tree analysis diagram

Figure 2-10 shows a risk event (in this case, a firewall failure), with the potential causes shown as no rule configured, a firewall appliance failure, and unknown or unusual traffic. Note that the risk event itself is the root of the tree. Conversely, in Figure 2-11, an event-tree diagram, the risk event (in this case, a break-in to a corporate facility) is also at the root. However, the branches leading away are the potential consequences, not the causes.

Factor Analysis of Information Risk The Factor Analysis of Information Risk (FAIR) is a semiquantitative methodology used to determine the probable loss event frequency and magnitude for individual risks.

The FAIR methodology consists of four stages:

•   Identify scenario components This step identifies the asset at risk, as well as the threat community being analyzed.

•   Evaluate loss event frequency Activities in this stage include an estimation of threat event frequency, threat capability, protective control strength, vulnerabilities, and the frequency of loss events.

•   Evaluate probable loss magnitude This stage is used to develop worst-case and most likely loss magnitude.

•   Derive and articulate risk Derived from the values established in earlier steps, the level of risk is calculated and portrayed.

The FAIR methodology is presented in the book Measuring and Managing Information Risk: A FAIR Approach, by Jack Freund and Jack Jones. An organization known as the FAIR Institute offers membership, training, and events and is found at www.fairinstitute.org.

Bow-Tie Analysis A bow-tie analysis uses diagrams to analyze and explain relationships between various risk elements, from causes (threats) to events and then to impacts (consequences). It is similar to both the fault-tree analysis and the event-tree analysis. It looks at the various causes of a risk event (fault tree) and analyzes the consequences of the event (event tree). The difference, however, is that the bow-tie analysis looks at the intervening characteristics of the events and causes, such as the path by which the cause leads to the event and then the consequences. Figure 2-12 illustrates a bow-tie diagram. In this figure, the adverse event is shown as the center of the bow tie, with potential causes on the left and possible consequences on the right.

Figure 2-12 An example of a bow-tie analysis diagram

Other Methods As mentioned, there are too numerous other methods to perform the different types of assessments to discuss them all here. Some of these methods focus on data collection, while others emphasize different group analysis techniques. All are, again, some variation of either the qualitative or quantitative method and may require looking at specific aspects of data to determine various elements of risk. Other examples of these techniques include the Delphi method, which centers on expert opinion from questionnaires; the Bayesian analysis method, which uses data distribution and statistical inference to determine risk probability values, checklists, scenario analysis, and business impact analysis (described later in this chapter); root-cause analysis (discussed earlier in this chapter); and various collaborative techniques, such as brainstorming. You won’t be expected to know all these methods for the exam, but you should be familiar with the concepts of qualitative and quantitative analysis and some of the techniques that use each. For further knowledge on various assessment and analysis techniques, consult with ISO/IEC 31010:2019.

EXAM TIP   You will not have to know any particular risk analysis method in detail for the exam, but you should understand how the qualitative, quantitative, and semiquantitative methods work.

Business Impact Analysis

A business impact analysis (BIA) is used to identify an organization’s business processes, the interdependencies between processes, the resources required for process operation, and the impact on the organization if any business process is incapacitated for a time for any reason.

While a BIA is considered a cornerstone of a business continuity and disaster recovery (BCDR) program, a BIA is also useful for risk analysis. The BIA reveals the most critical processes (and underlying resources such as information systems and other IT infrastructure), giving the risk manager a better idea of which business processes and systems warrant the most protection from an operational criticality point of view.

The presence of a BIA provides a strong indication of the organization’s maturity through its intention to protect its most critical processes from disaster scenarios. Correspondingly, the absence of a BIA may suggest that the organization does not consider risk management as having strategic importance.

Inventory Key Processes and Systems

The first step in a BIA is the collection of key business processes and IT systems. Within the overall scope of the business continuity planning (BCP) project, the objective here is to establish a detailed list of all identifiable business processes and systems. The usual approach is developing a questionnaire or intake form that would be circulated to key personnel in end-user departments and IT. Figure 2-13 shows a sample intake form.

Figure 2-13 BIA sample intake form for gathering data about key processes

Typically, the information collected on intake forms is transferred to a multi-columned spreadsheet, where information on all of the organization’s in-scope processes can be viewed together. This will become even more useful in subsequent phases of the BCP project, such as the criticality analysis.

TIP   The use of an intake form is not the only accepted approach when gathering information about critical processes and systems. It’s also acceptable to conduct one-on-one or group interviews with key users and IT personnel to identify critical business processes and systems. We recommend using an intake form (whether paper-based or electronic), even if the interviewer uses it herself as a framework for note-taking.

Planning Precedes Action

IT personnel are often eager to get to the fun and meaty part of a project. Developers are anxious to begin coding before design, system administrators are eager to build systems before they are scoped and designed, and BCP personnel fervently desire to start designing more robust system architectures and tinker with replication and backup capabilities before key facts are known. In business continuity and disaster recovery planning, completing the BIA and other analyses is critical, as the analyses help define the systems and processes most needed before getting to the fun part.

Statements of Impact

When processes and systems are being inventoried and cataloged, it is also vitally important to obtain one or more statements of impact for each process and system. A statement of impact is a qualitative or quantitative description of the impact on the business if the process or system were incapacitated for a time.

For IT systems, you might capture the number of users and the names of departments or functions affected by the unavailability of a specific IT system. Include the geography of affected users and functions if that is appropriate. Here are some sample statements of impact for IT systems:

•   Three thousand users in France and Italy will be unable to access customer records, resulting in degraded customer service.

•   All users in North America will be unable to read or send e-mail, resulting in productivity slowdowns and delays in some business processes.

Statements of impact for business processes might cite the business functions that would be affected. Here are some sample statements of impact:

•   Accounts payable and accounts receivable functions will be unable to process, impacting the availability of services and supplies and reducing revenue.

•   The legal department will be unable to access contracts and addendums, resulting in lost or delayed revenue.

Statements of impact for revenue-generating and revenue-supporting business functions could quantify financial impact per unit of time (be sure to use the same units of time for all functions to be easily compared with one another). Here are some examples:

•   Inability to place orders for materials will cost at the rate of $12,000 per hour.

•   Delays in payments will cost $45,000 per day in interest charges and late fees.

As statements of impact are gathered, it might make sense to create several columns in the main worksheet so that like units (names of functions, numbers of users, financial figures) can be sorted and ranked later.

When the BIA is completed, you’ll have the following information about each process and system:

•   Name of the process or system

•   Who is responsible for its operation

•   A description of its function

•   Dependencies on systems

•   Dependencies on suppliers

•   Dependencies on key employees

•   Quantified statements of impact in terms of revenue, users affected, and/or functions impacted

Criticality Analysis

When all of the BIA information has been collected and charted, the criticality analysis (CA) can be performed.

Criticality analysis is a study of each system and process, a consideration of the impact on the organization if it is incapacitated, the likelihood of incapacitation, and the estimated cost of mitigating the risk or impact of incapacitation. In other words, it’s a somewhat special type of risk analysis that focuses on key processes and systems.

The criticality analysis needs to include, or reference, a threat analysis. A threat analysis is a risk analysis that identifies every threat that has a reasonable probability of occurrence, plus one or more mitigating controls or compensating controls, and new probabilities of occurrence with those mitigating/compensating controls in place. To give you an idea of what this looks like, refer to Table 2-6, which provides a lightweight example of what we’re talking about.

Table 2-6 Sample Threat Analysis for Identifying Threats and Controls for Critical Systems and Processes

In the preceding threat analysis, notice the following:

•   Multiple threats are listed for a single asset. In the preceding example, we mentioned just eight threats. For all the threats but one, we listed only a single mitigating control. For the extended power outage threat, we listed two mitigating controls.

•   The cost of downtime wasn’t listed. For systems or processes where you have a cost per unit of time for downtime, you’ll need to include it here, along with some calculations to show the payback for each control.

•   Some mitigating controls can benefit more than one system. That may not have been obvious in this example. However, in the case of an uninterruptible power supply (UPS) and an electric generator, many systems can benefit, so the cost for these mitigating controls can be allocated across many systems, thereby lowering the cost for each system. Another example is a high-availability storage area network (SAN) located in two different geographic areas; although it’s initially expensive, many applications can use the SAN for storage, and all will benefit from replication to the counterpart storage system.

•   Threat probabilities are arbitrary. In Table 2-6, the probabilities are for a single occurrence in an entire year (for example, 5 percent means the threat will be realized once every 20 years).

•   The length of the outage was not included. You may need to include this also, particularly if you are quantifying downtime per hour or another unit of time.

It is probably becoming evident that a threat analysis and the corresponding criticality analysis can get complicated. The rule here should be as follows: the complexity of the threat and criticality analyses should be proportional to the value of the assets (or revenue, or both). For example, in a company where application downtime is measured in thousands of dollars per minute, it’s probably worth taking a few weeks or even months to work out all of the likely scenarios and a variety of mitigating controls and then work out which ones are the most cost-effective. On the other hand, for a system or business process where the impact of an outage is far less costly, a good deal less time might be spent on the supporting threat and criticality analysis.

Recovery Objectives and Next Steps

After the criticality analysis is performed, business continuity planners will establish a metric known as maximum tolerable downtime (MTD). This is the amount of time that the organization can tolerate a business process being nonfunctional before the ongoing viability of the business itself (or a major part of it) is at risk. Note that MTD is a theoretical figure that the organization will not attempt to verify.

Busines impact analysis is often used to establish recovery objectives that drive the development of disaster recovery plans. Recovery objectives and disaster recovery planning are discussed in more detail in Chapter 4.

Inherent and Residual Risk

Our coverage of the IT Risk Assessment domain in the CRISC certification concludes with a discussion of inherent and residual risk. These two concepts bring a small degree of added complication to the overall risk management and risk treatment concepts.

Risk treatment is discussed in full detail in Chapter 3.

Inherent Risk

No personal or business activity is entirely free of risk, and some activities are inherently more risky than others. The concept of inherent risk expresses the level of risk associated with a process or activity before applying any protections or safeguards. In the vernacular, some activities are just riskier than others.

Take, for example, two personal activities: gardening and hang gliding. We would state that the inherent risk associated with hang gliding is significantly higher than that of gardening. With hang gliding, any number of realistic scenarios can result in the death of the hang glider. At the same time, gardening is relatively safe, and death by gardening is highly unlikely. In both gardening and hang gliding, the probability of risk realization is relatively low, although the impact of risk realization is decidedly higher for hang gliding.

One approach to risk analysis is assigning inherent risk to a process or system, and then calculating changes to risk after protective controls and safeguards are applied. This helps a risk analyst understand the changes in risk when individual controls and safeguards are applied, and it better informs management of the full nature of risk for a given part of the organization.

Residual Risk

The risk management and risk treatment processes tend to reduce risk, but they rarely eliminate all risk. Instead, risk mitigation and risk transfer reduce risk to a lower level. This “leftover” risk is known as residual risk.

Residual risk is best explained with a real-world example. An organization’s workforce is equipped with laptop computers running Windows or macOS, neither of which utilizes whole-disk encryption. Risk analysis suggests that the risks associated with the theft or disappearance of an unencrypted laptop computer are quite high, with potential for a significant security or privacy incident, depending on whose laptop computer is lost or stolen.

In this scenario, the organization decides to implement whole-disk encryption on all of its laptop computers. Note that this measure does nothing to change the probability of laptop computers being lost or stolen. However, this measure changes the impact significantly. While, with whole-disk encryption, the organization need no longer worry about the potential data compromise, the stolen laptop will still need to be replaced. The residual risk, in this example, is the financial risk associated with the funds required to purchase a new laptop computer, plus any labor needed to make it ready for employee use.

To continue this example further, this residual risk is one in which the residual risk may still be a risk that warrants further analysis and treatment. Analysis of the risks associated with the need to replace a lost or stolen laptop computer could result in a recommendation of the purchase of security cables that are issued to each employee, together with directives that laptop computers are to be locked to a piece of furniture (or locked in a safe) when not in the direct control of the employee. This measure reduces the probability of theft or loss, but not the impact: if the laptop computer is stolen, it must still be replaced, but theft is less likely to occur since, at least some of the time, employees will use those cable locks, reducing the number of opportunities for someone to steal them.

Larger and more complex risk scenarios may require multiple rounds of risk analysis and risk treatment. However, an organization will eventually reach the point where the residual risk is low enough that business leaders and department heads will accept the residual risk.

Often, risk analysis, risk treatment, and residual risk are more complicated than this. A risk assessment performed on a business process or information system is likely to identify multiple risks, which should be considered in whole as well as individually. It may be easier to understand all the risks together to compare various types of risks and risk treatment options when considered together. Sometimes, a single risk treatment measure may mitigate more than one of the identified risks. Figure 2-14 visually depicts multiple rounds of risk analysis and risk treatment until the final remaining risk is accepted.

Figure 2-14 Risk reduction through multiple rounds of risk treatment

Let’s go back to our stolen laptop example for a moment. Imagine that multiple risks are identified in a stolen laptop scenario, all having to do with the compromise of different types of information: personally identifiable information (PII) such as human resource information, non-public financial information, intellectual property, and trade secrets. Whole-disk encryption will reduce the impact of all four of these scenarios to near zero.

Miscellaneous Risk Considerations

There may be other options to consider when performing risk assessments, which may or may not be applicable in an organization. Understanding industry and compliance models related to an organization’s industry can be absolutely critical to using the risk assessment to pass an audit or ensure legal compliance. There may be unique methodologies used by the organization to illustrate different aspects of a cybersecurity program.

For companies that have protected health information (PHI), there are extra considerations that should be followed related to the data from a legal standpoint because those companies should follow Health Insurance Portability and Accountability Act (HIPAA) regulations. In this case, tying in each risk to confidentiality, integrity, and availability is required by HIPAA. This can be as simple as creating a new column on a risk register that denotes if confidentiality, integrity, or availability is affected by the risk. It is a simple additional step that can help demonstrate not only compliance with HIPAA, but a deeper understanding of how the risks may affect an organization.

The enforcement arm of HIPAA is the Office of Civil Rights (OCR). Working with their regulations, they have risk requirements that need to be assessed for legal compliance reasons. The OCR does not expect companies to follow their exact risk methodology so long as the concerns are fully applied within the risk framework of the organization. If there ever is a HIPAA violation where the OCR becomes involved, considerations like this and assessing confidentiality, integrity, and availability can make regulators feel more at ease related to the violation and sometimes help reduce the overall penalties.

Stepping away from HIPAA considerations, sometimes organizations may choose to follow or report to others using frameworks such as NIST CSF (described previously). In this case, as with the confidentiality, integrity, and availability example, the NIST CSF functions (Identify, Protect, Detect, Respond, Recover) may be used in the same way. This can sometimes be useful to help business executives who do not understand the intricacies of cybersecurity to understand, at least at a high level, why certain risks are so important to consider.

Another option that may or may not be helpful depending on the organization is the concept of materiality. Materiality comes from the audit world and denotes a fundamental flaw in a specific program. For example, if there is no antivirus in an organization, that is a fundamental flaw and thus a material weakness. Adding a column like this into a risk register is yet another way that organizations can create extra emphasis around a risk management program.

It should be clear that there are a number of ways organizations can approach risk. In some instances, it is not so much about being right or wrong concerning a risk methodology but rather about working through the right flavor of risk within an organization.

Chapter Review

IT risk identification consists of activities performed to identify various types of risks associated with an organization’s use of information technology, including strategic, operational, cybersecurity, privacy, supply chain, and compliance risks.

The types of activities where risks may be identified include risk assessments, audits, incidents, penetration tests, news and social media, advisories, threat modeling, word of mouth, whistleblowers, and passive observation.

Threat modeling is a risk identification technique that involves examining every possible threat agent, action or event, attack vector, and vulnerability for a given system, asset, or process, and then modeling or simulating how it could progress and the damage that could occur.

Vulnerability and control deficiency analysis are important parts of risk analysis, focusing on weaknesses in a system or process that could result in a potentially serious incident if exploited by a threat actor.

Root cause analysis, or RCA, is a method of problem-solving that seeks to identify the root cause of an event, situation, or problem.

A risk scenario is a potential real-world, business-impacting event that consists of a threat, threat actor, vulnerability, and asset.

Risk analysis is a detailed examination of a risk to better understand basic factors, including the likelihood and impact of risk occurrence, and the development of a measure that might be enacted to reduce likelihood or impact.

Several types of assessments can be used to identify risks, including a gap assessment, threat modeling, vulnerability assessment, maturity assessment, penetration test, data discovery, code review, architecture review, design review, code scan, audit, and risk assessment.

Several techniques are used in a risk assessment to identify risks, including interviews, documentation review, observation, and system testing.

Risk ranking is the process of sequencing risks, generally with the greatest risks appearing first.

A risk owner is the owner of a business process or system that focuses on an identified risk.

A risk register is a business record containing information about business risks and their origin, potential impact, affected assets, probability of occurrence, and treatment.

A risk analysis is the detailed analysis of a risk that has been identified in an activity, such as a risk assessment.

Quantitative risk analysis uses concrete (nonsubjective) numerical values and statistical analysis to calculate the likelihood and impact of risk. On the other hand, a qualitative risk analysis involves using subjective scales, such as a numeric scale from 1 to 10, or subjective values, such as High, Medium, and Low.

There are several risk analysis techniques, including fault- and event-tree analysis, factor analysis of information risk (FAIR), and bow-tie analysis.

A business impact analysis (BIA) is used to identify an organization’s business processes, the interdependencies between processes, the resources required for process operation, and the impact on the organization if any business process is incapacitated for a time for any reason.

A statement of impact is a qualitative or quantitative description of the impact on the business if the process or system were incapacitated for a time.

A criticality analysis is a study of each system and process, a consideration of the impact on the organization if it is incapacitated, the likelihood of incapacitation, and the estimated cost of mitigating the risk or impact of incapacitation.

Inherent risk is the level of risk associated with a specific activity or function before applying any protective controls or safeguards.

Residual risk is the risk that remains after any risk transfer or risk mitigation that may have been performed.

The materiality of a risk may help to highlight its importance to management.

Quick Review

•   CRISC candidates and risk managers must be familiar with the vocabulary of terms related to risk assessment and risk analysis, including asset, vulnerability, threat, impact, attack, and risk.

•   CRISC and IT Risk Management consider cybersecurity risks and operational risk, workforce risk, privacy risk, and compliance risk.

•   Appendixes D and E in NIST Special Publication 800-30, “Guide for Conducting Risk Assessments,” offer a comprehensive list of threat agents and their related threats.

•   Risk, asset, and control owners are not always the same person, functional area, department, or organization.

•   Risk analysis is a detailed, focused examination of a risk performed as a part of an overall risk assessment.

•   The scope of an assessment determines the boundaries of inquiry and analysis of a process or system.

•   Well-known risk assessment standards include NIST SP 800-30 (Guide for Conducting Risk Assessments), OCTAVE, ISO/IEC 27005 (Information technology – Security techniques – Information security risk management), ISO/IEC 31010 (Risk Management – Risk Assessment Techniques), and ISACA’s Risk IT Framework.

Questions

1.   Awareness of new risks can be obtained through all of the following activities except which one?

A.   Security advisories

B.   Privacy incidents

C.   Budget reviews

D.   Audits

2.   In a discussion about the security of endpoint devices, one security professional described that some endpoints’ antivirus programs are not functioning correctly. What is this a description of?

A.   Threat

B.   Vulnerability

C.   Risk

D.   Threat model

3.   A security specialist is examining a particular preventive control and has determined that the control is not operating as designed. What term describes the state of the control?

A.   Undocumented

B.   Inefficient

C.   Fail-open

D.   Ineffective

4.   A risk analyst reviewing a business process has identified a control gap. What is the meaning of this conclusion?

A.   A control exists but is undocumented.

B.   A control does not exist.

C.   An earlier risk assessment determined that a control is not necessary.

D.   A new risk has been discovered.

5.   Several security professionals are discussing a recent security incident. The discussion is proceeding through the phases of the incident and the conditions preceding the incident in order to understand why those conditions occurred. What are the security professionals performing?

A.   Root cause analysis

B.   Incident debrief

C.   Incident forensics

D.   Reverse engineering

6.   What is the primary purpose for risk scenario development?

A.   To identify the highest rated risks

B.   To quantify the highest rated risks

C.   To prepare an executive briefing

D.   To associate risks with business objectives

7.   A risk manager wants to better understand the factors in particular business processes that could lead to an incident. What activity should the risk manager perform?

A.   Risk analysis

B.   Threat modeling

C.   Vulnerability analysis

D.   Root cause analysis

8.   Hackers, cybercriminal organizations, disgruntled employees, and hurricanes are known as what?

A.   Threat agents

B.   Threat actors

C.   Threats

D.   Attacks

9.   An auditor has contacted an organization’s data center security manager and has requested a walkthrough. What is the auditor asking for?

A.   A meeting to discuss one or more security controls

B.   A tour of the data center

C.   An explanation for a recent incident

D.   Interpretation of a security report

10.   What does NIST Special Publication 800-30 describe?

A.   A risk management methodology

B.   A risk assessment methodology

C.   Security and privacy controls

D.   Audit procedures for security and privacy controls

11.   A security analyst is finishing up a risk assessment and is about to identify the risk owner for each risk in the report. In general, who should be the risk owner for each risk?

A.   The board of directors

B.   The CISO or CIRO

C.   The CIO

D.   The related business process owner

12.   Which of the following is the best description of a risk register?

A.   A list of threat agents and threat actors

B.   A list of identified risks

C.   The root cause analysis (RCA) for a security incident

D.   A list of likely risk scenarios

13.   A risk manager is performing risk analysis on a specific risk to better understand the risk and to identify potential remedies. Various aspects of the initial risk and its potential remedies are scored on a scale of 1–10. What type of risk analysis is being performed?

A.   Qualitative risk analysis

B.   Quantitative risk analysis

C.   Semiquantitative risk analysis

D.   Factor Analysis of Information Risk (FAIR)

14.   An organization has performed a risk analysis of a complex scenario. Two different mitigation strategies have been approved that will reduce the original risk to a much lower level. The risk that remains after these mitigation strategies have been completed is known as what?

A.   Inherent risk

B.   Leftover risk

C.   Residual risk

D.   Accepted risk

15.   Which of the following is the best method for managing residual risk?

A.   Subject it to risk analysis and risk treatment.

B.   Retain it on the risk register and consider it as accepted.

C.   Retain it on the risk register and label it as closed.

D.   Add it to the cumulative total of risk tolerance.

Answers

1. C.   Awareness of risks can be obtained through numerous sources and activities, such as audits, incidents, advisories, threat modeling, assessments, and news articles. Budget reviews are an unlikely source of information about new risks.

2. B.   The matter of a failure of a protective control such as antivirus or a firewall is known as a vulnerability. The basic terms of risk, such as vulnerability, threat, control, and risk, are sometimes misused.

3. D.   A control that is not operating as designed is considered ineffective. To reach this conclusion, an analyst or auditor needs to understand the objective of the control and determine whether the control as it is presently operating meets that objective.

4. B.   A control gap is a situation where a control does not exist, but should exist. A control gap can also describe a situation where a control is not properly designed or implemented.

5. A.   A root cause analysis (RCA) attempts to get to the ultimate explanation of an incident, by proceeding backward through time to ask “why” specific conditions or events occurred.

6. D.   Risk scenario development is performed to associate specific risks with specific business objectives or business activities. Risk scenario development makes risks more tangible by describing their potential impact on the organization in business terms.

7. C.   A vulnerability analysis is a detailed examination of a process or system to discover vulnerabilities that a credible threat agent could exploit.

8. A.   Threat agents are the entities, human or not, that may perform actions that could cause harm to an organization, its processes, or its systems.

9. B.   A walkthrough with an auditor is a discussion where a control owner describes the operation of one or more controls and answers specific questions about them.

10. B.   NIST SP 800-30, “Guide for Conducting Risk Assessments,” is a step-by-step guide to performing qualitative and quantitative risk assessments. The standard also briefly describes the overall risk management life-cycle process to provide context for individual risk assessments.

11. D.   The owner of individual risks should be the business unit leader or department head that manages business processes most closely related to those risks. In rare circumstances, risks should be assigned to the CIO, CISO, or CIRO.

12. B.   A risk register is a master list of all credible risks that have been identified and are awaiting further analysis, treatment, or follow-up.

13. A.   Qualitative risk analysis uses a scoring scheme such as “high-medium-low” or a simple numeric scale such as 1–3, 1–5, or 1–10.

14. C.   Residual risk is the risk that remains after risk treatment (whether mitigation, transfer, or avoidance) has been completed.

15. A.   The best way to manage residual risk is to include it in the risk register and then subject it to the usual risk analysis, risk scenario development, and risk treatment.

CHAPTER 3

Risk Response and Reporting

In this chapter, you will:

•   Understand the concepts of risk and control ownership

•   Understand the various risk treatment and response options

•   Learn about the risk response process

•   Understand risk response options and how to align choices with business objectives

•   Understand how controls are designed, implemented, and evaluated

•   Learn methods to document and assess risk responses

•   Understand and define key performance indicators (KPIs)

•   Understand and define key risk indicators (KRIs)

This chapter covers Certified in Risk and Information Systems Control Domain 3, “Risk Response and Reporting.” This domain comprises 32 percent of the CRISC examination.

The CRISC Task Statements relevant to this domain address several key activities present in risk response and reporting, beginning with the collection of information about an organization’s business and IT environments as well as identifying impacts to the organization’s objectives and operations. This includes the identification and evaluation of threats and vulnerabilities and establishing accountability by assigning risk and control ownership. An IT risk register is used to document the risk profile. Identifying risk appetite and tolerance and conducting security awareness training help to promote a risk-aware culture. IT risk assessments and risk analysis help to identify control deficiencies that bring about risk responses, risk treatment plans, and the design and implementation of controls—all of which should be validated. Risk reporting includes the use and monitoring of key control indicators, key risk indicators, and key performance indicators. Assessments of controls and analysis of risks can help understand their maturity and effectiveness. New and emerging technologies should be evaluated to identify changes in risks. All of this should drive risk-driven decision-making.

In this chapter, we will review the concepts that comprise CRISC Domain 3, which is focused on risk response and reporting. There is a natural progression from the risk framing, analysis, and assessment discussions in the previous chapters, which covered CRISC Domains 1 and 2, to the discussion of risk response in this chapter; you will see that many of the outputs from those processes lead directly to this chapter because an organization generally wants a meaningful response to any risk to itself and its systems and data. After discussing how risk responses are chosen, we will discuss how to implement those risk responses, including how to design, develop, and adjust controls, and then, finally, how to report on risk.

Risk Response

Every organization has risk. The leaders of smart organizations, however, have determined how they will deal with that risk appropriately for their business context. Will they accept all risks? Will they transfer some risks to a third party, such as an insurance company? These are some questions that need to be considered within the risk response process, as discussed in this chapter.

We will also discuss the major control frameworks within the field and how they are incorporated into risk response. You should note that risk is different for every organization; risk within an educational context is different from a financial context, which is different from a government context. Also keep in mind that IT risks are different from business or mission-oriented risks. It’s important to note that the mission of the organization helps to shape risk responses as well. This is why it’s so important that organizations conduct a thorough risk analysis and understand and prioritize the response options that are right for them. You should also remember that the risks to the business, the business goals and objectives, and the systems supporting those functions should all be considered throughout the risk response process. It’s easy as an IT professional to forget that the business objectives are the top priority, but to maximize efficiency and effectiveness (and to pass the exam), you should keep that in mind.

Risk and Control Ownership

Risk and control ownership are issues that must be considered during a risk assessment and response. Depending on how the organization is structured and how the risk management strategy has been developed, risk ownership may be assigned to one or several different managers, spanning multiple functional areas. This is because the risk that affects one area likely affects other areas as well, so many different people may have responsibility over affected areas and be required to deal with and respond to risk.

Control ownership is also something that should be examined; often controls that provide protections for a given asset or a number of systems may not fall under the operational purview of the risk owner. Some controls span the entire organization and protect multiple assets, rather than only a specific system. These are referred to as common controls, and the responsible entity for these controls is the common controls’ provider. For example, consider physical security controls. There may be a physical security officer for the organization who is in charge of guards, personnel security, and physical access to secured areas. They may also be responsible for locks, closed-circuit televisions (CCTVs), and physical intrusion detection systems and alarms. All of these controls serve to protect information systems and data assets that might be in a secure data center. Risks may be presented to the person who is responsible for information systems in the data center, but the controls that serve to protect them may belong to the physical security functional area. This would require some coordination between the different functional areas if controls managed by one functional area are insufficient to protect assets managed by another area. This may also affect organizational structures, budget, and allocation of resources.

It is normally important that risk and control owners be identified and documented on the risk register. This helps assign responsibility and accountability for risks, the responses, and the controls. Additionally, the risk and control owners should be given the authority to carry out responsibilities in reducing risk and implement controls as needed. Both risk and control owners, as part of this authority, should have some level of control over budgets, personnel, equipment, and other resources required under the purview of their responsibilities. If owners are given authority to carry out their responsibilities, they can be held accountable when risk is not properly responded to or when controls are ineffective in reducing risk.

NOTE   Risk, asset, and control owners are not always the same person, functional area, or even organization. It’s important that you identify these particular owners early in the assessment process and maintain careful coordination and communication between these and other relevant stakeholders, within the boundaries of your authority and assessment scope. Having different types of owners can result in politically sensitive issues that revolve around resourcing, responsibility, accountability, and sometimes even blame.

Risk Treatment/Risk Response Options

Having developed your understanding of risk, you should also develop an understanding of the corresponding risk response options. These options will help you bring your risk down to a level of risk tolerance your organization can accept. Understand that this is not just merely responding to risk; risk treatment and response options should also meet the needs of the mission, business goals and objectives, and overall organizational strategy. A risk response option whose focus is only to reduce risk in a vacuum may interfere with the normal business operations or reduce the effectiveness of the business when performing its mission. Therefore, you should consider risk responses not just within the context of simply reducing risk; they must also reduce risk and not adversely impact business processes at the same time. Within this context, consider how you would recommend your organization respond to risk effectively but with a balanced approach. We’ll discuss the different risk response options in the next few sections.

Risk Mitigation

Risk mitigation generally involves the application of controls that lower the overall level of risk by reducing the vulnerability, the likelihood of a successful threat exploiting that vulnerability, or the impact to the asset if the risk were to be realized. Mitigation actions come in a number of forms; a policy requiring nightly offsite backups of critical data can mitigate the risk of data loss, for instance. Similarly, applying a newly released web browser patch can mitigate the risk of exploitation. The goal is to get the risk down to a level considered acceptable by the organization’s leadership. We will discuss controls and their implementation a bit later in the chapter, but for now you should understand that you may have to add new controls; update, upgrade, or even change controls; or even in some cases change the way your business processes work. All of these actions are designed to mitigate or reduce risk.

Risk Sharing

Risk sharing (often referred to as risk transference) entails the use of a third party to offset part of the risk. Risk sharing can involve the outsourcing of some activities to a third party to reduce the financial impacts of a risk event in many cases. Sharing offsite (co-location) assets and contractual obligations with other entities is one way that organizations implement risk sharing; a cloud service provider can be used within this scenario. The cloud provider might be contractually obligated to assume part of the financial impact in the event of a breach, but be aware that there is a potential loss of brand goodwill or other intangible assets that can be difficult to offload. Another example of risk sharing is the use of an insurance service to cover the financial impacts (at least partially) of a breach; however, the intangible losses mentioned previously would still be present. The point is that risk sharing (or transference) typically only works with a portion of the risk; it does not reduce all of the risk. Therefore, multiple risk response options used concurrently will likely be needed.

EXAM TIP   Don’t forget that use of a risk-sharing scheme does not totally absolve an organization of its responsibilities; organizations may still retain responsibility—and more importantly, accountability—if there is loss of data or revenue. Additionally, legal liabilities may also be involved.

Risk Acceptance

There will always be some level of residual risk, no matter how many controls you implement or the amount of insurance you purchase. Again, the goal is to get the risk down to a level considered acceptable by the leadership. Risk acceptance occurs when the active decision is made to assume the risk (either inherent or residual) and take no further action to reduce it. The word active is critical here; risk acceptance is different from being risk ignorant in that the risk is identified, alternatives are considered, and a conscious decision is made to accept it. A good example of this would be when you have taken all practical steps to reduce the risk of an attack from a malicious entity. Your organization may have installed perimeter security devices, strong authentication methods, and intrusion detection systems, which will reduce the risk significantly. However, since risk cannot be completely eliminated, there is always a chance that an attacker may enter the infrastructure through some other means. This residual risk may have to be accepted because it might be financially unwise to invest more resources into further mitigating the risk. Similarly, a company might choose to willfully ignore government-mandated control implementation that would incur fines or other financial penalties, assuming that the financial cost incurred would be less than the cost of implementing the controls. As we will also discuss, the value of the asset may be far less than the cost of implementing any mitigating controls, so in those cases risk acceptance may be the right choice.

Note that risk acceptance of any kind should be a formal management decision, and fully documented, along with provisions to monitor the risk, typically through the risk register. As with all risk response options, management should be cognizant of monitoring risk, since it frequently changes, and in turn make changes to the response as dictated by the changing operating environment, new technologies, and the threat landscape.

EXAM TIP   It’s important to note that risk acceptance doesn’t insinuate ignorance; it’s an active acknowledgment and conscious decision to accept risk as it is, assuming it is at a level that is comfortably within risk appetite and tolerance ranges.

Risk Avoidance

Risk can be avoided through a number of methods. Sometimes risk can be avoided by simply choosing not to participate in the activity that incurs the risk. For example, an organization may decide that a particular business venture or entry into a new market would incur far more risk than it is willing to take on. Perhaps you don’t need to conduct the activity at all. Avoiding risk can mean eliminating risk associated with a particular activity by not performing that planned activity. Risk avoidance is the option taken when, after all risk treatment options, including mitigating controls, have been considered, the level of risk is still not acceptable. An organization might choose not to take on a proposed project because of the probability of failure and subsequent loss of capital, for example. Another scenario might be the organization choosing to not adopt a cloud solution because of the level of sensitivity of information that would be stored within the cloud. In any event, risk avoidance does not simply mean ignoring the risk, as some people may be led to believe. Risk avoidance requires careful thought and planning as well as balancing the level of risk incurred in following a particular path versus eliminating the risk by not following that path at all.

Evaluating Risk Response Options

Risk mitigation, sharing, acceptance, and avoidance are all valid options you should consider using (sometimes at the same time) to lower the risk level you face. The key is to use these options together; you want to balance risk and reward to maximize the benefits. These benefits can be financial or some other, perhaps difficult to quantify, benefit (such as morale, partnerships, or long-term strategy).

One of the key considerations in balancing risk options is the cost and effectiveness of any response option. For example, as briefly mentioned, if the value of the asset to the organization is much lower than the security controls it would take to protect it, is risk mitigation or reduction the right option? You should also consider the effectiveness of the controls; if all possible controls you could implement still don’t reduce the risk to an acceptable level, are they worth it?

Other factors that should be considered in risk response options include those inherent to the organization itself. Sometimes organizational design and layout is a factor because how different divisions and departments are structured within the organization and who they report to affect resource allocation, chain of command, and so on. Sometimes these factors have to be changed in order to implement a good risk response. Other considerations are governance, including legal and regulatory requirements, and organizational culture. An example of how organizational culture can affect a risk response is when an organization determines that it needs to pull back administrative privileges from ordinary users—something that is very much frowned upon in the security community. While this response may not be expensive in terms of any required equipment or additional controls, the cost here is the shock to and pushback from the organizational culture. People normally do not like giving up what they already have, and administrative rights is one of those things that all users seem to believe that they need. Organizational culture will definitely be an impediment to implementing this particular risk response.

In evaluating and selecting risk responses, you should consider all the factors we’ve discussed previously, such as the cost of the response (and of the potential cost of not responding), organizational context and associated missions, risk tolerance, governance, and the simple ease of implementation.

Third-Party Risk

In today’s business world, an organization rarely functions independently from other entities. Most businesses are not entirely independent and self-sustaining; they depend on suppliers, service providers, and so on to help them bring their products and services to market. These third parties often perform services that are outsourced from the organization because of a lack of infrastructure or simply a desire to not perform these functions or services internally. A great example of a third-party service provider is one that provides cloud services to businesses, such as data storage, applications, and even entire infrastructures to organizations that don’t have the means or the desire to create the internal structures needed to manage them internally. Sometimes it is more cost effective for an organization to simply hire a third party to perform a function or provide a service than it is to expend the resources to create and maintain all of the equipment and processes itself.

If you recall the risk treatment options discussed earlier, transferring (or sharing) risk includes the use of third parties to bear some of the risk in performing certain business functions. Insurance is the classic example of transferring risk used in most risk management training texts, but this instance usually only provides monetary funds in case of a disaster or liability scenario. Transferring risk to third parties also includes outsourcing certain functions and services to third parties, so this, too, is a standard risk treatment method. The organization, for example, can reduce its risk of accounting and budget errors with a small, untrained staff by outsourcing its accounting functions to a third-party accounting firm.

It’s important to note that while this strategy of dealing with risk is effective and common, the organization is transferring only risk, not responsibility. The organization almost always retains final accountability and responsibility for functions and services outsourced to a third party. For example, transferring a business’s accounting functions to an outside firm mitigates risk by transferring some of it to the third party, but the organization is still ultimately responsible to its stakeholders, government regulators, banks, and financial obligations, even if the accounting firm makes an error. As another example, an organization that makes use of cloud data storage services still maintains accountability and responsibility for any data stored with a cloud provider if that provider suffers a breach that results in the release of sensitive information. While third-party providers may still incur some level of liability in these cases, the final liability rests with the organization that contracted with them. Liability, accountability, and responsibility are also some of the key risk factors with third parties that we’ll discuss next.

Third-Party Risk Factors

As indicated earlier, several risk factors relate to the legal aspects of dealing with third-party providers. Most of these risk factors deal with trust in the third-party provider or in dependencies the organization may have on the provider’s services. For example, the organization must be able to trust that the third-party provider will provide adequate security for any data that is maintained in its infrastructure. In addition to trust, other risk factors include interoperability with existing systems in the organization, data protection and security, and legal liability. Remember we said earlier that an organization can outsource risk to third-party providers, but the organization typically retains accountability, responsibility, and legal liability. Some legal liability, however, is levied on the third-party provider since it usually has a duty to provide services as well as assurances that those services will meet certain legal standards, as written in the contract between the provider and the organization.

The risk factors relating to third-party providers depend on the types of services provided as well as how the contract agreements are set up between the organization and the provider. Some contracts have cybersecurity provisions built into them. A document known as a service level agreement (SLA) is the key to reducing risk factors when dealing with a third-party provider. The SLA stipulates what the third party must provide in terms of level of service, performance, and so on. Some of these contracts are specific to the data type involved. For example, third-party agreements that deal with protected health information, called business associate agreements (BAAs), have cybersecurity provisions built into them. Another common approach is to have companies that are performing business provide responses to security questionnaires. There are standardized formats available on the Internet, but many companies rely on answers from security frameworks or they design their own set of questions to assess the security/risk. Companies that are more mature may perform their own assessments of cybersecurity, including doing their own audits, penetration testing, evidence gathering, and so on. In some cases, these can be just as intensive as an actual audit. All of these methods can be used as minimal cybersecurity standards for the third-party providers. In many cases, they result in findings that need to be remediated in order to conduct business (meet minimal risk thresholds).

Third-Party Threats

Like the risk factors mentioned earlier, threats associated with dealing with third-party providers primarily relate to trust and the contractual and legal aspects of those arrangements. Threats include failure to provide services as specified in contracts, failure to meet performance or security levels, failure to protect data, and loss of availability for systems or data to an organization’s users. Third-party providers can certainly succumb to some of the same threats the organization would, such as natural disasters and so forth. Therefore, some of the threats could also include loss of service or data for the business in some of these negative events. Third-party providers are also susceptible to hacking and malicious insiders, the same as any organization would be. Therefore, threats of data loss or disclosure are also present with third-party providers.

Third-Party Vulnerabilities

Vulnerabilities that result from associations or dealings with third-party providers include failure to adequately cover contingencies in contractual agreements, such as system or data availability or loss, lack of or inadequate security protections, and service levels that fall below an acceptable standard. Furthermore, any vulnerabilities that the third-party provider has inherent to its own organization are, unfortunately, indirectly incurred by any organization that deals with the third party, since those vulnerabilities could affect data in its custody or services provided to others. Examples of internal vulnerabilities that could affect organizations for whom the third party provides services include infrastructure vulnerabilities (such as patch or configuration management issues, loss of equipment, or malicious intrusion by hackers), organizational vulnerabilities (such as loss of revenue or bankruptcy), and even technological vulnerabilities (such as lack of sufficient encryption strengths or strong authentication methods). All these vulnerabilities could indirectly affect any organization that has a contractual agreement with a third-party provider.

EXAM TIP   Remember that even if risk is transferred to a third party, accountability and responsibility usually remain with the business.

Third-Party Risk Management

Managing third-party risk can be challenging and is an ongoing process. The initial risks may change due to a growing relationship with a business partner, additional data being sent to a third party, or the threat landscape affecting risks. Considerations for managing that risk may be performed yearly, as contracts change, as technology changes, and so on. As mentioned previously, some assessments are based purely on questionnaires, but there may be other tools that provide additional ongoing technical assessments of third parties. These can be used to help detect whether the effectiveness of a third party’s security controls is trending in a negative direction, which in turn can be used as an additional set of information to more completely inform risk about third parties.

Issues, Findings, and Exceptions Management

Rarely do our security processes and risk response efforts go as smoothly as we would like. There are always things that don’t go as planned. Sometimes there are contentions between security requirements, competition for resources within the organization, findings that cannot be easily mitigated, and other issues and exceptions that must be dealt with. These departures from planned activities, as well as from our established configuration baselines, are cause for concern, especially when we must implement solutions that are outside the normal security parameters we would like. Security and risk, like most things in life, involve compromise and balance. As security and risk practitioners, we are always trying to balance security, functionality, and resources, which always seem to be in conflict with each other. Security and functionality are almost always inversely proportional with each other; for example, typically the more secure a system is, the less functional it is for its users, and vice versa. Resources are always at a premium, and we never have enough money, qualified personnel, equipment, or facilities to achieve the level of security we would like. Additionally, risk itself is a give-and-take. We are often forced to accept a level of risk based on how cost-effective it is to implement controls to reduce the risk to a manageable level. In any case, how we deal with departures from the normal baselines, in the form of issues, findings, exceptions, and so on is critically important.

Change and Configuration Management

One of the primary sources of issues with our security posture, in the form of findings and exceptions, is our change and configuration management processes and status. Remember that change management is a formal management process designed to ensure that needed changes are carefully requested, considered, approved, tested, and implemented in a safe, secure, and predictable manner. The change management process, when implemented properly, should allow an organization to make major changes to the infrastructure without suffering unexpected or critical consequences. However, change management can cause issues if emergency changes must be made for security or other reasons, and there is simply not enough time to route the change through the organization’s change control board (CCB). There are also issues if people do not follow the steps of a proper change management process, and simply implement changes on the fly without approval. Both of these issues should be carefully considered because they could incur additional risk, represent an undesirable departure from the normal change process, and must be minimized whenever possible.

Configuration management brings the same challenges. While change management applies to major infrastructure changes, configuration management is a subset of that process and is specific to individual systems. Arbitrarily changing configurations without careful planning and testing could result in unstable or unusable systems. If emergency configuration changes must be made, this represents additional risk because there may not always be time for the formal testing and approval process. Configuration management is also impacted by older or legacy systems that cannot be updated in the event a critical security issue is discovered, such as a zero-day vulnerability. These problems could crop up during a vulnerability scan, where a vulnerability finding is discovered and the patch for that vulnerability either does not exist or cannot be implemented on an older system, or on a system that, if patched, would break line-of-business systems. This is where an exception would have to be considered: the company could either allow the system to operate under its current configuration, while acknowledging the security risk, or risk the impact of the update on the line-of-business systems, resulting in a loss of potential revenue. Even when the risk is considered and an exception must be made, this, again, is an undesirable departure from the normal process steps. We will discuss exception management in more detail in the next section.

Release management is also a subset of change management and, along the same lines, represents risks when software must be released ahead of its schedule or before it is adequately tested and considered for risk. The release management process must, as much as practical, adhere to scheduled releases that are tested as much as is practical and include risk-reduction measures. As discussed in the preceding paragraphs, emergency releases incur risk and should be avoided as much as is possible.

Exception Management

No matter how standardized security controls are, there are always exceptions, and you need to have a process in place to manage those exceptions and keep them minimized. Consider the example in the previous section where an operating system patch cannot be applied because of a legacy application that is critical to the organization’s mission. This mitigation is important, but less important than the legacy application and its associated mission. Exception management, as mentioned earlier, comes into play here; you should evaluate the risk of implementing the patch and breaking the application, thus putting the organization’s mission in jeopardy, versus the risk of not implementing the patch and dealing with the security ramifications that come with that decision. Management will have to make a decision regarding which is the riskier choice. If the choice is to make an exception and not implement the patch, you need to document this as an accepted exception to the policy and track it, usually in the risk register. Perhaps the patch can be implemented in the future, or another mitigation could come along and make the exception moot. This is another aspect of risk acceptance; you are asking management to accept an ongoing risk, as an exception, because the response cannot be implemented for whatever reason. Either way, keeping a close eye on the issue is key to not letting these exceptions slip through the cracks.

Regardless of where issues, security findings, and exceptions to normal processes, policies, or baselines occur, these departures should be avoided as much as possible, and when they cannot be avoided, they must be carefully considered, with great care taken to reduce the risks they present.

Management of Emerging Risk

Risk is not static; it is constantly changing. The dynamic nature of risk means that it must be constantly monitored, reassessed, and reevaluated, and risk responses will often need to change as risk changes. The components of risk, including threats and vulnerabilities, also change. The organization itself changes, as it is restructured, as its mission and goals change over time, as its place in the marketplace evolves, and of course as its risk appetite and tolerance change. Technologies also change, and organizations sometimes are in a hurry to adopt the latest and greatest technology because it becomes convinced that there is a need to do so; sometimes that need is indeed valid, but sometimes the technology marketing machine convinces an organization it has a need where before it did not. Emerging technologies, and their associated threats, vulnerabilities, risks, and, by extension, risk responses, must be constantly evaluated.

Emerging Technologies

New or emerging technologies can present risks to organizations simply because there are several different important considerations when integrating the latest technologies into the existing infrastructure. Many organizations have an unfortunate tendency to rush out, buy, and attempt to implement the latest (and often unproven) technologies on the market, without careful planning or consideration of the existing infrastructure and how it will react to the new technologies. One of the primary considerations organizations must look at is making a business case for a new technology, which may be to fill a gap that the older technology does not provide or to provide a capability that the organization must now have to compete in the market space. In other words, the company really must justify new technologies to make them worth the risk they could incur.

At the opposite end of the spectrum, many companies are averse to investing a great number of resources in new technologies, instead relying on older, tried-and-true technologies that have always worked in the past. These organizations fail to consider the changing threat landscape, and sometimes the need for maintaining a cutting edge in the marketplace. The threat landscape can render older technologies obsolete and ineffective in protecting the company’s information assets. The market a particular organization participates in can also drive the need to update its older technologies to those that make it able to produce goods and services faster, more efficiently, and to better meet the needs of its customers.

In any event, emerging technologies present challenges to organizations that must be considered. These challenges include the emerging risk factors, vulnerabilities, and threats that go along with those technologies. We will discuss those in the next few sections.

Emerging Risk Factors

Emerging technologies have several risk factors inherent to their integration into the existing infrastructure. If the organization has been able to justify the implementation based on a true business need for the emerging technology, it must consider several risk factors. One of the major risk factors is interoperability with existing infrastructure. Frequently, newer technologies don’t work properly with older systems right out of the box; adjustments might need to be made to the existing infrastructure to integrate the new technology, or bridging technologies may be needed to connect the two. Interoperability doesn’t just involve the right connections; it can involve data formats and flows, security methods, and interfaces into other systems. These considerations, and many others, are risk factors that must be considered before acquiring and integrating new technologies.

Another risk factor is security. New technologies may have security mechanisms that are not necessarily backward compatible with existing ones. Examples include encryption algorithms and strengths, identification and authentication technologies, integrity mechanisms, and even redundant or backup systems. Additionally, the systems may involve a learning curve that might intimidate users who must now learn new security methods for the system. The human factor can be a weak link in the security chain, so either a lack of training or a lack of adaptability to the new security mechanisms can introduce risk.

Additionally, system updates and changes can be risky if not managed properly. Integrating new technologies into the environment with older ones can introduce both intentional and unintended changes into the environment, affecting the stability of the organization’s implementation, operations, and maintenance of a particular system, so change is also a risk factor. Even in the disposal or replacement phase of a system’s life cycle, introducing new technologies to replace older ones can be problematic if not planned and executed properly. New technologies that are not adequately tested for functionality, performance, integration, interoperability, and security may not be able to adequately replace older systems, resulting in extended costs and possibly even requiring the extension of the older systems’ life cycle.

Emerging Threats

Threats resulting from the introduction of new and emerging technologies into the existing infrastructure are numerous. If the organization has failed to adequately plan for the new technology, these threats can become significant. These include untested or unproven technologies, non-interoperability, incompatible security mechanisms, and lack of suitability of the technology for use in the organization. The organization could also incur additional cost and require more resources because of a faulty implementation. These threats can be minimized by careful planning and integrating new technologies using a stable systems development life cycle (SDLC) model.

Additionally, organizations should implement both threat modeling and threat hunting processes into their security program when new technologies are considered. Threat modeling and threat hunting can help an organization identify not only the generic threats that affect all organizations, but those specific to its own business model, processes, assets, vulnerabilities, and risk scenarios involving the new technology.

Emerging Vulnerabilities

As with threats, vulnerabilities that go along with working with emerging technologies are numerous as well. General vulnerabilities could include a lack of trained staff committed to managing and implementing the new technology. Lack of adequate project planning is also a serious vulnerability that could affect the organization’s ability to effectively integrate new technologies. Another vulnerability could be a weak support contract or other type of warranty, guarantee, or support for a new technology or system. Most of these vulnerabilities appear when new technologies are first implemented and tend to become mitigated or lessened as the technologies are integrated into the existing infrastructure, but they still exist.

Beyond general vulnerabilities, new technologies also have their own inherent technical vulnerabilities. Often these vulnerabilities are not discovered until long after a technology has been implemented. Although vendors are increasingly security conscious in implementing and designing technologies from a secure perspective, zero-day vulnerabilities are often discovered months or even years after those technologies are installed and operational.

To make matters more challenging, some vulnerabilities are not detectable by vulnerability management tools. They are only detailed by the vendor, and only if they happen to detail them. In some situations, this makes monitoring the updates for the applications all the more relevant to ensure, including in the vulnerability management process.

When implementing a new technology, organizations should make an extra effort toward vulnerability scanning and assessment, and they should pay particular attention to new vulnerabilities, even those that seem unrelated to the new technology. Often these vulnerabilities could be indirectly related and appear because of interoperability or integration issues with the infrastructure.

In some cases, it may make sense to perform other types of validations against new technology—especially if there are additional risk factors such as large amounts of sensitive data. Validations may include but are not limited to penetration testing, secure configuration reviews, and application security testing.

EXAM TIP   The key areas of concern with emerging technologies are interoperability and compatibility. These two concerns affect the security, functionality, and performance of the new technologies when they are installed into an existing infrastructure.

Control Design and Implementation

A control is a measure or safeguard put into place to protect organizational assets (including systems, equipment, data, facilities, processes, and even people), ensure compliance with laws and regulations or other governance requirements, and reduce overall risk to the organization and its assets. Controls can help improve the overall security posture of your organization through correcting a gap or making up for a shortfall in another control. Controls can be technical solutions, such as firewalls or intrusion detection systems, but they can also be processes, procedures, policies, or physical controls.

In this part of the chapter we will discuss the various types and functions of controls as well as different control frameworks that can help an organization secure its assets. We will also discuss how an organization can design, select, and analyze its controls for effectiveness. Additionally, we will cover the particulars of implementing controls as well as control testing. So, how do you determine which controls to apply to your system or whether your existing controls are good enough? We will discuss this in more depth in the following sections.

Control Types and Functions

As you may have gathered by now, there are many types of controls to choose from. However, you can generally group these controls into a number of broad categories by their intended type and also by their function. Depending on which control framework you read, or which cybersecurity or risk expert you are talking to, these controls may be referred to differently, as some standards categorize them in different ways. However, for our purposes and for the CRISC exam, you need to understand three main types of controls: administrative (also sometimes referred to as managerial), technical (sometimes called logical), and physical (also called operational) controls. The following are examples of each.

Administrative (Managerial)

•   Requiring an acceptable use policy to dictate IT usage within the organization

•   Starting a risk management program to identify, lower, and monitor unacceptable risk levels within the organization

•   Implementing additional policies and procedures within the organization to support external governance and the desires of management

Technical (Logical)

•   Implementing additional firewalls to protect internal (non-public-facing) systems

•   Adding 802.1X port-based network access control to deter unapproved assets being added to the network

•   Installing an intrusion detection system/intrusion prevention system (IDS/IPS) to monitor for malicious activities or violations of policy

Physical (Operational)

•   Implementing physical intrusion detection and alarm systems throughout the facility

•   Deploying a human-based guard force to patrol sensitive areas

•   Construction of fencing, bollards, and other physical obstacles to prevent unauthorized entry into an organization’s campus

Controls are also categorized by function—that is, what purpose they serve and how they work. The most common control functions are deterrent, preventive, detective, corrective, and compensating. Table 3-1 lists each control type function, its definition, and an example of the control.

Table 3-1 Control Functions and Descriptions

EXAM TIP   Controls may be categorized by function, which includes preventative, deterrent, detective, corrective, and compensating controls. Often, controls can serve more than one function simultaneously, and it may be difficult to completely categorize them as one particular function or another.

Note that different control functions can fall within all three control types; there are deterrent, preventative, detective, corrective, and compensating controls that are technical, administrative, or physical. You will also notice some significant overlap between these types and functions. For example, video surveillance can be a deterrent control as well as a detective control. Also, since some experts do not distinguish between, for example, deterrent controls and preventative controls, it is important to point out their difference here.

A deterrent control must be known by an individual or entity in order for it to be effective since it dissuades them from committing a policy violation or an illegal act. For example, a video surveillance camera can be a deterrent control—if a person sees it in operation, they are less likely to commit a malicious act because they know they are being viewed and recorded. This deters them from that act. A preventative control, on the other hand, does not have to be known by an individual for it to be effective. An example of this would be a firewall rule that prevents a user from surfing to a malicious site. The user doesn’t have to know that the firewall rule exists in order for it to still be effective and prevent them from committing this policy violation.

Another difference worth pointing out is the one between corrective and compensating controls. As indicated in Table 3-1, compensating controls are implemented to take the place of a more desired or primary control, which can’t be implemented for various legitimate business reasons (for example, lack of resources). Even if the primary control can’t be implemented, the risk must still be reduced, so a control (or sometimes multiple controls) is implemented in its place. Compensating controls are longer-term controls, which are not likely to be changed anytime in the immediate future.

Corrective controls, however, are temporary, short-term duration controls. They are designed to correct an immediate security issue. For example, let’s say that a storm comes through your area and destroys a section of strong concrete wall surrounding your facility. Now there is a huge hole in the perimeter, which could allow an unauthorized person to enter at the facility grounds. To immediately mitigate this risk, you may post a guard to patrol that particular area for a few days until you can come up with something better. Obviously, keeping a guard there on a long-term basis is not wise financially or from a resource usage perspective. After a few days, you might be able to fix the wall, if possible, which restores the primary control to its operational state. If for some reason that portion of the wall can’t be fixed, however, you may install temporary fencing or another physical obstruction in its place, and supplement it with surveillance cameras, an intrusion detection system, and additional alarms so that it would reduce the risk of an intruder entering the area, without having to keep a guard there all the time. These might be considered compensating controls since the primary control (the strong concrete wall) can’t be immediately addressed.

As mentioned previously, control types and functions can overlap. They can also complement each other. For a given administrative control (for example, a policy that dictates that all sensitive data must be encrypted), there is usually a technical control, such as the encryption mechanism, and possibly even a physical control, such as hardware encryption devices being locked in a secure area, to back it up. Again, it should be pointed out that the various standards and frameworks, which we’ll discuss in a moment, often categorized these types and functions of controls differently, so don’t be surprised if sometimes you see them referred to in a different manner.

NOTE   Some professionals, texts, and frameworks also include recovery controls as a control function. These controls could include safeguards such as backups, redundant systems, and so on. While you likely won’t see this control function called out on the CRISC exam, simply be aware that sometimes you will see other control functions, as well as other control types, such as operational controls, in other contexts.

Figure 3-1 summarizes some of the key characteristics of controls and their implementation, with regard to types and functions. Note that, as depicted in the figure, controls that are designed to prevent a malicious act or policy violation are generally known as safeguards, whereas controls that come into play after a violation has occurred, and must be used to respond to the event, are called countermeasures.

Figure 3-1 Control characteristics and their implementation

Control Standards and Frameworks

Control standards and frameworks are defined sets of controls that can be used in a given set of circumstances, market, or area. Controls are often tied to governance directives and regulations, but this isn’t always the case. Sometimes different regulations or even process frameworks reference controls only to the extent that a control framework is required, but not to specify which control standard must be used. The Health Insurance Portability and Accountability Act (HIPAA) is good example of this scenario because HIPAA requires security and risk controls, but it does not specify which control set must be used (although HIPAA guidance does recommend the NIST control catalog). As another example, while references to controls are specifically called out in the ISACA Risk IT Framework (RR 2.1, “Inventory Controls,” and RR 2.4, “Implement Controls”), the framework itself does not give any clear guidance on how controls are defined, selected, or implemented; however, the assumption is that implementing the framework will show you how to use and evaluate whichever control set you choose. The NIST Risk Management Framework (RMF), in contrast, does provide guidance on how its controls are constructed, used, and assessed, devoting several publications to this subject.

Specific industry or market environments may require the use of specific, context-related controls, as indicated in Table 3-2.

Table 3-2 Examples of Areas Requiring Control Standards

Controls in a given framework are often organized according to a particular area or context, usually by functionality or relevance. For instance, the CIS and NIST control standards (discussed shortly) are broken down into areas, or families, which are categories that apply to a specific context. As an example, the NIST Physical and Environmental Protection (PE) controls address physical and environmental concerns such as physical access control and environmental factors (lighting, humidity, and temperature), whereas the NIST Program Management (PM) control family addresses management processes that often appear as administrative controls, such as formally appointing a responsible information security officer. Most other control frameworks discussed in this chapter similarly categorize controls, usually by process area or other relevant aspect of context.

TIP   You’ll find that most control libraries similarly group controls into specific categories based on function or context, and most use specific identifiers for each control.

Which controls from the various frameworks are used by an organization depends on several factors, including governance, market segment or area, level of regulation, and internal factors such as risk tolerance, risk appetite, and maturity of the risk management processes. We cover more of how controls are selected, designed, implemented, and used later in this chapter and in the other chapters, but suffice it to say for now that controls are usually developed and applied to specific risk scenarios. These risk scenarios are developed by the organization or industry as part of their risk identification process. They describe threats, threat actors, events, time, and other circumstances, but of course control assignment and use may be required by legal or regulatory governance, as well as the needs of the organization that intends to employ them. It’s also fairly common for an organization to use more than one control set or framework because it may apply differently to various aspects of the business or mission areas in an organization. For example, a hospital may use NIST controls for some areas but may also be required to use PCI DSS controls since it may process payments from credit cards as patients pay for medical services. Oftentimes, controls from more than one source are applied against one or more areas of the business.

In examining the various control frameworks, you’ll also find that there are many similarities between controls in some instances; often a control in one framework has a close equivalent in another framework. For example, CIS Control 10, “Malware Defenses,” loosely maps to the corresponding NIST control, SI-3, “Malicious Code Protection,” but describes a more generic process than the equivalent NIST control. There will also be controls that have no matching control or even context in another framework; these are often controls that deal with specific instances of risk or security requirements unique to a particular environment.

NOTE   Most control catalogs have controls that can be easily mapped to controls in other catalogs, although in some cases, this mapping may be imprecise, may not be as detailed, or may even map to multiple controls in another control library.

Control Frameworks

Now that we’ve covered some generalities about controls, it’s time to look at various control frameworks you might use in your professional career. Keep in mind that some control frameworks go into more depth than others on their controls; some controls in a given framework may treat a particular subject area lightly, whereas others may go into detail on a particular subject area. Also keep in mind that some control frameworks are geared toward specific environments or areas, and not all frameworks are necessarily geared toward security specifically; some frameworks apply to a broad general business or risk management area but may have security controls built into them for specific needs or direct security actions from a higher level. Not all control frameworks are technical in nature either; some frameworks apply to security and risk from a business process perspective rather than a technical perspective. Some control frameworks are privacy oriented and provide a different set of controls. The control frameworks described in the following sections are just some of the more popular ones you may encounter in your professional career as a risk practitioner.

NIST The U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) has produced several documents—some of which we have already mentioned—that relate to risk management. The entire Risk Management Framework (RMF), and all of its different components, spans several documents. We’re not going to provide a comprehensive review of the framework and its related documents here, but we will examine a particular piece of the framework: the controls catalog. NIST Special Publication (SP) 800-53, revision 5, “Security and Privacy Controls for Information Systems and Organizations,” is the control catalog supporting NIST’s RMF. The NIST controls are a comprehensive set of security measures and processes intended to mitigate and reduce risk from an IT security perspective. The NIST control catalog is divided up into 20 separate control groups, called families, each related to a particular aspect of IT security.

The NIST control families span a great deal of subject areas. Each family has several controls in it; there are smaller families (such as the Awareness and Training family) that may have as few as six controls, but there are others that have many different controls that go into great detail on security measures. An example is the System and Communications Protection (SC) family, with 51 controls.

EXAM TIP   You will likely not be tested on any specific NIST controls; however, it’s a good idea to have this knowledge in order to differentiate among the different control frameworks you may see on the exam, as well as for real life.

PCI DSS The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements levied on merchants that process credit card transactions. The standard was developed jointly by the major payment card industry players, including Discover, Visa, MasterCard, and American Express. The standard was developed in an effort to impose security requirements and controls on retailers (merchants and service providers) to reduce credit card fraud and identity theft. Note that PCI DSS is not a law; rather, it is an effort by the credit card industry to self-regulate. Although not a law, it does have the effect of being mandatory in terms of governance requirements; retailers must comply with PCI DSS to be allowed to process credit cards from the major industry brands. A few U.S. states, however, have codified into their laws the use of PCI DSS standards.

The PCI DSS (currently in version 3.2.1 as of this writing) is a set of six control objectives, broken down into 12 major requirements, which are further broken down into sub-requirements. Table 3-3 lists the basic PCI DSS requirements.

Table 3-3 PCI DSS Control Objectives and Requirements

On the surface, these objectives and requirements don’t seem to go into much depth. Understand, however, that PCI DSS further decomposes the requirements into detailed processes and procedures. The standard also provides guidance for testing at the control level. For example, requirement 5, “Protect all systems against malware and regularly update antivirus software or programs,” breaks down into four sub-requirements, some of which break down even further. Requirement 5.1.2, continuing the example, specifies continuous monitoring and evaluation of hosts for malware threats. Overall, there are actually more than 200 sub-requirements, which are the equivalent of controls.

EXAM TIP   You likely won’t be asked any PCI DSS control–specific questions on the exam, but you should keep in mind its applicability to merchants and retailers that process credit card transactions. You can find more detailed information on the PCI DSS standards at the website of the PCI Security Standards Council at https://www.pcisecuritystandards.org/security_standards/.

CIS Controls The Center for Internet Security (CIS) publishes 18 critical security controls, which are essentially areas or families that decompose into 153 individual safeguards, spanning three implementation groups. These 18 areas are similar to other control sets in that they cover areas of common security concern, including malware, penetration testing, inventory of software assets, account management, access control, and so on. The three Implementation Groups (IGs) are designed to provide a path for progressively implementing safeguards, with prioritization and scalability in mind, to help smaller organizations, or those that have limited resources, implement a minimum of 56 core security controls that are absolutely necessary to secure systems and data.

The CIS controls were formally known as the SANS Top 20 Critical Security Controls, before the CIS took responsibility for them in 2015. They were originally developed by an effort led by the National Security Agency (NSA) and many other government and industry partners. The most current version of the CIS controls is version 8, published in May 2021.

ISO/IEC 27001 Although we’ve primarily discussed different control sets that originate in the United States (such as PCI DSS and NIST), most of the various control frameworks map to, and in some cases originate from, standards used worldwide and developed by internationally respected governing bodies. In Chapter 1, we briefly mentioned some of these standards, including those from ISO and IEC. The ISO and IEC produce information technology standards used internationally, including several that apply to information security and risk management. You may see individual standards prepared by each of these organizations, but you may also see combined standards, usually indicated as ISO/IEC for those standards that are jointly developed. We discussed standards that applied more specifically to risk assessments in Chapter 1, but there are also ISO/IEC standards that are essentially control requirements. Two examples are ISO/IEC 27001:2013, “Information technology – Security techniques – Information security management systems – Requirements,” and its companion guide, ISO/IEC 27002:2022, “Information security, cybersecurity and privacy protection – Information security controls.” These two standards, like the ones discussed previously, break down their controls into different areas or categories and include areas such as information security policies, human resource security, asset management, access control, cryptography, and so on. Since the ISO/IEC 27001 and 27002 standards are developed by an international standards organization, they can be used across the globe.

As mentioned earlier, most of the control standards we have discussed have built-in mappings to help facilitate their implementation where organizations may have multiple governance requirements to which they are required to adhere. Both the NIST and CIS controls have mappings to the ISO/IEC standards, for example. In examining these control mappings, a couple points should stand out. First, there’s not necessarily a straight one-to-one mapping of controls. In some cases, the requirements for a given control in a control set may map to one, many, or even none of the other control set’s controls. Second, controls tend to follow similar patterns and requirements, such as acceptable use, password requirements, media and storage, encryption, and so on. Most controls from the various control sets have these commonalities because all of them in some way trace back to the three goals of security (confidentiality, integrity, and availability) as well as the supporting elements of identification, authentication, and authorization. This is generally true regardless of which security control framework you examine.

NOTE   You’ll find that many control frameworks are derived from and map to the ISO/IEC standards. They are international standards and can be applied across most industries and market spaces.

Control Design, Selection, and Analysis

The importance of designing, selecting, maintaining, and monitoring the right controls cannot be understated. Remember that controls serve three primary purposes: protecting assets, ensuring compliance, and reducing risk. If controls are not adequately planned for and implemented, they will fail to meet any or all three of these purposes. In the next few sections of this chapter, we will discuss the critical elements of control design, selection, and analysis.

Control Design

Controls are designed and applied to a system, data, process, or even organizational element to address a weakness or vulnerability or to counter a specific threat. Often, controls are designed to address a specific risk response strategy, such as risk reduction/mitigation, sharing, avoidance, and acceptance. Controls are applied to reduce the impact and likelihood elements of risk, as follows:

•   Reduce the likelihood of a threat agent initiating a threat (deterrence, preventative, and detection controls are examples).

•   Reduce the likelihood of a threat exploiting a vulnerability (preventative and detection controls).

•   Reduce the impact to the organization or asset if a threat exploits a vulnerability (corrective, compensating, and recovery controls).

•   Reduce the vulnerability (deterrent, preventative, corrective, and compensating controls all could perform this action).

Note that none of the scenarios listed earlier describes a case where a control prevents a threat or a threat actor. Threats and threat actors exist, and controls can’t really prevent their existence. Controls can, however, affect how they interact with vulnerabilities and assets. Also note that all these strategies may be pursued simultaneously in the case of controls that are well designed and effective, using the concept of economy of scale and multiple use of controls.

EXAM TIP   Remember that controls can affect the likelihood or impact of risk elements only by reducing vulnerabilities or protecting assets. They cannot eliminate or reduce threats or threat actors; they only serve to reduce the likelihood or impact resulting from an attempted or successful exploitation of a vulnerability by a threat.

Control Selection

When an organization selects controls to be applied to protect systems and minimize risk, several considerations come to mind. First, the organization should look at its governance requirements and ensure that its controls meet those requirements, particularly where specific data protection requirements are indicated. This may include level of performance or function of a control (encryption strength, for instance). The organization also has to look at its existing infrastructure. It is likely to already have some level of controls in place, although the controls might not be applied directly to the system in question. Take, for example, an organization that has industrial control systems and other types of operational technologies present. Many of these devices cannot support basic security measures, such as authentication or encryption; however, as compensating controls, the organization could implement network segmentation by putting them in their own physically or logically separated subnets and install authentication and encryption mechanisms specifically for those devices, since they do not have their own built-in capabilities. If there are existing controls that can already fulfill the requirements for a control, those should be used to the maximum extent possible.

Second, controls should be selected also based on their level of effectiveness, as indicated by the design parameters we discussed earlier. A control that is minimally effective, and perhaps meets governance requirements, may still not be desirable if it does not provide the level of security the organization needs. Effectiveness also may mean how good the control is at reducing risk or ensuring compliance. If either of these levels of functionality or performance are not met by the control, the organization should consider strengthening or changing the control.

Third, cost is also an issue with control selection. A control that costs $10,000 to implement but only protects a single system that is valued at $2000 is not cost-effective. However, a control that costs $10,000 and protects several systems, even if individually they are not high-value systems, but collectively generate $100,000 in revenue for the organization per year, is likely more cost-effective. Control selection with regard to cost should include the cost of the control as well as the cost to maintain it. This includes spare parts and components, service contracts, and the cost of qualified personnel to maintain the control. This is where quantitative data elements, such as asset value (AV), exposure factor (EF), single loss expectancy (SLE), and annualized loss expectancy (ALE), which you learned about in earlier chapters, come into play, since they affect whether a control is worth it financially to implement.

Ultimately, security and risk practitioners recommend controls based on their effectiveness and cost to management, who must make the decision regarding their implementation. If the desired controls cannot be implemented, for whatever reason, both the practitioners and management must consider selecting appropriate compensating controls, which must be approved and documented.

Control Analysis

Controls are analyzed at several different points in their life cycle. They are looked at to ensure they fulfill their basic functions of asset protection, compliance with governance, and risk reduction. They’re examined for not only effectiveness (how well they do their job) but also efficiency (meaning that they do their job with as little additional effort, resources, and management as possible). Even if a control is performing its job functions wonderfully, if the cost to maintain it is prohibitive, the organization may need to look at changing the control or its implementation in some fashion.

The most common way to analyze controls is through controls assessment, where controls are evaluated for their effectiveness. A control can be evaluated using various methods, such as interviewing key personnel responsible for managing and maintaining the control, reviewing the documentation associated with the control, observing the control in action, and testing the control through technical means. These different assessment methods will give a risk practitioner an idea of how effective the control is in meeting its primary functions.

Risk assessments for the specific system under review, as well as the entire organization, will also indicate how well a control is performing its function. Even if a risk practitioner is not examining a particular control, levels of increased or decreased risk for the system itself or the entire organization would indicate whether or not one or more controls are effective. Historical and trend analysis methods tell a risk practitioner how risk has changed over time. They also help the practitioner predict how risk will change, given changes in the environment, technology, the threat landscape, and how effective the control will be. If risk has increased inexplicably, the practitioner must analyze the different controls designed and implemented to mitigate that risk.

After controls have been tested and analyzed, results from those analyses should be recorded on the overall risk register, particularly with regard to risk the control is supposed to mitigate. Obviously, management must be informed of any changes in risk caused by control effectiveness issues.

Control Implementation

Controls aren’t simply installed in infrastructures, even in the event there is urgency to do so. As we have previously discussed, some planning goes into control implementation. Most of this planning focuses on determining the effectiveness of the control and ensuring it is designed to protect assets, assist in compliance, and reduce risk. There are also other considerations when implementing controls, including the change management process, configuration management, and testing.

Change and Configuration Management

Change and configuration management processes are critical during control implementation because, in actuality, implementing new controls is a change that occurs in the infrastructure and must therefore be part of the formal change control process. This involves requesting the change and presenting a justification as to why it is necessary. In this case, the change is necessary to fill a gap or need that an existing control (or the absence of a control) does not fill. Compliance may also drive the need for the change, since governance may require that the control be implemented. Risk reduction is also valid justification for implementing a control in the change management process. Once the change is requested as part of the formal process, it is reviewed by the change control board and approved or returned for amendments to the request. After it has been approved, it must go through the testing process. Once it clears the implementation testing process, discussed in the next section, the change is formally approved and implemented. If, for some reason, it does not pass the different types of tests it must go through before implementation, the change is returned to the requester so that any test failures can be addressed.

Control implementations may go through different types of implementation strategies, such as parallel installation and implementation with like systems, a gradual update to the system, a phased implementation, or even a clean cut-over with the system using the new controls. Since the installation may incur unacceptable downtime for critical systems, this must be carefully considered. The organization must decide the appropriate strategy, based on its resiliency, system and data criticality, and tolerance for any risks that always come with implementing a significant change in the infrastructure.

Implementation Testing

Although controls undergo testing at various points in their life cycle, testing before implementation is critical because often it is difficult to go back to a previous control or a point in time before the control is implemented. This is especially true if the infrastructure is significantly altered to accommodate the new control. Consider a network infrastructure that has a new firewall or other network security device installed. The network may have to be rerouted and reconfigured and new rules configured on the network security device. If for some reason it is installed without testing and then fails, it may cause serious impact to business operations if users cannot use the network, get on the Internet, or otherwise are unable to perform their duties.

Several types of implementation testing should occur on new controls before they are implemented. One of the first is interoperability testing. Interoperability is critical since the new control must work with existing technologies and infrastructure. If for some reason they do not work together, this can cause work stoppages or outages and will impact business operations. A risk analysis conducted before implementing a new control should take this into account, and the organization should be reasonably informed about how the new technology or control will interact with the existing infrastructure before it is tested and implemented. Another type of testing involves testing security mechanisms that are inherent to the new control, such as authentication and encryption mechanisms. Not only should they be interoperable with existing infrastructure, but they should also be tested for function and performance as well as compliance with any governance. It would not do to install a security control that has legacy authentication or encryption mechanisms that do not meet governance requirements, for example, and therefore fails to protect systems and data.

Testing a control, especially a complex one, before implementation ensures that it is interoperable, satisfies technical requirements, meets governance requirements, and performs and functions as it should. Understanding the limitations and operating parameters of a complex control through testing before implementation is in itself a method of risk reduction.

Other Implementation Considerations

It goes without saying that implementation of a complex control has many more aspects to it than are discussed here. Some of these are resource considerations, such as having enough money in the budget, having enough qualified people to install, manage, and monitor the control, not to mention political considerations within the organization. Consider the implementation of a relatively “easy” control, such as revoking administrative rights on user workstations. Not only will users typically revolt, but managers who are used to having administrative rights over their own workstations will complain and likely go to upper management, who may cave in to those complaints, effectively rendering the control useless. Users also typically balk at having their systems offline for any amount of time since it may interrupt their work. All these issues should all be carefully considered and decided upon by management, or at the very least kept in mind by the risk practitioner.

Another aspect of control implementation is documentation. All steps of the implementation should be thoroughly documented, as well as any exception items, such as configuration or interoperability issues that may need to be addressed later. Documentation also includes policies and procedures to support the control, change management records, implementation test results, operator training materials, schedules for maintenance, and any other information relevant to the control.

Control Testing and Effectiveness Evaluation

Control testing and evaluation, as well as analysis, were discussed earlier in the chapter, but they bear repeating here. Controls must be tested and evaluated not only prior to implementation, but also at various points during their life cycle. Controls should be tested and assessed as part of routine risk assessments, controls testing, vulnerability and penetration testing, and so on. Controls are tested not only for their effectiveness in protecting assets, but also their compliance with governance and their ability to reduce risk to acceptable levels. Remember that earlier we discussed four methods for testing a control:

•   Interviews with key personnel, such as operators, security analysts, engineers, and even managers

•   Observation of the control in operation to ensure it does what it is supposed to do

•   Review of any documentation supporting the control, such as policies, procedures, maintenance records, architectural diagrams, exceptions, and so on

•   Technical testing, such as that conducted during vulnerability assessments and penetration testing

All of these different types of tests are critical in getting the complete picture of how well a control is functioning and performing. The results of control testing should be documented and reported on in various circumstances as part of different assessments and tests.

Controls that fail testing or do not perform or function as expected should be further evaluated in more detail for any possible changes and any additional increase in risk. A control may need to be reinstalled, replaced, or upgraded, or compensating controls may need to be added to strengthen the function the control is meant to perform.

Risk Monitoring and Reporting

What are the reporting requirements for your organization? Are they dictated by government regulations, international business partnerships, or other binding agreements? Understanding what is required of your organization in terms of reporting risk is absolutely critical in fulfilling governance requirements, whether they are imposed by external sources, such as laws and regulations, or by internal governance, such as policies published by executive management. You also need to understand what you should report in any of these contexts. For example, it is a good idea to report any ongoing risk issues you have, the status of any ongoing remediation actions, how your controls are performing, any incidents, and how your overall risk response activities are performing.

Along with understanding the organization’s risk environment, it is important to understand your stakeholders and what their reporting needs are. For example, your board of directors will likely want a high-level, quarterly presentation on compliance levels relative to the previously discussed risk and control environment, as well as security performance relative to business goals and objectives. Business process owners, conversely, may want a much more detailed report about the individual risks identified previously, the new risks that could potentially come to the forefront, and how different business units are supporting the risk management program across the entire organization. It’s important that you understand how these different stakeholders need different reporting mechanisms and tools and that you identify clearly how they expect you to support them through timely and relevant risk reporting.

When reporting, you can include a few standard items, such as measured control effectiveness (which can be rolled up to a higher level, as necessary, for management), any ongoing issues, any perceived gaps, the status of any remediation actions, any incidents or risk events that have occurred since the last report, and the overall trending status of the effectiveness of the risk management process. Also, identify ahead of time whether your report will be included as an input to a greater enterprise report and work to include any appropriate information needed to facilitate that enterprise-level view. This will help garner support for the risk program supporting the business goals and objectives.

You should review the results of any third-party analysis or audit that has taken place and incorporate the findings into your understanding of the organization’s risk posture. Has your organization conducted any type of internal audit or self-assessment? These will be important to review to see how they affect the risk profile and where they will need to be included. We’ve discussed the organization’s tolerance for risk in many places throughout this book, so suffice it to say that the risk tolerance should be considered throughout the reporting process as a key input.

In the end, in order to develop a report that is valuable to management, a risk professional needs to make sure they have a clear understanding of the exposures their organization faces, the active mitigations for those exposures, and the indicators being used to measure the success or failure of the organization’s implemented control set, as well as the current risk posture as measured against the risk appetite. This all needs to be communicated to the stakeholders. The importance of articulating risk should not be underestimated; this is a critical task that ensures management receives accurate and unbiased information that is both actionable and supports the overall organizational risk strategy.

Responsible reporting involves helping leadership understand the risks to the organization and how critical it is to support its reduction through implementing appropriate controls, as well as monitoring and managing risk. This needs to be done in the most clear and concise manner possible, understanding the concepts of risk, the indicators that have been chosen, and the current statuses that allow leadership to make the best-informed decisions possible. Without the best possible information, we cannot expect organizational leadership to make informed decisions. You will also need to interpret technical findings and perhaps portray information in a manner that is less technical and more business-focused. By doing this, you will not only make the point that the risk program is useful, worthwhile, and supports business goals and objectives, but you will also identify opportunities for the risk program (and associated reporting) to integrate throughout the enterprise more cleanly.

No communication is complete without thoroughly understanding and depicting both the worst-case and most probable scenarios involved with a risk event. A risk event could mean many potential losses take place, and not only those affecting the company’s financial bottom line. There could be losses to the company’s goodwill, including any associated brands. Think about major security breaches in previous years, such as Target, T.J. Maxx, and Sony. The result of their losses was both tangible (financial) and intangible (brands associated with a major breach), which is difficult to quantify. This is also the time to include any other information pertinent to supporting the recommendations you’ve made, such as situations where a financial gain could be made (through exploiting an opportunity), or any outlying legal or regulatory concerns you might have.

Risk Treatment Plans

While reporting may at first seem to be only an occasional aspect of risk management, it actually takes place on a continual basis. Obviously, risk assessments, control assessments, and different types of tests have their own reporting requirements that will be accomplished when those test events are completed. However, reporting can also take place as continual information is sent to management on a regular basis.

Some of the most critical pieces of information that should be reported to management, regardless of a point-in-time test event, are risk response and treatment options and any plans used to implement those options. Management should always have the opportunity to review risk treatment options as they are developed, and risk practitioners have a responsibility to make those recommendations formally to management so that leadership can make the appropriate decisions regarding those particular treatment options. Understand that simply because a risk practitioner recommends specific treatments or responses, this does not necessarily mean that management will approve those options. Alternative risk treatment responses may be approved instead, based on information the risk practitioner doesn’t necessarily have or the priorities of management. This is particularly true when risk treatment options are expensive and management is seeking to reduce cost, but balance that with effective risk response at the same time. It is also true if management needs to make a broader decision, such as one that may involve risk avoidance, for example, by taking an entirely different strategic path within the business. When reporting on risk treatment options, you should always present the best recommendation, but also always have alternatives developed for management to consider. In any event, it’s important to convey risk treatment options, as well as their progress, to management on a continual basis, not merely after they have been implemented.

Data Collection, Aggregation, Analysis, and Validation

In order to make recommendations on risk treatment, risk practitioners must have a wide variety of data at their disposal. The data must be trustworthy and accurate as well as complete. A risk practitioner can take advantage of multiple sources of data. Technical data, such as logs, can show how a control is operating. Real-time data regarding intrusion detection alerts, user behaviors, and so on is also helpful. Other data, in the form of risk reports, incident reports, change and configuration management documentation, as well as information derived from control assessments should be used to help inform risk management decisions. The vast multitude of data available to the risk practitioner, however, might not be useful to an executive manager. It’s the job of the risk practitioner to take all this data and distill it down into useful, actionable information that clearly and concisely conveys how effective a control is, how it is meeting compliance requirements, and how it reduces risk. This information should also convey particulars about changes in risk and how these changes impact the organization.

Regardless of the source of the data risk practitioners use to perform risk management activities, the data must be collected in a sound and verifiable manner and validated as true and accurate. This is where formalized and documented data collection and analysis processes can assist. Some data may be collected in an ad hoc manner, but for the most part, data should be collected on a regular basis, from verified sources, and validated using various integrity-checking methods. The data must also completely describe the situation in the proper context and, of course, be analyzed by qualified risk practitioners and cybersecurity personnel. Data may be synthesized into useful information by reducing it, clarifying it, and performing trend or historical analysis on it. In any event, information supplied to management needs to present a clear, concise, and accurate picture.

Risk and Control Monitoring Techniques

The techniques used to monitor and assess risk, as well as control effectiveness, should be part of a formalized methodology adopted by the organization. This is where the overall risk strategy and associated policies and procedures come in. The risk strategy is management’s commitment to risk management and provides an overall long-term direction for where the organization wants to be in terms of managing its risk. The risk strategy is a high-level document and does not necessarily go into detail on the day-to-day risk management activities in which an organization must engage. The risk management policy, on the other hand, should go into further detail on the overall risk management program. This policy should be handed down by management, with consultation from the risk practitioner. It should assign roles and responsibilities as well as dictate what risk management, assessment, and analysis methodologies the organization officially uses. The policy can also define risk treatment options and how they should be considered. Most of the details required to implement the policy and, in turn, the strategy will typically be included in various lower-level risk management procedures, such as procedures used for risk assessment. In any case, the organization’s risk management and monitoring processes should be standardized and approved by management for consistency, reliability, and predictability.

Risk and Control Reporting Techniques

Reporting on risk and controls may use various techniques to convey data in a clear, accurate, and complete manner. Some techniques lend themselves to reporting better than others; narrative reports may often be undesirable except where a great deal of technical data is needed to support a recommendation or decision. Graphics and charts, on the other hand, are sometimes better suited to convey the bottom line to management, without all the unnecessary details involved in a technical explanation. Other data presentation techniques, such as statistical, historical and trend analysis, in the form of graphs or bar charts, may be useful to present data in the right way so that management can make an informed decision.

Some of these data reporting techniques include heat maps, scorecards, centralized dashboards, and real-time information feeds. Heat maps focus on data that shows areas of red, yellow, and green, for example, with data points in red (darker) being the obvious areas of concern, and data points in the green (lighter) areas being of lesser concern. Figure 3-2 shows an example of a heat map.

Figure 3-2 An example of a heat map

Scorecards are used to collect pieces of data and offer a comparison with other pieces of data, showing a relative performance or effectiveness increase, compared to previously collected data. Centralized dashboards, along with real-time information feeds, have the goal of showing a one-stop single view of all the necessary data points risk practitioners and managers need to view, often in real time, the status of control effectiveness, compliance, or risk. Often, however, these dashboards can seem to be very complex and “busy” with information, so extra effort must be taken to ensure they only display critical information, in the most simplistic manner possible, while allowing a risk practitioner or manager to “drill down” further to obtain more details about a piece of data in the dashboard.

Regardless of the data presentation technique used, reporting must be clear, accurate, and complete, and it must convey the critical information needed for managers to make meaningful risk-based decisions.

Key Performance Indicators

We have discussed the necessity to test, assess, and evaluate controls as well as risk itself. Remember that we’re trying to ensure that controls are effective, meet compliance requirements, and reduce risk. In order to determine those things, we have to measure different aspects of the control’s performance characteristics, both positive and negative. For this we use various pieces of information, called indicators, to help us measure these items. Once we identify these indicators, we can move toward the indicators associated with measuring and reporting that performance, and current risk levels, accurately and efficiently.

You will often hear indicators referred to as metrics, and in this text, those terms are interchangeable for our purposes. However, the types of indicators, and what they measure, differ. Key performance indicators (KPIs) are used to understand and enable the measurement of control performance. Control performance can be anything from how often your firewall blocks malicious incoming traffic to how often your continuity of operations plan is exercised. The level of “performance” can be different for each organization; it’s important that you determine performance goals unique to your organization, based on its own performance goals as well as its risk appetite and tolerance levels.

So why do you need indicators? How do you know if you’re doing well (or poorly)? Do you trust your risk team, hoping that they have some sort of reporting mechanism that will present stakeholders the correct information? At the end of the day, you want to be able to monitor and analyze those indicators to track trends and determine the effectiveness and efficiency of the controls, and to make decisions for creating new controls, ditching others, and sounding the alarm when risk has passed a predefined threshold.

Understanding what a KPI means to your organization requires you to ask yourself a few questions. What is your organization’s mission? Are you a research organization attempting to develop a new cryptographic algorithm? What things are important to your organization? Does it value availability above all other attributes (that is, the ability to conduct business through any fire, storm, hacking attempt, or any other scenario it may encounter)? Or does your organization value data privacy and security above any other consideration? These are questions you need to ask yourself when developing KPIs. Remember that these KPIs help you understand how controls are performing to enable all these attributes. You want to make sure the controls are performing at the level you expect.

Ideally, KPIs should be “S.M.A.R.T.” in order to be most effective. In other words, KPIs should be

•   Specific

•   Measurable

•   Attainable

•   Relevant

•   Timely

When a KPI is S.M.A.R.T., it is tailored to the organization and the area being measured. The first question you need to answer is, what are you trying to measure? You should be, according to the S.M.A.R.T. methodology, specific. Are you attempting to measure availability? Then you may want to look at a metric that measures how often your systems go down—or, conversely, what is the percentage of time your systems are up?

A KPI also needs to be measurable, in a way that is ensured to be accurate. In the case of the availability, how would you measure it accurately? Perhaps you could determine how often the systems went down based on the “uptime” command in the UNIX operating system.

When a KPI is attainable, it is readily achievable. For example, you wouldn’t want to set a performance goal of 100 percent uptime in a situation where you have an entirely new staff, new equipment, new management, and so on. Perhaps 85 percent is more achievable, and then you can work toward a higher goal.

KPIs that are relevant matter to your organization. If you’re in a situation where time is of the essence, such as stock trading, then availability is essential. Without availability, your systems cannot buy or sell stocks, and your user base will quickly move on to another organization that values availability as much as they do. However, other contexts, such as educational institutions, may not care so much about availability. Usability might be of more concern, or the ability to access content via mobile applications or other cutting-edge technologies. Take the time to consider what’s important or relevant to your organization when determining your KPIs.

Finally, timely KPIs allow the data to be collected when needed to quickly determine the performance of your measured initiative. You should be able to obtain data for the metric relatively easily from existing sources and repositories.

In some instances, a KPI may not meet all the criteria of S.M.A.R.T. For example, a firewall may block a number of external attacks per month. Depending on the organization, there may be nothing to attain, but most of the S.M.A.R.T. criteria is still met. This is perfectly fine in some circumstances.

Key Risk Indicators

Risk indicators are metrics, much like KPIs, used to determine if and when the organization has a high probability of risk that exceeds the defined risk appetite. Not all risk indicators, however, are key. Key risk indicators (KRIs) are considered to be highly probable indicators designed to accurately predict important levels of risk based on defined thresholds.

Along with determining the level of performance for our controls, we need to determine ways to indicate the risk that our organization is subject to. KRIs are related to, but separate from, KPIs, in that KRIs are all about how the metric predicts current and future risk rather than past performance of a specific control or set of controls. KRIs are linked to specific risks and provide an early warning alarm that a risk is emerging, allowing leadership to be proactive and deal with that risk sooner rather than later.

ISACA’s Risk IT Framework includes the following criteria to select KRIs:

•   Impact When a risk indicator has a high impact, it is likely to be a KRI.

•   Effort to implement, measure, and report When all else is equal, the easiest indicator to measure from is the best.

•   Reliability The indicator reliably predicts an outcome.

•   Sensitivity The indicator accurately indicates variances in the risk.

Similarly to the determination of KPIs discussed earlier, KRIs should be S.M.A.R.T., and they should drill down to the root cause and not just focus on the symptoms that are immediately evident. KRIs should include lagging indicators (indicators that determine current risk after an event has occurred), leading indicators (which indicate the controls in place to prevent an event from occurring), and trends (which consider patterns in the data that indicate risk). Root cause analysis is also important here in order to determine the root cause for any risk, not just the symptoms. This is where risk assessments and analysis, control evaluations, and other types of data collection and tests come into play, to give you this information.

Key Control Indicators

As discussed previously, KPIs are used to understand and enable the measurement of control performance. Key control indicators (KCIs) are often used interchangeably with KPIs, but they are really a subset of KPIs, since some KPIs don’t necessarily relate to controls. KCIs are those specific indicators that show the relative effectiveness of controls. This effectiveness, as mentioned before, can be in how well a control protects an asset, how well a control helps with compliance with governance (for example, the number of compliant versus noncompliant controls), and, probably most importantly in our context, how well the control reduces or mitigates related risk. It is important that the control indicator focus on the specific control as well as the particular risk that the control is meant to mitigate. Associating a KCI with a broad spectrum of risk is not effective; it should be associated with a very specific risk scenario. For example, a KCI could indicate effectiveness of the control in terms of risk reduction, by showing how it reduces the impact of a particular risk scenario for a given asset, the likelihood that a threat will exercise a particular vulnerability, or the vulnerability itself.

KCIs should be developed based on the known performance tolerances of the control. You should determine what the normal operating parameters for the control are and what should be expected based on how the control is configured and implemented. Baselining control performance is important so that you understand what normal operation looks like. Abnormal or anomalous operation, such as a sudden spike in unknown network traffic, may indicate that the control is not operating within its normal range. This, in turn, shows the control may not be as effective as it should be.

Examples of key control indicators might include, but are definitely not limited to, the following:

•   Bandwidth utilization

•   Number of false positives or false negatives detected

•   Number of instances of malware detected

•   Number of incidences per month attributable to user complacency or policy violations

•   Number of vulnerabilities discovered during a scan

Additionally, not all KCIs have to be technical in nature, although those likely are the majority of the ones many organizations concern themselves with. KCIs can be developed for not only technical controls but also administrative and physical controls as well.

Chapter Review

Once an organization has assessed and analyzed its risk, it must respond accordingly. In this chapter we discussed several key areas of risk response, including the different risk treatment and response options. Risk and control ownership are key to responsibility and accountability for risk response. Risk and control owners are not always business process owners, although they could be. Sometimes controls are dispersed across an organization and protect multiple assets in several areas at once. These are called common controls, and the control owners are common control providers. These entities are responsible and accountable for risk and its mitigation, respectively, and must be given the authority to carry out their responsibilities.

Risk treatment and response options include risk mitigation, risk sharing or transference, risk acceptance, and risk avoidance. Risk mitigation involves the reduction of risk through the implementation of adequate security controls. Risk sharing involves transferring risk to a third party, such as a cloud services provider, or through insurance. Note that even if risk is shared, responsibility and accountability are retained with the organization. Risk sharing usually involves offsetting financial responsibility or liability in the event of an incident or disaster. Risk acceptance means that the organization must accept any remaining or residual risk after all other risk response options have been implemented. Risk must be formally accepted and documented as well as monitored through the risk register. Risk avoidance does not mean simply ignoring risk; it means that an organization has chosen a different path or solution that eliminates a particular risk associated with an activity. Evaluating risk response options involves considering many factors, including the cost effectiveness of controls and how much they reduce risk versus the cost of the control and the asset’s value, organizational structure, governance, and other factors. More often than not, more than one risk response is necessary.

Third-party risk management involves considering all the different threats, vulnerabilities, and other risk factors inherent to engaging with third-party providers. Third parties incur many of the same vulnerabilities and threats that other organizations do, including external attack, infrastructure and system vulnerabilities, governance issues, and so on. Key considerations with third parties include contractual obligations to protect data, division of legal liability, data ownership, and so on.

Issues, findings, and exceptions management means the organization must have proactive measures in place to reduce risk when situations or events occur that are out of the normal processing parameters or configuration baselines. Examples of these cases include vulnerabilities that cannot be easily remediated, exceptions to security policies, and compliance findings. Each of these types of events should be considered carefully for risk and mitigated as much as practical by the organization. In the end, exceptions may have to be made, but they must be formally approved by management after due risk consideration, thoroughly documented, and monitored through the risk register.

Risk is dynamic; it changes according to the operating environment, new technologies, the threat landscape, and organizational changes. These emergent risks must be considered, since they may present unknown vulnerabilities that might not surface for a long time after new technologies have been implemented or the environment has changed. Emerging technologies are a key source of emergent risk, and organizations must be careful about the rush to implement those technologies. The implementation of emerging or new technologies should justify a valid business need, and appropriate risk assessment and analysis should take place before their implementation. Risk responses should be changed based on those emergent risks.

Security controls are measures or safeguards implemented to protect organizational assets and reduce risk. The three general types of controls you must understand are administrative, technical, and physical. Administrative controls usually involve policies and procedures, technical controls involve equipment and software, and physical controls involve physical barriers used to protect people, equipment, and facilities. Control functions are divided into five general categories: deterrent, preventive, detective, corrective, and compensating. Deterrent controls must be known in order to be effective. Preventive controls do not have to be known in order to prevent a violation of policy or illegal act. Detective controls are used to discover a violation of policy or malicious act. Corrective controls are temporary in nature and are used to solve an immediate security issue. Compensating controls are more longer-term controls and are used when a primary or desired control is unavailable. There are several control frameworks published by various entities, including government and professional frameworks. Examples of these include the ISO/IEC 27001 controls, the NIST controls, and the PCI DSS control set.

Controls are evaluated and selected based on their effectiveness in protecting assets, the level of risk they help to reduce, and compliance with governance. Controls are also evaluated based on cost-effectiveness. If the cost of an asset and its continued maintenance versus the revenue it produces or its value to the organization compared to the cost of the controls used to protect it do not correspond, a decision must be made whether to implement the controls for the asset.

Several considerations go into control design, including reducing risk elements such as the likelihood of an event occurring, the impact to an asset, and the severity of the vulnerability. Threats cannot normally be reduced through controls, but their interactions with the organization can be mitigated through properly designed controls. Controls are selected based on several factors, which include the cost to acquire and maintain, the level of risk they reduce, and the amount of protection they offer. Existing controls in an organization can be leveraged if they provide the proper security protections and are interoperable with all systems. If desired controls cannot be implemented, compensating controls must be considered. Controls are analyzed at different points in their life cycle, particularly during installation and periodically to ensure they are still effective, comply with governance, and reduce risk. Controls may need to be updated or changed periodically when technology changes, the controls become outdated, threats to the organization increase, and the operating environment changes.

Control implementation must consider how the control will interact with the infrastructure. Change and configuration management processes are critical to ensuring the safe, secure, and stable implementation of new security controls. Both before and after controls have been installed, they should be tested to ensure they meet functional and performance requirements and are interoperable with the existing infrastructure. Controls must also be documented thoroughly and any risks should be included in the risk register. Controls must be periodically tested during various assessments by interviewing those responsible for maintaining the controls, reviewing all documentation related to the controls, observing the controls in operation to ensure they fulfill their security functions, and testing the controls through technical means.

Risk monitoring and reporting are necessary to conveying control and risk information to management. Internal management policy as well as external governance will drive reporting requirements. Risk practitioners should understand reporting requirements as well as stakeholder needs so that they will be able to report data with clarity, accuracy, completeness, and timeliness. Risk treatment options and plans should be conveyed to management through reporting channels on a periodic and as-needed basis, rather than after the risk response is complete. Data used to create information for consumption by managers should be accurate, complete, and trustworthy. Risk practitioners must determine, based on their audience, how the information is presented using various techniques. Risk control and monitoring techniques should be part of a formally approved risk management methodology and promulgated in the risk strategy, policy, and procedures. Various risk reporting techniques exist, including narrative reports, scorecards, graphs, and real-time information feeds such as those that are part of a centralized management dashboard.

Key performance indicators are pieces of information that measure and show performance levels of different aspects of the security and risk management programs. Key risk indicators show how risk has changed. Key control indicators show how effective controls are functioning and performing as well as ensure compliance and reduce risk.

Quick Review

•   Risk response is what is needed after risk has been appropriately assessed and analyzed.

•   Risk and control ownership must be carefully considered as part of risk response.

•   Business process owners are not necessarily risk or control owners.

•   Controls that span the entire organization are called common controls.

•   There are four generally accepted risk responses: mitigation, sharing or transference, acceptance, and avoidance.

•   Risk mitigation means to reduce risk through the implementation of controls.

•   Risk sharing allows an organization to transfer some of the risk to a third-party provider or through insurance.

•   Risk sharing does not absolve an organization of its responsibility, accountability, or legal liability.

•   Risk acceptance means to take on any leftover risk after all other risk treatment options have been implemented.

•   Risk avoidance does not mean to ignore risk; it simply means to avoid actions that result in the risk.

•   Evaluating risk response options involves considering several factors, including cost, effectiveness, value of the asset, the organization, and governance, as well as other external factors.

•   Third-party risk management means that the organization must manage any risk inherent to third-party risk sharing, contracts, and so on.

•   Third-party risk factors include the same vulnerabilities and threats that other organizations encounter.

•   Considerations with third-party risk include protection of controls, responsibility, accountability, legal liability, and data ownership.

•   Issues, findings, and exceptions management helps to manage risk when there are departures from normal processes, security controls, or baselines.

•   Exceptions must be approved by management, thoroughly documented, and tracked in the risk register.

•   Emerging risk must be managed due to a changing operating environment, emerging technologies, or a changing threat landscape.

•   Emerging technologies should not be immediately adopted until they have been evaluated for risk.

•   The primary risks of emerging technologies include interoperability and compatibility with existing systems as well as security mechanisms.

•   Controls are security measures or safeguards implemented to protect systems and data, ensure compliance with governance, and reduce risk.

•   The three types of controls are administrative, technical, and physical.

•   Administrative (managerial) controls are implemented through policies and procedures.

•   Technical (logical) controls are implemented through hardware and software.

•   Physical (operational) controls are implemented through physical barriers and systems used to protect people, equipment, data, and facilities.

•   The five control functions are deterrent, preventative, detective, corrective, and compensating.

•   Deterrent controls must be known in order to be effective.

•   Preventative controls do not have to be known; they serve to prevent malicious actions or policy violations.

•   Detective controls are used to discover or detect malicious actions or policy violations.

•   Corrective controls are used to remedy an immediate security issue and are temporary in nature.

•   Compensating controls are used in place of a preferred primary control and are generally longer-term in nature.

•   Control frameworks are available to assist organizations in implementing controls to protect their systems, meet governance requirements, and reduce risk.

•   Which control framework an organization selects may be based on governance. Some governance vehicles require specific controls, but others are more flexible.

•   Control frameworks include the NIST controls, CIS controls, PCI DSS, and the ISO/IEC 27001/27002 control catalogs.

•   Controls are designed and selected based on their cost effectiveness, how well they perform and function, how well they protect assets, how they assist in meeting compliance requirements, and how well they reduce risk.

•   Controls are tested and evaluated during various points in their life cycle, including before and after implementation and during security assessments such as vulnerability assessments, risk assessments, and penetration testing.

•   Controls can be tested using four primary methods: interviews with key personnel, documentation reviews, control observation, and technical testing.

•   Change and configuration management are key processes involved in control implementation.

•   Interoperability with the existing infrastructure is a key concern while implementing a new control.

•   Controls must be thoroughly documented in the risk register.

•   Risk responses and risk treatment options should be reported to management on both a periodic and as-needed basis.

•   Risk practitioners should understand reporting requirements levied on the organization by both internal management and external governance.

•   Risk practitioners should ensure that all data collected to form reports and give information to management must be complete, accurate, and trustworthy.

•   Risk and control monitoring techniques should be part of the formally adopted risk management methodology and included in various documents, including risk strategy, policy, and procedures.

•   Risk reporting techniques include narrative reports, charts, and graphs such as heat maps, scorecards, and centralized dashboards, among other techniques.

•   The risk reporting technique used, as well as the complexity of the data and the goal of the report, should be tailored to the audience.

•   Key performance indicators are pieces of information that help measure the performance of controls and other aspects of the security program as well as show progress toward the organization’s goals in those areas.

•   Key risk indicators show how risk has increased or been reduced.

•   Key control indicators show how controls are performing and functioning in terms of effectiveness, compliance, or risk reduction.

Questions

1.   You are the business process owner for the manufacturing department of your company. After a risk assessment, several key risks have been identified that directly involve the protection of data within your department. Both the IT security and physical security departments have security safeguards in place, or planned for implementation, to help reduce those risks. Which of the following most accurately describes ownership in this scenario?

A.   You are the risk owner, and the IT and physical security departments are the control owners.

B.   As the business process owner, you are both the risk and control owner.

C.   The IT and physical security departments own both the risk and the controls.

D.   Executive management owns both the risk and controls; neither you nor the IT and security department have any responsibility for that ownership.

2.   As a risk practitioner in a larger organization, you have been asked to review the company’s risk response options for a particular risk and make recommendations to the company’s executive management. For some of the risk, there are obvious controls that could be implemented, but this will not completely eliminate all of the risk. None of the risk can be borne by any third party, and the business processes involved with the risk are extremely critical. Which of the following risk treatment options would you recommend after all possible mitigations have been put in place?

A.   Risk avoidance

B.   Risk mitigation

C.   Risk acceptance

D.   Risk sharing

3.   Your company has just established a contract with a third-party cloud services provider. Based on the contract language, in the event of a breach, the provider must disclose details of the event as well as allow an audit of the security controls that should have protected any data disclosed during the breach. The contract language as well as laws and regulations also stipulate that the third-party provider retains some legal liability for the loss. Which of the following accurately describes the responsibility and accountability borne by both your organization and the third-party provider during this event?

A.   All the responsibility and accountability are placed on the third-party provider.

B.   All of the responsibility and accountability are placed on the organization.

C.   The third-party provider has the responsibility for protecting the data, but the organization retains accountability.

D.   Both the third-party provider and the organization bear responsibility and accountability for the loss of the data as well as legal liability.

4.   Which of the following is the major risk factor associated with integrating new or emerging technologies into an existing IT infrastructure?

A.   Security mechanisms

B.   Data format

C.   Vendor supportability

D.   Interoperability

5.   During a vulnerability scan of its systems, your organization discovers findings that cannot be remediated without breaking several critical line-of-business applications. Which of the following should be the path forward in determining a solution to this problem?

A.   You should patch the systems regardless of the impact of the line-of-business applications since security is far more critical to the organization. Business process owners must accept this and configure their line-of-business applications accordingly.

B.   You must not patch a system that would affect the line-of-business applications, since this affects the mission and bottom line of the organization, which is far more important to the organization than its security posture.

C.   You should employ the risk avoidance response by not worrying about the security or business ramifications of the problem, since it is beyond your control and will waste critical resources in addressing it.

D.   You should evaluate the risk of patching systems and suffering the impact to the line-of-business applications versus the security risk if the systems are not patched and then allow management to make a decision based on that risk. Any exceptions should be formally approved and documented.

6.   Your company has implemented several new controls to strengthen security inside its facility. These controls include stronger steel doors, with new cipher locks, and two more guard stations to keep unauthorized personnel from entering sensitive areas. Which of the following types and functions would those new controls be considered?

A.   Physical, detective

B.   Physical, preventive

C.   Administrative, preventive

D.   Administrative, deterrent

7.   Your company is now doing business internationally, and as a result, one of its key business partners overseas requires that it adopt international security standards. You examine several different standards, and you are already using internally developed controls that may be mapped to a new standard. Which of the following control standards is the most appropriate to use when working with international partners?

A.   NIST SP 800-53

B.   CIS controls

C.   ISO/IEC 27001/27002

D.   HIPAA controls

8.   Your company is concerned about implementing controls for a new sensitive system it is about to install. Some existing controls can be easily used, but the new system will require more advanced network security devices since the data sensitivity requirements are much higher under laws and regulations imposed on the company. These laws and regulations mandate a higher level of protection because of the sensitivity of that system and data. Which of the following is the most important concern the company must consider when implementing the new security devices?

A.   Cost

B.   Compliance

C.   Risk reduction

D.   Interoperability

9.   Your company has installed a new network security device and is testing it in parallel with the rest of the infrastructure before cutting over all systems on the infrastructure to rely on the device. Security mechanisms within the device meet your strict governance compliance requirements, and risk analysis shows that it can reduce risk of an external attack significantly. However, some but not all critical systems on the network refuse to communicate with the device, making it difficult to troubleshoot any issues and stopping critical data from transiting the network. Which of the following is the most likely issue you should examine?

A.   Interoperability

B.   Authentication mechanisms

C.   Encryption mechanisms

D.   Network protocol issues

10.   Your organization is preparing to implement many new security controls, including upgrading legacy network security devices. While a thorough risk analysis has been performed, there is still uncertainty about how the network devices will interact with the rest of the infrastructure. Management is concerned with interoperability issues and the ability to monitor the installation carefully. Which of the following will assist in helping the implementation go smoothly?

A.   Vulnerability assessment prior to installation

B.   Parallel cutover

C.   Risk analysis

D.   Change and configuration management processes

11.   You are collecting data for your annual risk and control effectiveness report to the company’s board of directors. You’re gathering data from multiple sources, but you are concerned about the usefulness of the data used to create a report. Which of the following is not a concern regarding the data you’re collecting?

A.   Completeness

B.   Accuracy

C.   Trustworthiness

D.   Complexity

12.   You are creating a schedule for risk reporting for various managers and events. Which of the following strategies should you employ regarding reporting of risk treatment options and plans?

A.   Report on their progress periodically and as needed.

B.   Report annually to senior management and quarterly to middle management.

C.   Report results only when the risk treatment options have been implemented and are complete.

D.   Do not report on risk treatment options; only report on increases or decreases in risk as required by governance.

13.   Which of the following documents should describe the risk management methodology, to improve risk assessment and analysis methodologies, adopted by the organization?

A.   Risk management policy

B.   Risk management strategy

C.   Risk assessment procedures

D.   Organizational strategy

14.   You are implementing a new method to quickly inform management of any changes in the overall control effectiveness or risk posture of the organization. You want it to be in near real time but only include the critical information necessary that managers need to make informed decisions. You also want management to have the ability to drill down into more detailed information if needed. Which of the following reporting techniques would fill these requirements?

A.   Heat map

B.   Narrative report

C.   Centralized dashboard

D.   Scorecard

15.   You are developing metrics for senior management regarding control effectiveness and the risk posture of the organization. You need to create a metric that shows managers how potential risk has been reduced due to implementing several new controls over the past six months. You want to aggregate this measurement into one indicator. Which of the following would be the most effective indicator to show this reduction?

A.   Key performance indicator

B.   Key risk indicator

C.   Key management indicator

D.   Key control indicator

Answers

1. A.   As the business process owner, you have responsibility and accountability for the risk, while the IT and physical security departments are the control owners.

2. C.   After all other risk reductions and mitigation actions have been implemented, any residual risk must be accepted. Risk mitigation has already occurred, and the scenario states that risk cannot be shared with any third party. Since these are critical business processes, the risk cannot be avoided.

3. D.   Both the third-party provider and the organization bear some level of responsibility, accountability, and legal liability for the data loss since both the contract language and laws address this situation. However, it is likely that the organization will ultimately bear the most responsibility and accountability for the data loss to its customers.

4. D.   Interoperability is the major risk factor associated with integrating new or emerging technologies into an existing IT infrastructure. It covers a wide range of factors, typically including backward compatibility, data format, security mechanisms, and other aspects of system integration.

5. D.   You should evaluate the risk of patching systems and suffering the impact to the line-of-business applications versus the security risk if the systems are not patched and then allow management to decide based on that risk. Any exceptions should be formally approved and documented. You cannot simply ignore the risk, and taking any action without carefully considering the risk would be detrimental to the organization, whether it is making the choice to break the line-of-business applications or ignoring the security ramifications of the problem.

6. B.   The controls are physical because they involve using physical barriers to secure the interior of the facility. The controls are also preventive because they prevent people from entering sensitive, restricted areas. The controls are not administrative because they do not involve written policy or procedures established by management.

7. C.   ISO/IEC 27001 and 27002 are international standards developed to ensure interoperability and translation of security controls across international boundaries. The other control sets, while they may possibly be used in areas outside the United States, are unique to the U.S.

8. B.   Compliance is actually the most important consideration in this scenario because the company is installing a system that is considered sensitive enough to be regulated by laws and regulations. Since the data sensitivity requirements under those laws and regulations require that level of protection, the company has no choice but to implement those advanced network security devices, regardless of cost, interoperability, or any other consideration.

9. A.   Interoperability seems to be the issue here. Since authentication and encryption mechanisms meet compliance standards, it may be that they are not interoperable with existing infrastructures. Network protocols aren’t likely an issue since some devices on the network can communicate with the new device. All indications are that the new device may not be interoperable with some of the other devices, security mechanisms, or protocols on the network.

10. D.   Proper change and configuration management processes will assist in an orderly implementation and changeover to the needed network security devices. Management has the ability to carefully consider, prove, and monitor changes to the infrastructure, with the ability to back out the changes according to defined processes if something goes wrong.

11. D.   Data complexity is not an issue since it will be your job as risk practitioner to distill the data into understandable information for the board of directors. You are most concerned with the completeness of the data, how accurate it is, and whether it comes from a trustworthy source.

12. A.   You should report the progress of risk treatment options both periodically, as determined by organizational policy, and as needed, depending on the criticality or importance of the information and the desires of management.

13. A.   The risk management policy, which supports external and internal governance, should dictate the risk management methodology used by the organization. Often this methodology will include any risk assessment or analysis methods mandated for use. Both the risk management strategy and the overall organizational strategy are long-term, higher-level documents that do not go into this level of detail. Risk assessment procedures are step-by-step processes, activities, and tasks used to perform a risk assessment, but they do not direct overall risk management methodologies.

14. C.   A centralized dashboard can supply all the necessary critical information managers need to view control effectiveness and risk posture, all in one location. Information can be fed to the dashboard in real time, and managers would have the ability to drill down on particular data elements to gain more details if needed.

15. B.   In this scenario, a key risk indicator (KRI) could be developed to show the reduction in risk. A key performance indicator (KPI) would show the level of performance of a control or other aspect of organizational security, not necessarily the reduction in risk. A key control indicator (KCI) would show the effectiveness of a particular control, not the reduction in risk. Key management indicators are published by executive management and cover various metrics they are concerned with regarding the overall performance of organizational objectives. They do not indicate a reduction in risk.

CHAPTER 4

Information Technology and Security

In this chapter, you will:

•   Learn to describe how business goals, information criteria, and organizational structures affect risk

•   Determine how enterprise architecture presents risk to the organization

•   Analyze factors of enterprise risk, including areas such as data lifecycle management, hardware and software, third-party relationships, the system development life cycle, project management, business continuity and disaster recovery, IT operations management, and implementation of new technologies

•   Learn basic information security concepts

•   Examine different frameworks and standards

This chapter covers Certified in Risk and Information Systems Control Domain 4, “Information Technology and Security.” The domain represents 22 percent of the CRISC examination.

The CRISC Task Statements relevant to this domain focus on several key activities found in an information security program, including identifying threats and vulnerabilities, establishing accountability through the assignment of risks and control ownership, creating a risk-aware culture through security awareness training, reviewing risk analyses, developing remediation plans to fill gaps, collaborating on the development of risk treatment plans and on the selection and design of controls, and ensuring that business practices align with risk management, risk appetite, and risk tolerance, and selected security frameworks.

Information is a commodity. Even if an organization is in the business of producing goods to bring to market, it still relies on its information and its technology as enablers to produce those goods and deliver them to the market and consumers. Without the ability to generate, process, and otherwise use information, modern businesses would not be able to produce goods or services and compete in market spaces. Therefore, any negative events that affect the organization’s ability to process information directly affect the ability of the organization to survive. Information technology directly supports business goals, objectives, and strategies. All elements of a business endeavor depend on IT, including the organization’s information (or data), its people, its line-of-business applications and systems, and its overall infrastructure, including all of its equipment and processes.

Information technology affects risks to the business enterprise in two different ways. First, information technology is used to help protect the enterprise from risk; in other words, it serves to protect the information the business generates and relies on. That’s the purpose of having high-capacity storage, faster networking equipment, redundant systems, and security devices sprinkled throughout the infrastructure. The second way that IT affects risk is that it helps the organization to produce the information needed to fulfill its business goals and objectives in the first place. Without IT, there would be no information processed, no systems designed, and no advanced technologies developed for a business to take to market and compete with. Therefore, IT serves to both protect information and generate it to advance business goals.

The information the business generates and uses has several key characteristics. First, the information should be relevant to the processes that the business supports. It should also be timely; stale information can prevent a business from fulfilling its functions in both short-term and long-term time frames. It should also be accurate and complete. This is where information integrity comes in, which is one of the goals of information security. Anything that affects the accuracy and completeness of information is a risk. Information should also be controlled for access. Confidentiality is one of the goals of information security, and controlled access to information and the systems that process it is a must to maintain business function. As you might guess, another characteristic of business information is its availability to the users who need it whenever and however they need it. This means that authorized users should have business information, again, on a timely basis, but also in a format that suits their needs. Risk factors that affect any of these information characteristics, such as relevance, timeliness, integrity, confidentiality, and availability, must be considered in the overall risk management process for the organization. Any detrimental impact on these characteristics presents a risk to the business mission.

Enterprise Architecture

The enterprise architecture within an organization affects the business’s risk in several different ways. Aspects of enterprise architecture risk include interoperability, supportability, security, maintenance, and how the different pieces and parts of the infrastructure fit into the systems development life cycle. The business views IT as an investment of capital funds, much like it does facilities and other equipment: as a means of supporting the business mission. Information systems represent a risk to the business because of interoperability, supportability, security, and other issues. It costs the organization money to maintain and support all the IT assets within the organization, in the form of parts, software licenses, training for administrators and users, and upgrades. There are also the intangible aspects of IT, such as business value and liability. IT systems affect the bottom line of the organization, so a lot of thought is put into managing risk for them. Additionally, you should take care to remember that information technology risk is only a piece of the entire enterprise risk picture. In the next few sections, we’re going to talk about different aspects of the information systems architecture and how they contribute to the overall enterprise risk in the organization.

Platforms

Platforms are an element of the enterprise infrastructure that contributes to information security and business risk for several reasons. First, it costs to field and simultaneously maintain different operating systems and environments that come in different platforms. Platforms also introduce risk into the environment in the form of interoperability, security, and supportability. A diverse platform environment (with mixed platforms, such as Windows, Linux, Macs, Unix, and so on) can affect interoperability with other systems due to different versions of software, different network protocols, security methods, and so on. A diverse environment can also affect supportability because the organization must maintain different skillsets and a wide knowledge base to support the diverse platforms.

On the other hand, maintaining a homogeneous environment can reduce costs, ensure interoperability, and allow a more common set of security controls and mechanisms, such as patch management and configuration management. However, there is even risk involved in a homogeneous platform environment because of the likelihood that a vulnerability discovered in one system would also be shared in many others, offering a wider attack vector for a potential malicious actor. It is really a matter of the systems development life cycle as to how and when platforms are developed, introduced into the infrastructure, implemented, maintained, and, eventually, disposed of, and there is risk inherent in all of these different phases, as we’ll discuss in more detail later.

Software

Software introduces risk simply because, today, it’s so critical to business operations. Businesses need not only basic word processing and spreadsheet software but also complex databases, line-of-business applications, specialized software, security software, and other types of applications. Software must be managed within its own life cycle as well; it is constantly being patched, upgraded, superseded, and replaced by better, faster software with more features that usually costs more. Risks that are inherent to managing applications within an organization include supportability, backward compatibility, data format compatibility, licensing, and proper use.

Adding to this complexity are the decisions an organization makes in terms of the selection of proprietary software, open-source software, general-purpose commercial software, or highly specialized software. All these different categories incur different levels of cost, supportability, licensing, and feature sets. Interoperability also plays a part in application risk, as it does with other infrastructure components. Applications that do not use common data formats or produce usable output for the organization create the risk of expense or additional work that goes into transforming data between incompatible applications. Applications also introduce risk into the business environment with the level of security mechanisms built into them and how effective those security mechanisms are in protecting data residing in the application.

It’s worth mentioning here that web-based applications, in addition to presenting the same risks as normal client-server apps, also have their own unique risks. Security is a definite risk imposed by web-based applications since they often directly connect to unprotected networks such as the Internet. Other risks include those that come from the wide variety of web programming languages and standards available for developers to use.

Databases

Databases, as a subset of applications, impose some of the same risks that applications and other software do. Additionally, databases incur risks associated with data aggregation, compatibility, privacy, and security. Aggregation and inference are risks associated with database systems. Unauthorized access and data loss are also huge risks that databases introduce into the enterprise environment.

Operating Systems

Although we discussed platforms in a previous section, it’s also worth mentioning operating systems as their own separate risk element in the enterprise infrastructure. The terms platform and operating system are sometimes used interchangeably, but, truthfully, a platform is more a hardware architecture than an operating system categorization. A platform could be an Intel PC or a tablet chipset, for example, which are designed and architected differently and run totally different operating systems. Different operating systems, on the other hand, could run on the same platform but still introduce risk into the organization for the same reasons discussed previously with applications. For example, there are interoperability and supportability risks and all the other issues that go hand in hand with the normal operating system life cycle, such as patch and vulnerability management. Licensing, standardization, level of user control, and configuration are also issues that introduce risk into the organizational computing environment.

EXAM TIP   Although information security professions tend to focus more on the technical aspects of IT risks, for the exam, keep in mind that all IT risks also contribute to the overall business risks in the enterprise. Make sure you look at the larger picture beyond the IT realm.

Networks

Networks are another aspect of enterprise infrastructure that is absolutely critical to protecting data. They are most effective when they are implemented in a way that not only incorporates the business logic of the organization but also follows the data flow—taking into account how the software is most implemented and integrated with other systems such as databases.

Let’s first take a step back to understand what a network is. At its most basic level, a network is a mechanism that allows systems to communicate with each other. The components are often devices such as switches (for local network communication) and routers (for communications between networks). There are a number of protection mechanisms on networks such as firewalls (which regulate network traffic), intrusion protection systems (which protect traffic at a deeper level than firewalls), threat intelligence gateways (which are designed to protect external networks prior to connecting to firewalls), and so on. This is only a sampling of the protective technologies that are network based. The deeper the understanding of the technologies, the more granular a risk assessor may be.

The philosophy one uses to set up the location of protective network devices can be referred to as the architecture. For example, for sensitive data, most compliance frameworks require that the data not be stored in the database on the same local network segment as a web server. This way, if the web server is compromised, attackers will not have immediate access to the data. If they sit on the same network, that may be considered a higher risk in a risk assessment—the recommendation being to move the database to another network behind the web server, with firewalls and intrusion detection systems being the intermediary between the two local networks.

Another factor to consider is encryption of data in motion. If a legacy system does not have encryption and it is sending data to another location on the Internet, there is a risk to anyone between the networks for an on-path attack (formerly known as a “man-in-the-middle attack”). A VPN tunnel can be set up between the two networks to ensure that at least the traffic is encrypted as it traverses the networks (or Internet).

In the end, networks and networking can be extremely challenging and detailed. What we have covered here only scratches the surface of what is entailed by networks and networking. It is worth your time to explore this topic in depth to help create a better network and ultimately add to a risk assessment.

Cloud

No book on risk would be complete without considering cloud-based risks. The concept of “Anything as a Service” (XaaS) means that, for a price, nearly anything a user or company would use a computing system for can be delivered to them by a cloud service provider through the cloud infrastructure—typically through a thin client or web interface. In such a serverless architecture, a cloud provider manages the server and associated architecture and allocates resources as necessary to the end users. This requires less upfront investment in hardware and software by the customer, greater scalability, and centralized management for administration and security concerns. Each cloud infrastructure is a little different, but there are three main types of cloud infrastructure to consider when looking at risk:

•   Software as a Service (SaaS) allows a customer to essentially lease software, such as applications and databases, thus enabling rapid rollout to the greater user community.

•   Platform as a Service (PaaS) provides the framework of an operating system and associated software required to perform a function (for example, the Linux operating system and components needed to run a web server).

•   Infrastructure as a Service (IaaS) provides the ability to quickly stand up virtual machines, storage devices, and other infrastructure that would otherwise require the purchase of physical devices.

Gateways

A number of other technologies that can be used to protect organizations can be factored into a risk assessment. For example, secure e-mail gateways and secure web gateways are a must-have to protect organizations from web-based threats. These technologies can help to filter malware, block malicious links or websites, help prevent phishing, or a host of other tasks. Technically, they do not fit into the category of other technologies so they deserve special mention. A good risk assessor will learn about these technologies and how they can help reduce the risks related to the organization. That knowledge can be applied to the risk assessment process.

Enterprise Architecture Frameworks

Another facet to consider is enterprise architecture (EA). This is different from network architecture, presented earlier. EA focuses on the relationship between business and technology. In most cases, this includes the relationship between security and technology. It is very important because it provides a view into the governance of an organization, which can provide insight into some core problems that cause risks within the organization.

Two frameworks for enterprise architecture are discussed in this book: The Open Group Architecture Framework (TOGAF) and the Zachman framework.

NOTE   TOGAF and the Zachman framework are enterprise architecture models, not enterprise security architecture models.

The Open Group Architecture Framework

TOGAF is a lifecycle enterprise architecture framework used for designing, planning, implementing, and governing an enterprise technology architecture. TOGAF could be considered a high-level approach for designing enterprise infrastructure.

The phases used in TOGAF are as follows:

•   Preliminary

•   Architecture vision

•   Business architecture

•   Information systems architecture

•   Technology architecture

•   Opportunities and solutions

•   Migration planning

•   Implementation governance

•   Architecture change management

•   Requirements management

TOGAF is a business-driven, lifecycle management framework for enterprise architecture overall, and it certainly can be used for information security architecture as well. Figure 4-1 depicts TOGAF visually.

Figure 4-1 TOGAF components

You can find information on TOGAF at https://www.opengroup.org/togaf.

The Zachman Framework

The Zachman enterprise architecture framework, established in the late 1980s, continues to be a dominant EA standard today. Zachman likens IT enterprise architecture to the construction and maintenance of an office building: at an abstract level, the office building performs functions such as containing office space. As you look into increasing levels of detail in the building, you encounter various trades (steel, concrete, drywall, electrical, plumbing, telephone, fire control, elevators, and so on), each of which has its own specifications, standards, regulations, construction and maintenance methods, and so on. Zachman can easily be used to develop an enterprise security architecture as part of the enterprise architecture.

In the Zachman framework, IT systems and environments are described at a high, functional level and then in increasing detail, encompassing systems, databases, applications, networks, and so on. Table 4-1 illustrates the Zachman framework.

Table 4-1 Zachman Framework Showing IT Systems in Increasing Levels of Detail

While the Zachman framework allows an organization to peer into cross-sections of an IT environment that supports business processes, the model does not convey the relationships between IT systems. Data flow diagrams are used instead to depict information flows.

Information about the Zachman framework is available at https://www.zachman.com/about-the-zachman-framework.

Implementing a Security Architecture

Organizations use different means for implementing a security architecture. Because security architecture is both a big-picture pursuit and a detailed plan, different decision makers may be involved, and different business processes are used.

At the enterprise level, the organization will use its policy and governance functions to make decisions about major aspects of security architecture, such as decisions about the brands of servers, workstations, and network devices to be used.

At the detail level, processes such as configuration management and change management are used to implement device characteristics on individual devices or groups of devices. For instance, an upgrade to an organization’s Domain Name System (DNS) infrastructure might result in an increase in the number of name servers in use, necessitating that most or all devices in the organization be updated accordingly.

Over time, organizations will make changes to their architecture models (both at the macro level and micro level). For instance, changes and advances in technologies such as software-defined networking (SDN), virtualization, and microservices architectures will compel organizations to revise their enterprise security architecture. However, updating architecture documents is only the beginning. Organizations will also initiate tasks or projects to implement these improvements in their environment. Some of these changes, such as updates to industry device-hardening standards, may result in little more than change management to update a few configuration settings, but other changes may involve multiyear projects to modernize some aspect of an organization’s environment.

IT Operations Management

Managing the enterprise infrastructure is one of the most work-intensive efforts in an organization, especially in a larger business. The enterprise infrastructure in an organization covers a broad scope of areas. Infrastructure, of course, covers workstations, printers, and other end-user devices. It also covers the major pieces needed to conduct business, such as servers, cabling, switches, routers, and a variety of other network and security devices. Most organizations also include wireless networks in their supporting equipment. Additionally, the infiltration of mobile devices into businesses makes this a new and sometimes difficult area to bring under the organization’s infrastructure umbrella. Challenges with the enterprise infrastructure include not only maintenance, upgrades, updates, and implementing new technologies but also includes some of the more typical traditional management challenges, such as budgeting, project management, and staffing.

Key areas in IT operations management include server and infrastructure management, end-user support, help desk, problem escalation management, and, of course, cybersecurity. IT managers must maintain and meet any internal agreements that cover guaranteed service delivery in support of the different divisions within the organization, as well as service level agreements (SLAs) with other organizations. While information security personnel tend to focus more on IT risk, we find that most of the risk factors, threats, and vulnerabilities affecting IT also affect all the operations within the business. In the next few paragraphs, however, we’ll focus on those that directly affect managing the IT operations in an organization.

Management of IT operations incurs risk factors such as the size and complexity of the organization and its IT infrastructure, the criticality and priority of the different systems that make up the infrastructure, and the internal management processes of the organization. Resourcing issues also affect the management piece of IT operations; staffing the right people who have trained on the various technologies the organization needs as well as creating a budget that helps maintain the current level of support and future growth for IT are examples of resource-related risk factors. Additionally, compliance with legal and governance requirements in the face of increased regulation are also risk factors the IT managers must deal with.

Organizational structure also affects IT operations because the IT infrastructure may be managed on either a centralized or a decentralized basis—sometimes by one centralized IT shop, or in the case of larger organizations, by multiple areas within other divisions that are delegated the task of managing their own piece of the infrastructure. IT might also be managed on a functional basis; the accounting and human resources divisions may have the responsibility for managing the systems that support their mission. Additionally, the IT infrastructure may be managed on a geographical basis, in the case of physically separated locations in large organizations. All these structural considerations are factors that contribute to risk in managing IT operations.

Also directly affecting IT operations risk are two key processes: the change and configuration management processes. We’ve already discussed risk factors that affect the SDLC model in an organization, as well as how new and emerging technologies can affect the existing infrastructure. These same risk factors also directly affect the daily management of IT operations simply because they introduce change into the network. Some of this change can be planned and carefully introduced, but often there is change—from the large-scale network side, all the way down to individual configuration items on hosts—that may have unforeseen consequences and affect the network in different ways. How the organization deals with change and configuration management is a risk factor that affects not only the SDLC but also the management of day-to-day operations.

Threats that affect the IT operations are like those that affect other areas of the business and could be external or internal threats from a variety of sources. Some of these threats have a ripple effect in that they may first affect other areas of business and, in turn, affect IT. For example, the threat of a poor economy may affect the profitability and sustainment of the business, resulting in cuts, which often include IT personnel or equipment. Obviously, there are also direct threats to the daily management of the IT infrastructure. These include external threats such as hackers, of course, but also more commonly come as increases in cost to maintain operations, issues with external service providers, and disaster-related events (weather, fire, and so on). Internal threats could include those carried out by malicious insiders or even careless workers, such as theft, sabotage, accidental equipment breakage, and so on. Internal threats could also come from management processes and include budget cuts, loss of trained personnel, shifts in organizational priorities, and transitioning from one market segment to another.

Technical vulnerabilities are beyond the scope and purpose of this book; our focus here is on those associated with the IT management aspect of the organization. Vulnerabilities affecting IT management include faulty processes and procedures, lack of resources, and lack of trained technical personnel. An end-user population that has not been trained or held accountable for proper care and treatment of the infrastructure could also be a vulnerability. Other vulnerabilities might include a lack of infrastructure monitoring, a lack of control of sensitive information in IT systems, and a failure to maintain a stable SDLC throughout the entire infrastructure.

Project Management

Organizations use project, program, and portfolio management to oversee and sustain both short- and long-term aspects of systems and processes. These categories apply to the scope and scale of different sets of activities or processes within an organization. Projects are limited duration sets of activities geared toward a particular goal; programs are ongoing, longer term, and may also encompass several individual projects as well as other activities specific to processes that may have an indefinite duration. Portfolio management is the oversight of several different programs by a senior person in the organization. Keep in mind that the major difference between a project and a program is duration; a project has a definite beginning and ending, whereas a program is indefinite.

At the core of a project are three primary drivers: the scope (the amount or range of work), schedule (when work is to be done and its completion date), and cost (including all the resources expended toward the completion of the project). All projects depend on these three elements to ensure success. Any shortfalls in cost, delays in schedule, or out-of-scope work (also called scope creep) affect the ability of the project to succeed, on time, within budget, and all the agreed-upon work completed. We’ll discuss the risk factors that can affect all three of these elements next.

Since the three major elements of a project or program are scope, schedule, and cost, risk factors associated with projects and programs primarily affect each of these elements. Factors that affect scope often come from disagreement on exactly what work must be accomplished, in what order, and who will do it. These factors should be examined and agreed upon during the requirements process, where the project is formally scoped. In complex projects, factors that may affect scope include the necessity to task workers from different sections or departments, the exact amount of work to be done, in what order it will be done, and the priority of each task and subtask. The political culture within the organization can adversely affect scope as well since there may be disagreement between departments or executives on what work is required and whose responsibility it is to accomplish it.

The scheduling component of a project has several risk factors as well. The amount of work to be done (scope) affects the schedule as a risk factor because of the time given to accomplish a specific amount of work and the resources allocated to this work. Lack of workers or materials adversely affects the schedule, as does the availability of equipment, work location or site, and external factors such as contract negotiations, government shutdowns, and so on, as examples.

Cost risk factors stem from lack of budget control during the project, including an inaccurate budget or estimation of cost, unexpected expenditures, a weak economy, and so on. Project costs are affected by the cost of labor (to include wages, insurance, and benefits) as well as the cost of supplies or materials needed to complete the project. Additionally, since all three of the elements of scope, schedule, and cost are also risk factors for each other, a delay in schedule or any extra, out-of-scope work impacts the project budget and costs as well.

Other risk factors for projects include training, staffing the project with the right mixture of personnel who have the right skill sets, attitudes, and focus on making the project or program a success. A manager without the right project management skill set is a risk factor that can affect scope, schedule, and cost if they do not manage those three critical elements properly. A technician without the right technical skills may cost the project more money in training or delay work unnecessarily due to rework or slow production.

In addition to factors such as scope, cost, and schedule, adding an indefinite or longer-term duration affects programs as a risk factor because you must project how they will be staffed, funded, equipped, and otherwise managed in the future, over a longer, indeterminate period. Therefore, risk factors could be long term and fluctuate over that time. Factors such as market, economy, and technology changes will influence risk in a program much more so than a project, affecting its scope, schedule, and cost over a longer period.

The threats to a project or program are similar; the major difference is the duration of the time that the threat represents potential harm to a project or program. Keep in mind that threats for a project or program aren’t those you might traditionally think of as threat sources; they are rarely malicious in nature and usually come from the business environment itself. For example, threats to cost are usually those that involve money or resource issues, such as price increases, currency value fluctuation, stock market variations, and so on. These are usually external threats; internal threats to costs might include a sudden budget restructuring, cutting funds for a project, bankruptcy, and so on. Threats to the schedule might include worker shortage, strikes, inadequate training, delays in contract negotiations, delays from suppliers, and so on. Scope threats usually involve extra or additional work due to faulty requirements gathering and decisions about what falls into the project’s scope and scale.

NOTE   Sometimes it’s difficult to distinguish between threats to each of these elements individually and threats that affect all three project elements simultaneously, as it is more often the case that any threat affecting one element will usually, even indirectly, affect all three.

Since vulnerabilities are weaknesses or a lack of protective controls, the vulnerabilities found in project and program management are inherent to weaknesses in their critical elements and processes. For example, a weakness often found in the cost element of a project or program is a failure of the organization to adequately budget for all the resources it requires for the project. The organization might not list every piece of equipment or every major supply it needs or consider labor costs such as overtime in the event of schedule slippage. It may not adequately negotiate firm prices with a supplier, who then may raise prices on critical parts or equipment. These are all vulnerabilities inherent to the budgeting and cost elements of a project.

Scheduling also has some common vulnerabilities associated with it. If an organization fails to build in potential scheduling delays, such as work stoppages, dependencies on other organizations to fulfill parts of the schedule or even holidays, this can lead to problems with getting the project completed on time. Another scheduling vulnerability is to incorrectly estimate the amount of time it takes to perform a task or get a piece of work accomplished.

Vulnerabilities inherent to the scope element of a project affect how much work must be done, in what order, and by whom. A work breakdown structure (WBS) is a document that the project manager develops that covers exactly all this information and more. The WBS describes, in excruciating detail, the work, its subcomponent parts and tasks, what skill sets are needed, and what resources are required to do the job. Other documents may break down individual tasks into much more detail, even describing step by step how a task is accomplished. If the project manager and team do not create these documents, this is a weakness in that the work may not be performed exactly as needed. Resources may not be adequately allocated for the work, or the work may be performed by unskilled persons. Additionally, the amount and quality of work may not be performed to requirements. Failure to set requirements initially in the project and periodically check and track the work against those requirements are also vulnerabilities associated with scope since they can affect whether or not the work meets the established requirements.

An additional vulnerability that simultaneously affects all three project elements is the failure to monitor or control all these elements on an ongoing basis throughout the life of the project or program. Scope, schedule, and cost must be monitored on a continuing basis to ensure that they meet the original requirements set forth in the project’s charter. The project or program manager must monitor and control these things to prevent cost overruns, schedule slippage, and scope creep. Failure to monitor or control these elements is a serious vulnerability and could jeopardize the success of the entire project or program. Table 4-2 gives examples of some of the risk factors, threats, and vulnerabilities related to project and program management.

Table 4-2 Examples of Project Risk Factors, Threats, and Vulnerabilities

Business Continuity and Disaster Recovery Management

Business continuity and disaster recovery management are necessary parts of running a business, regardless of its market area. This is because incidents, disasters, and other negative events happen to all organizations eventually, despite the most favorable conditions and the most careful planning. Business continuity and disaster recovery are primarily concerned with the goal of business resilience. An entire area of expertise is dedicated to this goal with these processes in mind; sometimes, it’s referred to as continuity management.

One thing to keep in mind is the difference between business continuity and disaster recovery. Business continuity is concerned with the careful planning and deployment of resources involved in keeping the mission of the business going (that is, keeping the business functioning regardless of negative events). This process is more long term and requires continual commitment from the organization. Disaster recovery, on the other hand, is primarily concerned with the quick reaction involved with preserving lives, equipment, and data immediately following a serious negative event. Disaster recovery is (hopefully) a short duration process and does not concern itself with conducting the daily mission of the business. Business continuity is more concerned with the long-term survival of the business, while disaster recovery is more concerned with the short-term process of reacting to a disaster. While closely related, these two efforts are not the same thing; in fact, disaster recovery could be viewed as a subset of the activities that go on during the overall continuity management strategy.

Business Impact Analysis

Business continuity planning involves several steps. Since the focus of this domain isn’t solely on business continuity and disaster recovery, we’re not going to go into an in-depth treatment of these processes. However, we will discuss some of the basic concepts of business continuity and disaster recovery as they relate to risk. Two of the key processes involved in business continuity planning are conducting a business impact assessment (BIA) and determining a recovery strategy. A business impact assessment closely resembles some of the steps you would take during a risk assessment, simply because you are identifying assets (which include, of course, people, equipment, facilities, and processes) and prioritizing those assets. The reason they are prioritized is that in the event a disaster was to occur, the business would have to rely on certain assets or processes more so than others to get back in business. These critical assets or processes should be brought back online and recovered first, but to accomplish this, they must be identified by the organization, and plans have to be made for their recovery. That’s where the business impact assessment comes in. The organization must identify critical processes and assets, prioritize them for recovery, and, additionally, measure the impact on the business if those assets or processes were lost for any given amount of time due to an incident or negative event. Business impact analysis was described in more detail in Chapter 2.

Recovery Objectives

Two key areas of concern in business continuity are the recovery point objective (RPO) and the recovery time objective (RTO). Both areas can be measured in the context of time. The recovery point objective is the amount of data that can be lost based on a time measurement. In other words, if the recovery point objective is two days, the most amount of data that can be lost without a serious effect on the organization’s ability to function would be two days’ worth of data. Note that this measurement isn’t concerned with the actual amount of data in terms of quantity, such as gigabytes, for example; instead, it’s concerned with measuring how many days or hours’ worth of data can be lost, at most, without impeding the function of the business. The recovery time objective, also measured in terms of time, is the maximum amount of time the organization can afford to lose before it starts recovery. This measurement of time could be days, hours, minutes, or even seconds.

Recovery Strategies

The recovery strategy developed by the organization is a result of careful planning, as well as budgeting and allocating resources to the continuity management efforts. The recovery strategy should address the most efficient methods of getting the business back online and functioning after properly responding to the critical needs of protecting people and equipment during the disaster itself. Keep in mind that recovering the business to an operational state does not necessarily mean it will be working at 100 percent of its previous operational capacity; the business may only be able to get a few key services up immediately following a disaster. The organization should take a realistic look at the degree of continuity possible, given the seriousness and scope of the disaster, its resources, the environment it is working with after the disaster, and the availability of people, supplies, infrastructure, facilities, and equipment. All of this should be considered in the recovery strategy planning.

Plan Testing

Testing the disaster recovery plan is of critical importance; without testing the plan, the organization won’t really know whether it’s effective until a disaster occurs. Normally, that’s a bit too late to find out that you haven’t carefully considered all the different events that could occur during a disaster and how you will deal with them. Testing the plan involves making sure that people know what their responsibilities are, that they are well-trained, that they have all the equipment and resources needed to adequately respond to disaster, and that they practice these responses. Testing the disaster recovery plan will point out deficiencies in training, equipment, resources, and response activities.

NOTE   Much more information on business continuity and disaster recovery planning can be found in National Institute of Standards and Technology (NIST) Special Publication 800-34, “Contingency Planning Guide for Federal Information Systems,” which was written for use by government agencies but can be used by anyone or any business to help in understanding and planning for business continuity.

Resilience and Risk Factors

Resilience is a term that refers to the ability of the business to survive negative events and continue with its mission and function. In other words, it could be said that resilience is the ability of an organization to resist the effects of negative events and its ability to bounce back after one of these events. Resilience can affect to what degree different risk factors, as well as threats and vulnerabilities, have on impacting the normal business operations of the organization. A more resilient organization can better tolerate risk factors and the effects they have on the organization’s ability to prepare for and respond to negative events.

Various risk factors can affect the organization’s ability to respond to disasters as well as to continue the business and mission functions after it has recovered from a disaster. Some of these risk factors are inherent to the organization itself; these include the size of the organization, its facilities, its people, and how well it has performed business continuity and disaster recovery planning. A higher level of management commitment to business continuity planning reduces the effect of risk factors on the business; less commitment may render the organization more susceptible to these risk factors. A larger organization may have more complexity in terms of the number of people to take care of during a disaster, as well as the number of critical assets or processes that must be planned for. Small organizations don’t necessarily have an advantage; however, a small organization may have fewer resources to adequately plan for and address business continuity and disaster recovery.

Another risk factor that an organization could face is physical location and geography. For example, a business situated on the U.S. Gulf Coast is probably more susceptible to adverse weather, such as hurricanes and tornadoes, than a business located inland. Businesses that are in areas prone to heavy flooding or have forest fires or extreme snowstorms at various times of the year should plan for these weather conditions appropriately. Distance could also be a risk factor; if the organization is located farther away from population centers or infrastructure services (such as fire departments, police, hospitals, telecommunications providers, and so on), there is a greater risk that the organization could not adequately respond to a disaster.

There are also risks associated with third-party providers, and these providers can affect business continuity and disaster recovery as well. Yet another risk factor could be the degree of outsourcing the organization is involved with. A business that outsources some of its processes or key functions may have less control over those functions or processes during an incident or disaster. The business may be at the mercy of the third party with whom they are contracted and subject to the third party’s disaster recovery strategies (or lack thereof). Business continuity and disaster recovery are two areas that should be carefully considered when engaging in business with any external provider, usually through a service level agreement or another method.

In addition to the factors we discussed previously, the very nature of the organization’s mission or business could be a risk factor. Organizations that have critical processes or produce critical goods and services that are time-sensitive, for example, may incur more risk than an organization that can afford to be down or out of service for a few days. Time sensitivity can increase the impact of a disaster on an organization, so it should be considered when developing continuity and recovery strategies. Market factors, such as the perishability of goods, for example, can become risk factors that an organization must deal with as well.

Most people associate the threats involved with business continuity and disaster recovery with natural disasters. Obviously, natural threats exist: severe weather, earthquakes, fires, and so on. These are threats that can’t be typically prevented or neutralized, but they can be planned for. Hardened facilities, adequate ventilation, fire suppression systems, and other physical or environmental controls can mitigate the damage from these threats. On the other hand, man-made threats can also affect the ability of an organization to recover from an incident or continue to function. These can be broken down into unintentional and intentional threats. Intentional threats include those associated with hackers, terrorists, theft, and other malicious actors and activities. Unintentional threats may be attributed to accidents that are caused by carelessness, lack of training, and so on. All of these threats, both natural and man-made, are usually the types that cause incidents or disasters. However, there are also threats to the continuity management process itself.

Threats to the business’s ability to manage its continuity and disaster recovery include incomplete or inadequate planning as well as limited resources to carry out any BCP/DRP activities. Because of regulatory considerations in many cases, a business usually must have some degree of business continuity planning accomplished; the real threat centers on whether it is enough and adequately covers the different facets of recovery and continuity that the business must consider. Usually, inadequate planning and insufficient resources committed to this area are a result of shortsightedness on the part of the organization’s leadership and management.

A wide variety of vulnerabilities can affect the ability of an organization to respond to and recover from an incident or disaster. The same vulnerabilities can also, in turn, affect the organization’s ability to continue to function at some level or degree after the disaster. Some of these vulnerabilities involve the lack of resources, such as a lack of personnel, equipment or facilities, or dedicated recovery resources. For instance, if the organization has not acquired an alternate processing site, there may be no way it can quickly recover its operations back to a functional state. Other vulnerabilities include the lack of training for personnel tasked with disaster recovery or business continuity responsibilities. Additionally, there are also process vulnerabilities. Process vulnerabilities are those that result from a failure of the organization’s management to adequately plan for, staff, and equip continuity management efforts. For example, a lack of management commitment is a vulnerability that will certainly lead to a lack of training, resources, and personnel dedicated to continuity management. An inadequate or nonexistent business impact assessment is a vulnerability because an organization won’t be able to adequately identify its critical processes or assets and determine how the loss of those critical items impacts the organization. Another critical vulnerability could be faced if the organization has failed to adequately test the response plan.

EXAM TIP   Be familiar with the different business process areas and their respective risk factors, threats, and vulnerabilities. Remember that risk factors, while not a threat or a vulnerability, contribute to the overall risk of the organization by increasing or decreasing the likelihood or impact of threats exploiting vulnerabilities or the organization’s resilience to negative events.

Data Lifecycle Management

Most organizations produce a wide variety of documentation—from publications for internal use, to confidential papers for senior management, to publicly available documents. Without proper controls, such documentation could be used to compromise an organization’s security. Every organization should have guidelines that ensure all documents produced by the organization are classified, organized, and stored securely to prevent their loss, damage, or theft.

As part of its governance and risk management programs, an organization should develop data lifecycle management programs. This process also contributes to the business continuity planning we previously discussed. The organization takes a good look at all its data, categorizes it in terms of sensitivity and type (PII, proprietary, government classified, and so on), and assigns classification values to it. To ensure control over the protection and distribution of data, it needs to be classified with a certain designation. This data classification indicates what type of document it is, whether the information it contains is confidential or can be made public, and to whom it can be distributed. The classification also defines what levels of data retention and storage are needed for that document. Finally, policies must exist concerning the legal status of data and what can be destroyed and what needs to be retained.

Standards and Guidelines

To ensure the continuity of documentation across the organization, a set of documentation standards and guidelines should be introduced. These standards and guidelines can serve as templates for all documentation to guarantee that documents have the same look and feel and to ensure they’ll all be distributed and stored securely, according to their scope or sensitivity.

The standards and guidelines should address the following topics, at a minimum:

•   Data classification

•   Document handling, retention, and storage

•   Document disposal

Data Classification

An organization’s documentation can be voluminous, comprising a variety of documents of varying levels of value and importance. Depending on the type of document, the amount of security and types of procedures used in storing and distributing that document can greatly vary. Some documents might be considered public, so they can be posted in a public forum or distributed freely to anyone. Other documents might be highly confidential and contain information that only certain individuals should be allowed to see.

To aid in the document management effort, documents need to be assigned security classifications to indicate their level of confidentiality and then labeled appropriately. Each classification requires different standards and procedures of access, distribution, and storage. The classification also sets a minimum standard of privileges required by a user to access that data. If a user doesn’t have the necessary access privileges for that classification of data, the user won’t be able to access it. Typically, access is delineated using subjective levels such as high, medium, and low. These should be agreed upon by management based on the data’s sensitivity and the damage to the organization if the data is subjected to unauthorized access.

Several levels of classification can be assigned, depending on the type of organization and its activities. A typical organization might have only two classifications: private and public. Private classified documents are intended only for the internal use of the organization and can’t be distributed to anyone outside the organization. Public documents, however, would be available to anyone. Government and military institutions might have several levels of confidentiality, such as Unclassified, Confidential, Secret, Top Secret, and so on. Each level of classification represents the level of severity if that information is leaked. For example, the lowest level (Unclassified) means that the document is not considered confidential or damaging to security and can be more freely distributed (though not necessarily releasable publicly). At the highest level (Top Secret), documents are highly restricted and would be severely damaging to national security if they were to fall into the wrong hands. Each document needs to be assigned a classification depending on the sensitivity of its data, its value to the organization, its value to other organizations in terms of business competition, the importance of its integrity, and the legal aspects of storing and distributing that data.

EXAM TIP   The type of security protections, access controls, data retention, and storage and disposal policies to be used all depend on a document’s security classification.

Document Handling, Retention, and Storage

Depending on the classification of a document, the procedures and policies for handling and storing that document can be quite different. For example, a document might incur certain legal liabilities if it isn’t properly stored, distributed, or destroyed. To ensure proper document management, organizations have implemented data retention policies to help reduce the possibility of legal issues.

Certain documents are required to be archived, stored, and protected, while others should be disposed of after a certain period. These policies must be created by senior management and the legal department, which can define what retention policies apply to different classifications of documents. The data retention policy needs to be specific to your organization’s data. It also needs to consider items that could be legally damaging and information that could be damaging to the business if it were lost, leaked, or stolen.

To protect documentation properly, it should be kept offsite at a special document storage facility. In case of a disaster, such as a fire at the organization facility, this will ensure that all important documentation is secure and can be recovered.

Document Disposal

Document disposal can often be a tricky issue. In some cases, a document needs to be destroyed to avoid future legal or confidentiality ramifications. In other cases, it’s illegal to destroy certain documents that are required by law as evidence for court proceedings. Only your organization’s legal department can decide on retention and disposal policies for documents. Once decided on, these policies need to be communicated to workers to ensure that sensitive documents are either destroyed or retained as per their classification. Without proper disposal techniques, the organization is susceptible to dumpster diving attacks.

Data Retention Policies

Many organizations have been affected legally by archived e-mail or data that offers evidence against them during court proceedings. To prevent legal liabilities, organizations have implemented data retention policies to help reduce the possibility of legal problems arising from past messaging communications and data.

Data retention policies should apply to electronic information, such as files, e-mails, instant messages, and traditional paper documentation. Some clashes might occur between data retention policies and backup policies, where certain files are required to be archived, while others should be disposed of after a certain period. Only management and the legal department can define which data is covered under either policy. The data retention policy needs to be specific to your organization’s information and consider items that could be damaging legally, as well as information that can be damaging to the business if lost. In the case of e-mail, the concept of data retention becomes complicated because e-mail can contain file attachments. Part of your policy might require that e-mail be retained for a certain amount of time before deletion, while the policy for actual electronic files could be different.

Hardware Disposal and Data Destruction Policies

Any policies must also include guidance for the disposal of old hardware that might contain data. As the lifetime of computers is very low (three to five years), older equipment is constantly swapped out for newer, faster machines with more capabilities and resources. However, a critical security issue is apparent regarding the proper disposal of these systems. Servers and personal computers are typically returned with their original hard drives, which could contain sensitive and classified data. System administrators must follow a specific policy for the removal and disposal of hardware to ensure that any media containing data is completely erased or overwritten.

For electronic files, this process is more complicated. Merely deleting a file or e-mail from a hard drive doesn’t necessarily delete the data. Many operating systems use a special recovery method that enables you to recover deleted files easily. When a file is deleted, only the locator for the file in the hard drive directory has been removed; the data itself usually still exists in its original location. To ensure complete destruction of data on magnetic media such as hard drives, the media should be overwritten, or the drive physically destroyed. Many “shredder” utilities are available that can overwrite the contents of a hard drive with random data to ensure that any information on the drive is unrecoverable. Also, many high-security organizations, such as the military and national security agencies, opt to destroy the drives physically instead of using a shredding machine.

Systems Development Life Cycle

The systems development life cycle (sometimes known as the SDLC, which confusingly is used as the acronym for software as well) is essentially the entire life of a system, product, or piece of software. The life cycle covers every single aspect of a system or product, from the concept to development, from implementation to disposal. There are several popular system development life cycle models, including waterfall, iterative, and Agile. We won’t cover any of these models here, as an in-depth discussion on any one of them would fill an entire book. However, we will mention some of the more generic parts or phases of the SDLC and briefly describe them so that we can put them in the context of risk factors, threats, and vulnerabilities.

NOTE   Some models are linear, in that they progress in a sequential manner only, and some are cyclic in some way (repetitive, recursive, or iterative), where a system can be re-introduced into an earlier phase for updates or upgrades or to fix problems or issues.

At the basic level, the SDLC consists of several phases that include conceptualizing the system, discovering the requirements for a system, designing its architecture, developing the system, testing it as both a single unit and as integrated with larger systems in its environment, implementing the system, and, finally, disposing of the system after it has reached the end of its useful life. Each of these different phases of the life cycle has different aspects that include planning, management, resourcing, and so on. Each also has inherent risks. We’ll discuss these phases generically in the next few paragraphs.

NOTE   Some of the names we give to the different lifecycle phases may vary among different lifecycle models, but in general, the concepts are the same.

Software Development Life Cycle

It should be noted that in most organizations, the skills to properly set up computers and develop software are completely separate from one another. In fact, many compliance frameworks consider it a serious risk to have the software coders (often called developers) have access to a live production environment—some focusing on the ability of the software coders to implement their code in production. This need to prevent this is called separation of duties (sometimes segregation of duties). This came down from the banking industry in that two people were required to perform a task, which means that the likelihood of abuse is drastically reduced. This is another critical factor for risk assessors to take into account.

As a result of the differentiation, a software development life cycle (SDLC) is often used as a separate term from system development life cycle—two completely different groups and sets of governance are part of the organization. Typically, the CIO oversees an IT organization while a CTO would oversee the software development within an organization. As a result, for many organizations, SDLC typically refers to the former and not the latter interpretation. Both are extremely critical for many organizations, but the approach is different even though the goals may be the same.

Another factor today would be that with many cloud technologies, the software development life cycle is resting on cloud systems and system development is entirely up to the cloud provider and not as much on the organization. Cloud changes the whole relationship of systems development life cycle to software development life cycle.

Planning

The first phase of the SDLC normally involves some type of conceptual planning process, where the need for the system is determined and a general idea is developed of what the system needs to do and what purpose it will serve. Some models refer to this as the initiation phase. During this phase, the feasibility of developing or acquiring a system is studied and includes considerations such as when the system is needed, how much it might cost, what type of staffing it might need to develop, implement, maintain it, what other systems it might need to connect to or interface with, and so on. Security and privacy professionals want to be involved in this phase of the life cycle so that they can understand the basic concepts of the system and provide feedback on any potential security or privacy risks.

Often, it is the planning phase where a business case is developed, to help the organization determine whether the system (or changes to an existing system) is justifiable. A business case describes the resources required to build (or change) the system and the economic benefits expected to be derived from the system.

The phrase move to the left or shift left describes the desire for security and privacy professionals to be involved as early as possible (as far to the left on a timeline) in the conceptualization, requirements, and design of a system, in order to help avoid situations where basic concept or design of a system may be deeply flawed from a security or privacy perspective.

Requirements

The next phase of the SDLC is generally the requirements phase, and this phase is typically named as such in most models. During this phase, different sets of requirements are developed. These requirements might include functional requirements, performance requirements, security requirements, and business requirements. Requirements dictate concrete terms, such as what a system is exactly supposed to do, how it will do it, to what degree, and what standards it must meet. Without a clear set of requirements, there can’t be any good traceability back to what the system was supposed to do in the first place. That’s why it’s very important to try to accurately cover all the possible requirements and needs the system may have to meet. This is also where the scope of the development process is established. Security and privacy professionals should be invited to develop security and privacy requirements for the system, to ensure that later phases of the project will include all required characteristics.

Design

The next few phases can be a bit different based on the model under discussion and whether the product being developed is a system or software. System developers would move from the requirements phase into designing the architecture in terms of developing a general high-level design of how the system is supposed to work, what major components it might have, and what other systems it might interface with. Software developers similarly might design software architecture at a higher level during this phase. As the SDLC development process moves forward, this overall architecture is decomposed down into smaller pieces until finally individual components or pieces of code can be developed. Again, how this design process progresses depends on which model is being used. Security and privacy professionals should be asked to review the design of the system to ensure that requirements were properly represented.

Development

After the design phase, decisions must be made as to whether to build a system or software or simply acquire it from a third party. Some systems and software can be bought from other developers, but some must be developed specifically for the end application or end use. If the system is to be acquired from some other source, and the design specifications are provided to the best source, then a system or software that meets the requirements and design will be provided. If the system is to be developed, the next phase of the SDLC comes into play. During this phase, the software is written, and systems are assembled from individual components. Organizations can use tools to examine a system’s source and object code to identify any security-related defects that could be exploited by an attacker.

Testing

Following the development phase, many SDLC models include a test phase. In the test phase, different aspects of the software and systems are tested. Many different tests can take place during this phase. Some of these tests might involve unit testing, which simply means to test an individual component or unit of software at its most basic level for functionality and performance. Integration testing, another type of testing, usually involves testing the overall function and performance of all the components of the system or piece of software working together, as they would when assembled. During this phase, other types of testing could take place, including interface testing (testing different aspects of the system when it interfaces with other separate systems in its environment) and security testing (which may include compliance testing, vulnerability testing, and even penetration testing). User acceptance testing involves end users of the system performing various functions to determine whether they will accept the system in its current, developed state.

Implementation and Operation

Once a system has been tested and accepted, the implementation phase usually follows. In this phase, systems or software are put into production and used for their originally intended purpose. Some development models describe an overall implementation phase that includes the day-to-day maintenance and operations of the system. Other models move from the implementation phase to a more long-term maintenance or sustainment phase for the product. Regardless of how the phase is described in the model, during these phases, the system is used, undergoes minor maintenance and upgrades, and is periodically tested to make sure it still meets its original design and requirements.

Disposal

Once a system has been in operation for a while, it may eventually be superseded or replaced by a more efficient or updated system. When the system is replaced or removed from the environment, it is said to have entered the disposal phase. Some models refer to this also as the retirement phase. During this phase, the system is taken out of production, dismantled, and is no longer used. Its components may be reused, or they may be disposed of.

EXAM TIP   While you will likely not be expected to know the details of any specific SDLC model, be familiar with the generic phases of the SDLC: Initiation, Requirements, Design, Development, Testing, Implementation, and Disposal. Also, keep in mind that different models may refer to these phases by different names or even combine or separate phases out to some degree.

SDLC Risks

Most of the risk factors inherent to the SDLC affect both the entire model and each of the different phases separately. Since the SDLC could be considered to have several different facets, including a management process, an engineering framework, and even a methodology, you could say that risk factors that affect the SDLC are also common to other types of processes. For instance, earlier, we discussed risk factors that affect project and program management. These risk factors affect scope, schedule, and cost. The SDLC suffers from similar risk factors because each of the phases, as well as the SDLC, have different scope, schedule, and cost elements. Each of these phases can also be affected by risk factors that impact the availability of resources (manpower, funding, equipment, facilities, and so on), such as management commitment and organizational structure.

Unique risk factors that affect the SDLC include those that affect system changes, system configuration throughout the life cycle, and those that affect releasing different versions of the system as updates take place. Most of these elements occur during implementation, maintenance, and sustainment of a system but also can occur in other phases of the SDLC where multiple versions of a system are fielded simultaneously, as well as in models where there is a continuous iterative process of updating and upgrading a system or software. Risk factors that affect system changes include how well the change and configuration management processes work and how changes are implemented into the system. Change and configuration management processes that are not well managed are risk factors, because this could cause changes that are not documented or not tested for security, functionality, or performance. Additionally, factors such as the complexity of the system, how the organization is structured to manage the systems development process, and how rapid system changes occur are also potential risk factors.

Threats to the SDLC manifest themselves when systems are produced that are not interoperable or compatible with other systems and their environment or systems are not secure. Other threats might include systems that do not meet the requirements they were originally intended to meet. These threats would affect both the functionality and performance of the system as well. Threats to the design process include faulty design specifications as well as faulty requirements input from the previous requirements phase. Most of the threats to the SDLC come in the form of mismanagement, miscommunication, incorrect expectations, and lack of a commitment of resources or expertise.

Many different vulnerabilities can affect the SDLC; again, a great many of them have been previously discussed as also affecting the project or program management process. These vulnerabilities affect scope, schedule, and cost, of course, but can also affect the quality of the system or product. In addition, the system’s security, functionality, and performance are also affected by these different vulnerabilities. While probably too many to list here, examples of vulnerabilities that affect the SDLC start with a lack of firm requirements and mixed expectations from the different system stakeholders. A lack of documentation in all phases is also a significant vulnerability to the entire SDLC, but particularly to the requirements and design phases. Failure to develop solid design specifications and systems architecture is a vulnerability that can result in a faulty design that does not meet system requirements. In the development phase, lack of adequate consideration for system interfaces, as well as how subcomponents fail to support higher-level components or meet technical requirements, can result in a shoddy system or software. Failure to test systems properly and thoroughly, as well as their interaction with their environment, may mean that serious functional or performance issues with the system are not discovered until well after it is put into production. Vulnerabilities in the implementation phase include faulty implementation, lack of traceability to original requirements, and failure to properly maintain a sustained system after it has been put into production. And lastly, vulnerabilities associated with the disposal or retirement phase of the SDLC can result in systems that are not properly replaced or not securely disposed of. This can cost the organization money and potential liability.

Emerging Technologies

New or emerging technologies can present risks to organizations simply because there are several different important considerations when integrating the latest technologies into the existing infrastructure. Many organizations have an unfortunate tendency to rush out, buy, and attempt to implement the latest and greatest technologies on the market without careful planning or consideration of the existing infrastructure and how it will react to the new technologies. One of the primary considerations organizations must look at is making a business case for the new technology, which may be to fill a gap that the older technology does not provide or to provide a capability that the organization must now have to compete in the market space. In other words, the organization really must justify new technologies to make them worth the risk they could incur.

Emerging technologies have several risk factors inherent to their integration into the existing infrastructure. If the organization has been able to justify the implementation based on a true business need for the emerging technology, it must consider several risk factors. One of the major risk factors is interoperability with existing infrastructure. Frequently, newer technologies don’t always work properly with older systems right out of the box; adjustments may need to be made to the existing infrastructure to integrate the new technology, or even bridging technologies may be needed to connect the two together. Interoperability doesn’t just involve the right connections; it can involve data formats and flows, security methods, interfaces into other systems, and changes to business processes. These considerations, and many others, are risk factors that must be considered before acquiring and integrating new technologies.

Another risk factor is security. New technologies may have security mechanisms that are not necessarily backward compatible with existing ones. Examples include encryption algorithms and strengths, identification and authentication technologies, integrity mechanisms, and even redundant or backup systems. Additionally, the systems may involve a learning curve that may intimidate users who must now learn new security methods for the system. The human factor can be a weak link in the security chain, so either lack of training or a lack of adaptability to the new security mechanisms can introduce risk.

Earlier, when we discussed the SDLC model, we pointed out that system updates and changes can be risky if not managed properly. Integrating new technologies into the environment with older ones can introduce both intentional and unintended changes into the environment as well, affecting the stability of the organization’s SDLC with a particular system. Therefore, change is also a risk factor. Even in the disposal or replacement phase of the SDLC, introducing new technologies to replace older ones can be problematic if not planned and executed properly. New technologies that are not adequately tested for functionality, performance, integration, interoperability, and security may not be able to adequately replace older systems, resulting in extended costs and possibly even requiring an extension of the older systems’ life cycle.

Threats resulting from the introduction of new and emerging technologies into the existing infrastructure are numerous. If the organization has failed to adequately plan for the new technology, these threats can become significant. Some of these threats include untested or unproven technologies, non-interoperability, incompatible security mechanisms, and suitability of the technology for use in the organization. The organization could also incur additional costs and require more resources due to faulty implementation. These threats can be minimized through careful planning and by integrating new technologies using a stable SDLC model.

As with threats, vulnerabilities associated with emerging technologies are numerous as well. Vulnerabilities could include a lack of trained staff committed to managing and implementing the new technology. Lack of adequate project planning is also a serious vulnerability that could affect the organization’s ability to effectively integrate new technologies. Another vulnerability could be a weak support contract or another type of warranty, guarantee, or support for a new technology or system. Most of these vulnerabilities appear when a new technology is first implemented and tend to become mitigated or lessened as the technology is integrated into the existing infrastructure, but they still exist.

EXAM TIP   The key areas of concern with emerging technologies are interoperability and compatibility. These two concerns affect the security, functionality, and performance of new technologies when they are installed into an existing infrastructure.

Information Security Concepts, Frameworks, and Standards

In order to successfully sit for the CRISC exam, you should be familiar with some basic information security concepts. You can’t be expected to know how to manage risk in a security environment if you don’t understand the basics of information security in the first place. Now, we’re going to assume you have some level of experience already as an information security professional, since risk management is a significant portion of (and a logical career progression from) the information security profession. You may also have had some level of experience in specific risk management processes at some point during your career. As such, we’re not going to go into great detail on the basic information security concepts in the upcoming sections; this will just serve as a quick refresher to remind you of certain security concepts. We’ll also review a few key control frameworks in detail, including the NIST Risk Management Framework (RMF) and COBIT 2019, and how these frameworks are used in managing risk. Additionally, you’ll find that this chapter covers more material than you might find on the exam; this is for two important reasons. First, it’s important that you understand foundational and conceptual knowledge about controls and some of the relevant control frameworks you will find on both the exam and in the real world as a risk and control assessor. Second, this book is intended to be not only a study guide for the exam but also a comprehensive reference you will use even after you have passed the CRISC exam.

You may learn traditional information security doctrine, as well as fundamental information security knowledge, from various training courses and on-the-job experience over the years. One such doctrine teaches that there are three fundamental information security goals. These goals are what we’re striving for as risk and information security professionals; they are confidentiality, integrity, and availability. You’ll sometimes see these three terms strung together as an acronym, such as the CIA triad or, occasionally, the AIC triad, depending on the different information security literature you read. In any event, these three goals are what we want to achieve for all our information systems and data. They are also characteristics we want to ensure all our systems, processes, procedures, methods, and technologies display.

Popular security theory sets forth these three overarching security goals but also provides for auxiliary elements that support these goals in various ways. These are concepts that, both individually and combined, help us as security professionals to ensure we maintain data confidentiality, integrity, and availability, as well as protect our systems from unauthorized use or misuse. We’ll discuss all these different security elements and other concepts, as well as how they support three primary goals of information security, in the next few sections.

Confidentiality, Integrity, and Availability

Confidentiality is the goal of keeping information systems and data from being accessed by people who do not have the authorization, need-to-know, or security clearance to access that information. In other words, confidentiality means that only authorized individuals and entities should be able to access information and systems. Confidentiality can be achieved through a number of security protection mechanisms, such as rights, privileges, permissions, encryption, authentication, and other access controls. If confidentiality of data or information systems is breached, we get the opposite of confidentiality, which is unauthorized disclosure. Unauthorized disclosure is a risk to data and information systems, and one we as security professionals struggle very hard to protect against.

Integrity is the characteristic of data that describes the state in which a system or its data has not been subject to unauthorized modification or alteration. Data integrity means that data is left in the same state as it was when it was stored or transmitted. Therefore, when it is accessed again or received, it should be identical to the data that was originally stored or transmitted. Integrity is achieved in several ways, by using checksums, message digests, and other verification methods. Data alteration is the opposite of integrity, particularly when the modification has not been authorized by the data owner. Data modification or alteration can happen accidentally, such as when it is inadvertently changed due to human error or faulty transmission media. It can also happen intentionally (which is usually malicious in nature when this modification is unauthorized) by direct interaction with data during storage or transmission (during an attack, for example). This risk to data affects whether the data can be trusted as authentic or true, whether it can be read as intended, or whether it is corrupt.

Availability is the property of systems and data to be accessible to authorized users at any time or under any circumstances. Even if data is kept confidential, and its integrity is kept intact, it still does us no good if we can’t access it when we need it to perform critical business functions. Availability ensures we have this data (and the information systems that process it) at our fingertips. Just as confidentiality and integrity have their opposites, data destruction and denial of service are the opposite of availability. These risks to our information systems could prevent authorized consumers of that data or users of that information system from performing their jobs, thus severely impacting our business operations.

EXAM TIP   You will need to understand the definitions of the goals of information security—confidentiality, integrity, and availability—very well for the exam. Almost everything in information risk management supports those three goals, either directly or indirectly.

Access Control

As an information security professional, you probably already know that a security control is a security measure or protection applied to data, systems, people, facilities, and other resources to guard them from adverse events. Security controls can be broken down and categorized in several ways. Access controls directly support the confidentiality and integrity goals of security, and indirectly support the goal of availability. Access control essentially means that we will proactively ensure that only authorized personnel are able to access data or the information systems that process that data. Access controls ensure that only authorized personnel can read, write to, modify, add to, or delete data. They also ensure that only the same authorized personnel can access the different information systems and equipment used to store, process, transmit, and receive sensitive data.

There are several different types of access controls, including identification, authentication, and authorization methods, encryption, object permissions, and more. Remember that access controls can be administrative, technical, or physical in nature. Administrative controls are those implemented as policies, procedures, rules and regulations, and other types of directives or governance. For example, personnel policies are usually administrative access controls. Technical controls are those we most often associate with security professionals, such as firewalls, proxy servers, VPN concentrators, encryption techniques, file and folder permissions, and so on. Physical controls are those used to protect people, equipment, and facilities. Examples of physical controls include fences, closed-circuit television cameras, guards, locked doors, gates, and restricted areas.

In addition to classifying controls in terms of administrative, technical, and physical, we can also classify access controls in terms of their functions. These functions include preventative controls, detective controls, corrective or remedial controls, deterrent controls, and compensating controls. All the different controls can be classified as one or more of these different types of functions, depending on the context and the circumstances in which they are being used. Controls were described in more detail in Chapter 3.

Data Sensitivity and Classification

Asset is a general, all-encompassing term that could include anything of value to an organization. The term asset can be applied to data, systems, capabilities, people, equipment, facilities, processes, proprietary methods, and so on; it is anything the organization values and desires to protect. Organizations normally determine how important their assets are to them and how much protection should be afforded to those assets. For example, intellectual property is an extremely valuable asset to the organization and is normally well-protected. This is really the basic fundamental concept of risk management: how much security or protection a particular system or piece of data requires, based on how likely it is that something bad will happen to it, balanced with what the organization can really afford to spend on the protection for that asset. In order to make reasonable decisions on how much security an asset needs, the organization has to decide how much the asset is worth to it. We’ll discuss worth in terms of dollars a bit later in the chapter, but for now let’s look at it from a perspective of asset sensitivity. In terms of sensitivity, you’ll usually see the term data sensitivity in particular, but we could also broadly apply sensitivity to any asset in an organization.

Data (or other asset) sensitivity refers to how much protection the organization feels a particular system or piece of data requires, based on its value to the organization and the impact if it were lost, stolen, or destroyed. For example, information published on the organization’s public website or in the company newsletter is public knowledge and is usually easily retrievable if, for some reason, the hard disk containing that data fails or is erased. Since the data is public, we may not consider that data to be very sensitive in nature and therefore require less protection for it than other types of data. On the other hand, customer order data is extremely important to the organization, simply because its business operations depend on that data in order to function and turn a profit, so it makes reasonable sense that the organization would spend a little bit more time, money, and effort in protecting that particular data. Therefore, its sensitivity, or classification level, would be considered somewhat higher than public data. Generally, the higher the sensitivity of the data, the more protection it is given.

In basic security classes, you typically learn about the different classifications of data found in both commercial organizations and government ones. In commercial organizations, typical data sensitivity labels include Private, Company Sensitive, Proprietary, and so on. In the U.S. government, data sensitivity levels include Confidential, Secret, and Top Secret, and are classified based on the level of damage to the security of the United States that could be incurred if data at these various classification levels was disclosed or lost. Remember that data sensitivity is driven by the value of the data to the organization, the impact if it is lost, stolen, or destroyed, and balanced by the commitment of resources the organization is willing to provide to protect that data. Data sensitivity and classification policies specify the different formal levels of sensitivity in the organization and what those levels require in terms of protection.

Identification and Authentication

Identification and authentication are often misunderstood terms. They are related, to be sure, but they are not the same thing and really shouldn’t be used interchangeably by a knowledgeable security professional. Identification refers to the act of an individual or entity presenting valid credentials to a security system in order to assert that they are a specific entity. When you enter a username and password into a system, for example, or insert a debit card into an automated teller machine and enter a personal identification number (PIN), you are identifying yourself. Authentication, on the other hand, is the second part of that process, where your identity is verified with a centralized database containing your authentication credentials. If the credentials you have presented match those in the authentication database, you are authenticated and allowed access to the network or resource. If they do not match, you are not authenticated and are denied access to the resource.

There are several different methods of identification and authentication, including single factor (such as username and password, for example) and multifactor, which consists of two or more of the following: something you know (knowledge factor), something you have (possession factor), or something you are (biometric or inherence factor). Authentication also uses a wide variety of methods and technologies, such as Kerberos and 802.1X.

Authorization

Authentication to a resource doesn’t automatically guarantee you have full, unrestricted access to a resource. Once you are authenticated, the system or resource defines what actions you are authorized to take on a resource as well as how you are allowed to interact with that resource. Authorization is what happens once you’ve successfully identified yourself and have been authenticated to the network. Authorization dictates what you can or can’t do on the network, in a system, or with a resource. This is usually where permissions, rights, and privileges come in. In keeping with the concept of least privilege, users should only be authorized to perform the minimum actions they need in order to fulfill their position’s responsibilities. Authorization has a few different components. First, there is need-to-know. This means that there must be a valid reason or need for an individual to access a resource, and to what degree. Second, an individual may have to be trusted, or cleared, to access a resource. This may be accomplished through a security clearance process or non-disclosure agreement, for example.

EXAM TIP   Understand the differences between identification, authentication, and authorization. Remember that identification is simply presenting credentials, whereas authentication is verifying them. Authorization dictates what actions an individual can take on a system once authentication has occurred.

Accountability

Accountability means that a person is going to be held responsible for their actions on a system or with regard to their interaction with data. Accountability is essentially the traceability of a particular action to a particular user. Users must be held responsible for their actions, and there are different ways to do this, but it is usually ensured through auditing. First, there must be a unique identifier that is tied only to a particular user. This way, the identity of the user who performs an action or accesses a resource can be positively established. Second, auditing must be properly configured and implemented on the system or resource. What we are auditing is a user’s actions on a system or interactions with a resource. For example, if a user named Sam deletes a file on a network share, we want to be able to positively identify which user performed that action, as well as the circumstances surrounding the action (such as the time, date, from which workstation, and so on). This can only be accomplished if we have auditing configured correctly and take the time to review the audit logs to establish accountability.

NOTE   Although related, accountability is not the same thing as auditing. Accountability uses auditing as just one method to ensure that the actions of users can be traced to them and that they are held responsible for those actions. Other methods, such as non-repudiation, are used as well.

Non-Repudiation

Non-repudiation is closely related to accountability. Non-repudiation ensures that the user cannot deny that they took an action, simply because the system is set up such that no one else could have performed the action. The classic example of non-repudiation is given as the proper use of public key cryptography. If a user sends an e-mail that is digitally signed using their private key, they cannot later deny that they sent the e-mail since only they are supposed to have access to the private key. In this case, the user can be held accountable for sending the e-mail, and non-repudiation is ensured.

Note that there is no hard and fast rule about mapping security elements and access controls to security goals; all of these elements and controls can support any one or even more than one goal at a time. For example, encryption, a technical access control, can support both confidentiality and integrity at the same time.

NOTE   Although other texts may describe the supporting elements of the security goals differently, the basic ones we’ve described here are very common and directly support the three goals of confidentiality, integrity, and availability.

Frameworks, Standards, and Practices

Managing risk is not an ad-hoc process. It can be a complex effort and involves establishing a formal program with responsible people leading it. It requires developing procedures and processes that are defined, repeatable, and defendable. Fortunately, you don’t have to reinvent the wheel; most of this work has already been done for you in the form of established frameworks, methods, standards, and practices. One of the first things you’ll want to do when establishing a risk program is to understand what type of framework, processes, standards, and practices you will use since there is a variety to choose from. You must try to use the one that fits your organization the best, and you can’t do that unless you have at least a basic understanding of the more defined, standardized ones used in the industry. Let’s take a moment and discuss the difference between frameworks, standards, and practices.

Frameworks

A framework is a generally overarching methodology for a set of activities or processes. It may not get into the detailed processes and procedures; instead, it provides for a 500-foot view of the general direction and steps used to build a more detailed program or process. A framework is used as an overall architecture for a greater effort. A framework has characteristics that include defined steps and repeatability, and it can be tailored based on the organization’s needs. In terms of a risk management framework, you may have a set of general steps defining how to approach risk management, which include listing the processes and activities necessary to build such a program or effort. You would then break down these larger steps into specific supporting procedures for this effort based on the needs of your organization and using standards (described next). Frameworks are typically selected and adopted at the strategic level of corporate management and governance.

Standards

A standard is a mandatory set of procedures or processes used by the organization and usually fits into an overall framework. Standards often define more detailed processes or activities used to perform a specific set of tasks. Standards are used for compliance reasons and made mandatory by an organization or its governance. The National Institute for Standards and Technology (NIST) standards are mandatory for use by the United States federal government, for instance, but are published as an option for private organizations and industries to adopt if they so choose. If an organization adopts the NIST standards for risk management, for example, the organization may make them mandatory for use by its personnel. Then all processes and activities for a given effort within the organization would have to use and meet those standards. Some standards define the level of depth or implementation of a security control or measure. The Federal Information Processing Standards (FIPS) for cryptography and encryption are an example of this; they set forth the different levels of encryption strength for various cryptography applications that may be required in certain circumstances. So, if you create security policies and procedures for implementing cryptography within the organization, the FIPS standard could tell you to what level those policies and procedures must be implemented.

Practices

A practice is a normalized process that has been tried and proven as generally accepted within a larger community. Practices could also be developed by a standards organization or a recognized authority regarding a particular subject or particular process. Professional industry organizations or vendors often develop practices documents. You might also see “best practices” promulgated by various industries or organizations, for example. Practices are not usually mandatory but could be made mandatory by the corporate management or other governance if they were so inclined.

The next few sections give more detailed examples of some of the formal frameworks and standards you should be familiar with for the exam and in real life as a risk management professional. We recommend you pay particular attention to the ones developed and published by ISACA; these will likely be present in some form on the exam. Of course, in this book, we’re only going to give you a brief overview of each, and you should take the time to review the actual standards and frameworks in depth before you sit for the exam.

NIST Risk Management Framework

The NIST Risk Management Framework (RMF) is a seven-step methodology that provides for risk management all the way through the information systems life cycle. The steps for the RMF are briefly described in the following sections.

Step 1: Prepare

The first step, Prepare, has the purpose of carrying out essential activities to help prepare all levels of the organization to manage its security and privacy risks using the RMF. It involves identifying key risk management roles, establishing the organizational risk management strategy, determining the organization’s risk tolerance, assessing the organization’s risk assessment, developing the organizational strategy for continuous monitoring, and identifying the implemented common controls.

Step 2: Categorize

Step 2, Categorize, involves inventorying the types of information on target systems and assigning categorization levels to that information based on the level of impact if the security goals of confidentiality, integrity, and availability were affected or compromised for the information on the system. This step uses subjective values of high, medium, and low to assign values to each of the three goals for a particular type of information. Types of information processed on the system could include business-sensitive, financial, protected health information, and so on. FIPS 199, “Standards for Security Categorization of Federal Information and Information Systems,” as well as NIST Special Publication 800-60, “Guide for Mapping Types of Information and Information Systems to Security Categories,” provide detailed guidance on categorizing information systems.

Step 3: Select

Based on these individual values, as well as an aggregate of them, the applicable security controls you would assign to this information system would be accomplished in Step 3, Select. This step provides baselines of security controls based on the high, medium, and low values assigned during step 2. If the aggregate value of information or system has been rated as high, for example, the high baseline of security controls is employed for that system. Once a security control baseline has been established, the organization has the latitude and flexibility to add or subtract security controls from the baseline as it sees fit based on different factors, including the applicability of some controls, the environment the system operates within, and so on. The selected controls can be found in the supporting NIST Special Publication 800-53, revision 5, “Security and Privacy Controls for Information Systems and Organizations,” which contains a catalog of all the NIST controls.

Step 4: Implement

In Step 4 of the RMF, Implement, the selected controls are applied to the information systems and data is processed on those systems. This is a large process that can cover a good deal of the life cycle of the system in question, and it may take significant time and resources. In this step, the organization is essentially securing the information system against any validated threats and protecting identified vulnerabilities.

Step 5: Assess

Step 5, Assess, is where a lot of security professionals who manage certification and accreditation activities or perform risk assessments come into the picture. During this step, the controls the organization selects for the information system are formally assessed, verifying that they were implemented correctly and validating whether they perform as they were designed. They are assessed based on their effectiveness in protecting against the threats they were implemented to protect against. During this step, the system is assessed in its current state, with all existing controls and mitigations in place. Based on the assessment findings, there may be recommendations for further controls and mitigations, as well as alterations to the existing security posture for the system. In this step, the level of risk to the system and its data is normally analyzed and determined.

Step 6: Authorize

Step 6, Authorize, involves the decision from the entity in charge to authorize a system to be implemented and put into operation. This decision is based on various factors, including the level of risk assessed during step 5, the risk appetite the organization has settled on, and the tolerance for risk the organization is willing to accept. The decision to authorize a system for use may also come with caveats, including conditional authorization based on the continued mitigation and reduction of risk by the system or data owner. This authorization is a formal authority for the system to operate, made by someone with the legal authority to make that decision. It is typically in writing and only valid for a specified period, after which the system must be reassessed for risk and control compliance.

Step 7: Monitor

Continuous monitoring of security controls defines step 7 in the RMF; just because an authorization decision is rendered doesn’t mean the system will now be operated forever without continually monitoring its security posture for new or changed risks. Existing controls should be monitored for continued compliance and effectiveness against identified threats. New risks will be occasionally discovered for the system as new threats and vulnerabilities are identified, and the system will have to be reauthorized after a certain period. Note that the RMF is a cyclical process; all these steps will be accomplished again for each system at various times over its life cycle.

ISO 27001/27002/27701/31000

Whereas the NIST RMF is very much an American framework, the International Organization for Standardization (ISO) frameworks are used globally. The ISO family is largely focused on keeping information assets secure, ensuring privacy, and managing risk across the following major documents:

•   ISO/IEC 27000:2018 Provides the overview of information security management systems (ISMS).

•   ISO/IEC 27001:2013 Specifies the requirements for establishing, implementing, maintaining, and continually improving an ISMS within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization.

•   ISO/IEC 27002:2022 Gives guidelines for organizational information security standards and information security management practices, including the selection, implementation, and management of controls, taking into consideration the organization’s information security risk environment(s).

•   ISO/IEC 27701:2019 Specifies requirements and provides guidance for establishing, implementing, maintaining, and continually improving a privacy information management system (PIMS).

•   ISO 31000:2018 Provides guidelines on managing risk faced by organizations.

COBIT 2019 (ISACA)

COBIT (formerly an acronym for Control Objectives for Information and Related Technologies) is a framework developed by ISACA and facilitates the governance of enterprise information and technology. This framework has been around for several years and through several iterations. It also provides for integration of other popular frameworks and standards, including The Open Group Architecture Framework (TOGAF), the Project Management Body of Knowledge (PMBOK), the Information Technology Infrastructure Library (ITIL), PRojects IN Controlled Environments 2 (PRINCE2), the Committee of Sponsoring Organizations of the Treadway Commission (COSO), and the many International Organization for Standardization (ISO) standards. This interoperability enables new users of COBIT to leverage any of these other standards they have already been using in their adoption of COBIT.

COBIT consists of two layers in its model, governance and management, which further break down into a total of 40 separate objectives. Table 4-3 quickly summarizes these layers and their respective objectives.

Table 4-3 COBIT 2019 Governance and Management Objectives

Note that while COBIT covers a variety of business and IT processes and areas, those specific to risk management happen at both layers—governance and management—and are tightly integrated with other processes. COBIT, in this regard, is not a risk management framework per se, as is the NIST RMF, but offers more of a broader view of management and governance across all major areas of a business. The next topic we cover, ISACA’s Risk IT Framework, supports COBIT and provides a more granular view of risk management practices and activities.

NOTE   Understand that while COBIT is important to the overall risk discussion, it is not a risk framework itself. It does, however, support management and governance of IT as well as other critical business areas. It also leads to a more detailed discussion on the ISACA Risk IT Framework, which does deal with IT risk.

The Risk IT Framework (ISACA)

The Risk IT Framework is a more concise, risk-related set of processes than that offered by the related framework COBIT 2019. While COBIT covers the “big picture” of governance and management processes that support risk management programs in the organization, the Risk IT Framework gets more into the key processes of risk management, such as risk governance, evaluation, and response. The Risk IT Framework is also a mere summary of ISACA’s The Risk IT Practitioner Guide, available to ISACA members, which is an even more in-depth treatment of the processes and activities encountered during risk management.

The Risk IT Framework comes from traditional risk management principles of various enterprise risk management (ERM) standards and describes activities and processes thought of as best practices in the industry. It provides a starting place for the establishment of these processes—sort of a map to navigate from a nonexistent or immature risk management program to a formalized, defined set of processes. The Risk IT Framework focuses more on the business risks of using IT in the organization’s structure and how risk is involved with the gap often found between IT implementation and business goals. Table 4-4 lists the different domains of the Risk IT Framework model, with each of their three major processes.

Table 4-4 Domains and Processes of ISACA’s Risk IT Framework

Keep in mind we’ve only covered a few of the risk-related frameworks and standards available in the industry. Also, be aware that we’ve only scratched the surface of these bodies of knowledge here in this chapter; a full discussion of each one of them is quite beyond the scope of this book. You should obtain and review these publications in depth before you sit for the exam. There are also many other available frameworks and standards developed and promulgated by other professional organizations, government entities, industries, vendors, and so on. You should be familiar with as many of these as is relevant to your work since they help you turn risk management from “magic” into an art and science for your organization. The frameworks and standards we have described earlier are the ones most relevant to your studies for the CRISC exam.

EXAM TIP   While you may not be expected to know the intricate details of each framework described here, it will be helpful to know at least the basic characteristics and descriptions of each. You may be asked to identify a particular characteristic of a framework on the exam.

Security and Risk Awareness Training Programs

Both security awareness and risk awareness training programs are critical controls to reduce risk within an organization. They can cover a whole range of topics, including phishing, data handling, data sensitivity, compliance requirements, wireless challenges, how data is lost, how to submit incidents, and so on. Both help to improve the risk posture of organizations at an individual level by increasing general employee awareness of threats and required practices as well as leader awareness of organizational risks. Not having any training is an indication, from a risk perspective, that people may not know how to handle different types of risks or even how to recognize risks.

Awareness programs are a very necessary part of risk management. They can’t be viewed as simply just another two-hour training session to check a box for management or compliance. Awareness is essential because it helps form and maintain the organization’s risk culture. It also educates personnel at all levels of the organization, including employees and other workers, managers, and senior leadership, on the organization’s risk strategy, its appetite and tolerance levels for risk, its risk management plan, and other relevant topics necessary to manage risk in the organization. Beyond the education on organizational governance and risk management processes, awareness training can give all members of the organization the knowledge they need to better identify, assess and evaluate, and respond to risk. Awareness training may be required for compliance with governance in some cases, but even if it’s not, it should be considered critical to the overall risk management strategy in the organization and given due consideration in the organizational priority list. The next two sections discuss the different tools and techniques used in awareness training and how to develop an awareness program within an organization.

Awareness Tools and Techniques

Like most training, awareness training should meet several criteria. First, it should be geared toward specific groups of audiences. This might include basic training that everyone receives, more advanced training for managers or senior leaders, and in-depth training for personnel with assigned risk management responsibilities, such as risk owners, risk analysts, and so on. Second, training shouldn’t be a one-time event. Periodic, recurring training is a good idea simply because it can be used to reinforce and refresh stale knowledge and bring workers up to date on the latest tools, techniques, and risk considerations. Finally, awareness training should be well organized and conducted by knowledgeable instructors, both from inside and outside the organization. Internal trainers can give the benefit of the organization’s specific views on risk culture, appetite, and tolerance, while external trainers bring the benefit of objective knowledge and risk management methods from the industry.

The subject of the training depends on the audience, of course. The basics may include familiarization training with rules and regulations regarding risk within the organization as well as the basic steps of risk management. Basic concepts and definitions may also be provided in familiarization training. Specific training on risk management techniques and tools may be reserved for those workers who have direct risk management responsibilities. There also may need to be training for senior leadership on how to develop risk management strategies and plans for the organization.

An organization can deliver awareness training in several different ways, and using various combinations of training types can help to deliver an effective training program. Classroom training is, of course, one standard method. Other methods might include individual-based training that comes from reading, computer-based training, and so on. Workers might also be required to read a risk management handbook that defines the different rules and regulations covering risk within the organization. Specialized training on risk management might have to be provided by an external training provider for those individuals with defined risk management responsibilities.

Developing Organizational Security and Risk Awareness Programs

Establishing the security and risk awareness programs in an organization can be a challenge. One way organizations fail is to simply direct someone to develop a training program, when the organization has not even established its risk management strategy or plans. Developing the organization’s approach for risk is an essential first step before implementing awareness training. The organization must develop, formally if possible, its stance on risk appetite and tolerance as well as its risk management strategy. It should decide what risk management methodologies it will use as well as what standards and frameworks. Only then can a training program be developed based on a good, solid risk management framework within the organization.

Establishing the awareness training programs also requires buy-in from management at all levels. The program should be adequately funded, and allowances should be made for workers to be able to take part in the training. Management should be committed to awareness training as part of its overall risk management strategy. Sufficiently trained and experienced instructors or a training program manager should be selected to develop and maintain the program. Finally, the training program should articulate not only the risk culture of the organization but also the different risk management needs the organization has. These might include specific risk factors, threats, vulnerabilities, and so on, considered when the training is developed. Workers that participate in awareness training should be able to easily put into practice the concepts, tools, and techniques they learn. Additionally, the training program should be periodically evaluated for effectiveness, as well as updated with current risks, governance, tools, and techniques.

Beyond initial or recurring awareness training, ongoing communication within the organization is a must for effectively managing both security and risk awareness. Workers in general, but also specifically those with key risk management duties, should be given information on an ongoing basis regarding organizational risks and how to manage and deal with them. Obviously, some information would be restricted from the general organizational population, but specific instances of threats and vulnerabilities, risk factors, and so on should be provided to risk managers in key areas so they can keep updated on the most current risk posture for the organization.

EXAM TIP   While training programs are sometimes the first things that are cut from the budget or the last things to be developed in a program, don’t underestimate the importance of awareness training within the overall risk management strategy. Training not only can make the risk management process within the organization more effective, it can also actually help to reduce or mitigate risk because it educates people about the subject, and this alone may minimize risk.

Data Privacy and Data Protection Principles

Throughout this chapter, we have discussed the core concepts of information security that any program should be striving for. This section outlines key data privacy and data protection principles and associated policies and procedures that organizations should consider when aiming to reduce risk.

Security Policies

Security policies and procedures are official organization communications created to support those critical principles of data privacy and data protection. These policies and procedures define how the workers must interact with the organization’s computer systems to perform their job functions, how to protect the computer systems and their data, and how to service the organization’s clients and constituents properly. Essentially, these policies define how an organization will implement the principles that must be upheld.

Access Control

The following access control principles and policies help provide a consistent organizational structure and procedures to prevent internal fraud and corruption in your organization:

•   Least privilege The least privilege principle grants users only the access rights they need to perform their job functions. This requires giving users the least amount of access possible to prevent them from abusing more powerful access rights.

•   Separation of duties The separation of duties principle ensures that one single individual isn’t tasked with high-security and high-risk responsibilities. Certain critical responsibilities are separated between several users to prevent corruption.

•   Job rotation Job rotation provides improved security because no worker retains the same amount of access control for a position indefinitely. This prevents internal corruption by workers who might otherwise take advantage of their long-term position and security access.

•   Mandatory vacation A mandatory vacation policy requires employees to use their vacation days at specific times of the year or to use all their vacation days allotted for a single year. This policy helps detect security issues with employees, such as fraud or other internal hacking activities, because the anomalies might surface while the user is away. Increasingly, organizations are implementing a policy requiring mandatory administrative leave for situations in which an employee is under any sort of investigation, systems related or otherwise.

Physical Access Security

As part of its overall access control, your organization must have strong physical access controls and an associated policy, and it must ensure that all workers are educated on the policy’s use.

Depending on the security level of the organization, physical security may include guarded or unguarded entrances. Even on guarded premises, the use of security access cards ensures that only identified, authenticated, and authorized persons can enter a facility. Each security access card is coded with the authorization level of the user, who will be able to access only areas of the facility required by their job function. For example, only network and systems administrators would be able to access a server and network communications room with their access card.

Workers must be trained to always close automatically locking doors behind them and not allow unidentified people to follow them through (known as tailgating). Most security access cards include a photograph of the cardholder to further identify users in the event they are challenged for their identity. Workers must be encouraged to report suspicious individuals within the premises who are unfamiliar and do not have proper identification.

A published organizational security policy that addresses physical access allows your workers to have proper knowledge of security procedures and to be equally active in the responsibility for physical security.

Network Security

Several policies provide standard guidelines for implementing network security principles within an organization and encompass areas such as the use of the Internet and internal network, data privacy, security incident response, human resources (HR) issues, and document security. These policies are often enforced by technical controls such as data loss prevention (DLP) tools that monitor for breaches of policy and issue a report when a breach occurs. Other tools may alert an administrator to machines joining the network that don’t meet security requirements (having out-of-date antivirus signatures, for example) or report to an administrator when an unauthorized machine has been added to the network or an inappropriate website has been visited.

Acceptable Use

An acceptable use policy (AUP) is a policy consisting of a set of established guidelines for the appropriate use of computer networks within an organization. The AUP is a written agreement, read and signed by workers, that outlines the organization’s terms, conditions, and rules for Internet and internal network use and data protection.

An AUP helps educate workers about the kinds of tools they will use on the network and what they can expect from those tools. The policy also helps to define boundaries of behavior and, more critically, specifies the consequences of violating those boundaries. The AUP also lays out the actions that management and the system administrators may take to maintain and monitor the network for unacceptable use, and it includes the general worst-case consequences or responses to specific policy violations.

Developing an AUP for your organization’s computer network is extremely important for both organizational security and limiting legal liability in the event of a security issue. An AUP should cover the following issues:

•   Legality The organization’s legal department needs to approve the policy before it’s distributed for signing. The policy will be used as a legal document to ensure that the organization isn’t legally liable for any type of Internet-related incident and any other transgressions, such as cracking, vandalism, and sabotage.

•   Uniqueness to your environment The policy should be written to cover the organization’s specific network and the data it contains. Each organization has different security concerns—for example, a medical facility needs to protect data that differs significantly from that of a product sales organization.

•   Completeness Beyond rules of behavior, the AUP should also include a statement concerning the organization’s position on personal Internet use on company time.

•   Adaptability Because the Internet is constantly evolving, the AUP will need to be updated as new issues arise. You can’t anticipate every situation, so the AUP should address the possibility of something happening that isn’t outlined.

•   Protection for employees If your employees follow the rules of the AUP, their exposure to questionable materials should be minimized. In addition, the AUP can protect them from dangerous Internet behavior, such as giving out their names and e-mail addresses to crackers using social engineering techniques.

The focus of an acceptable use policy should be on the responsible use of computer networks and the protection of sensitive information. Such networks include the Internet—for example, web, e-mail (both personal and business), social media, and instant messaging access—and the organization’s intranet. An AUP should, at a minimum, contain the following components:

•   A description of the strategies and goals to be supported by Internet access in the organization

•   A statement explaining the availability of computer networks to workers

•   A statement explaining the responsibilities of workers when they use the Internet

•   A code of conduct governing behavior on the Internet

•   A description of the consequences of violating the policy

•   A description of what constitutes acceptable and unacceptable use of the Internet

•   A description of the rights of individuals using the networks in the organization, such as user privacy

•   A description of the expectations for the access and use of information

•   Proper use of social media

•   A disclaimer absolving the organization from responsibility under specific circumstances

•   A form for workers to sign indicating their agreement to abide by the AUP

Note that many organizations’ websites contain an acceptable use policy or terms of use statement that protects them from any liability from users of the site.

Social Media

Websites such as Facebook, Twitter, and Instagram are more popular than ever, and workers often use these sites, sometimes during the workday, to keep up with friends, family, and activities. While keeping your workers’ morale high is a plus, it’s important to limit social media usage at work, as it can be a hit to overall productivity. Perhaps even more importantly, workers who are posting negative comments about your organization, or even posting potentially private intellectual property, can be a competitor’s dream. For example, consider a disgruntled employee who begins tweeting about your organization’s secret spaghetti sauce recipe, which is then copied by a competitor. Not good!

However, some pleasant scenarios for an organization can be directly attributed to workers’ social media usage. That’s why it’s important to determine what level of social media use your organization is comfortable with while workers are on the clock. Many organizations have a policy that social media use during work is only allowed on breaks and lunch hours and that workers may not discuss or disclose any information regarding their workplace or intellectual property.

Personal E-Mail

As with social media, many workers have personal e-mail accounts they may want to keep an eye on throughout the day; this lets them know that bills are being paid, packages have been delivered, and so on. Maybe they even use e-mail to keep up with friends. Although this can be positive for workers’ morale, it is important that an organization understands how personal e-mail is being used throughout the workday. An important consideration is a potential threat associated with sophisticated adversaries in cyberspace who know a great deal about the organization’s workers and may use their personal e-mail account for spearfishing and other nefarious activities. If malware is introduced through this personal e-mail usage during the workday, it then becomes your problem—assuming they’re using one of the organization’s systems to read their personal e-mail. That malware could potentially leak trade or other secrets about your organization. Again, as with social media, it is important for an organization to dictate the terms of how personal e-mail will be used throughout the workday and whether personal e-mail is allowed to be used on the organization’s more sensitive systems. For example, it is generally considered bad practice to allow personal e-mail to be used on production computers, where malware could have a catastrophic effect if introduced into the environment.

Due Care, Due Diligence, and Due Process

Due care, due diligence, and due process are terms that apply to the implementation and enforcement of organization-wide security policies. An organization practices due care by taking responsibility for all activities that take place in corporate facilities. An organization practices due diligence by implementing and maintaining these security procedures consistently to protect the organization’s facilities, assets, and workers. Although many organizations outline plans for security policies and standards, they often never officially implement them or don’t properly share the information with workers. Without direction from management in the form of training, guidelines, and manuals, and without workers input and feedback, security policies will not be successful.

By practicing due care, the organization shows it has taken the necessary steps to protect itself and its workers. By practicing due diligence, the organization ensures that these security policies are properly maintained, communicated, and implemented. If the organization doesn’t follow proper due care and due diligence initiatives, it might be considered legally negligent if organization security and customer data are compromised.

Due process guarantees that in the event of a security issue by a worker, the worker receives an impartial and fair inquiry into the incident to ensure the worker’s employment rights are not being violated. If during an investigation or inquiry, the worker’s rights are violated, the organization may face legal ramifications via lawsuits or governmental employment tribunals.

Privacy

Privacy policies are agreements that protect individually identifiable information. An organization engaged in online activities or e-commerce has a responsibility to adopt and implement a policy to protect the privacy of personally identifiable information (PII). Increasingly, regulations such as the European Union’s General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and the U.S. Health Insurance Portability and Accountability Act (HIPAA) require a privacy policy that is acknowledged before use. Organizations should also take steps to ensure online privacy when interacting with other organizations, such as business partners. Privacy obligations also extend to an organization’s use of the PII of its workers.

The following recommendations pertain to implementing privacy policies:

•   An organization’s privacy policy must be easy to find, read, and understand, and it must be available prior to or at the time the PII is collected or requested.

•   The policy needs to state clearly what information is being collected; the purpose for which that information is being collected; possible third-party distribution of that information; the choices available to an individual regarding the collection, use, and distribution of the collected information; a statement of the organization’s commitment to data security; and what steps the organization takes to ensure data quality and access.

•   The policy should disclose the consequences, if any, of a person’s refusal to provide information or the refusal to permit its processing.

•   The policy should include a clear statement of what accountability mechanism the organization uses, such as procedures for dealing with privacy breaches, including how to contact the organization and register complaints.

•   Individuals must be given the opportunity to exercise choice regarding how PII collected from them online can be used when such use is unrelated to the purpose for which the information was collected. At a minimum, individuals should be given the opportunity to opt out of such use.

•   When an individual’s information collected online is to be shared with a third party, especially when such distribution is unrelated to the purpose for which the information was initially collected, the individual should be given the opportunity to opt out.

•   Organizations creating, maintaining, using, or disseminating PII should take appropriate measures to ensure its reliability and should take reasonable precautions to protect the information from loss, misuse, or alteration.

Each organization must evaluate its use of the Internet and its internal systems to determine the type of privacy policy it needs in order to protect all involved parties. The privacy policy will protect the organization from legal issues, raising employees, customers, and constituents’ comfort levels regarding the protection of their information. A privacy policy should include the following elements:

•   Information collection Collect, use, and exchange only data pertinent to the exact purpose, in an open and ethical manner. The information collected for one purpose shouldn’t be used for another. Notify persons of information you have about them, its proposed use and handling, as well as the enforcement policies.

•   Direct marketing The organization can use only non-PII for marketing purposes and must certify that the persons’ personal information won’t be resold to third-party organizations.

•   Information accuracy Ensure the data is accurate, timely, and complete and has been collected in a legal and fair manner. Allow people the right to access, verify, and change their information in a timely, straightforward manner. Inform people of the data sources and allow them the option of removing their names from the marketing lists.

•   Information security Apply security measures to safeguard the data on databases. Establish worker training programs and policies on the proper handling of PII. Limit the access to a need-to-know basis on personal information and divide the information so that no one worker or unit has the whole picture. Follow all government regulations concerning data handling and privacy.

EXAM TIP   Privacy policies must be easy to find, and they must provide information on how to opt out of any use of personally identifiable information.

Human Resources

An organization’s HR department is an important link regarding the organization and worker security. The HR department is responsible for hiring employees, tracking contractors, consultants, and other temporary workers, ensuring workers conform to company codes and policies during their term of work, and maintaining organization security in case of a worker termination. The following sections outline the responsibility of human resources during the three phases of the employment cycle: hiring, maintenance, and termination.

Hiring

When hiring employees for a position within the organization, the HR department is responsible for the initial employee screening. This usually takes place during the first interview: an HR representative meets with the potential employee to discuss the organization and to get a first impression, gauging whether this person would fit into the organization’s environment. This interview generally is personality based and nontechnical. Further interviews are usually more oriented toward the applicant’s skill set and are conducted by the department advertising the position. Both types of interviews are important because the applicant could possess excellent technical skills for the position, but their personality and communications skills might not be conducive to integration with the work environment.

During the interview process, HR also conducts background checks of the applicant and examines and verifies their educational and employment history. Reference checks are also performed, where HR can obtain information on the applicant from a third party to help confirm facts about the person’s past. HR will also verify professional licenses and certifications. Depending on the type of organization, such as the government or the military, the applicant might have to go through security clearance checks or even a credit check, medical examination, and drug testing.

To protect the confidentiality of organization information, the applicant is usually required to sign a non-disclosure agreement (NDA), which legally prevents the applicant from disclosing sensitive organization data to other organizations, even after termination of employment. These agreements are particularly important with high-turnover positions, such as contract or temporary employment.

When an employee is hired, the organization also inherits that person’s personality quirks or traits. A solid hiring process can prevent future problems with new employees.

Tracking Temps, Contractors, and Consultants

Many organizations have more than just employees in their workforce. Most will have a few contractors, consultants, and temps—and some will have a lot! In organizations where these “non-employee” workers have managed identities to regulate their access to computers and workspaces, it’s necessary for organizations to carefully track them with the same precision as regular employees.

Who better to do this than HR? For legal reasons, many organizations’ HR departments are reluctant to also track the non-employee workforce, but information security requirements demand centralized, competent tracking just the same.

Today’s human resource information systems (HRISs) have the ability to segregate employees from other types of workers. This helps HR departments manage employees and non-employee workers separately, as often they must.

Codes of Conduct and Ethics

The HR department is also responsible for outlining an organization’s policy regarding codes of conduct and ethics, which are general lists of what the organization expects from its workers in terms of everyday conduct—dealing with fellow workers, managers, and subordinates, including people from outside the organization such as customers and clients.

These codes of conduct could include restrictions and policies concerning drug and alcohol use, theft and vandalism, sexual harassment, and violence in the workplace. If a worker violates any of these policies, they could be disciplined, suspended, or even terminated, depending on the severity of the infraction.

Termination

The dismissal of workers can be a stressful and chaotic time, especially because terminations can happen quickly and without notice. A worker can be terminated for a variety of reasons, such as performance issues, personal and attitude problems, or legal issues such as sabotage, espionage, or theft. Alternatively, the worker could be leaving to work for another organization. The HR department needs to have a specific set of procedures ready to follow in case a worker resigns or is terminated. Without a step-by-step method of termination, some procedures might be ignored or overlooked during the process and thus compromise the organization’s security.

A termination policy should exist for each type of situation where a worker is leaving the organization. For example, you might follow slightly different procedures for terminating a worker who’s leaving to take a job in an unrelated industry than a worker who’s going to work for a direct competitor. In the latter case, the worker might be considered a security risk if they remain on the premises for their two-week notice period, where they could transmit organization secrets to the competition.

Similarly, terminating a contractor or consultant will involve different policies and procedures since their employment relationship is with another organization. Finally, organizations with one or more labor unions must navigate those waters according to collective bargaining agreements and rules.

A termination policy should include the following procedures for the immediate termination of a worker:

•   Securing work area When the termination time has been set, the worker in question should be escorted from their workstation area to the HR department. This prevents them from using their computer or other organization resource once notice of termination is given. Their computer should be turned off and disconnected from the network. When the worker returns to their desk to collect personal items, someone should be with them to ensure that they do not take private organization information. Finally, the worker should be escorted out of the building.

•   Return of identification As part of the termination procedure, the worker’s identification should be returned. This includes identity badges, pass cards, keys for doors, and any other security device used for access to organization facilities. This prevents the person from accessing the building after being escorted from the premises.

•   Return of equipment All organization-owned equipment must be returned immediately, such as desktops, laptops, cell phones, tablets, organizers, or any other type of electronic equipment that could contain confidential information.

•   Suspension of accounts An important part of the termination procedure is the notification to the network administrators of the situation. They should be notified shortly before the termination takes place to give them time to disable any network accounts and phone access for that worker. The network password of the account should be changed, and any other network access the worker might have, such as remote access, should be disabled. The worker’s file server data and e-mail should be preserved and archived to protect any work or communications the organization might need for operational or legal reasons.

EXAM TIP   All user access, including physical and network access controls, needs to be disabled for a worker once they have been terminated. This prevents the worker from accessing the facility or network.

Chapter Review

The enterprise architecture within an organization affects the risk of the business in several different ways. Aspects of enterprise architecture risk include interoperability, supportability, security, maintenance, and how the different pieces and parts of the infrastructure fit into the systems development life cycle.

Key areas in IT operations management include server and infrastructure management, end-user support, help desk, and problem escalation management, and, of course, cybersecurity.

Organizations use project, program, and portfolio management to oversee and sustain both short- and long-term aspects of systems and processes.

At the core of a project are three primary drivers. These are scope (amount or range of work), schedule (when work is to be done and its completion date), and cost (including all the resources expended toward the completion of the project).

Business continuity is concerned with the careful planning and deployment of resources involved in keeping the mission of the business going (that is, keeping the business functioning regardless of negative events). Disaster recovery is primarily concerned with the quick reaction involved with preserving lives, equipment, and data immediately following a serious negative event.

Resilience refers to the ability of the business to survive negative events and continue with its mission and function.

Data lifecycle management is a lifecycle process concerned with the creation, protection, use, retention, and disposal of business information.

The systems development life cycle, or SDLC, is essentially the entire life of a system or product, from concept to development, from implementation to disposal. Security should be a part of every step in the SDLC, thus ensuring security by design.

New or emerging technologies can present risks to organizations simply because there are several different important considerations when integrating the latest technologies into an existing environment.

Access controls ensure that only authorized personnel can read, write to, modify, add to, or delete data. They also ensure that only the same authorized personnel can access the different information systems and equipment used to store, process, transmit, and receive sensitive data.

The three goals of security, known as the CIA triad, are confidentiality, integrity, and availability. Supporting these three goals are other elements of security, such as access control, data sensitivity and classification, identification, authentication, authorization, accountability, and, finally, non-repudiation.

Standards, frameworks, and practices relevant to risk management include NIST RMF, COBIT 2019, and the various ISO standards.

Data classification policy defines data sensitivity levels, as well as handling and disposal procedures to ensure adequate protection of sensitive information.

Industry frameworks, standards, and practices can be adopted when building an information security program, as opposed to building these elements from scratch.

The NIST Risk Management Framework (RMF) is a seven-step methodology that provides for risk management all the way through the information systems life cycle.

COBIT is a management framework developed by ISACA and facilitates the governance of enterprise information and technology. COBIT consists of two layers, governance and management, which further break down into a total of 40 separate objectives.

The Risk IT Framework comes from traditional risk management principles of various enterprise risk management (ERM) standards and describes activities and processes thought of as best practices.

Information security awareness training ensures an organization’s workforce is aware of policy, behavior expectations, and safe computer and Internet usage.

Security policies and procedures are official organization communications that are created to support those critical principles of data privacy and data protection.

Effective physical access controls ensure that only authorized personnel are permitted to access work centers, processing centers, and other work areas. This contributes to an environment with better information security as well as workplace safety.

An organization practices due care by taking responsibility for all activities that take place in corporate facilities.

An organization practices due diligence by implementing and maintaining these security procedures consistently to protect the organization’s facilities, assets, and workers.

Due process guarantees that in the event of a security issue by a worker, the worker receives an impartial and fair inquiry into the incident to ensure the worker’s employment rights are not being violated.

Each organization must evaluate its use of the Internet and its internal systems to determine the type of privacy policy it needs in order to protect all involved parties.

An organization’s HR department is an important link regarding organization and worker security. The HR department is responsible for hiring employees, tracking contractors, consultants, and other temporary workers, ensuring workers conform to company codes and policies during their term of work, and maintaining organization security in case of worker termination.

Quick Review

•   Two common enterprise architecture frameworks are The Open Group Architecture Framework (TOGAF) and the Zachman framework.

•   Business continuity and disaster recovery are primarily concerned with the goal of business resilience.

•   Two of the key processes involved in business continuity planning are conducting a business impact assessment (BIA) and determining a recovery strategy.

•   Two key areas of concern in business continuity are the recovery point objective (RPO) and the recovery time objective (RTO).

•   Resilience is the ability of an organization to resist the effects of negative events and its ability to bounce back after one of these events.

•   Data classification refers to policies that define the proper use, handling, and protection of data at various sensitivity levels.

•   The term systems development life cycle represents an evolution of the original term software development life cycle, reflecting an earlier age when most organizations wrote their own custom business applications.

•   Some of the risks associated with emerging technology involve staff unfamiliarity, resulting in improper implementation or use.

•   Access controls directly support the confidentiality and integrity goals of security and indirectly support the goal of availability.

•   Identification refers to the act of an individual or entity presenting valid credentials to a system. Authentication involves the verification of one’s identity with a centralized database. Authorization refers to the access rights or privileges assigned to a user account. Non-repudiation is a record-keeping property of a system whereby a user will not be able to deny having performed some action.

•   A framework is a generally overarching methodology for a set of activities or processes.

•   A standard is a mandatory set of procedures or processes used by the organization and usually fits into an overall framework.

•   A practice is a normalized process that has been tried and proven as generally accepted within a larger community.

•   Periodic security awareness training can be used to reinforce and refresh stale knowledge and bring workers up to date on the latest tools, techniques, and risk considerations.

•   The least privilege principle grants users only the access rights they need to perform their job functions.

•   Separation of duties ensures that one single individual isn’t tasked with high-security and high-risk responsibilities.

•   Job rotation provides improved security because no worker retains the same amount of access control for a position indefinitely.

•   Mandatory vacations enable security and audit staff to examine absent workers’ procedures and records to identify signs of misbehavior or fraud.

•   An acceptable use policy (AUP) is a policy consisting of a set of established guidelines for the appropriate use of computer networks within an organization.

•   Social media policy governs acceptable use regarding the sharing of organization information and representation of the organization.

•   The use of personal e-mail is a potential distraction as well as a risk for information leakage and the introduction of malware into an environment.

•   Privacy policies are agreements that protect individually identifiable information.

•   Human resources should track not only employees but temporary workers, contractors, and consultants to ensure the integrity of access controls.

Questions

1.   You are managing a project that involves the installation of a new set of systems for the accounting division of your organization. You have just been told that there have been budget cuts and the project will not be able to purchase additional equipment needed for the installation. You now have to find other areas to cut in order to fund the extra equipment. Which element of project management is most affected by this threat?

A.   Schedule

B.   Scope

C.   Cost

D.   Quality

2.   As a risk practitioner in a larger organization, you have been asked to review the company’s SDLC model for potential risk areas. The model includes the Requirements, Design, Development, Implementation, and Disposal phases. Software and systems are moved from the development environment immediately into the production environment and implemented. Which SDLC phase would you recommend that the business add to reduce risk of integration or functionality issues as the system is implemented?

A.   Initiation

B.   Test

C.   Sustainment

D.   Maintenance

3.   Lack of a well-written work breakdown structure document can contribute to a vulnerability that affects which aspect of project management?

A.   Cost

B.   Schedule

C.   Scope

D.   Quality

4.   Which of the following is the major risk factor associated with integrating new or emerging technologies into an existing IT infrastructure?

A.   Security mechanisms

B.   Data format

C.   Vendor supportability

D.   Interoperability

5.   Which of the following is a short-term process primarily concerned with protecting personnel, facilities, and equipment immediately following a disaster or major incident?

A.   Disaster recovery

B.   Business continuity

C.   Business impact analysis

D.   Recovery point objective

6.   Which of the following would be a vulnerability that stems from the business not identifying its critical assets and processes during the continuity management process?

A.   Failure to adequately consider system requirements during the SDLC

B.   Failure to perform a business impact analysis

C.   Failure to consider interoperability with integrating new technologies

D.   Failure to maintain redundant systems or data backups

7.   Your business just went through a major storm, which has flooded your data center. Members of your recovery team are attempting to salvage equipment as well as locate critical data backups. No one seems to know exactly what they’re supposed to do, and they don’t have the right equipment available to them. Additionally, there is no coordinated effort within the team to perform specific tasks. Which of the following vulnerabilities most likely led up to this scenario?

A.   Failure to back up sensitive data

B.   Failure to acquire an alternate processing site

C.   Lack of a business impact analysis

D.   Failure to test the disaster recovery plan

8.   After a few incidents where customer data was transmitted to a third party, your organization is required to create and adhere to a policy that describes the distribution, protection, and confidentiality of customer data. Which of the following policies do you create?

A.   Privacy

B.   Due care

C.   Acceptable use

D.   Service level agreement

9.   You need to create an overall policy for your organization that describes how your users can properly make use of company communications services, such as web browsing, e-mail, and File Transfer Protocol (FTP) services. Which of the following policies do you implement?

A.   Acceptable use policy

B.   Due care

C.   Privacy policy

D.   Service level agreement

10.   Which of the following security goals is concerned with ensuring that data has not been modified or altered during transmission?

A.   Confidentiality

B.   Availability

C.   Integrity

D.   Non-repudiation

11.   Which of the following is most concerned with ensuring that users cannot deny that they took an action?

A.   Accountability

B.   Non-repudiation

C.   Auditing

D.   Authorization

12.   Which of the following describes a set of mandatory procedures or processes used by an organization?

A.   Standard

B.   Framework

C.   Practice

D.   Policy

13.   Which of the following frameworks might be used in business governance and IT enterprise management?

A.   NIST RMF

B.   COBIT 2019

C.   The Risk IT Framework

D.   ISO 27001

14.   You are implementing an organization-wide risk management strategy, and you are using the NIST Risk Management Framework (RMF). You have just completed step 1 of the RMF, “Categorize information systems.” Which of the following steps should you complete next in the RMF sequence?

A.   Authorize system.

B.   Assess security controls.

C.   Continuous monitoring.

D.   Select security controls.

15.   Which of the following statements most accurately reflects the effect of information technology (IT) on risk to the business enterprise? (Choose two.)

A.   Information technology is a serious risk to the mission of the organization.

B.   Information technology is used to protect the organization’s information.

C.   Information technology is used to eliminate risk to the mission of the organization.

D.   Information technology is used to generate the organization’s information.

Answers

1. C.   Cost is the element of project management that is most affected by the threat of not enough funding.

2. B.   A test phase introduced into this model would reduce risk by ensuring that a system or software application meets performance and functionality standards before it is introduced into the production environment, potentially eliminating costly issues before they occur.

3. C.   Lack of a well-written work breakdown structure document can contribute to a vulnerability that affects a project’s scope.

4. D.   Interoperability is the major risk factor associated with integrating new or emerging technologies into an existing IT infrastructure. It covers a wide range of factors, which typically include backward compatibility, data format, security mechanisms, and other aspects of system integration.

5. A.   Disaster recovery is a short-term process primarily concerned with protecting personnel, facilities, and equipment immediately following a disaster or major incident.

6. B.   Failure to perform a business impact analysis could cause a vulnerability in that the organization would not be able to adequately identify its critical business processes and assets.

7. D.   Failure to test the disaster recovery plan on a periodic basis—as well as make sure people are trained and have the right equipment—can result in poor or ineffective recovery efforts.

8. A.   A privacy policy concerns the protection and distribution of private customer data. Any company, especially one engaged in online activities or e-commerce, has a responsibility to adopt and implement a policy for protecting the privacy of individually identifiable information.

9. A.   An acceptable use policy establishes rules for the appropriate use of computer networks within your organization. The policy describes the terms, conditions, and rules of using the Internet and its various services within the company’s networks.

10. C.   Integrity is concerned with ensuring that data has not been modified or altered during transmission or storage.

11. B.   Non-repudiation is concerned with ensuring that users cannot deny that they took a particular action.

12. A.   A standard is a set of mandatory procedures or processes used by an organization.

13. B.   COBIT is used in business governance and IT enterprise management.

14. D.   Step 2 of the RMF is “Select security controls” and is accomplished after information systems have been categorized.

15. B, D.   Information technology is used to generate the business’s information as well as protect it.

APPENDIX A

Implementing and Managing a Risk Management Program

This appendix takes a more pragmatic view of building and managing a risk management program. Rather than the somewhat academic view in the CRISC job practice, we draw directly from our experience building several risk management programs in our careers.

We have built or improved numerous risk management processes and programs between the three of us. The process and technique are not overly complicated. The most challenging part of building a risk management process is figuring out how to engage with executives in the organization—so that they understand what the process is all about and participate meaningfully. After all, it’s their business, and we just want to make sure they make informed decisions related to various types of risks.

Today’s Risk Landscape

It’s a crazy world for an IT or cyber risk leader. While we find the profession both challenging and rewarding, increasing pressures on all sides are making the job more difficult (see Figure A-1). Some of the factors at play include the following:

Figure A-1 Pressure comes from all sides on security and risk programs today.

•   Innovation and chutzpah of cybercrime Cybercriminal organizations are thriving. Ransomware, extortion, social engineering, and DDoS are highly successful, drawing even more into this dark industry. Intruders develop new attack methods in shorter periods of time, indicating the presence of increases in research and development.

•   Upward pressure on regulations The success of cybercriminals is putting pressure on governments to pass laws requiring organizations (and governments) to do more to protect sensitive information. Industry sector regulations like GLBA and HIPAA, along with emerging privacy regulations like GDPR and CCPA, are building layers of regulation on already strained businesses.

•   Downward pressure on spend Despite the two factors mentioned, management is trying to keep a lid on rising costs and hold the line on spending increases while expecting security organizations to better defend them from attack. A related problem is the limited talent pool of qualified security and risk professionals to guide organizations out of the mess they’re in.

•   Increasing complexity of digital transformation Organizations’ IT environments have never been more complex. Despite pressure to standardize on tools and technologies, the move to cloud services and cloud infrastructure means IT organizations have more kinds of technologies, more types of services, and more kinds of operations to manage.

•   Introduction of IoT devices Increasingly, IT departments have to deal with more than just servers, desktops, laptops, printers, and mobile devices on their networks. Many other devices are plugged into internal networks, including “smart” devices, appliances, and voice-activated assistants. The so-called “attack surface” expands faster than a security team can ever hope to monitor and protect it.

•   BYOD Increasingly, organizations’ workers use personally owned devices, mainly smartphones, to access and manage business information and systems. Such organizations have effectively ceded control of their information and information systems if these devices are not actively managed.

•   Telework The COVID-19 pandemic thrust new working conditions on virtually every enterprise in the world, many of which were unprepared to deal with this and related changes. Organizations that were already stretched and accepting too much risk had still more risk to take on.

•   Cloud-based services Cloud-based services decrease the effort and friction of acquiring new information systems. Sometimes, however, this goes too far, resulting in individuals and workgroups that unilaterally decide to employ cloud-based services, escaping the scrutiny of legal and cybersecurity professionals. Corporate information has escaped the control of IT and risk owners in many cases.

•   Increasing variety of security tooling Many thousands of security software companies compete in the marketplace with their tools. Security leaders are increasingly distracted by these vendors and their promises of stopping whatever the latest attack techniques happen to be at the moment.

•   Difficulty in finding qualified security professionals Most organizations struggle to find enough qualified security professionals to fill their teams. Organizations take months, half a year, or more to find new hires. We won’t argue or debate the finer points on this matter, except to say that companies have a hard time finding the people they want to hire on their security teams.

These factors weigh heavily on security organizations, resulting in sub-par security architecture, planning, monitoring, and response, with too few personnel working on important issues.

Allegory of the Battlefield

Consider the following photograph that shows Major General Alexander M. Weyand poring over a battlefield map in Korea:

(Image courtesy U.S. National Archive)

Imagine, if you will, that General Weyand is taking in information from scouts on the enemy’s position and discussing where and when to deploy troops to counter the enemy’s moves and even gain territory. This is all about the allocation of scarce resources to provide the maximum margin of victory.

The soldiers on the front line depend on this strategizing—their very lives depend on it. Political leaders depend on this strategizing as well so that their armies will meet their objectives of countering the enemy’s objectives.

Imagine, for a moment, that an army lacked this planning and decision-making function. Without it, lower-level officers would be commanding their regiments to go this way and that, based on what they could see within their limited purview. Lacking big-picture information and purpose, they may succeed or fail, but they won’t be operating with a clear, central purpose.

Risk management is the modern equivalent of those field commanders. In risk management, security specialists are examining threat intel, considering available internal capabilities, and making decisions on which of many issues are the most important to discuss and take action on. Formal risk management is the modern equivalent of field commanders studying the enemy’s plans, available resources, and most effectively applying their resources to meet their objectives.

Most organizations do not do this, at least not in any repeatable way. Instead, when decisions are made, they usually lack any analysis or triage to determine the best way forward on any given issue. The result: high-risk matters get little attention, while other issues get more than their fair share. Scarce resources are applied to the wrong issues, while the highest risk issues go poorly resolved or entirely unaddressed.

What Is a Risk Management Program?

To fully describe a risk management program, first we’ll step back and describe what a program is. In business today, a program is a set of defined roles and responsibilities as well as processes or procedures that are carried out indefinitely.

A risk management program is simply a process or set of processes through which

•   Risks are discovered.

•   Risks are cataloged.

•   Risks are analyzed.

•   Business decisions about what to do about risks are made.

Also, follow-up is performed to ensure these business decisions are carried out on time and as agreed upon.

The primary artifacts found in a typical risk management program include the following:

•   Program charter This document defines the purpose and scope of the risk management program, roles and responsibilities, and describes its processes and records.

•   Process or procedures This document describes the steps in various risk management processes and procedures, who carries them out, and what records are maintained.

•   Risk register This is the central repository of risks that have been identified. The risk register is one of the historical records of a risk management program.

•   Risk analyses Individual risks are often studied in greater detail, with additional risk analysis to help decision-makers decide what to do about these risks.

•   Minutes This is a business record of decisions and other actions taken.

So far, this may sound formal. Risk management should be consistent and methodical so that its proceedings are managed and recorded.

The Purpose of a Risk Management Program

Many kinds of threats and risks demand the attention of cybersecurity leaders. Even the best-equipped organizations have insufficient resources to deal effectively with every identified risk. A risk management program facilitates informed decision-making that helps to prioritize resources to deal with identified risks.

When properly designed and implemented, a risk management program serves as a triage apparatus to help identify and distinguish more significant risks from lesser risks. Instead of going into the detail of determining the actual probability and financial impact of threats, risk management’s triage sorts out risks to help management understand which risks are more critical to deal with sooner and which can be dealt with later.

A common mistake made in risk management programs is the time spent in detailed analysis to determine accurate probabilities of threat events and actual costs of threat events. While, at times, it may be helpful to determine estimates of probability and impact, this is not the sole purpose of risk management. Instead, the triage function of risk management identifies those risks needing prompt attention versus those whose attention can wait.

In this respect, a qualitative analysis method can be far more useful than a quantitative one. If risks are considered still “very high,” it really doesn’t matter if it’s 85.2 percent versus 95.7 percent; it’s still coming, and it’s still bad.

When properly designed and implemented, risk management identifies the most critical risks and facilitates business-level decision-making by business leaders to deal with those risks.

Not Only IT Risk Management

Many in the business think of risk management as consisting primarily of cyber risk and increasingly of privacy risk. The scope of risk in the CRISC certification consists of all IT risk, which goes beyond cyber to include various aspects of operational risk, such as the capacity and availability of IT systems to continue running properly.

The methodology of risk management, however, transcends IT altogether. Other risk domains include workforce risk, economic risk, market/competitive risk, currency exchange risk, geopolitical risk, natural hazards risk, fraud risk, and more. The techniques used in risk management are agnostic to the context of risk.

Risk management is risk management, regardless of the focus or the context. It’s only necessary for a risk management program to have someone skilled in the techniques of risk management and someone skilled in the subject matter of the risk management program. The program can succeed, whether both of these are a single person or two people.

The Risk Management Life Cycle

Like many business activities, risk management is a life-cycle process. Risks are identified in many ways, and specific activities are performed for each of those risks. The entire life cycle is described in detail in this section.

Risk Discovery

In Chapter 2, we made a list of the ways in which new IT risks can be discovered, with complete explanations for each. We’ll provide just the summary here:

•   Audits

•   Penetration tests

•   Security advisories

•   Whistleblowers

•   Threat modeling

•   Risk assessments

•   Security and privacy incidents

•   Operational incidents

•   News and social media articles

•   Professional networking

•   Passive observation

•   Risk-aware culture

This list should not be construed as complete. Instead, it should help you understand that there are many ways in which a risk manager will discover new risks. Put another way, it would be dangerous to limit the identification of new risks to a fixed set of inputs, as this could artificially eliminate a source that is critical for some. Risk discovery is sometimes methodical and sometimes spontaneous. The spontaneity of risk discovery compels us to advise you to consider all possible likely and unlikely sources of risk. We can no more tell you the types of risk sources to include than we can tell you which of those sources will be related to your next risk event.

The Risk Register

The risk register (sometimes known as a risk ledger) is the centerpiece of business records in a risk management program. Each entry in the risk register represents a different IT risk that has been identified at some point in time, as recently as earlier today or as distant as a year or two in the past.

Since this appendix focuses on establishing a risk management program, we recommend implementing an initial risk register using a spreadsheet program such as Microsoft Excel or Google Sheets. It’s our style to build a program or a process using largely manual procedures and then introduce automation later.

A risk register starts quite simply, with columns like these:

•   Risk name

•   Risk description in terms of the risk context

•   Threat description

•   Vulnerability description

As you accumulate records in the risk register, you’ll find it helpful to add more columns. These columns indicate when the entry was recorded, its context, and a business-centric explanation:

•   Entry date

•   Entered by

•   Risk description in business terms

•   Risk context

While the description of risk in business terms appears to be just another bullet item, it is perhaps the most important field in the risk register. Without it, risk managers will have a more difficult time describing the risk in business terms to executives who may be asked to decide on the disposition of the risk. Including this column in the risk register compels the risk manager to begin thinking about the risk in business terms early, giving them time to ponder and develop the risk story.

Rating risks for severity is a topic all its own, discussed in more detail in the following subsections.

You will need to add more columns as you move through the life cycle and make risk treatment decisions. These columns describe basic risk treatment parameters:

•   Risk status

•   Risk treatment selection

•   Risk treatment description

•   Risk treatment owner

•   Risk treatment commit date

As risk treatment activities reach their conclusions, you’ll need additional columns:

•   Risk treatment completion date

•   Risk closure date

Over time, you’ll be spending considerable time in the risk register. You’ll want to view risks in various contexts and categories at times. Some columns that help classify risks include the following:

•   Location.

•   Business unit.

•   Technology type. This may consist of one or more columns that enable you to view risks in discrete categories. For instance, you may wish to view all risks related to mobile devices, endpoints, specific types of servers, database management systems, network devices, or other components.

Rating Risks—Qualitative

Not all risks are created equal. Some may be nearly trivial, while others represent an existential threat to the organization. A risk register must contain some columns used to describe the level of risk for each entry.

The two basic qualitative measures of risk are probability and impact, as detailed next:

•   Probability This specifies the likelihood of an actual occurrence of the risk. In qualitative terms, probability is typically expressed as High, Medium, or Low or in basic numeric terms such as 1 (Low) to 3 (High), 1 to 5, or 1 to 10.

•   Impact This specifies the impact on the organization due to an actual occurrence of the risk. Like probability, impact in qualitative risk ratings is expressed as High, Medium, or Low or on a numeric scale such as 1–3, 1–5, or 1–10.

Note that, in qualitative risk rating, no attempt at an actual probability or impact is being made. Instead, the purpose of qualitative risk ratings is one of triage—these ratings help the risk manager distinguish entries with higher risks from entries with lower risks.

Qualitative Terms Help with Ratings

Rating the probability and impact of risks on numeric scales of 1–3 or 1–5 can, at times, be too abstract. For this reason, we recommend a list of terms be associated with these levels for both probability and impact. Using these terms as a guide can help the risk manager perform more consistent risk ratings for risk register entries.

For event probability on a scale of 1–5, these terms can be used:

•   5 = Certain

•   4 = Likely

•   3 = Possible

•   2 = Unlikely

•   1 = Rare

Similarly, these terms can be used for impact:

•   5 = Global

•   4 = Country

•   3 = Department

•   2 = Team

•   1 = Individual

These impact terms describe the scope of impact for a risk event. The highest-rated events would affect the entire organization, while the lowest-rated events would affect only a single worker.

Two additional qualitative measures can be introduced that help the risk manager better understand the overall risk for each entry:

•   Asset value This qualitative term expresses the value of the asset(s) involved in a specific risk. Like other qualitative terms, asset value is expressed as High, Medium, or Low or on a numeric scale. Generally, this represents an asset that would have to be recovered or replaced should a relevant threat occur.

•   Operational criticality This term expresses the operational importance of an asset or function. An asset that the organization depends on for high-value operations (even if the value of the asset itself is low) would be assigned a higher value.

While these two measures are not seen as often in qualitative risk analysis, they help distinguish risks in that all-important triage used to identify the most critical risks.

Calculating Overall Risk The four qualitative risks explained here can help the risk manager sort out various risks in the risk register. One final column can help tie them all together that would simply be called “Risk.” This column can easily be calculated by multiplying the ratings of the four risk columns together. For example, a risk item in the risk register is rated as follows:

•   Probability = 4

•   Impact = 2

•   Asset value = 2

•   Operational criticality = 1

The risk value in this example is 4 × 2 × 2 × 1 = 16.

Using Qualitative Risk Ratings In qualitative risk analysis, the individual risk columns, as well as the column representing overall risk, exist to help the risk manager better understand how various risks compare to one another. No attempt is made to calculate the actual probability of occurrence or the costs incurred if a risk event occurs. Instead, qualitative risk ratings help the risk manager understand which risks warrant more focus and attention.

Other columns in the risk register provide opportunities for focus, including those columns specifying the type of asset or system, the business unit, the geographic location, and more. The ability to focus on a portion of the risk register associated with a specific part of the organization, a particular location, or other distinguishing characterization helps the risk manager focus on the risks that matter more versus the ones that matter less.

In a sample risk management scenario, a risk manager is preparing to have a conversation with the part of IT that manages end-user endpoints—primarily laptop and desktop computers—in a particular region of the world. To prepare, the risk manager can filter the risk register to view just the risks associated with end-user endpoints as well as risks in particular global regions. The resulting risk will contain just those items, which the risk manager can then examine more deeply to distinguish the items of greater concern from those of lesser concern. Now, the risk manager can have a more meaningful conversation with the IT leaders about risks directly associated with their work.

NOTE   The purpose of qualitative risk analysis is triage—to distinguish risks from one another and to more easily identify larger risks.

Rating Risks—Quantitative

Sometimes, a risk manager is asked to go beyond qualitative risk rating and provide actual probabilities and financial impacts of risks. “How much will it cost us if customer data is stolen?” is a reasonable question that an executive may pose to a risk manager. Arguably, the risk manager should attempt to arrive at an estimate to help the executive better understand the consequences of a security breach.

In our practice, we do not attempt to uplift every item in the risk register from qualitative to quantitative terms. Doing so would take a considerable amount of time and not result in much additional insight. Instead, we embark on quantitative risk analysis when examining individual risks. We discuss this further in the section “Performing Deeper Analysis.”

The Risk Register Is a Living Document

The risk register is a living document, and even when risks are reduced, this is recorded and reflected in the document; they are not simply deleted. This provides a history of risk management within the organization. The contents of the risk register should be managed accordingly.

Types of Risk Registers

Many kinds of risks are present everywhere in an organization, and it makes little sense to put them all together in one risk register. Imagine if there was a risk entry associated with currency exchange risk, and adjacent to it is another entry that expresses the misconfiguration of a server. Both are useful, even valuable, but they are vastly different in their context and importance. Further, particularly in larger organizations, other individuals will manage these risks and discuss them with different executives.

Layers of Risk Registers

Different levels of risk are typically maintained in separate risk registers. Most often, these basic three risk registers will exist:

•   Entity-level risk These are the overall “big picture” risks that affect an entire organization. The types of subject matter in an entity-level risk register generally include the following:

•   Workforce-related risks

•   Currency exchange risks in organizations operating in multiple countries, or with suppliers in other countries

•   Economic risks having to do with macroeconomic business cycles

•   Risks that exist as an aspect of organizational culture

•   Program-level risk These are risks most often associated with business processes throughout the organization. Examples of the types of risks found at this level include the following:

•   Effectiveness of vulnerability management If, for instance, the IT department is lackadaisical in its security patching, an entry may be created in the risk register that describes this systemic problem.

•   Identity management An organization may have little discipline in its access request, fulfillment, and termination procedures.

•   BYOD An organization may not have controls to prevent employees’ use of personally owned devices for managing critical data, leading to a significant data leakage risk.

•   Asset-level risk These risks are associated with individual assets and groups of assets. Often, these risks are identified with scanning tools and other tooling. Examples of risks at this level include the following:

•   Misconfiguration of critical devices

•   Missing critical patches

•   Newly discovered unmanaged devices

Communicating Between the Layers

A single risk manager may be involved in two or all three of these risk registers in smaller organizations. More often, however, different persons manage each risk register separately. One might think that these risk registers would be isolated from each other. While this may be true, organizations are wise to be cognizant of opportunities for communication between those who manage various risk registers.

Classic examples of the crossover between risk registers include the following:

•   Chronic occurrence of an IT department exceeding patching SLAs may compel a risk manager to create a program-level risk item describing a risk with the operational process of patching.

•   Chronic occurrence of a product engineering group avoiding engagement with security and privacy teams may compel a risk manager to create an entity-level risk describing a culture that lacks the essential cultural ingredient of “security and privacy by design.”

The most frequent communication between risk register layers is a chronic or repeated failure of processes at lower layers that suggests a systemic problem at a higher layer.

NOTE   Our frequent use of the term risk manager signifies a role rather than a job title. The job title of risk manager is generally seen only in larger organizations, whereas those with other job titles fulfill the role.

Reviewing the Risk Register

Risk managers should have intimate familiarity with the contents of their risk register(s). This requires a risk manager to frequently examine the contents of the risk register, using various filtering (“slicing and dicing”) techniques to view subsets of the entire risk register. This attention could approach what we would call “preening,” where a risk manager examines and periodically adjusts contents in the risk register.

Most often, a risk manager will occasionally adjust an aspect of risk rating of a risk register item. As the risk manager becomes intimately familiar with the risk register, sometimes the risk manager will realize that a particular risk entry’s risk rating should be adjusted a bit up or down, making risk ratings more credible and reasonable.

NOTE   A risk program aspiring to higher maturity should require recording rating changes and other changes to the risk register, or perhaps use a change control process requiring two or more persons to understand and agree to changes to the risk register.

In an example described earlier in this appendix, a risk manager is preparing for a conversation with a particular leader in an organization by examining risk register items relevant to that leader’s mission. This is a helpful example, but a risk manager should not wait for a conversation to focus on those relevant risks. Instead, the risk manager should routinely examine smaller sets of risks in logical groupings such as location, type of asset, and business unit to become even more familiar with the risk landscape in different parts of the organization.

Formal Risk Register Reviews

While the risk manager may be spending quality time alone with the risk register, formal reviews with one or more additional people are warranted. These reviews can help improve the quality of the risk register through consensus. Reviews strengthen the integrity of the risk register, as they will represent the opinion of a group rather than a single individual.

Few other persons may have skills or experience in risk management in smaller organizations. Risk register reviews with others are still valuable: as the risk manager describes risks to others, opportunities for improvements can still be identified.

Better organizations will document risk register reviews and record any changes to risk register entries.

Reviewing Risks with Staff It is often appropriate for the risk leader to review the contents of the risk register with other security, privacy, and risk staff members. Generally, these discussions will consist of a closer look at the details in the risk register, including a look at ratings, and any completed work on risk analysis that includes potential risk treatment options.

Staff members can be a good source of new material for the risk register. Reviews may, at times, remind staff members of other matters that may be good candidates for the risk register. Frontline personnel are often aware of good and poor practices in technology operations and business processes; earning their trust and using them for intel on new risks can be a valuable pursuit.

When possible, staff reviews should not be limited to personnel in cybersecurity but could include staff from IT and other departments.

NOTE   Risk-averse organizations may consider employing reminders of confidentiality before reviewing risk register contents with staff.

Reviewing Risks with Business Leaders At times, it is appropriate for the risk leader to review the contents of the risk register with business leaders. This discussion can take many forms, including the following:

•   A detailed review of all relevant risks

•   A high-level review of the “Top N” risks

•   A high-level review of the nature of top risks

These reviews may be considered formal or informal, depending on many factors, including the maturity of the risk program and governance in the organization.

These reviews are not a part of risk treatment but instead are an assessment of the universe of relevant risks. These reviews help business leaders be better informed of the risks that have been identified, and possibly would include discussion on what risks may be the subject of focus in the near term.

Identifying Candidates for Deeper Analysis

The purpose of risk register reviews is about reaching an agreement on each risk’s ratings and other data as well as overall risk reduction in the organization. Risk reduction is accomplished by selecting risks that are considered suitable candidates for next steps: deeper analysis and, eventually, risk treatment.

The purpose of deeper analysis is to help the risk manager decide if a specific risk is ready for risk treatment—the decision made by business leaders on the final disposition of the risk. Before that decision can be made, the risk manager must first analyze the risk in more detail.

In the risk management program, the risk manager may establish formal criteria or rely more on gut instinct for selecting risks to study in more detail. A blended approach will likely be used in this selection, where risks meet criteria and are more “visible” than others. This visibility may be related to applicable regulation, internal politics, market reputation, service profitability, or other factors.

A risk manager may select less politically charged risks in a new risk management program. Business leaders may then be more comfortable making risk treatment decisions due to the absence of emotional or political factors. When business leaders are more familiar with the risk treatment process, risks with greater visibility (whatever that may mean) can be selected and treated.

Performing Deeper Analysis

When a risk has been selected for deeper analysis, it’s time for the risk manager to begin working on it. The purpose of this deeper analysis is to determine one or more viable risk treatment options that, hopefully, business owners will agree with and ratify.

Individual risks are generally not simple: discerning risk treatment options may require much thought and discussion. We prefer the ideal small group discussion, where the risk manager and one or two subject matter experts brainstorm to identify feasible risk treatment options.

There is no ideal number of options to analyze, although, pragmatically, we prefer three to five options to be considered. If more than five options are selected, risk analysis will take additional time; with fewer than three, management may feel that too few options were considered.

NOTE   In our continuing discussion of risk management, risk analysis, and risk treatment, we use terms that imply a simple spreadsheet program for recording risks and performing risk analysis. The use of a spreadsheet may be practical for an emerging risk management program.

The Analysis Worksheet

The worksheet used for additional analysis compares the untreated risk score with the risk score for each of several possible risk treatment options. We like to use a simple model, as described here:

Untreated risk:

•   The same columns from the risk register, including likelihood, impact, criticality, asset value, and risk score.

Treated risk:

•   An additional set of risk score columns, including likelihood, impact, criticality, asset value, and risk score.

•   Additional columns that express the time, effort, and cost required to perform the risk treatment.

•   Columns that express the reduction in risk and residual risk.

Risk treatment:

•   One or more columns that would specify who or what department or team would perform the risk treatment.

Each risk treatment option occupies a new row in the worksheet. Each option is scored, with the scores representing the levels of likelihood, impact, criticality, and asset value, as well as the new calculated risk score, as though the risk treatment was in place.

Once each risk treatment option is scored, the risk reduction and residual risk are shown. The risk reduction and residual risk, together with other columns showing hard costs and impact on the workforce, can help the risk manager better understand the feasibility of each risk treatment option.

Depending on the complexity of the risk, a detailed analysis may require many hours of research and study. The amount of time available for this work will depend on the risk manager’s availability compared with other tasks. In some cases, detailed risk analysis may be considered a luxury.

Figure A-2 depicts a simple risk analysis worksheet that includes the initial risk rating, plus a description of various risk treatment options with their ratings.

Figure A-2 A simple risk analysis worksheet showing risk treatment options

NOTE   We prefer to use a separate workbook for performing detailed risk analysis; otherwise, the central risk register workbook will soon be overcrowded with numerous risk analysis tabs.

Qualitative and Quantitative Risk

For risks that involve relatively low costs, it may be sufficient for the risk manager to rely only on qualitative risk analysis techniques to portray which treatment options are more effective than others at reducing risk. However, when the costs of the risk and risk treatment are significant, the risk manager may need to perform a quantitative risk analysis to determine estimates of actual risk treatment costs. Quantitative risk analysis is instrumental when the risk treatment option includes significant hard and/or soft costs.

Selecting Treatment Options

For the risk analysis to contribute to successful risk treatment, the risk manager needs to understand how the business leaders in their organization think about risk. The risk manager should select one or more risk treatment options that business leaders can understand. Business leaders need to feel that their decision is not forced or coerced, and that the options represent a range of reasonable options.

As the risk manager ponders risk treatment options, they need to remember the goal is to bring the elements together to tell a story.

Considering Risk Appetite and Risk Tolerance

Organizations are all over the place regarding risk appetite and risk tolerance. It is our experience (through many years of consulting) that most organizations have no formal statement or practice of risk appetite. In other words, management has not drawn a line in the sand stating that risks above a certain magnitude will not be routinely accepted.

Organizations lacking a formal risk appetite policy or statement must rely instead on gut feel for determining whether to accept any particular risk. While not ideal, as long as the risk manager properly facilitates the risk treatment conversation, business leaders can still make an informed risk decision, even without formal risk guardrails.

A better situation is when the organization has formally defined risk appetite, which states the highest risks that the organization is permitted to accept. We advise another caution here: risk managers should resist the call to reclassify specific risks to a lower level, just to facilitate acceptance. Suppose a particular risk exceeds the allowable risk appetite. In that case, the organization’s risk tolerance comes into play: just how much more risk will the organization accept on an exception basis, and who is required to approve such an exception?

Understand that we’re still in the risk analysis phase but are anticipating possible outcomes for risk treatment discussions and an eventual decision. Risk managers should be prepared with talking points to argue for and against each risk treatment option as well as the array of risk mitigation options. Remember that it is not the risk manager’s responsibility to make risk decisions but rather to facilitate discussions leading to business leaders making informed decisions.

Developing a Risk Treatment Recommendation

We like to think about the risk analysis of a risk register item as the development of an entire package of information to be presented to senior management. The package will typically consist of the following:

•   A brief description of the risk

•   The context of the risk

•   Typical risk scenarios, with their probability and impact, if and when realized

•   Risk treatment options

•   The recommended risk treatment option

•   Backup information should management wish to explore the matter further

When taking risk treatment options to senior management, we have reduced this to a single presentation slide and speak to the matter in business terms. Typically, there will be some discussion and a few questions. Depending on the formality of the organization, there may be a formal vote or verbal support for or against a decision.

It’s vital to develop talking points, anticipate questions, and rehearse the briefing with a trusted peer. You generally have one opportunity to tell the story of the risk, its potential impact on the organization, and what you propose be done about it.

NOTE   It’s always better to be prepared with more information than is used in a risk treatment proceeding.

Risk Treatment Overruled

As a risk manager in a public company, I (Peter) brought to senior leadership in one of our risk management reviews a matter of workplace security and safety: a particular business office had no access control that segregated work areas from the reception area. Visitors during business hours could simply walk through the door and into the entire office suite where about 100 employees worked. My recommendation was to accept this risk.

The company president stood up and said, “No, I will not accept this risk. We should have a wall and door constructed to keep visitors out of the work area unless they are permitted to enter.”

While this may at first appear to have been a correction or a reprimand, I took it as an engaged senior executive taking a different point of view and making an informed risk decision. At this point, I knew that senior leaders were engaged and not merely rubber-stamping my recommendations.

The Risk Treatment Decision

Up to this point, the risk manager has been analyzing one or more risks, developing viable risk treatment and risk mitigation options, and preparing a package to present to senior management. During the meeting in which the risk manager has presented the story of the risk and the recommended course of action (or inaction, in the case of risk acceptance), senior leaders should be allowed to ask questions about the matter before being asked to ratify the recommendation (or decide otherwise). Note the questions, who asked them, and how they were answered—this will help in future proceedings.

The call for the actual decision may range from formal to informal. An accurate accounting of the decision is critical, as it should be a part of officially published meeting minutes used to document the decision. Note those present and (optionally) who agreed and who disagreed.

NOTE   In some cases, it may be wise to discuss the risk treatment matter with senior executives in one-on-one discussions, where they may be more apt to ask questions to understand the situation better. These discussions will also help the risk manager better prepare for the risk treatment discussion, and in some cases, it may even sway the risk manager to pursue a different remedy.

Risk Mitigation When the risk treatment decision is mitigation, the decision should also include the naming of the person responsible for performing the risk treatment and executives’ desire for the timing of risk treatment. This is particularly important if the risk treatment owner is not present in the discussion.

Any discussion about risk treatment options should be captured so that the risk treatment owner will have additional background and insight into why the particular risk treatment option was selected. This may help the risk treatment owner proceed more quickly with planning and execution without circling back to decision-makers to better understand the rationale behind the decision.

All of the basic facts about risk mitigation (who made the decision, when the decision was made, who the risk treatment owner is, when the risk treatment should be completed, and so on) should be entered into the risk register. Then, the risk manager can conduct effective follow-up over the coming weeks, months, and quarters and report on the progress to the decision-makers.

Risk Acceptance If the risk treatment decision is acceptance, we recommend that this decision not be perpetual but instead have an expiration date. After that expiration date, the risk will be reopened and a new risk treatment decision made. The reason for expiring risk acceptance is this: conditions related to the risk may change in a year, so much so that a different decision may be needed in the future. Many things can change in a year:

•   How the organization uses information systems

•   The organization’s reliance on critical business processes on information systems

•   Changes in underlying information technology

•   Changes in threats

•   Changes in tools that help mitigate threats

•   Changes in business priorities

One year may seem like a short period, but a lot can happen in a year. Make sure executives are on board with this concept.

Organizations with formal risk management programs sometimes utilize a risk acceptance letter—a signed memo in which a business unit leader or department head chooses to accept a specific, identified risk versus another risk treatment option such as mitigate, transfer, or avoid. In the risk acceptance letter, the signatory accepts the potential consequences if an event related to the risk occurs in the future.

CISOs Are Not Risk Owners

Many organizations have implicitly adopted the mistaken notion that the chief information security officer (CISO) is the de facto risk owner for all identified risk matters.

In a properly run risk management program, risk owners are business unit leaders and department heads who own the business activity where a risk has been identified. For instance, if a risk is identified regarding the long-term storage of full credit card numbers in an e-commerce environment, the risk owner would be the executive who runs the e-commerce function. That executive would decide to mitigate, avoid, transfer, or accept that risk.

The role of the CISO is to operate the risk management program and facilitate discussions and risk treatment decisions, not to make those risk treatment decisions. A CISO can be considered a risk facilitator but not a risk owner.

Even when embraced and practiced, this concept does not always stop an organization from sacking the CISO should a breach occur. A dismissal might even be appropriate, for example, if the risk management program that the CISO operated was not performing as expected.

Risk Transfer One of the four basic risk treatment options, risk transfer means that some outside organization is willing to take on the risk. Often, this comes in the form of cyber insurance, but it could just as easily be a business process outsourcing (BPO) arrangement in which a service provider is willing to accept certain risks.

We provide a note of caution here. While an organization can outsource risk, no organization can outsource accountability. Here is an example: a successful service business specializing in water damage mitigation outsources its entire IT and IT security functions to a large service provider, including information systems where customers register and request one-time or recurring services. The IT service provider suffers a breach, resulting in the exposure of its customers’ personal information and numerous identity theft and fraud cases. The service business attempts to explain that the external service provider is the party responsible for the breach. However, the customers are unhappy, blame the service business, and threaten to organize a class-action lawsuit for the damages.

In this example, the service business cannot absolve itself because the IT outsourcer’s lapse resulted in the breach. The service business decided to use this particular IT outsourcer and cannot absolve itself of responsibility because of an unfavorable outcome.

Cyber insurance is similar to this example. An organization with cyber insurance may suffer a breach, and the cyber insurance company may compensate the organization for particular losses. However, the organization will have lost some goodwill and may have a long-lasting tarnished reputation that can take years to undo.

It is imperative that senior executives fully grasp the complete picture of risk transfer.

Risk Avoidance Risk avoidance is often the least understood risk treatment option. With risk avoidance, the activity that causes the risk is itself discontinued.

Here is an example: a risk assessment reveals the use of an unsanctioned cloud service provider to process sensitive information. End users decided to employ a free online service to perform language translation and use it for translating sensitive documents, including contracts. In its end-user licensing agreement (EULA), the service provider claims ownership over any content that it translates. When this matter was brought to light in a risk treatment discussion, business executives directed the organization to immediately discontinue use of the service provider, thus avoiding the risk.

The Fifth Option in Risk Treatment

For decades, risk management frameworks have cited the same four risk treatment options: accept, mitigate, transfer, and avoid. There is, however, a fifth option that some organizations select: ignore the risk.

Ignoring a risk situation is a choice, although it is not considered a wise choice. Ignoring a risk means doing nothing about it, not even making a decision about it. It amounts to little more than pretending the risk does not exist. It’s off the books. It is not even added to a risk register for consideration, but it represents a risk situation nonetheless.

In some cases, such as for minimal risk items, this may be perfectly acceptable. A theft of a paperclip may simply be too small for consideration for a risk register. It would probably be wise to leave this off of a risk register unless there is a specific reason to add it. In some cases, listing minimal risk is very critical because compliance requirements dictate that specific risks be considered in risk evaluations. Developing the right level of detail for a risk register requires experience, listening to an organization’s culture, and striking the right balance.

Organizations without risk management programs may implicitly ignore all risks, or many of them at least. Organizations might also be practicing informal and maybe even reckless risk management—risk management by gut feel. Without a systematic framework for identifying risks, many are likely to go undiscovered. This practice could also be considered as ignoring risks through the implicit refusal to identify them and treat them properly.

Note that ignoring risk, particularly when governance requires that you manage it, is usually a violation of the principles of due diligence and due care. Many organizations can be legally charged with “willful negligence” if they have a duty to manage risk, and they simply don’t.

Other Risk Response Options Other common risk response options include contingency, enhance, and exploit.

Contingency is all about creating contingency plans in case a risk materializes. For instance, an organization might develop a playbook within its security incident response or business continuity planning process to respond to a specific type of event.

Enhance may be a response to a positive risk such as a project coming in under budget. If a few dollars spent earlier in the project will save some money long term, it may make sense to enhance the risk. In another example, a security engineering team determines that a new detective control helps to reduce other risks not considered initially.

Exploit can be very much related to the same situation. If a project finishes early, the resources may be reassigned to another project. Note that this use of the term exploit is different from that of malware or an attacker exploiting a vulnerability in an information system, business process, or worker.

Publishing and Reporting

Like any formal business program, risk leaders publish periodic reports and metrics from the risk management program. The risk program needs to inform business executives on the state of risk in the organization and proceedings in the program. Several aspects of risk reporting are discussed here.

Risk Register

The risk register itself is considered a detailed, operational business record. Reporting about the risk register generally consists of high-level depictions of risk instead of reporting the detail. Challenges in reporting risk include the following:

•   Trends Changes in the size of the risk register, or the aggregate or average risk levels, may be misleading, particularly in newer risk programs that still identify risk.

•   Completeness A risk register should not be considered a complete record of risk, as there may be numerous undiscovered and unidentified risks.

New Risks

Risk leaders may opt to disclose the number of, or even some details about, new risks identified in the reporting cycle. This reporting is a good indication that the risk program continues to keep its risk radar operating and open to risk discovery.

Risk Review

Reporting and metrics on risk reviews are an indication of engagement and involvement. Executives should expect risk leaders to periodically engage business leaders and department heads throughout the organization and may want to know how often (and with whom) this occurs.

Risk Treatment

The rate at which risk treatment decisions are made, and trends in risk treatment options, shows that the risk leader continues to work through the risk register.

Risk Mitigation Follow-Up

When mitigation is the chosen risk treatment for a given risk, the risk leader needs to track that risk mitigation and report on whether mitigation is performed on schedule. Mitigation activities that are behind schedule can be highlighted so that executives can understand where their directives are falling short and which are being completed on time.

Risk Renewals

As discussed earlier in this appendix, risk acceptance should not be perpetual but should expire. Risk leaders may want to publish, as a leading indicator, the number of risks nearing renewal. Those risks will be redeliberated and new decisions made, whether to continue to accept the risks for another year or take a different approach.

Risk Prioritization

In risk reporting, leaders often care only about the top-priority risk, such as a top 5, 10, or 20 risks. These may not be precisely the top risks, according to the risk manager. However, these priorities represent an articulation of risk appetite and risk tolerance, as well as leadership’s culture and focus on risk. All too often, risk prioritization with managers boils down to nothing more than cost, unfortunately.

The Sensitivity of Risk Reporting Information

In most organizations, detailed information about risk, particularly vulnerabilities and safeguards, is treated as highly confidential. If it became public, that information might allow the organization to be attacked. Further, this information would reveal clues about the organization’s risk culture. This is especially true in government and healthcare, in our experience.

APPENDIX B

About the Online Content

This book comes complete with TotalTester Online customizable practice exam software with 300 practice exam questions.

System Requirements

The current and previous major versions of the following desktop browsers are recommended and supported: Chrome, Microsoft Edge, Firefox, and Safari. These browsers update frequently, and sometimes an update may cause compatibility issues with the TotalTester Online or other content hosted on the Training Hub. If you run into a problem using one of these browsers, please try using another until the problem is resolved.

Your Total Seminars Training Hub Account

To get access to the online content you will need to create an account on the Total Seminars Training Hub. Registration is free, and you will be able to track all your online content using your account. You may also opt in if you wish to receive marketing information from McGraw Hill or Total Seminars, but this is not required for you to gain access to the online content.

Privacy Notice

McGraw Hill values your privacy. Please be sure to read the Privacy Notice available during registration to see how the information you have provided will be used. You may view our Corporate Customer Privacy Policy by visiting the McGraw Hill Privacy Center. Visit the mheducation.com site and click Privacy at the bottom of the page.

Single User License Terms and Conditions

Online access to the digital content included with this book is governed by the McGraw Hill License Agreement outlined next. By using this digital content you agree to the terms of that license.

Access To register and activate your Total Seminars Training Hub account, simply follow these easy steps.

1.   Go to this URL: hub.totalsem.com/mheclaim

2.   To register and create a new Training Hub account, enter your e-mail address, name, and password on the Register tab. No further personal information (such as credit card number) is required to create an account.

If you already have a Total Seminars Training Hub account, enter your e-mail address and password on the Log in tab.

3.   Enter your Product Key: cqpq-9s9f-3fbz

4.   Click to accept the user license terms.

5.   For new users, click the Register and Claim button to create your account. For existing users, click the Log in and Claim button.

You will be taken to the Training Hub and have access to the content for this book.

Duration of License Access to your online content through the Total Seminars Training Hub will expire one year from the date the publisher declares the book out of print.

Your purchase of this McGraw Hill product, including its access code, through a retail store is subject to the refund policy of that store.

The Content is a copyrighted work of McGraw Hill, and McGraw Hill reserves all rights in and to the Content. The Work is © 2022 by McGraw Hill.

Restrictions on Transfer The user is receiving only a limited right to use the Content for the user’s own internal and personal use, dependent on purchase and continued ownership of this book. The user may not reproduce, forward, modify, create derivative works based upon, transmit, distribute, disseminate, sell, publish, or sublicense the Content or in any way commingle the Content with other third-party content without McGraw Hill’s consent.

Limited Warranty The McGraw Hill Content is provided on an “as is” basis. Neither McGraw Hill nor its licensors make any guarantees or warranties of any kind, either express or implied, including, but not limited to, implied warranties of merchantability or fitness for a particular purpose or use as to any McGraw Hill Content or the information therein or any warranties as to the accuracy, completeness, correctness, or results to be obtained from, accessing or using the McGraw Hill Content, or any material referenced in such Content or any information entered into licensee’s product by users or other persons and/or any material available on or that can be accessed through the licensee’s product (including via any hyperlink or otherwise) or as to non-infringement of third-party rights. Any warranties of any kind, whether express or implied, are disclaimed. Any material or data obtained through use of the McGraw Hill Content is at your own discretion and risk and user understands that it will be solely responsible for any resulting damage to its computer system or loss of data.

Neither McGraw Hill nor its licensors shall be liable to any subscriber or to any user or anyone else for any inaccuracy, delay, interruption in service, error or omission, regardless of cause, or for any damage resulting therefrom.

In no event will McGraw Hill or its licensors be liable for any indirect, special or consequential damages, including but not limited to, lost time, lost money, lost profits or good will, whether in contract, tort, strict liability or otherwise, and whether or not such damages are foreseen or unforeseen with respect to any use of the McGraw Hill Content.

TotalTester Online

TotalTester Online provides you with a simulation of the CRISC exam. Exams can be taken in Practice Mode or Exam Mode. Practice Mode provides an assistance window with hints, explanations of the correct and incorrect answers, and the option to check your answer as you take the test. Exam Mode provides a simulation of the actual exam. The number of questions, the types of questions, and the time allowed are intended to be an accurate representation of the exam environment. The option to customize your quiz allows you to create custom exams from selected domains or chapters, and you can further customize the number of questions and time allowed.

To take a test, follow the instructions provided in the previous section to register and activate your Total Seminars Training Hub account. When you register, you will be taken to the Total Seminars Training Hub. From the Training Hub Home page, select your certification from the Study drop-down menu at the top of the page to drill down to the TotalTester for your book. You can also scroll to it from the list of Your Topics on the Home page, and then click the TotalTester link to launch the TotalTester. Once you’ve launched your TotalTester, you can select the option to customize your quiz and begin testing yourself in Practice Mode or Exam Mode. All exams provide an overall grade and a grade broken down by domain.

Technical Support

For questions regarding the TotalTester or operation of the Training Hub, visit www.totalsem.com or e-mail support@totalsem.com.

For questions regarding book content, visit www.mheducation.com/customerservice.

GLOSSARY  

acceptable use policy (AUP) Organizational policy that describes both acceptable and unacceptable actions when using organizational computing resources, as well as the consequences of violating the policy.

access control The processes and technologies involved in protecting information, systems, and data against unauthorized disclosure, modification, or loss through the control of access to those resources physically and/or logically.

accountability The ability to trace an action or event to a specific subject and to hold that subject responsible for their actions.

AIC triad See CIA triad.

assessment The process of determining whether a program, project, or control is meeting specified objectives as well as determining whether the controls selected to protect the system are performing their desired function to the level required.

asset Anything of value to an organization; assets can include tangible items such as information, data, equipment, supplies, facilities, and systems as well as intangible items such as customer loyalty and reputation.

asset valuation The practice of assigning a monetary value to an asset.

attack An offensive action that results in potential harm to an asset.

attack surface The set of components that could be the target of attack by an adversary.

audit A formal inspection of a control, process, or system to determine whether it is being followed, operates effectively, and meets its objectives.

authentication The process of validating credentials a user has supplied to verify that they are the actual authorized user and that the credentials belong to that user.

authorization The process of giving authenticated users the proper accesses to systems, data, and facilities.

availability The goal of having information and systems available to authorized users whenever and however they need them.

bow-tie analysis A risk analysis technique used to depict the relationships between various elements of risk.

brainstorming A problem-solving technique in which participants spontaneously generate potential ideas for discussion and analysis.

business case In the context of risk management, a written or oral presentation that explains the reasoning for the expense and effort associated with risk response.

business continuity The process, generally detailed in a supporting plan, that keeps the company operating and functioning in the event of a power outage, IT malfunction, or major disaster.

business impact assessment (BIA) The process of analyzing critical business processes, as well as the assets used to support them, and determining the impact to them when a loss of or disruption in access to those assets occurs.

business process outsourcing (BPO) The process of outsourcing one or more business processes to a service provider.

business triage A decision-making system used to prioritize resources to maximize outcomes.

capability The ability for the organization to implement a risk response.

capability maturity model integration (CMMI) A business process maturity model developed by Carnegie Mellon University and now owned by ISACA.

change management The overall process used to manage the request, review, approval, and execution of changes to IT systems or business processes.

CIA triad The three security principles of confidentiality, integrity, and availability.

COBIT A management and governance framework developed and used extensively by ISACA in its various risk management and business process frameworks.

code review A manual examination of software source code to identify defects, including those that may be exploited by an attacker. See also code scan.

code scan An automated examination of software source code to identify defects. See also code review.

common control A control spanning the entire organization that protects multiple assets rather than only a specific asset. A physical control is a good example of a common control, and the responsible entity for that control would be the common controls provider.

confidentiality The goal of protecting systems and information from unauthorized disclosure.

configuration management The use of recordkeeping to record changes made to configuration settings in an information system.

control A measure put in place to increase protection for an asset, to make up for a lack of protection for an asset, or to strengthen a weakness for an asset. Controls can be administrative, technical, or physical and operational. They can also be further divided by functionality (deterrent, preventative, detective, and so on).

control baseline The initial set of controls selected, based on the security categorization to be applied to systems and data and maintained throughout their life cycle.

control deficiency analysis The process of determining the difference between the existing state of a control’s effectiveness and its desired state.

control gap A situation where controls do not exist or are insufficiently designed to meet a control objective.

control objective An overarching statement describing the intent of a group of controls.

control ownership The person or entity responsible for the proper implementation and maintenance of security controls within the organization.

cost The financial impacts of any decision as well as the less-easily quantified aspects such as loss of goodwill, loss of brand status, and other hard-to-define attributes. Cost also includes the maintenance of the responsive mitigation over its required life span.

criticality analysis A study of each system and process, a consideration of the impact on the organization if it is incapacitated, the likelihood of incapacitation, and the estimated cost of mitigating the risk or impact of incapacitation

culture The values and norms in an organization that define how people treat each other and work together to achieve organization objectives.

data classification Policies that define sensitivity levels and handling procedures, and controls used to protect information at various levels.

data destruction The willful or malicious destruction of data that renders it unavailable for intended uses.

data discovery A manual or automated technique in which a target system is examined to determine the presence of specific types of data; additionally, this may include an examination of access rights to particular sets of data.

data sensitivity The level of protection required for information or data based on its impact to the organization if it were disclosed to unauthorized people, subject to unauthorized modification, or otherwise lost.

Deming cycle A generic business life cycle model consisting of Plan, Do, Check, and Act.

denial of service (DoS) An attack on a system that renders it unavailable for legitimate uses.

design review The examination of the design of a system or process to determine whether it is sound and meets stated objectives.

disaster recovery (DR) The process of reacting to an incident or disaster and recovering an organization, its personnel, and systems to a functioning state.

due care The process of taking the necessary responsibility and steps to protect an organization and its workers.

due diligence The reasonable amount of investigation taken prior to entering into a legal agreement.

due process An impartial and fair inquiry of violations of organization policy.

economy of use The design principle that states that you should attempt to design and implement controls that can be applied to more than one system or set of data or that provide more than one function in effectively mitigating risk. The goal is to minimize single-use controls (controls that apply only to a specific system or set of data) because they can be more expensive and specialized to implement.

effectiveness The extent to which the response reduces the likelihood or the impact of the risk event to the organization; also, the degree and depth to which a control fulfills its security requirements.

efficiency The interaction of a control with its environment, affecting factors such as cost, reliability, supportability, and interoperability.

enterprise risk management (ERM) The practice of identifying and managing strategic risk in an organization.

event An instance of threat realization.

event-tree analysis A bottom-up risk analysis technique that focuses on all possible risk impacts and looks for all possible risk events.

exception management The process of accepting, documenting, and tracking exceptions to security policies and risk mitigation strategies.

exploit 1) A specific tool or method that can be used to carry out a threat. 2) The act of attacking an asset, made possible by the presence of a vulnerability.

Factor Analysis of Information Risk (FAIR) A risk analysis methodology used to analyze the factors that contribute to individual risks.

false negative A situation where a vulnerability isn’t detected but does actually exist.

false positive A situation where a vulnerability is reported that isn’t actually legitimate.

fault-tree analysis A top-down risk analysis technique that focuses on risk events and looks for all possible causes of the event.

Federal Information Processing Standards (FIPS) Public standards published by the National Institute of Standards and Technology (NIST) for use in U.S. government systems.

Federal Information Security Management Act (FISMA) A U.S. federal law requiring federal agencies to develop information security programs and capabilities aligned to NIST Special Publication 800-53.

framework An overall methodology prescribing higher-level processes or controls.

fuzzing A technique used to generate various forms of input to a system to identify potential vulnerabilities that could allow an attacker to compromise the system.

gap assessment An examination of a system or process to determine whether it complies with established requirements or standards.

governance The legal or corporate standards that prescribe how an organization will conduct itself with regard to its behavior in handling information and data.

governance, risk, and compliance (GRC) system See integrated risk management (IRM) system.

Gramm-Leach-Bliley Act (GLBA) U.S. law that requires financial institutions (including banks, loan companies, insurance, and investment companies) to protect sensitive financial data and make their information-sharing practices known to their customers. Of particular interest to security professionals is the Safeguards Rule incorporated into GLBA, which requires institutions under the jurisdiction of the Federal Trade Commission to have specific measures in place to protect customer information.

Health Insurance Portability and Accountability Act (HIPAA) Law passed in 1996 requiring the U.S. government’s Health and Human Services Department to establish requirements for protecting the privacy and security of personal health information (PHI). The two important elements of HIPAA of interest to security professionals are the HIPAA Privacy Rule and the HIPAA Security Rule, which set forth specific standards to protect electronic PHI.

identification The process of initially presenting credentials to a system to identify an authorized user.

impact The level of potential harm or damage to an asset or the organization if a given threat were to exploit a given vulnerability.

inherent risk The level of risk associated with a specific activity or function, prior to applying any protective controls or safeguards.

integrated risk management (IRM) system An information system used to track and manage various governance, risk, and compliance activities, including risk management.

integrity The goal of preventing unauthorized modification to a system or data.

ISO/IEC The International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), which together are responsible for a majority of the information technology standards used worldwide, including several that apply to information security and risk management.

IT general control (ITGC) A control that is applied across all information systems and supporting processes in an organization.

job rotation A practice where an organization occasionally moves personnel from one job to another to help prevent practices contrary to policy.

key control indicator (KCI) A specific indicator that shows the relative effectiveness of a control.

key performance indicator (KPI) An indicator that is used to understand and enable the measurement of a control’s performance.

key risk indicator (KRI) A highly probable indicator designed to accurately predict an important level of risk based on a defined threshold.

least privilege A security principle that dictates that subjects should be given only the minimum level of rights, permissions, and privileges necessary to perform their designated functions or jobs, and no more than that.

life cycle A characteristic of a business process where a sequence of activities is repeated.

likelihood The certainty that an incident will occur; often expressed statistically as a probability of occurrence.

mandatory vacation A practice where an organization requires that each employee use a minimum amount of vacation each year to provide the opportunity for audit, security, and privacy specialists to examine the employee’s practices or records during their absence.

materiality A quantitative or qualitative expression of significance.

maturity The degree of formality and optimization of a business process or capability.

maturity assessment An assessment of processes or capabilities to determine their maturity. See also maturity.

maximum tolerable downtime (MTD) A theoretical period, measured from the onset of a disaster, after which the organization’s ongoing viability would be at risk.

multifactor authentication Any means used to authenticate a user that is stronger than just the use of a user ID and password. Examples of multifactor authentication include digital certificates, tokens, smart cards, and biometrics.

need-to-know A security concept that requires a subject have an actual requirement to access systems or data, based on their job requirements.

NIST The U.S. Department of Commerce’s National Institute of Standards and Technology, a standards development organization.

NIST Risk Management Framework (RMF) The overall risk management methodology published and promulgated by the National Institute of Standards and Technology (NIST) in Special Publication 800-37.

non-repudiation The security concept that requires a subject to be accountable for their actions, such that they cannot deny that they took an action.

OCTAVE The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) methodology developed by Carnegie Mellon University and the U.S. government to assist organizations in identifying and assessing information security risk.

Payment Card Industry Data Security Standard (PCI DSS) A set of security requirements levied on merchants that process credit card transactions by the major payment card industry providers, including Discover, Visa, MasterCard, and American Express. PCI DSS was developed to impose security requirements and controls on retailers (merchants and service providers) to reduce credit card fraud and identity theft.

penetration test An authorized assessment that actively identifies and exploits vulnerabilities or weaknesses in a system or process.

personally identifiable information (PII) Data elements that uniquely identify a natural person.

platform A hardware, software, or cloud infrastructure upon which to base computing operating systems, applications, and networks. It may involve different operating systems, network protocols, or particular types of hardware.

port scanner A software program that determines which ports on a target system are listening for incoming requests. See also vulnerability scanner.

portfolio A grouping of programs managed as a whole. Portfolio management involves the oversight of several different programs by a senior person in the organization.

practice A proven, standardized methodology or way of performing particular tasks or processes.

privacy The principles and practices of ensuring the protection and proper use of the personally identifiable information (PII) of customers, constituents, and workers.

probability The chance that an event will occur.

program 1) A grouping of similar projects; programs are usually ongoing and longer term in nature and may also encompass several individual projects. 2) Activities specific to processes that may have an indefinite duration.

project A limited-duration set of activities geared toward a particular goal; projects have definitive start and stop dates, resource allocations, scopes, schedules, and costs.

project management A set of processes covering a defined project from start to finish, generally looking to cut costs such as time, scope, and overall project cost.

protocol analyzer A hardware or software tool that collects network traffic for the purpose of examination, either for determining network issues or for capturing plaintext usernames, passwords, or other sensitive information being sent in the clear.

qualitative assessment An assessment technique that uses subjective values, such as low, moderate, and high, to describe various components of risk, such as likelihood and impact. Qualitative techniques rely on data that is often not easily described in numerical terms.

quantitative assessment An assessment technique that uses nonsubjective values, such as numerical or other measurable data, to describe various components of risk, such as likelihood and impact. Quantitative techniques rely on data that is numerically derived and not easily subject to individual opinion.

quick win A high-reward, low-cost risk response that is both effective and efficient.

recovery point objective (RPO) The maximum tolerable period in which data can be lost by the organization because of an incident or disaster.

recovery time objective (RTO) The maximum amount of time allowed to pass between an incident and recovering a business process to an operational state.

residual risk The risk that remains after the application of risk treatment, acceptance, or transfer.

resilience The ability of the business to survive negative events and continue with its mission and function.

return on investment (ROI) The ratio between investment and value received.

risk The possibility of harm that can come to an asset or an organization.

risk acceptance An active decision made to assume risk (either inherent or residual) and take no further action to reduce it.

risk acceptance letter A formal memo in which a business leader agrees to accept an identified risk.

risk analysis The detailed examination of an individual risk identified in a risk assessment.

risk appetite The organization’s overall acceptable level of risk for a given business venture.

risk assessment The process of identifying and assessing various factors, including threats, threat actors, vulnerabilities, assets, and likelihood to determine their impact on the organization.

risk avoidance A risk treatment option taken when the level of risk is still not acceptable after controls have been considered, resulting in an activity being canceled or not being started.

risk capacity The amount of loss that an organization can incur without seriously affecting its ability to continue as an organization.

risk culture The overall attitude toward risk, promulgated and supported by the organization’s leadership.

risk factor Any factor that may contribute to an increase or decrease in risk; risk factors could be external or internal, and they could affect either likelihood or impact should a risk event actually occur.

risk identification The realization of a new risk to an organization, its systems, or its processes.

Risk IT Framework ISACA’s own risk management methodology; it is strongly tied to and integrated with COBIT. The Risk IT Framework merges traditional IT models with a more risk-focused mindset.

risk ledger See risk register.

risk management The life cycle process of managing risk within an organization at all levels, according to the organization’s risk appetite, tolerance, and strategy.

risk mitigation Involves the application of controls that lower the overall level of risk through the reduction of the vulnerability, the likelihood of the threat exploit, or the reduction of the impact to the asset, if the risk were to be realized.

risk monitoring Ongoing risk assessment activities in which risks are periodically reviewed to determine whether the nature of threats, threat actors, vulnerabilities, impact, or probabilities of occurrence have changed.

risk owner The person ultimately responsible and accountable for a risk.

risk ownership The state of being responsible and accountable for a risk.

risk profile A collection of detailed data on identified IT risks, typically applied to a specific system or groups of systems.

risk ranking The process of placing risks into a sequence, usually with the greatest risks appearing first.

risk realization The awareness that a potential risk scenario has become actualized.

risk register The master product or document that reflects the different risk scenarios and factors for the organization; it could be broken down by asset or system and reflects the different risk factors, including threats, vulnerabilities, assets, likelihood, and impact to assets.

risk response action plan A list of the risk responses that have been chosen, and the charts of their progress and associated timeline, with an appropriate action owner or owners.

risk scenario An identified risk event possibility, which consists of a threat actor, threat, vulnerability, and asset.

risk sharing Often referred to as risk transference, risk sharing entails the use of a third party to offset part of the risk. It can involve the outsourcing of some activities to a third party to reduce the financial impacts of a risk event.

risk tolerance The organization’s level of acceptable variation from the risk appetite.

risk transference See risk sharing.

root-cause analysis (RCA) A method of problem-solving that seeks to identify the root cause of an event or problem.

Sarbanes-Oxley Act of 2002 (SOX) U.S. law passed in 2002 establishing requirements for public companies in the United States, as well as auditors and accounting firms, to improve the accuracy and reliability of corporate disclosures concerning securities laws. The law is enforced by the U.S. Securities and Exchange Commission (SEC) and provides governance for the integrity and accuracy of data produced by an organization. For security professionals, this has the effect of imposing specific integrity and protection controls on information systems and processes.

scope The set of systems, processes, personnel, data, or work centers to be included in an assessment.

security categorization The process of determining the impact to the organization regarding the confidentiality, integrity, and availability of information and systems. The security categorization uses qualitative benchmarks of low, moderate, and high. FIPS 199 and NIST Special Publication 800-60 offer a defined process for the security categorization of information.

security control A security measure or protection applied to data, systems, people, facilities, or other resources to protect them from adverse events. See also control.

segregation of duties See separation of duties.

separation of duties The process design and access control concept that enforces the rule that no single individual can carry out certain high-value or high-risk tasks.

service level agreement (SLA) A contractual agreement, signed by an organization and a third-party provider, that details the level of security, data availability, and other protections afforded the organization’s data held by the third party.

sniffer See protocol analyzer.

Software as a Service (SaaS) A third-party cloud-based service that offers outsourced use of software; this allows an organization to use licensed software at a lower cost than buying, installing, and maintaining hardware and software.

stakeholder Any business-related individual, department, or entity directly affected by risk to the organization.

standard A prescribed set of detailed processes, which may include specific levels of performance or function, used to complete and measure a given task or function.

statement of impact A qualitative or quantitative description of the impact on an organization if a process or system is incapacitated for a time.

systems development life cycle (SDLC) A framework describing the entire useful life of a system or software, which usually includes phases relating to requirements definition, design, development, acquisition, implementation, operations, and disposal.

tailgating A practice of unauthorized persons following authorized persons through a security door or entrance.

The Open Group Architecture Framework (TOGAF) A life-cycle enterprise architecture framework used for the designing, planning, implementation, and governance of an enterprise architecture.

third-party risk management (TPRM) The set of activities used to identify and manage risks associated with the use of external suppliers and service providers.

threat An event or occurrence that has the potential to cause harm or damage to people, places, or things or to adversely affect operations.

threat actor A threat agent that is one or more people. See also threat agent.

threat agent An entity that has the intent to initiate a threat event. This doesn’t have to be a person; it could also be nature, in the case of a natural disaster.

threat assessment An assessment that attempts to determine all potential threat actors and threats that may affect a given asset or its vulnerabilities.

threat landscape The set of threats that have been identified that are associated with a business activity or business asset.

threat modeling A threat assessment that attempts to determine all possible vectors of attack and includes risk factors that may affect the ability of a threat actor to initiate or complete a threat event.

threat realization A threat that is carried out that causes harm or damage to people, places, or things.

three lines of defense The concept of defense within a risk management framework that consists of operational management, risk and compliance management, and audit and accountability.

triage See business triage.

vulnerability A weakness in a system, asset, or process, such as a flaw in software code; it can also be considered a lack of protection for an asset, such as an unlocked server room door.

vulnerability analysis Examination of a vulnerability in a system, asset, or process.

vulnerability assessment An assessment that attempts to discover potential weaknesses for an asset. This involves identifying the assets that will be covered within the scope of the assessment, conducting scans and other tests against those assets, and providing a report of the vulnerabilities that have been found.

vulnerability scanner A software program designed to scan a system to determine what services the system is running and whether any unnecessary open ports, operating systems and applications, or back doors can be exploited because of a lack of patching or other flaws. See also port scanner.

walkthrough An interview with a control, process, or system owner as a part of an assessment.

work breakdown structure (WBS) A detailed decomposition of the work to be performed during the project, including specific step-by-step tasks, as well as required resources.

workers An inclusive term that means employees (full-time and part-time), temporary workers, contractors, consultants, and others who are a part of an organization’s workforce.

Zachman framework An enterprise architecture framework used to describe an IT architecture in increasing levels of detail.

INDEX

A

acceptable use policies (AUPs), 169–170

acceptance, risk, 84–85, 200–201

access control

non-repudiation, 158

PCI DSS, 100

principles and policies, 167–168

types, 155–156

account suspension, 175

accountability

auditing relationship, 13

overview, 158

risk ownership, 83

third-party risk, 87

adaptability issues in AUPs, 169

administrative controls, 32, 94

advisories, 24

aggregation of data, 108–109

ALE (annual loss expectancy), 60–62, 103

analysis

controls, 31–37, 103–104

data, 108–109

risk. See risk analysis methodologies

analysis worksheets, 197–198

annual loss expectancy (ALE), 60–62, 103

annualized rate of occurrence (ARO), 60

Anything as a Service (XaaS), 131

architecture and design reviews, 42

ARO (annualized rate of occurrence), 60

assess step in RMF, 161

assessments

data collection for, 42–43

defined, 40

IT risk. See IT risk assessment

scope, 42

types, 41–42

asset-level risk registers, 193

asset value (AV)

control selection factor, 103

qualitative risk analysis method, 191

risk analysis, 56

assets

collecting and organizing data for, 9–10

description, 26, 156

examples, 7–8

identifying in risk analysis, 56, 58

IT risk assessment, 43–44

management systems, 9

organizational, 6–10

sources of data for, 8–9

attacks, defined, 26

attainability in KPIs, 111–112

audience for training programs, 166

audits

accountability, 158

description, 42

new risk identification, 23

overview, 13

risk register information source, 55

AUPs (acceptable use policies), 169–170

authentication, 157

authorization, 157–158

authorize step in RMF, 161–162

AV (asset value)

control selection factor, 103

qualitative risk analysis method, 191

risk analysis methodology, 56

availability

description, 154–155

health data, 73

key performance indicators, 111–112

avoidance, risk, 85

awareness training programs, 165–167

B

BAAs (business associate agreements), 87

background checks in hiring, 173

battlefield allegory, 185–186

Bayesian analysis method, 66

BCDR. See business continuity and disaster recovery (BCDR) management

BCP (business continuity planning) projects, 67–68

BIA. See business impact analysis (BIA)

bottom-up risk scenario development, 39

bow-tie analyses, 65–66

brainstorming and risk identification, 25

brand equity assets, 8

building assets, 7

business alignment, 45

business associate agreements (BAAs), 87

business context in risk analysis, 56

business continuity and disaster recovery (BCDR) management

business impact analysis, 66, 141

overview, 140–141

plan testing, 142

recovery objectives, 141

recovery strategies, 141–142

resilience and risk factors, 142–144

business continuity planning (BCP) projects, 67–68

business impact analysis (BIA)

criticality analysis, 69–70

inventory key processes and systems, 67

overview, 66, 141

recovery objectives, 70

statements of impact, 68–69

business impact in risk analysis, 58

business leaders, risk register reviews with, 195–196

business processes

asset organization by, 9

organizational governance, 5–6

BYOD devices, 184, 193

C

CA (criticality analysis), 69–70

California Consumer Privacy Act (CCPA), 171

categorize step in RMF, 160–161

causal analysis step in root cause analysis, 37

CCBs (change control boards), 89

CCPA (California Consumer Privacy Act), 171

Center for Internet Security (CIS), 97–98, 100

centralized dashboards for controls, 110

change control boards (CCBs), 89

change management, 89–90

controls, 104

IT operations management, 136

SDLC, 151

change risk in emerging technologies, 153

chief information security officers (CISOs), 201

chronology step in root cause analysis, 37

CIS (Center for Internet Security), 97–98, 100

CISOs (chief information security officers), 201

classification

assets, 58

data, 145–146, 156–157

clearance for authorization, 158

cloud services

enterprise architecture, 131

risk, 184

COBIT 2019, 162–164

Code of Professional Ethics, 15

code reviews, 42

code scans, 42

codes of conduct and ethics, 174

collection of data, 108–109

Committee of Sponsoring Organizations of the Treadway Commission (COSO), 163

common controls, 36, 82

common controls providers, 36

Common Vulnerability Scoring System (CVSS) score, 32

communication between risk register layers, 194

compatibility in emerging technologies, 153

compensating controls, 94–95

completeness issues

acceptable use policies, 169

risk registers, 203

complexity increases, 184

compliance management, 12–13

compliance risks, 23

concepts in IT risk assessment, 40–45

conduct, codes of, 174

confidentiality

data classification, 145–146, 157

health data, 73

information security, 128

overview, 154–155

configuration assessments, 24

configuration management

controls, 104

IT operations management, 136

overview, 89–90

SDLC, 151

consultants

risk register information source, 56

tracking, 173–174

contingency responses, 203

continuity. See business continuity and disaster recovery (BCDR) management

contractors, tracking, 173–174

contractual requirements, 14–15

controls

analysis, 103–104

change and configuration management, 104

deficiency analysis overview, 30–31

design, 101–102

effectiveness evaluation, 31–34, 106

frameworks, 98–101

gaps, 34

key control indicators, 113

key performance indicators, 110–112

key risk indicators, 112–113

monitoring techniques, 109

overview, 93

ownership, 36, 82–83

recommendations, 34–35

reporting techniques, 109–110

security, 155–156

selecting, 102–103

standards, 96–101

testing, 104–106

types and functions, 93–96

corrective actions in root cause analysis, 37

corrective controls, 94–95

COSO (Committee of Sponsoring Organizations of the Treadway Commission), 163

cost

controls, 103

pressure on, 184

project management, 137–139

risk response options, 85

countermeasure controls, 96

critical processes risks, 143

criticality analysis (CA), 69–70

culture in organizational governance, 4

currency of technology in risk scenario development, 40

CVSS (Common Vulnerability Scoring System) score, 32

cyber insurance, 202

cybercrime, 183

cybersecurity risks, 23

D

dashboards for controls, 110

data

availability, 155

classification, 145–146, 156–157

collecting for assessment, 42–43

destruction policies, 147, 155

discovery, 42

retention policies, 146–147

sensitivity, 156–157

data governance risks, 24

data in motion, 131

data lifecycle management

overview, 144–145

standards and guidelines, 145–146

data processing in risk reporting, 108–109

databases

enterprise architecture, 130

networks, 130–131

risk analysis, 56

Delphi method, 66

denial of service, 155

design

controls, 101–102

SDLC phase, 149–150

destruction of data, 147, 155

detective controls, 94–95

deterrent controls, 94–95

development phase in SDLC, 150

differentiation step in root cause analysis, 37

direct marketing, privacy policies for, 172

discovery

data, 42

risk, 188–192

disposal

documents, 146

hardware, 147

SDLC phase, 151

distance risks in BCDR, 143

documents and documentation

classification, 145–146

control implementation, 104–105

disposal, 146

handling, retention, and storage, 146

reviews in IT risk assessment, 43

due care, 171

due diligence, 171

due process, 171

E

e-mail, 170–171

EF (exposure factor) in control selection, 103

effectiveness

controls, 102–103, 106

risk response options, 85

effort in KRIs, 112

electric generators, 70

emerging risk

managing, 90–93

technologies, 152–153

encryption for networks, 131

enhance responses, 203

enterprise architecture

cloud, 131

databases, 130

frameworks, 132–135

gateways, 132

networks, 130–131

operating systems, 130

overview, 128–129

platforms, 129

security architecture, 135

software, 129–130

enterprise risk management (ERM), 10–11

entity-level risk registers, 193

equipment

description, 7

recovery strategies, 141–142

returning in termination, 175

ERM (enterprise risk management), 10–11

ethics codes, 15, 174

evaluation

controls effectiveness, 31–34, 106

defined, 40–41

risk analysis, 59

event-tree analysis, 64–65

events

defined, 26

overview, 25–26

types, 28

vocabulary terms, 26–27

exception management, 89–90

exploits

description, 26

risk responses, 203

exposure factor (EF) in control selection, 103

external audits as risk register information source, 55

F

Factor Analysis of Information Risk (FAIR), 65

families, control, 97, 99

fault-event-tree analysis, 64–65

Federal Information Processing Standards (FIPS), 160

financial system asset inventory, 8

findings, managing, 89–90

FIPS (Federal Information Processing Standards), 160

five whys in root cause analysis, 37–38

formal risk register reviews, 195

frameworks

controls, 98–101

enterprise architecture, 132–135

information technology and security, 159

IT risk assessment, 45–51

risk management, 10–11

G

gap assessments, 41

gateways in enterprise architecture, 132

General Data Protection Regulation (GDPR), 171

geography issues

asset collection and organization, 9

business continuity and disaster recovery, 143

goals in organizational governance, 2–3

governance

assessments, 24

organizational. See organizational governance

overview, 1–2

questions, 17–20

review, 15–17

risk, 10–15

governance level in COBIT, 163–164

governance, risk, and compliance (GRC) tools, 53

government classified documents, 145–146, 157

guards, 168

guidelines for data lifecycle management, 145–146

H

hardware disposal, 147

Health Insurance Portability and Accountability Act (HIPAA)

controls requirements, 96

OCR involvement, 73

privacy issues, 171

heat maps for controls, 110

hiring employees, 173

human resources

codes of conduct and ethics, 174

hiring, 173

terminating, 174–175

tracking, 173–174

I

IaaS (Infrastructure as a Service), 131

identification

assets, 6–8

and authentication, 157

risk, 22–25

identification step in root cause analysis, 37

ignoring risk, 202

impact

business continuity and disaster recovery, 144

business impact analysis, 68–69

description, 26

key risk indicator criteria, 112

qualitative risk analysis, 190

risk analysis, 58–59

implement step in RMF, 161

implementation testing for controls, 104–105

incidents

new risk identification, 23

risk register information source, 55

indicators

key control, 113

key performance, 110–112

key risk, 112–113

industry development as risk register information source, 55

information assets, 7

information policies for privacy, 172

information sources for risk registers, 55–56

information technology and security

access control, 155–156, 167–168

accountability, 158

authorization, 157–158

business continuity and disaster recovery management, 140–144

confidentiality, integrity, and availability, 154–155

data lifecycle management, 144–147

data sensitivity and classification, 156–157

emerging technologies, 152–153

enterprise architecture. See enterprise architecture

frameworks, 159

human resources, 173–175

identification and authentication, 157

IT operations management, 135–137

network security, 168–172

non-repudiation, 158–159

overview, 127–128

physical access security, 168

project management, 137–140

questions, 178–182

review, 175–178

security and risk awareness training programs, 165–167

security concepts, 154

security policies, 167

standards, 159–165

systems development life cycle, 147–152

Information Technology Infrastructure Library (ITIL), 162–163

Infrastructure as a Service (IaaS), 131

inherent risk

description, 26

IT risk assessment, 71

innovation in cybercrime, 183

integrated risk management (IRM) tools, 53

integration testing in SDLC, 150

integrity, 155

intellectual property assets, 7

intent threat category, 30

intentional threats in BCDR, 143

interface testing in SDLC, 150

internal audits as risk register information source, 55

International Organization for Standardization (ISO) frameworks, 162

interoperability

controls, 105

emerging technologies, 153

interviews

asset identification, 8

hiring, 173

IT risk assessment, 43, 106

inventories

financial system assets, 8–9

key processes and systems, 67–68

IoT devices, 184

IRM (integrated risk management) tools, 53

ISACA

COBIT, 162–164

Code of Professional Ethics, 15

key risk indicators, 112–113

Risk IT Framework, 11–12, 49–51, 164–165

system testing, 45

ISO (International Organization for Standardization) frameworks, 162

ISO/IEC 27000, 162

ISO/IEC 27001, 100–101, 162

ISO/IEC 27002, 101, 162

ISO/IEC 27005, 49

ISO/IEC 27701, 162

ISO/IEC 31000, 162

ISO/IEC 31010, 49

ISO/IEC standards overview, 48–49

issues management, 89–90

IT equipment assets, 7

IT operations management, 135–137

IT risk assessment

analysis and evaluation overview, 40

business impact analysis, 66–70

concepts, 40–45

inherent and residual risk, 71–72

miscellaneous risk considerations, 72–73

overview, 21–22

questions, 75–79

review, 73–75

risk analysis methodologies, 56–66

risk events, 25–28

risk identification, 22–25

risk ownership, 51–52

risk ranking, 51

risk registers, 52–56

risk scenario development, 38–40

standards and frameworks, 45–51

threat landscape, 29–30

threat modeling, 28–30

vulnerability and control deficiency analysis, 30–38

IT systems portfolios for asset identification, 8

ITIL (Information Technology Infrastructure Library), 162–163

J

job rotation, 168

K

key control indicators (KCIs)

business processes, 6

controls, 113

key performance indicators (KPIs)

business processes, 6

controls, 110–112

key processes and systems inventories, 67

key risk indicators (KRIs)

business processes, 6

controls, 112–113

L

laws as risk register information source, 56

layers in risk registers, 193–194

least privilege principle, 157–158, 167

legal requirements, 14–15

legality issues in AUPs, 169

likelihood

description, 27

risk analysis, 58–59

Likert scale in qualitative risk analysis, 62

lines of defense, 12–13

logical controls, 94

loss event frequency in FAIR, 65

M

management buy-in for training programs, 166

management level in COBIT, 163–164

managerial controls, 94

mandatory vacations, 168

market factor risks in BCDR, 143

maturity assessments, 41

maximum tolerable downtime (MTD), 70

measurability of key performance indicators, 111

methods threat category, 30

military classified documents, 145–146

minutes, 187

mission risks in BCDR, 143

mitigation of risk

deeper analysis, 200

follow up, 204

process, 83–84

risk analysis, 58

monitor step in RMF, 162

monitoring

controls, 109

risk, 106–108

MTD (maximum tolerable downtime), 70

multifactor authentication, 157

N

National Institute of Standards and Technology (NIST)

business continuity and disaster recovery, 142

control effectiveness, 33–34

control framework, 98–99

control guidelines and standards, 96–98

quantitative risk analysis, 62–63

risk assessment guidelines, 45–47

Risk Management Framework, 11–12, 97, 160–162

Special Publication 800-17, 97

Special Publication 800-30

quantitative risk analysis, 62–63

risk assessment guidelines, 45–47

Special Publication 800-34, 142

Special Publication 800-37, 11–12

Special Publication 800-53, 33–34, 97–99, 161

Special Publication 800-60, 161

standards, 159–160

natural threats in BCDR, 143

NDAs (non-disclosure agreements), 173

need-to-know authorization, 158

network security

acceptable use policies, 169–170

due care, due diligence, and due process, 171

overview, 168

personal e-mail, 170–171

privacy, 171–172

social media, 170

networks

enterprise architecture, 130–131

new risk identification, 24

new risks, reporting, 203

news articles for risk identification, 23

NIST. See National Institute of Standards and Technology (NIST)

non-disclosure agreements (NDAs), 173

non-repudiation, 158–159

O

objectives in organizational governance, 2–3

objectives threat category, 30

observation in IT risk assessment, 43

OCR (Office of Civil Rights), 73

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) methodology, 47–48

Office of Civil Rights (OCR), 73

online data for asset identification, 8

operating systems in enterprise architecture, 130

operational controls, 32, 94

operational criticality in qualitative risk analysis method, 191

operational management, 12

operational risks, 23

Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) methodology, 47–48

organizational governance

assets, 6–10

business processes, 5–6

culture, 4

overview, 2

policies and standards, 5

strategy, goals, and objectives, 2–3

structure, roles, and responsibilities, 3–4

organizational units, asset organization by, 9

outsourcing risks in BCDR, 143

ownership of risk and control, 36, 51–52, 82–83

P

PaaS (Platform as a Service), 131

passive observation for new risk identification, 24

Payment Card Industry Data Security Standard (PCI DSS), 99–100

penetration tests

description, 41

new risk identification, 23

personal e-mail, 170–171

personally identifiable information (PII), 171

personnel assets, 7

PHI (protected health information), 73

physical access security, 168

physical controls, 32, 94

physical location risks in BCDR, 143

PII (personally identifiable information), 171

plan testing in BCDR, 142

planning phase in SDLC, 149

Platform as a Service (PaaS), 131

platforms in enterprise architecture, 129

PMBOK (Project Management Body of Knowledge), 162

policies

acceptable use, 169–170

access control, 167–168

organizational governance, 5

privacy, 171–172

retention and destruction, 146–147

security, 167

termination, 174–175

portfolios in project management, 137

practices, 160

preparation step in RMF, 160

preventive controls, 94–95

PRINCE2 (PRojects IN Controlled Environments 2), 163

prioritization, risk, 204

privacy

assessments, 24

network security, 171–172

risks, 23

private classified documents, 145–146

probability

description, 27

qualitative risk analysis method, 190–191

probable loss magnitude in FAIR, 65

processes

asset organization by, 9

organizational governance, 5–6

risk management programs, 187

professional ethics, 15

program charters, 186

program-level risk registers, 193

programs

project management, 137

risk management, 186–188

training, 165–167

project management, 137–140

Project Management Body of Knowledge (PMBOK), 162

PRojects IN Controlled Environments 2 (PRINCE2), 163

property assets, 7

protected health information (PHI), 73

protection issues in acceptable use policies, 169

public documents, 145–146

publishing, 203–204

Q

qualitative analysis method

deeper analysis, 198

risk analysis, 59–60, 62–63

risk management programs, 187

risk ratings, 190–192

quantitative analysis method

deeper analysis, 198

risk analysis, 59–63

risk management programs, 187

risk ratings, 192

R

ranking risk, 51

ratings

qualitative analysis, 190–192

quantitative analysis, 192

RCA (root cause analysis)

key risk indicators, 113

steps, 36–37

RE (Risk Evaluation) domain, 11, 49–51

real-time data, 108–109

recommendations for risk treatment, 199–203

records, 7

recovery objectives in business impact analysis, 70

recovery point objectives (RPOs), 60–61, 141

recovery strategies, 141–142

recovery time objectives (RTOs), 60–61, 141

regulations

asset organization by, 10

overview, 14–15

pressure on, 183–184

risk register information source, 56

relationship threat category, 30

relevancy

key performance indicators, 111–112

risk scenario development, 39

reliability in key risk indicators, 112

renewals, risk, 204

reporting, risk. See risk reporting

reputation assets, 8

requirements phase in SDLC, 149

residual risk

description, 27

IT risk assessment, 71–72

risk acceptance, 84

resilience in BCDR, 142

responsibilities in organizational governance, 3–4

results threat category, 30

retention

data, 146–147

documents, 146

retirement phase in SDLC, 151

return of identification in termination, 175

return on investment (ROI) in control recommendations, 35

reviewing risk registers, 194–196

risk

description, 26

emerging technologies, 152–153

SDLC, 151–152

risk acceptance, 84–85, 200–201

risk analysis, description, 27

risk analysis methodologies

asset identification, classification, and valuation, 58

bow-tie analyses, 65–66

Factor Analysis of Information Risk, 65

fault- and event-tree analysis, 64–65

likelihood determination and impact analysis, 58–59

miscellaneous, 66

overview, 56–58

qualitative analysis, 59

quantitative analysis, 59–62

risk appetite

deeper analysis, 198

description, 13–14

risk analysis, 58

risk assessments

description, 27

IT. See IT risk assessment

risk register information source, 55

risk avoidance, 202

risk-aware culture, 24

risk awareness training programs, 165–167

risk derivation in FAIR, 65

Risk Evaluation (RE) domain, 11, 49–51

risk events

overview, 25–26

types, 28

vocabulary terms, 26–27

risk factors

business continuity and disaster recovery, 142

emerging, 91–92

risk governance

enterprise risk management and risk management frameworks, 10–11

ISACA Risk IT Framework, 49

legal, regulatory, and contractual requirements, 14–15

lines of defense, 12–13

overview, 10

risk identification, 22–25

Risk IT Framework

key risk indicators, 112–113

overview, 164–165

process areas, 49–50

risk landscape, 178–182

risk management

description, 27

frameworks, 10–11

overview, 12–13

Risk Management Framework (RMF)

controls, 97–99

steps, 11–12, 160–162

risk management life cycle

deeper analysis, 196–198

publishing and reporting, 203–204

risk discovery, 188–192

risk registers, 193–196

risk treatment recommendations, 199–203

risk management programs

processes, 186–187

purpose, 187–188

risk managers, 194

risk mitigation

deeper analysis, 200

follow up, 204

process, 83–84

risk analysis methodology, 58

risk ownership

considerations, 36

IT risk assessment, 51–52

risk prioritization, 204

risk profiles

description, 13

ISACA Risk IT Framework, 50

risk ranking in IT risk assessment, 51

risk ratings

qualitative analysis, 190–192

quantitative analysis, 192

risk registers

columns, 189–190

data structures, 52–55

description, 27, 188

information sources, 55–56

layers, 193–194

managing, 192

reports, 203

reviewing, 194–196

types, 193

updating, 56

risk renewals, 204

risk reporting

controls, 109–110

data processing, 108–109

key control indicators, 113

key performance indicators, 110–112

key risk indicators, 112–113

monitoring techniques, 109

overview, 81–82, 106–108

questions, 119–125

review, 114–118

treatment plans, 108

risk response

acceptance, 84–85

avoidance, 85

control design. See controls

ISACA Risk IT Framework, 49

managing, 89–93

mitigation, 83–84

options, 83–86

overview, 81–82

ownership, 82–83

questions, 119–125

review, 114–118

sharing, 84

third-party risk, 86–88

risk reviews in reports, 203

risk scenario development

bottom-up, 39

considerations, 39–40

overview, 38

top-down, 38–39

risk tolerance

deeper analysis, 198

description, 13–14

risk analysis methodology, 58

risk transfer, 201–202

risk treatment

description, 27

recommendations, 199–203

reports, 203

RMF (Risk Management Framework)

controls, 97–99

steps, 11–12, 160–162

ROI (return on investment) in control recommendations, 35

roles in organizational governance, 3–4

root cause analysis (RCA)

key risk indicators, 113

steps, 36–37

RPOs (recovery point objectives), 60–61, 141

RTOs (recovery time objectives), 60–61, 141

S

S.M.A.R.T. guidelines, 111–112

SaaS (Software as a Service), 131

safeguard controls, 96

SANs (storage area networks), 70

SANS Top 20 Critical Security Controls, 100

scaling process in threat modeling, 29

scenario components in FAIR, 65

schedules in project management, 137–139

scope

assessment, 42

project management, 137–139

threat modeling, 29

scorecards for controls, 110

SDLC. See systems development life cycle (SDLC)

secure configuration assessments, 24

securing work area in termination, 174

security

emerging technologies, 153

policies, 167

tools, 185

training programs, 165–167

security advisories, 24

security architecture in enterprise architecture, 135

security concepts in information technology and security, 154

security controls, 155–156

security incidents

new risk identification, 23

privacy, 23

risk register information source, 55

security professionals shortage, 185

security scans for asset identification, 9

security testing in SDLC, 150

SEI (Software Engineering Institute), 47–48

select step in RMF, 161

semiquantitative values, 62

sensitivity

asset organization by, 9

data, 156–157

key risk indicators, 112

risk reporting information, 204

separation of duties principle, 148, 167

service level agreements (SLAs)

IT operations management, 136

third-party risk, 87

service providers, asset organization by, 9

sharing risk, 84

single-factor authentication, 157

single loss expectancy (SLE)

control selection factor, 103

quantitative risk analysis, 60–62

skills threat category, 30

SLAs (service level agreements)

IT operations management, 136

third-party risk, 87

SLE (single loss expectancy)

control selection factor, 103

quantitative risk analysis, 60–62

social media

policies, 170

risk identification, 23

Software as a Service (SaaS), 131

Software Engineering Institute (SEI), 47–48

software in enterprise architecture, 129–130

specificity in key performance indicators, 111

staff

project management, 138

risk register reviews with, 195

stakeholders in risk environment, 106–107

standards

controls, 96–101

data lifecycle management, 145–146

information technology and security, 159–165

IT risk assessment, 45–51

NIST. See National Institute of Standards and Technology (NIST)

organizational governance, 5

statements of impact in business impact analysis, 68–69

storage area networks (SANs), 70

storage of documents, 146

strategic risks, 22

strategies

organizational governance, 2–3

recovery, 141–142

structure in organizational governance, 3–4

supply chain risks, 23

suspension of accounts, 175

systems

IT risk assessment, 43–44

testing, 44–45

systems development life cycle (SDLC)

design phase, 149–150

development phase, 150

disposal phase, 151

implementation and operation, 150

overview, 147–148

planning phase, 149

requirements phase, 149

risks, 151–152

separation of duties, 148

test phase, 150

T

tailgating, 168

technical controls, 32, 94

technical data, 108–109

technologies, emerging, 91

telework, 184

temps, tracking, 173–174

termination, employee, 174–175

testing

controls, 104–106

penetration, 23, 41

recovery plans, 142

SDLC, 150

system, 44–45

The Open Group Architecture Framework (TOGAF)

COBIT, 162

enterprise architecture, 132–133

third-party risk

business continuity and disaster recovery, 143

factors, 87

managing, 88

overview, 86–87

threats, 88

vulnerabilities, 88

threat actors, 26

threat intelligence as risk register information source, 55

threat landscape, 29–30

threat modeling

description, 26, 41

new risk identification, 24

overview, 28–30

threat realization, 26

threats

business continuity and disaster recovery, 143

criticality analysis, 69

description, 26

emerging, 92, 153

IT operations management, 136–137

project management, 138–140

risk analysis, 56

third-party, 88

time sensitivity risks in BCDR, 143

timeliness in key performance indicators, 111–112

TOGAF (The Open Group Architecture Framework)

COBIT, 162

enterprise architecture, 132–133

Top 20 Critical Security Controls, 100

top-down risk scenario development, 38–39

tracking employees, 173–174

training

project management, 138

security and risk awareness programs, 165–167

treatments

options, 198

plans, 108

recommendations, 199–203

reports, 203

trends in risk registers, 203

triage apparatus

qualitative risk analysis, 192

risk management programs as, 187

U

unintentional threats in BCDR, 143

uninterruptible power supplies (UPSs), 70

uniqueness issues in AUPs, 169

unit testing in SDLC, 150

updating risk registers, 56

UPSs (uninterruptible power supplies), 70

user acceptance testing in SDLC, 150

V

vacations, mandatory, 168

validation of data, 108–109

valuation of assets, 58

virtual assets, 7

vocabulary terms for risk, 26–27

vulnerabilities

business continuity and disaster recovery, 144

description, 26

emerging technologies, 92–93, 153

IT operations management, 137

project management, 139–140

risk analysis, 56

SDLC, 152

third-party risk, 88

vulnerability and control deficiency analysis

control effectiveness, 31–34

control gaps, 34

control recommendations, 34–35

overview, 30–31

risk and control ownership, 36

root cause analysis, 36–37

vulnerability assessments

description, 41

risk register information source, 55

W

walkthroughs in IT risk assessment, 43

whistleblowers for new risk identification, 24

work breakdown structures (WBSs), 139

worksheets, analysis, 197–198

X

XaaS (Anything as a Service), 131

Z

Zachman framework, 133–135