Professional Documents
Culture Documents
CISM Certified Information Security Manager All in One Exam Guide Second Edition 2nd Edition
CISM Certified Information Security Manager All in One Exam Guide Second Edition 2nd Edition
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-426832-0
MHID: 1-26-426832-7
The material in this eBook also appears in the print version of this title:
ISBN: 978-1-26-426831-3, MHID: 1-26-426831-9.
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.
TERMS OF USE
Peter is the author of more than 50 books about information security and
technology, including Solaris Security, CIPM Certified Information Privacy
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)² Security Congress, ISACA
CACS, SecureWorld Expo, West Coast Security Forum, IP3, Source
Conference, Society for Information Management, the Washington
Technology Industry Association, and InfraGard. Interviews of Peter appear
in SC Magazine, U.S. News & World Report, CNET News, SearchSecurity,
Information Security Magazine, CIO, The Seattle Times, and Forbes.
Peter resides with his family in Washington state and can be found
online at www.peterhgregory.com.
Jay has worked with customers of different sizes and types to build,
enhance, and manage best-in-class cybersecurity programs. As an
executive-level security professional, he has led detailed maturity
assessments and facilitated executive workshops to assist CISOs in
maturing their cybersecurity programs. His practical experience includes
engagements addressing strategic consulting, project management,
regulatory compliance (Sarbanes–Oxley, PCI, NERC CIP, HIPAA, SOC 1
and SOC 2), and cybersecurity program development leveraging ISO
27001/2, NIST 800-53, Cloud Security Alliance CCM, Shared Assessments
SIG, and Unified Compliance Framework.
Jay currently serves as the strategic service manager for Tenable, helping
customers gain visibility of cyber risk by leveraging the Tenable Cyber
Exposure platform while also providing the executive suite and board of
directors with insight to focus on the issues that matter most and make
better strategic decisions. Additionally, Jay is a partner at Sage Advisory,
LLC, which helps young professionals find their voice in the workplace and
supports the SMB market in the cybersecurity space.
Disclaimer
Enterprise Governance
Incident Management
Glossary
Index
CONTENTS
Acknowledgments
Introduction
Enterprise Governance
usiness Alignment
rganizational Culture
thics
oard of Directors
xecutive Management
ustodial Responsibilities
oftware Development
ata Management
etwork Management
ystems Management
T Operations
ecurity Operations
ecurity Audit
ervice Desk
uality Assurance
ther Roles
eneral Staff
Monitoring Responsibilities
hapter Review
otes
uestions
nswers
trategy Objectives
trategy Participants
trategy Resources
trategy Development
trategy Constraints
he Zachman Framework
SO/IEC 27001
trategic Planning
oadmap Development
hapter Review
otes
uestions
nswers
isk Objectives
hreat Identification
isk Identification
he Risk Register
hapter Review
otes
uestions
nswers
isk Mitigation
isk Transfer
isk Avoidance
isk Acceptance
esidual Risk
he Risk Register
isk Ownership
ontrol Ownership
ey Risk Indicators
isk Documentation
hapter Review
otes
uestions
nswers
rends
utcomes
harter
cope
sset Valuation
ontrol Frameworks
olicy Development
tandards
uidelines
equirements
ypes of Metrics
udiences
he Security Balanced Scorecard
hapter Review
otes
uestions
nswers
ontrol Classification
ontrol Objectives
ontrol Frameworks
ontrols Development
ontrol Implementation
ecurity and Control Operations
ontrol Monitoring
enefits of Outsourcing
isks of Outsourcing
ecurity Incidents
ecurity Operations
isk Management
nternal Partnerships
xternal Partnerships
ompliance Management
echnical Architecture
ersonnel Management
T Service Management
ervice Desk
ncident Management
roblem Management
hange Management
onfiguration Management
elease Management
ervice-Level Management
nancial Management
apacity Management
vailability Management
sset Management
ontinuous Improvement
hapter Review
otes
uestions
nswers
Incident Management
tatements of Impact
riticality Analysis
ecovery Objectives
ncident Classification/Categorization
otes
uestions
nswers
ncident Detection
ncident Initiation
ncident Analysis
ncident Eradication
ncident Recovery
ncident Remediation
losure
ost-incident Review
hapter Review
otes
uestions
nswers
rivacy Notice
otalTester Online
echnical Support
Glossary
Index
Figure Credits
gure 2-2 Adapted from the Business Model for Information Security,
ISACA.
Many thanks to Patty Mon, Nitesh Sharma, and Thomas Somers for
managing the editorial and production ends of the project, and to Lisa
Theobald for copy editing the book and further improving readability. I
appreciate KnowledgeWorks Global Ltd. for expertly laying out the final
manuscript pages. Also, thanks to Rick Camp and Lisa McCoy for expert
proofreading and Ted Laux for indexing. Like stage performers, they make
hard work look easy, and I appreciate their skills.
This is the 52nd book manuscript I have written since I started writing in
1998. I’m grateful for those who initially brought me into the publishing
business, particularly Liz Suto (author of Informix Online Performance
Tuning, and my first official gig as a tech editor) and Greg Doench
(executive editor at Prentice-Hall Publishers), and so many more along the
way, including Melody Layne, Mark Taub, Rev Mengle, Sebastian Nokes,
Greg Croy, Katie Feltman, Katie Mohr, Lindsey Lefevere, Josh Freel, Amy
Fandrei, Amy Gray, Tim Green, Steve Helba, and many others. Thank you,
all of you, for the splendid opportunity that has enabled me to help so many
readers.
I have difficulty putting into words my gratitude for my wife and love of
my life, 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.
INTRODUCTION
Let’s get the obvious out of the way: This is a comprehensive study guide
for the security management professional who needs a serious reference for
individual or group-led study for the Certified Information Security
Manager (CISM) certification. The content in this book contains the
technical information that CISM candidates are required to know. This book
is one source of information to help you prepare for the CISM exam, but it
should not be thought of as the ultimate collection of all the knowledge and
experience that ISACA expects qualified CISM candidates to possess. No
single publication covers all of this information.
This book covers everything you’ll need to know for ISACA’s CISM
certification examination. Each chapter covers specific objectives and
details for the exam, as ISACA defines in its job practice areas. The
chapters and their sections correspond precisely to the CISM job practice
that ISACA updates from time to time, most recently in mid-2022.
The topics covered in each chapter are listed in the first section to help map
out your study.
Tips in each chapter offer great information about how the concepts you’re
reading about apply in a place I like to call “the real world.” Often, they
may give you more information on a topic covered in the text.
Exam Tips are included to highlight areas you need to focus on for the
exam. They won’t give you any exam answers, but they help you know
about important topics you may see on the test.
The new CISM job practice information was made available in March
2022. We began work at that time to update the second edition manuscript.
This has been updated to reflect all of the changes in the CISM job practice
and changes in information security and information technology since the
first edition was published.
For the 2022 CISM job practice, ISACA reformatted how the practice areas
are described. Previously, each job practice had a set of Knowledge
Statements and Task Statements. In the 2022 model, each job practice
consists of two major categories with three to six subtopic areas each. This
is followed by 37 Supporting Tasks for CISM that are not specifically
associated with the four domains. Table 1 illustrates each previous and
current CISM job practice and its corresponding chapters in this book,
along with the structure of the new job practice and coverage in this book.
As is typical for each new job practice and revision of this CISM
Certified Information Security Manager All-in-One Exam Guide, I
performed a gap analysis to understand what subject matter was added to
the new job practice and what was eliminated. My conclusion: ISACA
made no significant additions or changes to the CISM 2022 job practice
besides numerous structural changes and changes in the weighting between
domains.
Several topics are new or expanded from the first edition, including the
following:
Crosswalks
Data debt
Data governance
Distributed workforce
Groupthink
Information governance
Passwordless authentication
Personnel classification
Reference architectures
Technical debt
To become a CISM professional, you must 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 CISM certification, you
must 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.
Education Those who are certified must adhere to the CISM 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 each three-year certification period.
Experience Requirements
To qualify for CISM certification, you must have completed the equivalent
of five years of total work experience in information security management.
Additional details on the minimum certification requirements, substitution
options, and various examples are discussed next.
You must have a minimum of five years of work experience in the field of
information security management. This is equivalent to roughly 10,000
actual work hours, which must be related to three or more of the CISM job
practice areas, as follows:
Substitution of Experience
Two Years
Two years of direct experience They can count their two full years of
information security management experience in 2015 and 2016.
One-year substitution They cannot take into account one year of IT
management experience completed between January 2002 to January 2007,
because it was not completed within ten years of their application.
The candidate would need to send the following with their application to
prove the experience requirements are met:
TIP Read the CISM certification qualifications on the ISACA web site.
ISACA changes the qualification rules from time to time, and I want you to
have the most up-to-date information available.
Perform their duties with objectivity, due diligence, and professional care,
in accordance with professional standards.
You can find the full text and terms of enforcement of the ISACA Code
of Ethics at www.isaca.org/ethics.
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 asked to turn in
your smartphone, wallet or purse, and other personal items for safekeeping.
The exam proctor will read aloud the rules you must follow while taking the
exam. These rules will address matters such as breaks, drinking water, and
snacks. While you take the exam, you will be supervised by the proctor,
who may monitor you and your fellow test-takers by video surveillance in
the test center to ensure that no one can cheat.
If you have registered for a remote proctored exam, you must meet all of
the technical requirements. ISACA has published the “Remote Proctoring
Guide” that includes all of 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 while you take the exam to ensure you are
not cheating through the use of reference materials (books or online). You
will also be required to use your webcam to show the entire room to your
proctor, to demonstrate that 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 (such as Brave, SRware Iron) browser, a webcam with at least
640×480 resolution, a microphone, and a stable broadband Internet
connection. You must be able to install the PSI Secure Browser and modify
firewalls and other administrative tasks on the day of the exam (this
requires administrative privileges on the computer you are using, which
might be a problem if you are using a company-issued computer).
You are not permitted to speak or perform gestures during the exam. In
short, you cannot be seen to perform any action that may be an indication of
aid by an accomplice.
Exam Questions
Each registrant has four hours to take the exam, with 150 multiple-choice
questions representing the four job practice areas. Each question has four
answer choices; you must select only one best answer. You can skip
questions and return to them later, and you can also flag questions 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’ll be directed to close the
exam. At that time, the exam will display your pass or fail status, reminding
you 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; a final score of 450 is
required to pass.
Exam questions are derived from a job practice analysis study conducted
by ISACA. The selected areas represent tasks performed in a CISM’s day-
to-day activities and 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
www.isaca.org/credentialing/cism/cism-exam-content-outline.
Exam Coverage
The CISM exam is quite broad in its scope. It covers four job practice areas,
as shown in Table 2.
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, go to www.isaca.org/credentialing/exam-
candidate-guides and select the guide in your language of choice.
Register If you can, 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 then commit.
Become familiar with the CISM job practice areas The job practice
areas serve as the basis for the exam and requirements. Beginning with the
2022 exam, the job practice areas have changed. Ensure that your study
materials align with the current list at www.isaca.org/credentialing/cism.
Download and study the ISACA Glossary It’s important for you to be
familiar with ISACA’s vocabulary, which you can download from
www.isaca.org/resources/glossary.
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.
Avoid cramming We’ve all seen the books on the shelves with titles that
involve last-minute cramming. The Internet reveals various web sites that
teach individuals how to cram for exams. 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, I 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 web site. And use your
local network to find out whether there are other local study groups and
helpful resources.
Logistics check Check the candidate 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 to look at the
schedule for the day of the exam: if your CISM exam is 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 The night before, 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. Leave behind food,
drinks, laptops, cell phones, and other electronic devices, because they are
not permitted at the test site. For information on what can and cannot be
brought to the exam site, see the CISM exam candidate guide at
www.isaca.org/credentialing/cism.
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 exam date with the results.
Sleep Make sure you get a good night’s sleep before the exam. Research
suggests that you 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.
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 during the exam and are unsure about the rules, be sure to
ask first. For information on conduct during the exam, see the ISACA
Exam Candidate Information Guide at www.isaca.org/credentialing/exam-
candidate-guides.
Answer all exam questions Read questions carefully, but do not try to
overanalyze. Remember to select the best solution based upon the CISM
Job Practice and ISACA’s vocabulary. There may be several reasonable
answers, but one is better than the others. If you aren’t sure about an
answer, mark the question, so that after working through all the questions,
you can return to any 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; there is
plenty of time to take as much as a few minutes for each question. But at
the same time, do watch the clock so that you don’t find yourself going so
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, observe any remarks about
your status; you will be able to retake the exam—you’ll find information
about this on the ISACA web site.
Don’t lose heart if you do 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. Be honest about areas where
you need to learn more. Then reread the chapters or sections and return to
this book’s practice exams. If you participated in a study group or training,
contact your study group coach or class instructor if you believe you may
get advice about 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,
and then give it another go. Success is granted to those who are persistent
and determined.
NOTE You are not permitted to display the CISM moniker until you have
completed certification. Passing the exam is not sufficient to use the CISM
anywhere, including e-mail, résumés, correspondence, or social media.
You must submit evidence of a passing score and related work experience
to apply for certification. Remember that you have five years to apply for
CISM certification after you receive a passing exam score. After this time,
you will need to retake the exam before you can apply. In addition, all work
experience submitted must have occurred within ten years of your new
certification application.
CISM application Note the exam ID number in your exam results letter,
list the information security management experience and any experience
substitutions, and identify which CISM job practice area (or areas) your
experience pertains to.
Continuing Education
For training and activities to be utilized for CPEs, they must involve
technical or managerial training directly applicable to information security
and information security management. The following activities have been
approved by the CISM certification committee and can count toward your
CPE requirements:
Self-study courses
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 include the following:
Name of attendee
Activity title
Activity description
Activity date
Number of CPE hours awarded
For new CISMs, the annual and three-year certification period begins on
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. You will receive an e-mail directing you to
the web site to enter CPEs earned over 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. If ISACA has
questions about your submitted information, you will be contacted directly.
To remain CISM certified, you must pay CPE maintenance fees each year.
These annual fees are (as of 2022) $45 for members and $85 for
nonmembers. The fees do not include ISACA membership and local
chapter dues (neither is required to maintain your CISM certification). More
information is available from www.isaca.org/credentialing/cism/maintain-
cism-certification.
Revocation of Certification
Failure to comply with the Code of Professional Ethics, which can result in
investigation and ultimately lead to revocation of certification
ISACA has more than 200 chapters in about 100 countries around the
world. Chances are there is a chapter near you. I attended many ISACA
chapter meetings and other events in Seattle when I lived there, where
engaging speakers spoke on new topics, and I 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. Some chapters have various programs, events, study
groups, and other activities that enrich participants professionally. Most of
my ISACA experiences happen in my local chapter.
If you are at the point in your career where you qualify for and have a
reasonable prospect of passing the CISM exam, chances are you have had a
mentor or two earlier, 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 ask if you would consider mentoring him or her. 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. Mentoring will enrich your life as well.
Volunteer
Please take a minute to reflect upon 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 helps others and enriches you. Will you consider leaving your
mark and making ISACA better than you found it? For more information
about these and many other volunteer opportunities, visit
www.isaca.org/why-isaca/participate-and-volunteer.
Although this may not immediately make sense to you, know this:
helping others, whether through any of the volunteer opportunities listed
here, or in other ways, will enrich you personally and professionally. I’m
not talking about feathers in your cap or juicy items in 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
Enterprise Governance
Organizational culture
Supporting Tasks in the CISM job practice that align with the
Information Security Governance / Enterprise Governance domain include:
Policy At its minimum, security policy should directly reflect the mission,
objectives, and goals of the overall organization.
Priorities The priorities in the security program should flow directly from
the organization’s mission, objectives, and goals. Whatever is most
important to the organization should also be essential to information
security.
These and other governance activities are carried out through scripted
interactions among key business and IT executives at regular intervals.
Meetings will include a discussion of the impact of regulatory changes,
alignment with business objectives, effectiveness of measurements, recent
incidents, recent audits, and risk assessments. Other discussions may
include changes to the business, recent business results, and any anticipated
business events such as mergers or acquisitions.
Business Alignment
An organization’s information security program needs to fit into the rest of
the organization. This means that the program needs to understand and align
with the organization’s highest-level guiding principles, including the
following:
Mission Why does the organization exist? Who does it serve and through
what products and services?
Goals and objectives What goals does the organization hope to achieve,
and when does it want to accomplish them?
Asset value Assets are information the organization uses to operate. They
often consist of intellectual property such as designs, source code,
production costs, pricing, sensitive information related to personnel and
customers, information-processing infrastructure, and service functions.
Risk tolerance Risk tolerance for the organization’s information security
program needs to align with the organization’s overall tolerance for risk.
Legal obligations What external laws and regulations govern what the
organization does and how it operates? These laws and regulations include
the Gramm-Leach-Bliley Act (GLBA), Payment Card Industry Data
Security Standard (PCI DSS), European General Data Protection
Regulation (GDPR), the California Consumer Privacy Act (CCPA), the
Health Insurance Portability and Accountability Act (HIPAA), and the
North American Electric Reliability Corporation (NERC) standard. Also,
contractual obligations with other parties often shape the organization’s
behaviors and practices.
Each organization has a particular appetite for risk, although few have
documented that appetite. ISACA defines risk appetite as the level of risk
that an organization is willing to accept while pursuing its mission, strategy,
and objectives before taking action to treat the risk. This topic is discussed
fully in Chapter 4.
Organizational Culture
The way an organization’s leaders treat one another and the rest of the
organization’s employees 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.
Every organization also has a risk culture, which affects how the
organization deals with risk and how it treats risk over time. 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 essentially comprises 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. As
discussed, risk tolerance and risk appetite support the organizational risk
culture.
Often, an acceptable use policy serves as the body of security policy that
is applicable to all of an organization’s workers. A more specific security
policy that defines acceptable uses for access control, encryption, and other
measures is generally intended for information workers designing,
implementing, and operating information systems. Security policy is
discussed fully in Chapter 5.
Ethics
How the business is organized can help drive how it deals with
cybersecurity. Most companies are managed from a functional perspective;
in other words, departments and other hierarchical structures are established
to take care of specific functions that contribute to business goals and
objectives. For example, a production-driven business may have a
manufacturing or production department, an engineering department, a
research and development department, and an assembly line. Additional
departments may also cover support functions such as marketing,
accounting and finance, public relations, and so on. On the other hand, a
hospital 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 are found in any business, such as
information technology, information security, privacy, and legal
compliance. Each functional area has a primary mission and function, 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 cybersecurity.
Each unit, whether in the lower levels of the business hierarchy or at the
highest levels, should be aware of, and responsible for, its impact on
information protection and cybersecurity at its level. This innate
responsibility originates from the well-known phrase, “information security
is everyone’s responsibility.” Beyond an awareness of how a worker
handles files on a laptop with tools such as e-mail and cloud storage,
“information security is everyone’s responsibility” covers everything,
including the following:
Organizational Roles
IT auditor
Systems engineer
Individual contributor
Supervisor
Manager
Senior manager
Director
Senior director
Executive director
Vice president
Senior vice president
President
RACI CHARTS
Responsible The person or group that performs the actual work or task.
Board of Directors
In many cases, board members have fiduciary duty. This means they are
accountable to shareholders or constituents to act in the organization’s best
interests with no appearance of impropriety, conflict of interest, or ill-gotten
profit resulting from their actions.
Board members may also be selected for any of the following reasons:
Boards of directors are generally expected to require that the CEO and
other executives implement a corporate governance function to ensure that
executive management has an appropriate level of visibility and control
over the organization’s operations. Executives are accountable to the board
of directors to demonstrate that they effectively carry out the board’s
strategies.
Many, if not most, organizations are highly dependent upon IT for their
daily operations. As a result, information security is an important topic for
boards of directors. Today’s standard of due care for corporate boards
requires that they include information security considerations in the
strategies they develop and the oversight they exert on the organization.
Most boards of directors now include subcommittees that focus on risk and
information security.
Executive Management
Custodial Responsibilities
Chief risk officer (CRO) This position is responsible for all aspects of
risk, including information, business, compliance, and market risk. This
role is separate from IT. Note that some organizations have a chief revenue
officer (also CRO); ensure that you understand how the organization
structures its leadership roles.
The one arena where a CISO may not be required is in small to medium-
sized organizations where a full-time strategic leader may not be cost
effective. It is advisable to contract with a virtual CISO (vCISO) to assist
with strategy and planning. When organizations do not require or cannot
afford a full-time person, this approach enables the organization to benefit
from the knowledge of a seasoned security professional to assist in driving
the information security program forward. This book’s technical editor and
I have served organizations in this capacity for several years.
The CPO is sometimes seen as a customer advocate, and often this is the
role of the CPO, particularly when regulations require a privacy officer.
Software Development
Data Management
Database analyst This person performs tasks that are junior to the
database administrator, carrying out routine data maintenance and
monitoring tasks.
EXAM TIP The roles of data manager, database architect, big data
architect, database administrator, database analyst, and data scientist are
distinct from data owners. Don’t confuse them on the exam. The former are
IT department roles for managing data models and data technology,
whereas the latter (data owner) governs the business use of and access to
data in information systems.
Network Management
Positions in network management are responsible for designing, building,
monitoring, and maintaining voice and data communications networks,
including connections to outside business partners and the Internet.
Network architect This position designs data and voice networks and
designs changes and upgrades to networks to meet new organization
objectives.
Systems Management
IT Operations
When cloud development and operations are more common, the word
“cloud” may eventually disappear from these and other job titles.
Governance, Risk, and Compliance
Business Resilience
Security Audit
Positions in security audit are responsible for examining process design and
verifying the effectiveness of security controls.
Service Desk
Positions at the service desk are responsible for providing frontline support
services to IT and IT customers.
Service desk manager This position serves as a liaison between end users
and the IT service desk department.
Quality Assurance
Other Roles
General Staff
The rank and file in an organization may or may not have explicit
information security responsibilities, as determined by executive
management’s understanding of the broad capabilities of information
systems and the personnel who use them.
Monitoring Responsibilities
Chapter Review
The chief privacy officer is responsible for the protection and proper use
of sensitive personal information (often referred to as personally
identifiable information). The CPO’s information protection responsibilities
are sometimes shared with the CISO, who has overall information
protection responsibilities. The chief compliance officer is responsible for a
broad range of compliance tracking and reporting.
While security steering committees are not required, organizations may find
it helpful to implement single-level or multilevel security steering groups as
a cross-functional vehicle for discovering security risks and disseminating
security organization.
Questions
External
Internal
Regulatory
Professional
Organizational strategy
External governance
Organizational policy
Published values
Policies
Leadership behavior
Behavioral norms
Business leader
Information security
Control owner
Internal audit
Security policy
IT policy
Security strategy
Board of directors
Which of the following people is/are responsible for ensuring that PII is not
used improperly?
Asset owner
All employees
Applicable laws
Non-applicable laws
Employee handbook
Privacy policy
Code of conduct
Answers
Business alignment
Supporting Tasks in the CISM job practice that align with the
Information Security Governance / Information Security Strategy domain
include:
Identify internal and external influences to the organization that impact the
information security strategy.
Strategy Objectives
Business alignment The desired future state, and the strategy to get there,
must be in alignment with the organization and its strategy and objectives.
Rank and file Many individual contributors will have key knowledge and
valuable insight that will enable the security leader (and team) to craft an
effective strategy for the program. The security leader’s challenge is to
identify those individuals and collaborate with them to understand their
perspectives on information security.
Strategy Resources
Before a strategy can be developed, it is first necessary to understand
everything that is in place currently. A strategy describes how goals and
objectives are to be met. Without knowing the starting place of a journey, it
is not possible to chart a course to the journey’s destination. Before future
security capabilities can be mapped out, it’s necessary to understand an
organization’s current state and capabilities. The differences can be seen as
a gap that needs to be filled, whether that means employing tools,
technologies, skills, policies, or practices.
Two types of inputs must be considered: those that will influence the
development of strategic objectives, and those that define the current state
of the security program and protective controls. The following inputs must
be considered before objectives are developed:
Risk assessments
Threat assessments
When suitable risk and threat assessments have been completed, the
security strategist can then develop strategic objectives, or, if they have
been created already, validate that the established strategic objectives will
satisfactorily address risks and threats identified in those assessments.
Next, security strategists can examine several other inputs that help them
understand the workings of the current security program, including the
following:
Risk assessments
Threat assessments
Policy
Standards
Guidelines
Architecture
Controls
Skills
Metrics
Assets
Risk register
Vulnerability assessments
Insurance
Critical data
Outsourced services
Audits
Culture
Maturity
Risk appetite
Risk Assessments
Any historical record of risk assessments may give the strategist a better
idea of the maturity of the organization’s security program, as well as an
indication of whether risks in the past had been mitigated. If older risk
assessments indicate significant risks that are still present in newer risk
assessments, or if risk assessments are performed only for compliance
purposes and not for making actual improvements in the organization’s
security posture, you could wonder whether the organization places much
credence in those risk assessments.
The strategist should also request corporate risk assessments to feed into
the strategy; many times, IT risk assessments are technology focused. By
reviewing and using the corporate risk assessment, the strategist can better
align the security strategy with the organization’s business objectives.
Threat Assessments
Strategists should have a threat assessment performed so that they can
better understand relevant threats. This assessment provides the strategist
with information about the types of threats most likely to have an impact on
the organization, regardless of the effectiveness of controls.
Policy
An organization’s security policy, as well as its practices in relation to its
policy, may say a great deal about its desired current state. Security policy
can be thought of as an organization’s internal laws and regulations with
regard to the protection of important assets (as well as personnel safety).
Examination of current security policy can reveal a lot about what
behaviors are required in the organization.
Breadth of coverage What subject areas are covered by the policy? Does
it include expected computer and mobile device usage behavior? Are other
topics such as vulnerability management, third-party risk, or software
development included in security policy?
Standards
Guidelines
While an organization’s guidelines are not “the law” per se, the presence of
guidelines may signal higher than average organizational maturity. Many
organizations don’t go beyond creating policies and standards, so the
presence of proper guidelines means that the organization may have (or had
in the past) sufficient resources or prioritization to make documenting
guidance on policies important enough to do.
Architecture
Although it’s good to look for and examine network diagrams, system
diagrams, data flow diagrams, and so forth, it’s nearly as valuable to find
good and consistent designs even if they aren’t documented anywhere. I’d
rather see an organization’s infrastructure as modern, effective, and
consistent versus a collection of outdated diagrams or, worse yet,
inconsistent uses of technologies and techniques throughout an
organization. Whether or not architecture diagrams exist is a concern that is
similar to that regarding policies, standards, guidelines, and other artifacts.
Controls
Internal and external audits, discussed later in the “Audits” section, are
another way to understand control effectiveness.
A strategist will want to understand whether the controls in place are part
of a control framework such as COBIT, ISO/IEC 27002, NIST SP 800-53,
NIST SP 800-171, HIPAA, or PCI DSS. But more than that, the strategist
should know whether all controls in the control framework are implemented
—or have some been omitted? The reason for omission may vary from
irrelevance to irresponsible avoidance.
Finally, the strategist should look for additional controls that have been
implemented. This may be a sign of regulatory requirements or the result of
an effective risk management program, where identified risks compelled
management to enact additional controls to mitigate risk.
Skills
Metrics
If metrics are properly established, they’ll serve as a guide for the long-
term effectiveness of security controls. This helps the strategist understand
what works well and where improvement opportunities may be. The
strategist can then design end states with more certainty and confidence
than if metrics didn’t exist.
Risk Register
A risk register, also known as a risk ledger, can offer the strategist a great
deal of insight into risk management and risk analysis activities in the
organization. Depending on the detail available in the risk register a
strategist may be able to discern the following:
Security incidents
A risk register is the business record reflecting the history and findings
from risk assessments, threat assessments, vulnerability assessments,
security incidents, and other activities. Its content reflects the types of
activities occurring in the information security program and the significant
results of those activities.
The lack of a risk register would indicate that the organization’s security
management program is not taking a risk-based approach. Instead, the
organization may be compliance-based or, worse yet, asset-based or ad hoc.
These approaches are signs of lower maturity, where the organization’s
security personnel are mainly reactive and do little planning.
Vulnerability Assessments
Insurance
The security strategist may want to know whether the organization has
cybersecurity insurance or any general insurance policy that covers some
types of cyber events and incidents. As important as having cyber insurance
is, equally important is the reason the organization purchased it. A strategist
will want to explore possible reasons.
Critical Data
Though this section is not about the cloud and cloud services, the
existence and ease of use of cloud services make it easy for individuals and
groups in an organization to upload critical data to these services. The fact
that many cloud-based services offer low-cost and zero-cost services
encourages this phenomenon all the more. This has given rise to the
colloquial phrase “bring your own app” (BYOA) to describe this growing
problem. Most organizations have lost sight of all the locations and uses of
their critical data, whether sanctioned or not.
The cloud, BYOA, and BYOD underscore the lack of visibility and
control over critical and sensitive data. Understanding this is important for
strategists when determining the current state of security, which, as stated,
is required if a viable strategy is to be developed to take the organization to
a desired future state. This is one of many categories where a strategist will
be unable to gather all desired facts about the state of security and where
experience and judgment are required to discern the state of data
management.
The BIA is also useful for information security professionals aside from
business continuity purposes. Again, the BIA indicates the most critical
processes (and underlying resources such as information systems and other
IT infrastructure), giving the security strategist a better idea of which
business processes and systems warrant the greatest protection.
Outsourced Services
Site visit The organization may elect to visit one or more of the service
provider’s processing sites and perhaps corporate offices.
“Turtles all the way down” refers to an idea that the flat earth rests on the
back of a giant turtle, which itself rests on the back of an even larger turtle,
which rests on a still larger turtle, and so on, forever. This is a mythological
way of explaining infinite regress. Third-party risk management can be
likened to the epistemological stack of world turtles, in that each
organization obtains goods and services from other organizations, those
organizations depend on others, and so on, with no apparent end. All
organizations are at least partly dependent upon others for goods or services
essential for delivering goods or services to their customers.
So where does it all end? Depending upon the industry and the criticality
of individual goods or services, third-party risk management generally vets
critical vendors and determines whether those vendors have effective third-
party risk management programs.
Audits
Internal and external audits can tell the strategist quite a bit about the state
of the organization’s security program. A careful examination of audit
findings can potentially provide significant details on control effectiveness,
vulnerabilities, disaster preparedness, or other aspects of the program—
depending on the objectives of those audits.
Objective The objective or purpose of the audit tells the reader why the
audit took place. This often provides additional insight into why certain
people, processes, or technologies were examined while others were
apparently omitted. For example, was an audit performed because it is
required by regulation or another requirement, or was it performed
voluntarily as another means of organization improvement?
Scope The scope of an audit tells the reader which technologies, business
processes, business locations, or other aspects of the organization were
examined.
The security strategist needs to consider the bigger picture: mainly, is the
organization using audit results to drive improvements in the organization,
or are audit reports merely shelfware shown to regulators on their annual
visit?
Culture
The culture of an organization can tell the strategist a lot about the state of
security. Many people mistakenly believe that information security is all
about technology. While technology is part of security, the most important
aspect of information security is people. No amount of technology can
adequately compensate for a person’s wrong attitude and understanding
about protecting an organization’s information assets. People are absolutely
key.
Accountability The strategist will look for evidence that the organization
enforces company policies and requires employees to be accountable for
violations. Equally important is the observation of outcomes of bad
decisions—are decision-makers held accountable?
Empowerment Organizations are sometimes measured by employee
empowerment: whether employees are implicitly given the go-ahead to act
and “ask for forgiveness” if something goes wrong, versus organizations
that do not empower employees, requiring them to “ask for permission”
before acting. This is not so much about good versus bad policy, but more
about understanding how the organization behaves. Also important is the
organization’s behavior when things go wrong. Does the organization seek
to punish the person or people responsible for the mistakes or learn from its
mistakes—or is it somewhere in between?
Maturity
The strategist will probably find that the maturity levels of various
aspects of the organization’s security program vary widely. For instance, the
organization may have mature asset management and vulnerability
management programs but be lacking in other areas such as internal audit
and security awareness.
The levels of maturity are discussed in greater detail in the next section.
Maturity also plays a part during a gap assessment, also discussed in the
next section.
Risk Appetite
Every organization has a risk appetite, although most have not formally
documented it. A security strategist needs to understand business leaders’
implicit and explicit risk appetite, which is manifested in many ways:
Risk appetite can be summed up this way: does anyone really care?
Strategy Development
After performing risk and threat assessments and carefully reviewing the
state of the security program through the examination of artifacts, the
strategist can develop strategic objectives. Generally speaking, strategic
objectives will fall into one of these categories:
Reductions in cost
Once one or more objectives have been identified, the security strategist
will undertake several activities that are required to meet the objectives.
These activities are explained in the remainder of this section.
Gap Assessment
Internal and external audit results Audit reports are generally seen as an
in-depth view of the effectiveness of internal controls in the organization.
A security manager needs to understand how to read the audit report—as
well as be able to read between the lines—to understand specific audit
methodologies used to examine controls and report on them. Note that for
some audits, auditors are examining specific controls, whether or not they
actually exist in the organization. Understanding the scope of an audit is
also important, as it may, in some cases, be quite narrow and not provide a
broad view of control risk.
Risk register An organization’s risk register can provide insight into the
issues that are considered important security issues. Depending on the
details available in the risk register, a security manager may be able to
discern the various activities and methods in place to capture content for the
register.
Risk treatment decision records When available, risk treatment records
reveal what issues warranted attention, discussion, and decisions. Coupled
with the risk register, information here can provide a record of issues
tackled by the organization’s risk management process.
Security incident records The record of security incidents can reveal a lot
about the capabilities and attitudes in the security program. A sparse record
might indicate gaps in capabilities or skills. A rich record is probably an
indication of a more mature program and personnel intent on identifying
issues so that improvements can be made.
Not all security strategists are familiar with maturity models. Strategists
unaccustomed to capability maturity models need to understand two
important characteristics of maturity models and how they are used:
Level 5 is not the ultimate objective. Most organizations’ average maturity
level targets range from 2.5 to 3.5. There are few organizations whose
mission justifies level 5 maturity. The cost of developing a level 5 process
or control is often prohibitive and out of alignment with risks.
Each control or process may have its own maturity level. It is neither
common nor prudent to assign a single maturity level target for all controls
and processes. Instead, organizations with skilled strategists can determine
the appropriate level of maturity for each control and process. They need
not all be the same. Instead, it is more appropriate to use a threat-based or
risk-based model to determine an appropriate level of maturity for each
control and process. Some will be 2, some will be 3, some will be 4, and a
few may even be 5.
Policy Development
The Fast Car Company recently implemented its first security incident and
event monitoring system that produces alerts whenever actionable security
events occur. Prior to implementing the SIEM, IT and security personnel
would examine security logs every day to see whether any security events
had occurred in the past 24 hours.
Before implementing the SIEM, Fast Car Company’s security policy stated
that appropriate personnel were required to examine security logs daily and
log any actions taken. Now that the company has a SIEM, IT and security
personnel no longer need to examine logs. The company’s policy needs to
be changed so that 1) personnel are required to respond to security alerts
and 2) personnel are required to examine the SIEM’s configuration
periodically so that it will produce alerts for relevant events.
Security policies are supposed to align with current capabilities and are
not a vision statement describing future capabilities. This is the case
whether policies are addressing the use of technologies or business
processes. It’s generally considered unwise to develop a security policy that
requires an activity that the organization is incapable of performing.
Industries generally consider security policies as being out-of-date if
they are not examined and updated annually. This is not saying that security
policies are required to be updated annually, but they should be examined
and approved annually and updated as needed.
NIST SP 800-53
The goal of a good security policy is to define the “rules of the road” for
an organization’s employees. Policies should be clear, concise, and
applicable to the organization. The policies should be developed in a
collaborative manner to ensure that appropriate information is delivered to
the appropriate audience. Additionally, if policies are written without the
involvement or buy-in of the different stakeholders, an organization risks
deploying policies that it cannot adhere to or that will cause significant
investment to comply with.
Controls Development
Standards Development
They must properly reflect the intent of one or more corresponding policies.
Protocol standards Examples include TLS 1.2 for web server session
encryption, AES-256 for encryption at rest, 802.11ac for wireless
networking, and SAML 2.0 for authentication.
Job descriptions
Recent studies indicate that more than 90 percent of breaches begin with
phishing attacks. Arguably, security awareness training is one of the most
important defenses available for an organization, given that with even the
best spam filters, some phishing attacks do successfully penetrate even the
best defenses. The next line of defense is the sound judgment on the part of
every worker with an e-mail account. Organizations implementing new
security strategies often do so to improve their defenses; it makes sense,
then, to include a review and perhaps an upgrade in security awareness
training for all personnel. Some of the new features available in security
awareness training include the following:
Strategy Constraints
While the development of a new security strategy may bring hope and
optimism to the security team, there is no guarantee that changes in an
organization can be implemented without friction and even opposition.
Instead, the security manager should anticipate many constraints and
obstacles and be prepared to maneuver around, over, or through them.
Normalcy Bias
People at all levels can suffer from normalcy bias, a pattern of thinking in
which people believe that because a disaster or breach has never occurred, it
will never occur. Normalcy bias manifests itself in many situations, the
common theme being a general lack of personal and corporate preparedness
for disastrous events. This may be part of the reason that organizations do
not take information security seriously—they have never had a breach
before. Experienced information security professionals understand that an
organization claiming to have not suffered from security breaches in the
past may simply be unaware of them because of a lack of visibility into
events in their environment. A common saying in the information security
profession is, “There are two types of organizations: those that have been
breached and those that do not yet realize they have been breached.”
Culture
Strong culture The culture reflects and aligns with stated organizational
values. Personnel understand and support organizational goals and
objectives and need little prodding to figure out how to be productive and
provide value to the organization and its constituents.
Healthy culture Workers and management value and respect each other,
have a strong sense of accountability, and cooperate to be successful and
accomplish organizational goals and objectives.
Organizational Structure
The security strategist must understand the organization’s command-and-
control structure, which is often reflected by the organizational chart.
However, there may be an undocumented aspect to the org chart, which is
actually more important: who is responsible for what activities, functions,
and assets. In other words, security strategists must understand “who owns
what turf” and develop collaborative relationships with those individuals
and groups to implement a successful strategy. As with other considerations
in a security strategy, alignment with written and unwritten organizational
structures is the key to success.
Staff Capabilities
This is not limited to technical workers who design, build, and manage
information systems and applications. To the extent that all staff members
are impacted by some change introduced by the strategy, those staff
members need to be informed or trained so that they, too, will be successful.
For example, an organization that needs to improve its ability to protect
sensitive data includes the development of a data protection program in its
strategy. The strategy for data protection includes the development of a data
classification scheme with data-handling policies and procedures for data at
each classification level and in each use case. This is a high-impact
endeavor that will require that many, if not all, workers in the organization
be trained in data classification and handling procedures. If new security
systems are in place that augment manual tasks, personnel will need to be
trained in the use of these tools as well.
Every organization has a core business to run, with budgeted costs for all
associated activities. A security strategy almost always represents added
costs, which must also be funded. While it is possible to obtain out-of-
budget money for unbudgeted activities, it is usually necessary to create
security strategy initiatives and attempt to get those activities budgeted in
future fiscal cycles. For initiatives in future budget cycles, the security
strategist needs to determine the price increases that may occur that will
impact the strategy. A key project that will cost $100,000 this year may cost
$105,000 to $110,000 a year from now and be even more expensive in
future years.
Time
As security strategies take shape, each initiative will have its own project
plan with associated timelines for executing various tasks. Realistic project
planning is needed so that everyone will know when project and strategy
milestones will be completed. Project and strategy timelines need to take
into account all business circumstances, including peak periods and holiday
production freezes (where IT systems are maintained in a more stable state),
external events such as regulatory audits, and other significant events that
may impact schedules.
These examples suggest that legal and regulatory obligations often have
time components. New laws and contracts require organizations to have
specific capabilities in place by established deadlines. For organizations that
have failed to meet a deadline, the obligation still exists, and its completion
has a greater sense of urgency.
Legal and regulatory requirements often have international
considerations. What is legal and required in one country may be forbidden
in another. For instance, an international organization may have, as a part of
its strategy, key improvements in its pre-employment and post-employment
background checks. The organization needs to understand that some
countries, such as the United States, are quite permissive with background
checks, while other countries, such as France, do not permit background
checks for most positions. In another example, a security project that is
improving its endpoint protection capabilities with cloud-based web proxy
filters will find that users’ Internet access activities may not be observed or
logged in some countries.
Acceptable Risk
Risk is, by its nature, difficult to quantify. Most organizations, then, have
a cultural “feel” for risk appetite that may or may not be documented. The
security strategist must be familiar with the organization’s risk appetite, in
whatever formal or informal sense, and keenly understand two important
aspects of the strategy:
Its alignment with risk appetite Initiatives in the security strategy need
to align with executive management’s risk appetite. For example,
implementation of a data loss prevention (DLP) system together with
restricting the use of USB-attached external storage may help to protect
data, but this may be viewed as excessive in some organizations. A
common mistake made by security strategists is the incorporation into
strategies of new capabilities that may not be urgently needed. This can
happen, especially if a strategy is developed without soliciting input from
key stakeholders in the organization.
ISO/IEC 27001
The BMIS model includes the three traditional elements found in IT, which
are people, process, and technology, and adds a fourth element,
organization. The elements are connected by dynamic interconnections
(DIs), which are culture, governing, architecture, emergence, enabling and
support, and human factors. The elements and DIs are described in more
detail in the following sections.
NOTE BMIS is described fully in the document, The Business Model for
Information Security, from ISACA, available at www.isaca.org/bmis.
People The people element in the BMIS model represents all of the people
in an organization, whether full-time employees or temporary workers,
contractors, or consultants. Further, as an organization outsources its
operations to other organizations, the people in those organizations are also
part of this element in BMIS. Like the other elements in the BMIS model,
people cannot be studied by themselves but instead must be considered
alongside the other elements of process, technology, and organization.
Process The process element in the BMIS model represents the formal
structure of all defined activities in the organization, which together help
the organization achieve its strategic objectives. Process defines practices
and procedures that describe how activities are to be carried out.
Policies
Standards
Guidelines
Process documentation
Resource allocation
Compliance
Scalability Sound architectures are not rigid in their size but can be made
larger or smaller to accommodate various business needs, such as growth in
revenue, various size branch offices, and larger data sets.
Enact controls Putting key controls in place can help management focus
on factors responsible for outcome deviation. This can lead to process
improvements later.
The tool that is used to fill this gap is the requirements document. Often
developed at the onset of a major project (and often a minor one), business
people endeavor to develop charts listing required and desired functionality
for new technologies to improve their chances of selecting and
implementing a technology that will support their business processes.
Display and readability Users should be able to read text and images
easily.
Error recovery Users should be able to repeat a step when they have
recognized that they have made an error.
Using BMIS
But what if the new mobile device policy adversely affects other
processes? One would then follow the DIs from process and see where they
lead and how they lead. First, the emergence DI connects to people. In the
case of this policy, emergence includes ways in which people follow—or
don’t follow—the process. Next, following the enabling and support DI to
technology, this could indicate how other technologies may be affected by
the policy change.
The BMIS model for enabling and support is a life cycle, as opposed to a
do-it-once approach, as depicted in Figure 2-3.
Figure 2-3 BMIS enabling and support life cycle (Adapted from The
University of Southern California, Marshall School of Business, Institute
for Critical Information Infrastructure Protection, USA)
Data flow diagrams (DFDs) are frequently used to illustrate the flow of
information between IT applications. Like the Zachman model, a DFD can
begin as a high-level diagram, where the labels of information flows are
expressed in business terms. Written specifications about each flow can
accompany the DFD; these specifications would describe the flow in
increasing levels of detail, all the way to field lengths and communication
protocol settings.
Preliminary
Architecture vision
Business architecture
Technology architecture
Migration planning
Implementation governance
Requirements management
ISO/IEC 27001
Leadership
Planning
Support
Operation
Performance evaluation
Improvement
Asset management
Access control
Cryptography
Operations security
Communications security
Supplier relationships
Compliance
NOTE Many readers of ISO/IEC 27001 gloss over the core of the
standard, the seven sections of requirements for managing an ISMS, and
instead focus on the appendix with its list of controls. The controls in the
appendix are there for the reader’s convenience and are fully explained in
the companion standard, ISO/IEC 27002.
Note that the text of the CSF claims that these tiers are not maturity levels,
but upon reading the tier descriptions, it is difficult to come to any other
conclusion.
For implementation in the private sector, the CSF can be customized into
profiles. A profile is a particular customization of the CSF core for an
organization or sector; it is based on the organization’s or sector’s unique
requirements. NIST publishes profiles for a variety of industry sectors, such
as the manufacturing and petroleum industries.
Prepare
Categorize
Select
Implement
Assess
Authorize
Monitor
Data retention
Data destruction
Records management
Electronic discovery
Records retention
Strategic Planning
In strategic planning, one or more persons develop the steps and resources
required to achieve a desired end state. In the context of information
security, strategic planning should include the steps and resources required
for principal functions of the information security program to adequately
protect the organization’s information assets and to continue doing so
despite changes in threats, defensive techniques, technologies, and even the
organization’s overall strategic objectives.
Roadmap Development
Once strategic objectives, risk and threat assessments, and gap analyses
have been completed, the security strategist can begin to develop roadmaps
to accomplish each objective. A roadmap is a list of steps required to
achieve a strategic objective. “Roadmap” is an appropriate metaphor,
because it represents a journey that, in the details, may not always appear to
be contributing to the objective. But in a well-designed roadmap, each
objective, milestone, initiative, and project gets the organization closer to
the objective.
A roadmap is just a set of plans, but the term is often used to describe the
steps that an organization needs to take to undertake a long-term, complex,
and strategic objective. Often a roadmap can be thought of as a series of
projects—some running sequentially, others concurrently—that an
organization uses to transform its processes and technology to achieve the
objective.
Desired state This describes the future state of the relevant systems,
processes, or staff.
Success criteria These are the defined items that the program will be
measured against.
Approach This describes the proposed steps that will result in the desired
future state. This section may include alternative approaches that were
considered, with reasons why they were not selected. If the initiative
requires the purchase of products or professional services, business cases
may include proposals from vendors. Alternatively, the business case may
include a request for proposal (RFP) or a request for information (RFI) that
will be sent to selected vendors for additional information.
Chapter Review
Notes
Capability maturity models are useful tools for understanding the maturity
level of a process and developing desired future states. The maturity of
processes in the organization will vary; it is appropriate for some processes
to have high maturity and acceptable for others to have lower maturity. The
right question to ask about each separate process is this: what is the
appropriate level of maturity for this process?
Each organization has its own practice for the development of business
cases for the presentation, discussion, and approval of strategic initiatives.
Questions
What are the elements of the Business Model for Information Security
(BMIS)?
Culture, governing, architecture, emergence, enabling and support, human
factors
A security strategist has examined several business processes and has found
that their individual maturity levels range from Repeatable to Optimizing.
What is the best future state for these business processes?
Enact new detective controls to identify personnel who are violating policy.
Security policy
IT policy
Security strategy
What relationship should exist between an ERM risk register and a cyber-
risk register?
Industry vertical
Compliance level
None of these
While gathering and examining various security-related business records,
the security manager has determined that the organization has no security
incident log. What conclusion can the security manager make from this?
Initial
Repeatable
Defined
Managed
A security strategist has discovered that IT does not control the usage and
acquisition of software on endpoints. What can the strategist conclude?
Answers
C. The ERM and cyber-risk registers should influence one another. For
instance, chronic risks in the cyber-risk register should compel the creation
of a new entry in the ERM risk register.
A. An organization that does not have a security incident log probably lacks
the capability to detect and respond to an incident. It is not reasonable to
assume that the organization has had no security incidents, since minor
incidents occur with regularity. Claiming that the organization has effective
controls is unreasonable, as it is understood that incidents occur even when
effective controls are in place (because not all types of incidents can
reasonably be prevented).
Supporting Tasks in the CISM job practice that align with the
Information Security Risk Management / Information Security Risk
Assessment domain include:
Culture
Mission, objectives, and goals
Management structure
Management support
Industry sector
Market conditions
Financial health
Operating locations
Risk Objectives
Antivirus software
Forensics tools
Spam filters
Salespeople who claim their solutions will solve the organization’s security
risks (without actually knowing what the specific risks are)
Once a framework has been selected, the security manager can then start
to develop a sound risk management strategy. Security managers will need
to perform one or more gap analyses to understand the organization’s
current state so that they can develop adequate plans to define, document,
and highlight the desired future state. Because no security manager has a
complete repertoire of knowledge and skill, many outside resources are
available to supplement their knowledge and/or provide direct assistance.
Culture
Organizational maturity
Management structure
Management support
Market conditions
Possibly the most important factor that will enable or constrain security
managers as they develop a risk management strategy is the development of
key relationships throughout the organization. When a security manager
develops and implements a risk management strategy, he or she is acting as
a change agent in the organization. The security manager is subtly but
intentionally driving key changes in the organization through changes in
people, processes, and technologies. This role as a security catalyst is an
ongoing journey that will become a way of life as the organization becomes
a risk-aware culture.
Risk Consulting Security managers often play the role of security and risk
consultant in their organizations. As they develop trusted relationships
throughout the business, security managers are regarded as technology risk
experts who are available to consult with on a wide variety of issues.
Though these mini-consulting engagements may seem like ad hoc activities,
security managers should treat them as formal service requests, even in the
absence of a service request system or formal capability. This includes
being mindful of responsiveness and service levels. Here are some of the
key attributes that make a good information risk consultant:
Risk IT framework
Risk managers can take two main approaches when considering existing
frameworks: use a single framework that has the best alignment with the
organization’s practices, or use elements from one or more frameworks to
build the organization’s risk management program. As noted earlier in the
chapter, several considerations influence the decision.
Framework Components Risk management frameworks have a common
core of components, including the following:
Program scope
Risk appetite/tolerance
Management review
Risk appetite/tolerance
Organizational maturity
Culture
Economic conditions
Geopolitical factors
Process-level risks Risks at this level are usually associated with the
effectiveness of business processes, typically those that affect cybersecurity
posture. Issues at this level typically involve security policies, standards,
process design, workflow, and workload.
Asset-level risks Risks at this level are associated with individual systems
or small groups of systems. Generally, asset-level risks involve
configuration and small-scale architecture. Analysis is focused on technical
vulnerabilities and threats, and remediation is usually tactical.
Risks at one tier sometimes inform adjacent tiers. For instance, a surge in
asset-level risks may indicate defects in process-level risks, or even a shift
in workforce priorities. Similarly, the presence of multiple process-level
risks may be an indication of macro issues that should be addressed at the
enterprise level.
Gap Analysis
External Support
Setting up a new information risk management program involves a great
deal of knowledge and details. Even the most experienced information
security managers may find themselves lacking in a few areas. For instance,
a new security manager may have worked previously in an organization
without an existing risk management program, or the security manager may
have worked in a different industry sector in the past. Or perhaps the
organization may use tools, technologies, or processes that are unfamiliar to
the security manager. Fortunately, a wealth of information is available to
security managers, which will help to supplement their existing knowledge
and skills so that they can proceed with building and running an
information risk management program with more confidence and with
better assurances of positive outcomes.
Security round tables Many areas have informal security round tables
whose members include chief information security officers (CISOs) and
security managers. These local networks of information risk security
professionals are invaluable for networking and advice.
InfraGard
ISACA
ISACA
SANS Institute
CIO magazine
CSO magazine
Dark Reading
Infosecurity Magazine
ISACA
(ISC)²
SANS Institute
SC Magazine
TechTarget
Ponemon Institute
PricewaterhouseCoopers (PwC)
Symantec
Verizon Business
Forrester
Frost Sullivan
Gartner
IDC
Ovum
Training Education and training courses tailored for established security
and risk professionals are available from many universities, community
colleges, and vocational schools, as well as ISACA, (ISC)², and SANS.
Books Some of the titles listed in The Cybersecurity Canon are focused on
risk management and go deeper into the topic than is needed for the CISM
certification. Originally curated by Palo Alto Networks, The Cybersecurity
Canon is now managed by Ohio State University
(https://icdt.osu.edu/about-cybersecurity-canon).
Black Hat
Defcon
ISACA Conference
SecureWorld Expo
Risk treatment decisions about risks are made after weighing various risk
treatment options. These decisions are typically made by a business owner
associated with the affected business activity.
Risk analysis In the second step in a typical risk management process, the
risk is analyzed to determine several characteristics, including the
following:
Mitigate The organization chooses to mitigate the risk, which can take the
form of some action that serves to reduce the probability of a risk event or
reduce the impact of a risk event. The actual steps taken may include
business process changes, configuration changes, the enactment of a new
control, or staff training.
Figure 3-2 shows the elements of a typical risk management life cycle.
Figure 3-2 The risk management life cycle
Step 2: Risk assessment This is the actual risk assessment, where threats
and vulnerabilities are identified and assessed to determine levels and types
of risk.
Step 3: Risk response This is the process of analyzing each risk and
developing strategies for reducing it, through appropriate risk treatment for
each identified risk. Risk treatment options are accept, mitigate, avoid, and
transfer. This step is defined in more detail in NIST SP 800-30, described
later in this section.
Step 4: Risk monitoring This is the process of performing periodic and
ongoing evaluation of identified risks to see whether conditions and risks
are changing.
Determine risk The organization determines the level of risk for each threat
event. These tables aid the risk manager in this effort:
Briefings
Risk evaluation criteria Determine the means through which risks will be
examined and scored.
Impact criteria Determine how the impact of identified risks will be
described and scored.
Risk acceptance criteria Specify the method that the organization will
use to determine risk acceptance.
Logistical plan This includes which personnel will perform the risk
assessment, which personnel in the organization need to provide
information such as control evidence, and what supporting facilities are
required, such as office space.
Asset identification Risk analysts identify assets, along with their value
and criticality.
Because some forms of risk treatment (mainly, risk reduction and risk
transfer) may require an extended period of time to be completed, risk
managers usually track ongoing risk treatment activities to completion.
Step 6: Risk monitoring and review Organizations are not static, and
neither is risk. The value of assets, impacts, threats, vulnerabilities, and
likelihood of occurrence should be periodically monitored and reviewed so
that the organization’s view of risk continues to be relevant and accurate.
Monitoring should include the following:
Fines and judgments All forms of legal costs resulting from the incident
FAIR also focuses on the concept of asset value and liability. For
example, a customer list is an asset because the organization can reach its
customers to solicit new business; however, the customer list is also a
liability because of the impact on the organization if the customer list is
obtained by an unauthorized person.
FAIR guides a risk manager through an analysis of threat agents and the
different ways in which a threat agent acts upon an asset:
Collect Data (RE1) The data collection process aligns with some of the
risk identification processes 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 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.
In addition, it involves consideration of existing controls and how effective
they are as currently installed and functioning. Likelihood and impact
values are considered after existing controls are considered.
In the security industry, the key terms involved with risk assessments are
often misunderstood and misused. These terms are distinguished from one
another in this way: a vulnerability is a weakness in a system that could
permit an attack to occur. A vulnerability is not the attack vector or
technique—this is known as a threat.
Threat Identification
In the security industry, the key terms involved with risk assessments are
often misunderstood and misused. These terms are distinguished from one
another in this way: a threat is the actual action that would cause harm, not
the person or group (generically known as an actor or threat actor)
associated with it. A threat is also not a weakness that may permit a threat
to occur; that is known as a vulnerability, discussed earlier in this chapter.
Upon capturing threat events from one or both of these sources, the security
manager may identify a few additional threats not found in these lists.
These additional threats may be specific to the organization’s location,
business model, or other factors.
A security manager will typically remove a few of the threats from the
list that do not apply to the organization. For instance, an organization
located far inland is not going to be affected by tsunamis, so this threat
source can be eliminated. Similarly, in an organization located in an area
not affected by tornados, volcanos, or earthquakes, these threat sources can
be removed.
Internal Threats
Internal threats originate within the organization and are most often
associated with employees of the organization. Quite possibly, internal
employees may be the intentional actors behind these threats.
After understanding all the ways that something can go wrong, security
managers may sometimes wonder if things can ever proceed as planned!
A network manager in San Francisco locks all other network personnel out
of the network on the claim that no others are competent enough to manage
it.
Access controls are only one of several areas of concern. Table 3-3
contains human-made threats that may be included in an organization’s risk
assessment.
Table 3-3 Internal and External Human-Made Threats
It may be useful to build a short list of threat actors (the people or groups
that would initiate a threat event), but remember that these are not the
threats themselves. Building such a list may help the security manager
identify additional threat events that may not be on the list.
Table 3-4 contains a list of internal and external natural threats.
External Threats
Like internal threats, threats that originate outside of the organization can
include both deliberate and accidental actions. External threats can also be
human-made or associated with naturally occurring events.
The security manager performing a risk assessment needs to understand
the full range of threat actors, along with their motivations. This is
particularly important for organizations where specific types of threat actors
or motivations are more common. For example, certain industries such as
aerospace and weapons manufacturers attract industrial espionage and
intelligence agencies, and certain industries attract hacktivists.
Table 3-5 contains a list of external threat actors, and Table 3-6 lists the
motivations behind these actors.
This cat-and-mouse game could continue for months, or even years, with
the adversary continuing to compromise targets and study the organization’s
systems—all the while searching for specific targets—while the security
manager and others would continually chase the adversary around like the
carnival game of “whack a mole.”
NOTE The term “APT” is not used often nowadays, although its
definition is largely unchanged. APTs were discussed more often when
these techniques were new. But today, the techniques used by a multitude of
cybercriminal organizations, along with hundreds if not thousands of
talented, individual threat actors, resemble the APTs of a dozen years ago.
Today APTs are not novel but routine.
Emerging Threats
One of the biggest problems with information risk management is the lack
of reliable data on the probability of many types of threats. Although the
probability of some natural threats can sometimes be obtained from local
disaster response agencies, the probabilities of most other threats are
notoriously difficult to predict.
Risk Identification
During risk identification, various scenarios are studied for each asset to
identify which risks pose the greatest potential for realization. Several
considerations are applied in the identification of each risk, including the
following:
Threats All realistic threat scenarios are examined for each asset to
determine which are most likely to occur.
Threat actors The risk manager must understand the variety of threat
actors and know which ones are more motivated to target the organization
and for what reasons. This further illuminates the likelihood that a given
threat scenario will occur.
Vulnerabilities For all assets, business processes, and staff members being
examined, vulnerabilities need to be identified. Then various threat
scenarios are examined to determine which ones are more likely as a result
of corresponding vulnerabilities.
During risk analysis in a risk assessment, the risk manager will perform
some simple calculations to stratify all of the risks that have been identified.
These calculations generally resemble one or more of the following:
Likelihood
Velocity This factor is related to the timing of various threat scenarios and
whether there is any warning or foreknowledge.
Skill For various threat scenarios, what skill level is required to attack the
organization successfully? If attackers require a higher skill level to
infiltrate an organization’s system, this doesn’t mean that an attack is less
likely; other considerations such as motivation come into play as well.
Impact
Reputation damage
Civil liability
Legal liability
One of the main tools in the business continuity and disaster planning
world, the business impact analysis (BIA), is highly useful for information
security managers. A BIA can be conducted as part of a risk assessment or
separate from it. A BIA differs from a risk assessment in this way: A risk
assessment is used to identify risks and, perhaps, suggested remedies. A
BIA is used to identify the most critical business processes, together with
their supporting IT systems and dependencies on other processes or
systems.
Asset value
Threat scenarios
Threat probabilities
Relevant vulnerabilities
Impact
Gathering Information
Most risk analysis begins with qualitative risk analysis, a rating technique
that does not seek to identify exact (or even approximate) asset value or
impact or the exact probability of occurrence. Risk items are expressed in
levels such as high, medium, and low. The purpose of qualitative risk
analysis is to understand each risk relative to other risks, so that higher risks
can be distinguished from lower risks. This system enables the organization
to focus on risks that are more critical, based on impact in qualitative terms.
Event cost It is difficult to put an exact cost on any given security incident
scenario. Security incidents are complex events that involve many parties
and have unpredictable short- and long-term outcomes. Despite improving
information from research organizations on the cost of breaches, these are
still rough estimates and may not take into account all aspects of cost.
Asset value (AV) The value of the asset is usually (but not necessarily) the
asset’s replacement value. Depending on the type of asset, different values
may need to be considered.
Exposure factor (EF) The financial loss that results from the realization
of a threat is expressed as a percentage of the asset’s total value. Most
threats do not completely eliminate the asset’s value; instead, they reduce
its value. For example, if an organization’s $120,000 server is rendered
unbootable because of malware, the server will still have salvage value,
even if that is only 10 percent of the asset’s actual value. In this case, the EF
would be 90 percent. Note that different threats have different impacts on
EF, because the realization of different threats will cause varying amounts
of damage to assets.
Single loss expectancy (SLE) This value represents the financial loss
when a threat scenario occurs one time. SLE is defined as AV × EF. Note
that different threats have a varied impact on EF, so those threats will also
have the same multiplicative effect on SLE.
ALE is based upon the verifiable values AV, EF, and SLE, but because
ARO is only an estimate, ALE is only as good as ARO. Depending upon
the value of the asset, the risk manager may need to take extra care to
develop the best possible estimate for ARO, based upon whatever data is
available. Sources for estimates include the following:
OCTAVE
Bow-Tie Analysis
Upon completion of a risk assessment, when all risks have been identified
and scored, the security manager, together with others in the organization,
will begin to analyze the results and begin to develop a strategy going
forward.
Risks can be evaluated singly, but the organization will better benefit
from an analysis of all the risks together. Many risks are interrelated, and
the right combination of mitigation strategies can result in many risks
having been adequately treated.
Because no two organizations (or their risk assessment results) are alike,
this type of analysis is likely to identify themes of risk treatment that may
have broad implications across many risks. For example, an organization
may have several tactical risks, all associated with access management and
vulnerability management. Rather than treating individual tactical risks, a
better approach may be to improve or reorganize the access or vulnerability
management programs from the top down, resulting in many identified risks
being mitigated in a programmatic fashion. Organizations need to consider
not just the details in a risk assessment, but the big picture.
Risk Ownership
Risk Treatment
Controls
Both seek to discover risks and develop remedies for events that threaten
business operations and the ongoing viability of an organization.
Both rely on risk assessments to identify risks that will require mitigation.
Awareness of risks can come from many places and through a variety of
events. The information in Table 3-8 provides some hints about the
potential sources of information that would lead to the creation of a risk
register entry, which include the following:
Risk assessment A prime source for risk register entries, a risk assessment
identifies risks in the organization’s staff (such as excessive workload,
competency, and training issues), business processes, and technology.
New laws and regulations The passage of new laws, regulations, and
applicable standards and private legal obligations may reveal the presence
of risks that require attention. Also, note that compliance risk (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.
Note that Table 3-8 includes ratings for mitigated probability, impact, and
risk, as well as a description of risk treatment with associated cost and level
of effort. The information in those fields should represent the result of more
detailed risk analysis for each entry in the risk register.
For example, a security manager may have discovered that the
organization’s software development team continues to produce code
containing numerous security defects. The security manager would analyze
the situation and consider many different potential remedies, each with its
own costs, levels of effort, and impact on risk. The security manager may
then consider the following:
Ultimately, the ratings in the risk register, as well as the risk mitigation
description, will reflect the mitigation technique that is selected.
Residual Risk
Risk treatment rarely eliminates all risk; instead, risk treatment will reduce
the probability and/or the impact of a specific threat. The leftover, or
residual, risk should be entered into the risk register for its own round of
risk treatment. Depending upon the nature of the original risk, an individual
risk may undergo two or more cycles of risk treatment, until finally, the
residual risk is accepted and the risk matter closed.
The risk management life-cycle process is not the only place where risk
analysis and risk management are performed in an organization. The
concept of risk should be integrated into several other IT and business
processes in an organization. This section describes the incorporation of
security and risk into several processes, including the following:
Architecture
Software development
Change management
Configuration management
Physical security
Project management
Architecture
Code reviews Performed by peers, code reviews are part of the program
development and maintenance process. A peer is more likely to find defects
and security problems than the developer who wrote the code.
Security impact of the change and also of not implementing the change
Privacy impact
Dependencies
Configuration Management
Physical Security
Project Management
Chapter Review
The risk management life cycle consists of a set of activities that enable
the discovery and management of risks. The steps in the process include
scope definition, asset identification and valuation, risk identification, risk
analysis, risk treatment, and risk communication. Periodic risk assessments
and other means contribute to continued risk identification.
After risks are identified, the amount of risk present can be calculated
using input from threats, threat actors, vulnerabilities, asset value, and
impact. In most cases, risk is calculated in a qualitative way, primarily
because it is difficult to know the precise (or even an approximate)
probability of threat occurrence and somewhat difficult to know the
financial impact of a threat.
In quantitative risk analysis, key values are asset value, exposure factor,
single loss expectancy, annualized rate of occurrence, and annualized loss
expectancy.
Security and risk management are incorporated into many other business
activities, including but not limited to software development, change
management, configuration management, incident and problem
management, physical security, enterprise risk management, and human
resource management.
Notes
The need to minimize the impact of the risk management business process
cannot be overstated. Where possible, utilize existing governance,
management, control, and communications structures already present in the
organization. The impact on decisions made in the risk management
program may be significant; the process itself need not be.
Security managers, when their knowledge or skills fall short on any topic,
underestimate the value of networking and soliciting advice from industry
peers. Many security professionals are willing to help, and plenty of events
provide networking opportunities to meet them.
In a risk assessment, while listing credible threat events, first obtain the list
of threats from a standard such as NIST SP 800-30, and then add other
threats that may be relevant for the asset, organization, or geographic
location.
The term “advanced persistent threats” was developed when such threats
were novel. They no longer are new. Although use of the term has
diminished, this type of threat has become commonplace.
Most organizations that are establishing a risk management program for the
first time can use spreadsheets for key business records such as the risk
register and the security incident log. As organizations become more
mature, they can acquire a governance, risk, and compliance platform that
includes risk management modules.
Questions
Do not inform executive management until the risk assessment has been
completed.
A security manager has completed a vulnerability scan and has identified
numerous vulnerabilities in production servers. What is the best course of
action?
Gap analysis
Risk analysis
Risk assessment
Threat assessment
Penetration tests
Threat modeling
Vulnerability assessment
Risk treatment
Compliance risk can be tolerated when fines cost less than controls.
Compliance risk is just another risk that needs to be understood.
Risks
Threats
Vulnerabilities
Threat actors
A phishing attack, network scan, and social engineering are examples of:
Risks
Threats
Vulnerabilities
Threat actors
A security manager has been directed by executive management not to
document a specific risk in the risk register. This course of action is known
as:
Probability
Threat
Vulnerability
Risk
Probability
Threat
Vulnerability
Risk
Threat actors
Risks
Threats
Exploits
All of the following are core elements used in risk identification except:
Threats
Vulnerabilities
Asset value
Asset owner
No security incidents
Improved compliance
Answers
C. One of the main advantages of NIST standards is that they are available
free of charge. ISO standards are relatively expensive, ranging from
US$100 to $200 for single user copies.
A. These are all threat actors, or persons/entities that may carry out threats
against targets if sufficiently motivated.
D. The identity of an asset owner does not factor into the risk identification
process. Although knowing the asset owner is important in subsequent
phases of the risk management process, it is not relevant in identifying the
risk. The factors relevant to risk identification are threats, threat actors,
vulnerabilities, asset value, and impact.
Supporting Tasks in the CISM job practice that align with the
Information Security Risk Management / Information Security Risk
Response domain include:
Compile and present reports to key stakeholders on the activities, trends,
and overall effectiveness of the information security program.
Monitor for internal and external factors that may require reassessment of
risk.
Risk mitigation
Risk transfer
Risk avoidance
Risk acceptance
These four actions are explained in more detail in the following sections.
The decision to ignore a known risk is different from an organization
ignoring an unknown risk, which is usually a result of a risk assessment or
risk analysis that is not properly scoped or sufficiently thorough to identify
all relevant risks. The best solution for these “unknown unknowns” is to
have an external, competent firm perform an organization’s risk assessment
every few years, or have the firm examine the organization’s risk
assessment thoroughly to discover opportunities for improvement,
including expanding the span of threats, threat actors, and vulnerabilities so
that there are fewer or no unknown risks. Now that we know the options for
risk responses, we should consider the impact of those responses.
One impact of risk treatment is that it pits available resources against the
need to reduce risk. In an enterprise environment, not all risks can be
mitigated or eliminated, because there are not enough resources to treat
them all. Instead, a strategy for choosing the best combination of solutions
that will reduce risk by the greatest possible margin is needed. For this
reason, risk treatment is often more effective when all the risks and
solutions are considered together, instead of each one separately. Then they
can be compared and prioritized.
Undefined An organization that does not define who makes risk treatment
decisions is, by definition, not running an effective security management
program.
In many organizations, consensus decisions are made by a combination of
these parties.
Risk Mitigation
Risk mitigation is one of four choices that an organization can take when
confronted with a risk. Risk mitigation, aka risk reduction, involves the
implementation of some solution that will reduce an identified risk—for
example, by changing a process or procedure, changing how a security
control functions, or adding a security control. In another example, the risk
of advanced malware being introduced onto a server can be mitigated with
advanced malware prevention software or a network-based intrusion
prevention system. Either of these solutions would constitute mitigation of
some of this risk on a given asset.
Risk mitigation may, at times, result in a task that can be carried out in a
relatively short period of time. However, risk mitigation may also involve
one or more major projects that start in the future, perhaps in the next
budget year or many months, quarters, or years in the future. Further, such a
project may be delayed, its scope may change, or it may be canceled
altogether. For this reason, the security manager needs to monitor risk
mitigation activities carefully to ensure that they are completed as originally
planned so that the risk mitigation is not forgotten.
Controls and risk assessments are tightly coupled in the risk management
life cycle. In a typical security program, an organization selects a control
framework (such as NIST SP 800-53, ISO/IEC 27002, HIPAA, NERC, CIS
CSC, or PCI DSS) as a starting point. Then, as the organization conducts
risk assessments, from time to time, the action taken to mitigate risk is the
creation of a new control. It is important to understand that control
frameworks represent a starting point, not the entire journey, in an
information security program. Every organization is different, and no
experienced information risk professional believes that any of the standard
control frameworks will address all risks in an organization.
Risk Transfer
Risk transfer, or risk sharing, means that some or all of the risk is being
transferred to some external entity, such as an insurance company, service
provider, business process outsourcer (BPO), or business partner. The risk
transfer option is selected when an organization does not have the
operational or financial capacity to accept the risk and when risk mitigation
is not the best choice.
Risk transfer typically works with only 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 CISM candidates need to understand that the use of a risk
transfer 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, revenue, or customers.
Additionally, legal liabilities may also be involved.
Risk Avoidance
Risk Acceptance
The value of the asset may have changed during the year.
The value of the business activity related to the asset may have changed
during the year.
The potency of threats may have changed during the year, potentially
leading to a higher risk rating.
The cost of mitigation may have changed during the year, potentially
leading to greater feasibility for risk mitigation or transfer.
As with other risk treatment activities, detailed records help the security
manager better track matters such as risk assessment review.
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.
Risk mitigation, transfer, acceptance, and avoidance are all valid options to
consider (sometimes at the same time) when attempting to reduce the level
of risk. The key is to use these options together, balancing risk and reward
to maximize the benefits. These benefits can be financial or some other
benefit, one perhaps difficult to quantify (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? A risk manager should also consider the effectiveness of the
controls: if all possible controls that could be implemented still don’t reduce
the risk to an acceptable level, are they worth the effort?
Acquisition
Recurring maintenance
Training
End-of-life decommissioning
Residual Risk
Residual risk is the leftover risk that exists after some of the risk has been
removed through mitigation or transfer. For instance, if a particular threat
had a probability of 10 percent before risk treatment and 1 percent after risk
treatment, the residual risk is that 1 percent. This is best illustrated by the
following formula:
Original Risk – Mitigated Risk – Transferred Risk – Avoided Risk =
Residual Risk
Each organization has a particular appetite for risk, although few have
documented that appetite. ISACA defines risk appetite as “the level of risk
that an organization is willing to accept while pursuing its mission, strategy,
and objectives before taking action to treat the risk.” Risk capacity is related
to risk appetite. ISACA defines risk capacity as “the objective amount of
loss that an organization can tolerate without its continued existence being
called into question.” Risk tolerance is the acceptable level of deviation in
risk for a particular endeavor or business pursuit. In other words, risk
tolerance is the amount of variation from the expected level of risk the
organization is willing to put up with.
Risk identification Information about the introduction of the risk into the
risk register, including a unique ID designation, the date of discovery, how
it was discovered, and by whom
Risk Ownership
Risks are identified and recorded in the risk register, and each risk should
be assigned an owner. The risk owner is not necessarily the same individual
who is accountable for making the risk treatment decision, nor is it the
person who owns the asset(s) associated with the risk. Generally, the risk
owner is the department or business unit owner where the risk resides.
The risk owner will generally want a risk treatment decision to be made,
particularly in circumstances where the risk owner is uncomfortable
accepting the entire risk as it is. However, the risk owner should also have a
say in the risk treatment decision with regard to whether they are inclined to
accept the risk or whether they want the risk reduced through mitigation,
transfer, or even avoidance.
Changes in Risk
Changes in Personnel
Control Ownership
Any records or other artifacts created through normal control operation are
correct and complete.
The appropriate personnel are notified when the control is known to have
failed.
Control owners should have the authority to make decisions about the
operation of their controls to ensure that these activities and outcomes can
be assured.
NOTE Risk, asset, and control owners are not always the same person, in
the same functional area, or even in the same 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 Documentation
Any business process that warrants the time and effort to execute deserves
to be documented so that it can be performed consistently and correctly. An
organization’s risk management program should be fully documented,
including the following:
Locations for data storage and archives, such as where the risk register and
risk treatment records reside
Risk tolerance, such as how acceptable and unacceptable risks are defined
Business rules regarding what is included in the risk register and why
Procedures and methods for the development of metrics and key risk
indicators
Review cycle defined to ensure that the program is in alignment with the
business
Chapter Review
Notes
Risk tolerance/appetite is difficult to quantify, and few organizations have
defined it for themselves. A lack of a formal risk tolerance statement should
not be an impediment to starting or continuing a risk management program.
Instead, risk decisions should be made one at a time.
If a decision is made to accept a risk, the risk should remain on the risk
register, and the matter should be considered again one to two years later.
Risks that are accepted should not be accepted in perpetuity, because
conditions may change in the future that could compel management to
make a different decision.
Any risk that is not identified, documented, and treated is, by definition,
accepted.
Questions
Noncompliance
Irresponsibility
Outsourcing
Risk avoidance, risk reduction, risk transfer, risk mitigation, and risk
acceptance
Risk acceptance
Risk transfer
Risk treatment
Risk ownership
Risk acceptance
Risk treatment
Risk register
Meeting minutes
Risk charter
In a risk assessment, a risk manager has identified a risk that would cause
considerable embarrassment to the organization if it were revealed to the
workforce and the public. Executives have directed the risk manager to
omit the finding from the final report. What has executive management
done in this case?
The leftover risk that exists after risk mitigation has been performed is
known as:
Residual risk
Open risk
Untreated risk
Accepted risk
A recent risk assessment has identified a data loss risk associated with the
use of unapproved software. Management has directed the removal of the
unapproved software as a result of the risk assessment. What risk decision
has been made in this situation?
Risk mitigation
Risk avoidance
Risk abrogation
Risk reduction
A. The four categories of risk treatment are risk avoidance (the risk-
producing activity is discontinued), risk transfer (risks are transferred to an
external party such as an insurance company or managed services provider),
risk mitigation (risks are reduced through a control or process change), and
risk acceptance (management chooses to accept the risk).
C. A risk item that has been accepted should be shelved and considered
after a period of time, such as one year. This is a better option than closing
the risk item permanently; in a year’s time, changes in business conditions,
security threats, and other considerations may compel the organization to
take different action with regard to the risk.
B. The risk committee has formally treated the risk through its decision to
mitigate the risk.
A. The risk register is the best place to document a formal risk treatment
decision. It may also be appropriate to publish meeting minutes and
document the decision in a decision log if one exists.
D. Ignoring the risk is the best answer to this question, but it could also be
said that executive management accepted the risk. However, since the risk
was not documented, there was no formal risk acceptance.
C. Ownership of the risk has been delegated to another person in the
department. This is not necessarily inappropriate, because the other person
may be more directly responsible for business operations related to the risk.
Supporting Tasks in the CISM job practice that align with the
Information Security Program / Information Security Program Development
domain include:
Establish and maintain information security policies to guide the
development of standards, procedures, and guidelines.
Security program models have been developed that include the primary
activities needed in any organization’s security program. However, because
every organization is different, each security manager needs to understand
their particular organization’s internal workings so that their security
programs can effectively align with the organization’s operations, practices,
and culture.
Trends
Outcomes
Charter
Scope
Requirements development
Compliance monitoring
Data classification and handling
Contingency planning
Access governance
Architecture reviews
Technical standards
Forensics
Vulnerability management
Threat intelligence
The three lines of defense is a functional model that defines three aspects of
the development and operation of controls:
Foundation technologies
TCP/IP internals
Middleware
Endpoint protection
Antimalware
Firewalls
Network protection
Antimalware
Firewalls
Data protection
Password vaults
Event management
Centralized logging
Vulnerability management
Security scanning
Penetration testing
Penetration testing
Code review
Risk management and risk treatment are not the only drivers compelling an
organization to implement new information security tooling. A major factor
is peer pressure; many organizations adopt new security tooling for several
reasons, including these:
Indeed, there is only one valid reason for adopting new security
technology: risk analysis and risk treatment call for it, and the organization
is unwilling to accept a related risk. All other reasons are generally invalid
and the result of peer pressure, emotional decision-making, or the desire to
“get their hands dirty” in the latest security tooling fad.
Hardware Assets
Identification This includes the make, model, serial number, asset tag
number, logical name, and other means for identifying the asset.
Value Initially, this may signify the purchased value, but it may also
include its depreciated value if an IT asset management program is
associated with the organization’s financial asset management program.
Owner This is usually the person or group responsible for the operation of
the asset.
Information Assets
Information assets are less tangible than hardware assets, because they are
not easily observed. Information assets take many forms:
Customer information Most organizations store information about
people, whether employees, customers, constituents, beneficiaries, or
citizens. The information may include sensitive information such as contact
information and personal details, transactions, order history, and other
details.
Intellectual property This type of information can take the form of trade
secrets, source code, product designs, policies and standards, and marketing
collateral.
Virtual Assets
These and other criticality measures form the basis for information
protection, system redundancy and resilience, business continuity planning,
disaster recovery planning, and access management. Scarce resources in the
form of information protection and resilience need to be allocated to the
assets that require it the most, because it doesn’t usually make sense to
protect all assets to the same degree; instead, more valuable and critical
assets should be more fully protected than those deemed less valuable and
critical. To illustrate this point, the late McGeorge Bundy, former U.S.
National Security Advisor, is known to have said, “If we guard our
toothbrushes and diamonds with equal zeal, we will lose fewer toothbrushes
and more diamonds.”
Information Classification
Secret
Restricted
Confidential
Public
These levels of information, examples of the types of levels that fall into
each category, and instructions on handling information at each level form
the heart of a typical information classification program.
Secret Merger and acquisition plans, user and system account passwords,
and encryption keys
Internet time server A server provides precise time clock data to other
servers, network devices, and end-user workstations. Although the time
server itself does not store, process, or transmit sensitive information, it is
classified as Restricted because this server has direct access (via time
protocols and possibly other protocols) to assets that are classified as
Restricted. This server will be hardened according to hardening standards
developed by the organization.
Facilities Classification
Personnel Classification
Personnel with access to the most sensitive information (trade secrets and
other intellectual property)
Asset Valuation
Note that some of these standards appear in more than one category. Some
are multipurpose in nature. For instance, NIST CSF prescribes a risk
management methodology and includes a mapping of controls.
Control Frameworks
When assessing the use of a specific framework, the strategist may find
that a specific control area is not applicable. In such a case, rather than
ignoring the section, the strategist should document the business and
technical reasons why the organization chose not to use the control area.
This will assist if a question is raised in the future as to why the decision
was made not to implement the control area. The date and those involved in
the decision should also be documented.
COBIT
ISO/IEC 27002
HIPAA
NIST SP 800-53
NIST SP 800-171
NIST CSF
CIS CSC
PCI DSS
Manage risk.
Manage security.
ISO/IEC 27002
HIPAA
Administrative safeguards
Physical safeguards
Technical safeguards
Several controls reside within each of these three categories. Each
control is labeled as Required or Addressable. Every covered entity must
implement controls that are labeled as Required. Controls labeled as
Addressable are considered optional in each covered entity, meaning the
organization does not have to implement an Addressable control if it does
not apply or if there is negligible risk if the control is not implemented.
NIST SP 800-53
Access control
Configuration management
Contingency planning
Incident response
Maintenance
Media protection
Planning
Personnel security
Risk assessment
Program management
Even though the NIST 800-53 control framework is required for federal
information systems, many organizations that are not required to employ
the framework have used it, primarily because it is a high-quality control
framework with in-depth implementation guidance and also because it is
available without cost.
NIST SP 800-171
Access control
Configuration management
Identification and authentication
Incident response
Maintenance
Media protection
Personnel security
Physical protection
Risk assessment
Security assessment
Training resources
Adding or changing business processes or procedures
The NIST CSF can be used as the foundation for a controls framework.
Table 2 of Version 1.1 of the CSF maps its Framework Core to CIS CSC,
COBIT 2019, ISA 62443, ISO/IEC 27001, and NIST SP 800-53.
The Critical Security Controls framework from the Center for Internet
Security (CIS CSC) is a well-known control framework that traces its
lineage back to the SANS organization. Despite having 18 sections, the
framework is still commonly referred to as the “SANS 20” or “SANS 20
Critical Security Controls.”
Data Protection
Secure Configuration of Enterprise Assets and Software
Account Management
Malware Defenses
Data Recovery
Penetration Testing
The CIS CSC controls are available from www.cisecurity.org/controls
(registration required). The CIS CSC controls are also published by the
European Telecommunications Standards Institute (ETSI) as ETSI TR 103
305-1 V4.1.2, available at https://ipr.etsi.org/.
PCI DSS
Protect all systems against malware and regularly update antivirus software
or programs.
Develop and maintain secure systems and applications.
Track and monitor all access to network resources and cardholder data.
NIST CSF NIST developed the CSF in 2014 to address the rampant
occurrence of security breaches and identity theft in the United States. The
NIST CSF is an outcomes-based security management and control
framework that guides an organization in understanding its maturity levels,
assessing risk, identifying gaps, and developing action plans for strategic
improvement.
Policy Development
Considerations
Risk tolerance
Controls
Organizational culture
Security policy and controls need to be in alignment. This is not to say that
there must be a control for every policy or a policy for every control, but
policies and controls must not contradict each other. For example, suppose a
control states that no personally owned mobile devices may connect to
internal networks. In that case, the policy cannot state that those devices
may be used, provided no corporate information is stored on them. It also
makes sense for the structure of policies and controls to resemble one
another. This alignment makes it easier for personnel to become familiar
with the structure and content of policies and controls.
Security policy needs to align with the audience. In most organizations, this
means that policy statements need to be understood by most workers. A
common mistake in developing security policy is the inclusion of highly
technical policies such as permitted encryption algorithms or statements
about the hardening of servers. Such topics are irrelevant to most workers;
the danger of including policies that are irrelevant to most workers is that
they are likely to “tune out” and not pay attention to those policies that do
apply to them. In other words, security policy should have a high signal-to-
noise ratio.
Security policy structure comprises several different topics that may include
the following:
Mobile devices
Vulnerability management
Social media
Workplace safety
Visitors
Consequences of noncompliance
Cloud computing
Encryption
Privacy
Security managers can choose how to package these and other security
policies. For example, they may exist in separate documents or together in
one document. There is no right or wrong method; instead, a security
manager should determine what would work best in the organization by
observing how other policies are structured, published, and consumed.
Standards
It is said that policy states what to do, whereas standards describe how to do
it or what to do it with. Like policies, standards should be written down,
periodically examined and updated, approved by management, and
published so all personnel can find them.
Guidelines
In the password reset function, the system must provide visual information
indicating the strength of the proposed new password.
After five minutes of inactivity, the system must invoke an automatic lock
and require the user to reauthenticate to continue work.
The system must not contain comments, symbol tables, or other human-
readable information in its machine-readable state.
The system must use Microsoft SQL Server as its relational database
management system.
Functional and nonfunctional requirements can further be distinguished
in this way: nonfunctional requirements define what a system is supposed to
be, whereas functional requirements define what a system is supposed to
do. Arguably, some functional versus nonfunctional requirements may be
more difficult to distinguish; for instance, requiring that a system include a
specific encryption algorithm could be considered a nonfunctional
requirement, whereas requiring a system to encrypt data using a specific
algorithm could be considered a functional requirement. It matters little
whether such requirements are called functional or nonfunctional, however;
rather, requirements should be consistent in language and tone to ensure
that working with them is not a difficulty in itself.
While useful, these metrics do not address the bigger picture of the
effectiveness or alignment of an organization’s overall security program.
They do not answer key questions that boards of directors and executive
management often ask, such as the following:
Monitoring
Effective Metrics
Measurable
Attainable
Relevant
Timely
Leading indicator Does the metric help management predict future risk?
Strategic Alignment
For a security program to be successful, it must align with the
organization’s mission, strategy, goals, and objectives. A security program
strategy and objectives should contain statements that can be translated into
key measurements—the program’s key performance and risk metrics.
Based on these criteria, these metrics are all measurable, all align with
the security strategy, and are all leading indicators. If the metrics trend in an
unfavorable direction, this could indicate that a breach is more likely to
occur that would damage CareerSearchCo’s reputation and ability to earn
new business contracts from large corporations.
Types of Metrics
Compliance
Convergence
Value Delivery
Metrics on value delivery focus on the long-term reduction in costs, in
proportion to other measures. Examples of value delivery metrics include
the following:
Resource Management
Organizational Awareness
Operational Productivity
Organizational Support
Risk Management
There are, however, some metrics available that have meaning for
business executives. Examples include the following:
Operational Performance
Operational performance metrics generally show how well personnel are
performing critical security functions. Processes measured by these metrics
need to have sufficiently detailed business records so that metrics can be
objectively measured. These are some examples of operational performance
metrics:
Percentage of critical systems not patched with critical patches within the
service level agreement (SLA)
Audiences
Although there may be value in automated systems that keep records that
can be examined or measured later, there is often little point in developing
metrics with no audience in mind. Such a pursuit would merely take time
away from more valuable activities.
An ongoing debate has been raging for years on the return on investment
(ROI) of information security safeguards, known as return on security
investment, also known as ROSI (pronounced “rosy”). The problem with
investments in information security is that significant events such as highly
impactful security attacks are infrequent (occurring far less than once per
year for many organizations). Therefore, investments in information
security controls may not have a noticeable effect.
If there were no break-ins prior to implementing new security systems
and no break-ins afterward, an organization’s management may well
question whether the investment in new security systems was warranted.
Could the resources spent on security systems have been better spent in
other ways to increase service delivery capacity or production efficiency,
resulting in increased revenues or profits? Additionally, if a security
investment is made (for example, in security monitoring and vulnerability
management solutions), it may uncover new risks previously unknown to
the organization. So, the ROI is diminished, but the benefit is that a
previously unknown risk was identified.
It is easier to compute ROSI for events that occur more frequently. For
example, laptops and mobile devices are frequently lost and stolen in many
organizations, so investments in security controls of various types have a
more obvious benefit. However, security managers should keep in mind that
ROSI is only one of several means that help justify the expenditure of
resources on security capabilities. Other means include the following:
Chapter Review
Notes
The three lines of defense model, used often in banking, is a good model for
formally separating and defining roles related to control development,
operation, and assurance. A similar model can be used for policy
development.
Questions
Industry vertical
Compliance level
Policy
Charter
Standard
Control
Privacy policy
Data dictionary
Data classification policy
ISO/IEC 27001
ISO/IEC 27002
NIST SP 800-53
PCI DSS
Procedure
Policy
Standard
Guideline
Procedure
Requirements
Standard
Guideline
Procedure
Requirements
Standard
Guideline
Controls framework
Split custody
Separation of duties
D. The metric on time to patch critical servers will be the most meaningful
metric for the board of directors. While potentially interesting at the
operational level, the other metrics do not convey business meaning to
board members.
D. The three lines of defense model describes the separate roles in control
management as development, operations, and assurance (audit).
CHAPTER 6
Information Security Program Management
Supporting Tasks in the CISM job practice that align with the
Information Security Program / Information Security Program Development
domain include:
Establish, promote, and maintain a program for information security
awareness and training.
Audit result The results of a recent audit may indicate a trouble spot
warranting additional attention and care.
Control Classification
Before exploring the steps used to create and manage a control, you should
understand the characteristics, or classifications, of controls. Several types,
classes, and categories of controls are discussed in this section. Figure 6-1
depicts this control classification.
Figure 6-1 Control classification shows types (along the right side of the
box), classes (at the front of the box), and categories (at the top) of controls.
You can look at controls in many different ways, which can help you better
understand them and how they work. In this book, controls are described
using the words “types,” “classes,” and “categories.” The use of these three
terms is not set in stone, and there is no standard way of modeling controls
using these or other terms. In fact, the depiction of controls in this book by
type, class, and category is purely arbitrary, but these terms can be useful in
helping information security managers, information security auditors, and
other security personnel understand controls and how they contribute to the
protection of assets.
Types of Controls
EXAM TIP ISACA does not expressly use the terms “type,” “class,” or
“category” in its literature or on the exam to describe and distinguish the
variety of controls and their basic characteristics. These terms are used in
this book to highlight the multidimensional nature of controls and how they
can be understood and classified. Like other constructs, these are models
that help you better imagine how controls operate and are used.
Classes of Controls
There are six classes of controls, which speak to their relationship with
unwanted outcomes:
Detective This type of control is used to record both wanted and unwanted
events. A detective control cannot enforce an activity (whether it is desired
or undesired), but it can ensure that the appropriate security personnel are
notified of whether, and how, an event occurred. Examples of detective
controls include video surveillance and event logs.
NOTE Many controls can fit into more than one class. For example, a
video surveillance camera can be both a detective control (because it is part
of a system that records events) and a deterrent control (because its
visibility is designed to discourage persons from committing unwanted
acts). Also, an audit log can be both a detective control and a compensating
control—detective because it records events, and compensating because it
may compensate for a lack of a stronger, preventive control, such as a user
IDs and password access control.
Categories of Controls
There are two categories of controls that relate to the nature of their
operation:
Control Objectives
Accuracy of transactions
Availability of IT systems
Together, these five (or more) controls contribute to the overall control
objective on IT system availability. Similarly, the other control objectives
will have one or more controls that will ensure their realization.
Passwords are encrypted while stored and transmitted and are not displayed.
In years past, organizations often custom designed and built their core
business applications. Today, however, the majority of organizations buy (or
lease) core business applications. And, increasingly, organizations no longer
build their own data centers, opting instead to lease data center space from
colocation providers or cloud providers.
In part, the build versus buy argument is related to an organization’s
mission and core competencies. For instance, a new social media company
may decide to lease serverless computing platforms rather than buy servers,
claiming that the company specializes in social media, not data centers,
computer hardware, or operating systems.
Control Frameworks
Gut feeling
EXAM TIP CISM candidates are not required to memorize the specifics
of COBIT or other frameworks, but a familiarity with them will help the
candidate better understand how they contribute to effective security
governance and control.
Organizations may find that more than one control framework needs to be
selected and adopted. The primary factors driving this are as follows:
The control in NIST SP 800-53 Rev 5 is far more specific than the
control in ISO/IEC 27002:2022, making this a good example of an
imperfect mapping.
In another example, on the topic of audits and audit tools, NIST SP 800-
53 Rev 5 AU-9 does not clearly map to any control in ISO/IEC
27002:2022. The closest control in ISO is control 8.34. The text of each
control reads as follows:
These controls do not map together well at all. In the earlier version of
ISO/IEC 27002, control 15.3.2 reads, “Access to information systems audit
tools should be protected to prevent any possible misuse or compromise.”
Unfortunately, in the newer revisions of these standards, for this control, the
mapping has diverged and is less clear now. Thus, mapping controls
requires continual effort.
The control may be too rigorous and costly (in the case of a moderate or
low risk).
Defense in depth
Split custody
Separation of duties
Work from home (WFH) The shift of global workforces to working from
home on a part-time or full-time basis changes the risk landscape for
individual workers, particularly on the topics of physical security, endpoint
management, and LAN management.
ISO/IEC 27002
ISO/IEC 27002 is available from www.iso.org. This and most other ISO
standards are fee-based, meaning that they must be purchased and have
licensing and usage restrictions that govern their use in an organization.
Generally, these standards are purchased in single quantities and are “single
user” in nature, and they are not permitted to be stored on file servers for
use by multiple users.
NIST SP 800-53
The Center for Internet Security (CIS) maintains a popular and respected
control framework called the CIS Critical Security Controls (CIS CSC).
While CIS CSC currently includes 18 control objectives, it included 20
control objectives for many years and is still commonly known as the “CIS
20” or the “SANS Top 20.” Still occasionally referred to as the “SANS 20
Critical Security Controls,” this control framework was originally
developed by the SANS Institute.
Table 6-5 shows the structure of the CIS CSC control framework.
Table 6-5 CIS CSC Framework (Source: The Center for Internet Security
(CIS) www.cisecurity.org)
The CIS CSC framework is structured in a way that makes it easy for
security practitioners to understand and use. Within each control category is
a section entitled “Why Is This Control Critical?” followed by the
individual controls. This is followed by a section called “Procedures and
Tools” that provides additional guidance. Finally, each control category
includes a system entity relationship diagram that depicts the control’s
implementation in an environment. Many consider the CIS CSC a more
pragmatic and less academic framework than NIST SP 800-53 or PCI DSS.
The CIS CSC framework includes one or more controls within each
control category. Some controls are flagged as “foundational,” meaning
they are essential in any organization. The controls not marked as
“foundational” may be considered optional.
Repeatable Risk management practices are formal and approved. The risk
management program is integrated into the business. External parties are
engaged so that the organization can respond to events. Supply chain risk
management process is governed.
The PCI DSS is a control framework whose main objective is the protection
of cardholder data. PCI DSS was developed by the PCI Security Standards
Council, an organization founded by the major credit card brands in the
world including Visa, MasterCard, American Express, Discover, and JCB.
The PCI Security Standards Council has also defined business rules
around the PCI DSS standard. There is a tier structure based on the number
of credit card transactions; organizations whose credit card volume exceeds
set limits are subject to onsite annual audits, while organizations with lower
volumes are permitted to complete annual self-assessments. There is also a
distinction between merchants (retail and wholesale establishments that
accept credit cards as a form of payment) and service providers (all other
organizations that store, process, or transmit credit card data); service
providers are required to comply with additional controls.
NOTE The PCI Security Standards Council release version 4.0 of the PCI
DSS standard takes effect in March 2024. The structure of the 4.0 standard
is nearly identical with the structure of the 3.2.1 standard.
COBIT 2019
COBIT 2019 includes more than 1100 control activities to support these
principles. Established in 1996 by ISACA and the IT Governance Institute,
COBIT is the result of industry-wide consensus by managers, auditors, and
IT users. Today, COBIT 2019 is accepted as a best-practices IT process and
control framework. COBIT has absorbed ISACA’s Risk IT Framework and
Val IT Framework.
COSO
Self-assessment
Third-party Audit
More information on CSA and CCM is available at
cloudsecurityalliance.org.
The SOC 1, SOC 2, and SOC 3 audit standards are discussed next.
System and Organization Controls 1 In 2010, the SAS-70 standard was
superseded by the Statement on Standards for Attestation Engagements No.
16 (SSAE 16) standard in the United States and by International Standards
on Assurance Engagements No. 3402 (ISAE 3402) outside the United
States. In 2017, SSAE 16 was replaced with SSAE 18. Together, SSAE 16,
SSAE 18, and ISAE 3402 are commonly known as System and
Organization Controls 1 (SOC 1).
In a SOC 1 audit, the service organization specifies the controls that are
to be audited. While a service organization has complete latitude on which
controls are in scope for a SOC 1 audit, the service organization must be
mindful of which controls its customers and their internal and external
auditors will expect to see in a SOC 1 audit report.
Type II This audit takes place over a period of time (typically three
months to one year), where the auditor examines not only the design of in-
scope controls (as in Type I) but also business records that reveal whether
controls are effective.
Several controls are included within each trust principle. All controls
within each selected trust principle are included in a SOC 2 audit.
After a control has been designed, it needs to be put into service and then
managed throughout its life. Depending upon the nature of the control, this
could involve operational impact in the form of changes to business
processes and/or information systems. Changes with greater impact will
require greater care so that business processes are not adversely affected.
Controls Development
For organizations that elect to develop their controls from scratch, the first
step is the development of high-level control objectives. These control
objectives could be thought of as overarching principles from which
individual controls will be developed. Control objectives are typically
similar from organization to organization. However, since each organization
is different, some organizations will have one or two unique control
objectives that address specific business activities or objectives.
Approval date The date of the most recent approval of the control.
Version The version number of the control, according to whatever version
numbering system is used by the organization.
Controls must have control owners, who are responsible for proper
operation of each control. When an organization implements new controls,
control owners should be identified and trained on the operation of the
controls they are responsible for. Ideally, control ownership and training is
included in the control life cycle to ensure that control owners are identified
and trained prior to the control being placed into operation.
Controls that have been placed into service will transition into routine
operations. Control owners will operate their controls and try to be aware of
any problems, especially those that appear early on. Whether controls are
automatic or manual, preventive or corrective, control owners are
responsible for ensuring that their controls operate correctly in every
respect.
Event monitoring
Vulnerability management
Network protection
Data security
Business continuity planning
Event Monitoring
Event monitoring is the practice of examining the security events that occur
on information systems, including applications, operating systems, database
management systems, end-user devices, and every type and kind of network
device, and then providing information about those events to the
appropriate people or systems.
Often, one or more scanning tools, such as the following, are used to
scan target systems in the search for vulnerabilities:
Periodic scanning One or more tools are used to scan assets in the
organization to search for vulnerabilities and discover new devices.
Reconnaissance
Resource development
Initial access
Execution
Persistence
Privilege escalation
Defense evasion
Credential access
Security scan One or more vulnerability scanning tools are used to help
identify easily found vulnerabilities in target systems. A security scan will
identify a vulnerability in one or two ways: by confirming the version of a
target system or program that is known to be vulnerability, or by making an
attempt at proving the existence of a vulnerability by testing a system’s
response to specific stimulus.
Penetration test A security scan, plus additional manual tests that security
scanning tools do not employ, are used in a penetration test, which is
intended to mimic a realistic attack by an attacker who intends to break into
a target system. A penetration test of an organization’s production
environment may fall somewhat short of the techniques used by an actual
attacker, however. In a penetration test, a tester is careful not to exploit
vulnerabilities that could result in a malfunction of the target system. Often,
an actual attacker will not take this precaution unless he or she wants to
attack a system without being noticed. For this reason, it is sometimes
desirable to conduct a penetration test of nonproduction infrastructure, even
though nonproduction environments are often not identical to their
production counterparts.
Design With proper input at the requirements stage, product designs are
more likely to be secure. Security managers’ involvement in design reviews
will ensure that initiatives are heading in the right direction.
Network Protection
Firewalls Firewalls are network devices that are used to control the
passage of network traffic from one network to one or more other networks.
Firewalls are typically placed at the boundary of an organization’s network
and other, external networks. Organizations also use firewalls to logically
separate internal networks from each other; examples include the following:
A data center network is often protected from other internal networks with
a firewall.
Permit e-mail from the entire Internet to reach the e-mail server at
141.204.10.22 only.
Permit DNS from the entire Internet to reach the DNS server at
141.204.10.24 only.
Permit NNTP traffic from the entire Internet to reach time server at
141.204.10.22 only.
Permit all users to access the entire Internet on ports 80 and 443 (HTTP and
HTTPS protocols) only.
Deny all other traffic from the Internet on all ports from reaching any
internal system.
Some IPSs can import information from a threat intel feed, which is a
subscription service about known threats. A threat intel feed often contains
IP addresses associated with known malicious sites; an IPS will
automatically block traffic being transmitted to or from those IP addresses.
In addition to blocking malicious traffic, an IPS can also permit suspect
traffic, log the event, and optionally create an alarm. This falls into the
category of network traffic that may or may not be malicious. This would
serve to alert personnel who can investigate the event and take necessary
action.
Traffic between two systems at a higher volume than has been observed
before
Traffic between two systems taking place at a different time of day than has
been observed before
There are two main types of NTA systems. The first is a dedicated
system (an appliance or virtual machine) that collects network traffic data
from various points in the network, as depicted in Figure 6-6. The second
method is the use of detailed event logging in core routers and firewalls that
are sent to a SIEM, where NTA detection rules are established. These two
methods can achieve the same goal: detection of unusual network traffic
that may be signs of an intrusion or other unwanted event in the network.
A simple way to make all network traffic available for these detective
systems is to place security appliances inline in the network so that they can
analyze all network traffic. However, network managers are often reluctant
to place inline security tools in the network because they can impact
network performance, and they would serve as an additional single point of
failure.
Packet sniffers can retain specific types of packets for later analysis. For
instance, if a network engineer is troubleshooting a domain name system
(DNS) problem, the engineer can capture just the DNS packets so that she
can examine the contents of those packets, in hopes that this will lead to a
solution to the problem. Because the types of problems that an engineer
may be troubleshooting can vary, packet sniffers display packets in different
ways, from Ethernet frames, to TCP/IP packets, to application messages.
Figure 6-7 shows the popular Wireshark packet-sniffing tool running on
macOS.
Initial web content filtering products took the form of inline devices
located in an organization’s data center, thereby protecting all users
connected to the internal network. But with more organizations employing
remote workers, newer web content filtering products take the form of
software agents installed on endpoints so that web content protection takes
place regardless of each user’s location.
On consumer devices, end users can easily change the DNS servers from
the network-supplied default to any of several well-known public DNS
servers, thereby bypassing any local DNS filters. However, organizations
can lock down the network configuration of their devices, preventing
employees from changing DNS settings and thereby preserving protections
provided by their DNS filters.
Built-in rules are used to determine whether any individual e-mail message
should be blocked.
Blocked e-mails are stored in quarantine. End users can typically access
their quarantine to view messages and release (to their e-mail inbox)
messages that should not have been blocked.
Smishing Phishing messages are sent via SMS messages to users’ mobile
devices and smartphones. Note that enterprise security tools have little
visibility or control over SMS content.
Spear phishing Phishing messages are specially crafted for a target group
or organization.
Security patches and configurations are current and comply with policy
Resource access Known users are permitted to access only the resources
that are specifically allowed. Additional policies may include:
Logging All of the preceding activities are logged to a SIEM and/or user
behavior analytics (UBA) system for further analysis that could result in
alerts or alarms if business rules are violated. Well-known rules could be
tied to a SOAR-TIP platform that would automatically disconnect the user
and the device being used if an access violation has occurred.
The term endpoint now includes smartphones, tablets, laptops, and desktop
computers. Endpoints are used to create, process, distribute, and store
sensitive information in organizations.
Remote control A typical computer support team will use a tool that
permits them to access running endpoint systems remotely. Some of these
tools permit covert remote access to a user’s endpoint system without the
user’s knowledge. Most of these tools require that the end user initiate a
session whereby a computer support person is granted remote access and
control of an endpoint for the purpose of assistance and troubleshooting.
The creators of malware have won the battle. The techniques used to
create malware include a process known as packing, whereby the malware
program is packaged into an executable (EXE) file. Today, many species of
malware repackage themselves prior to attacking each successive endpoint
and employ some randomness in the process. The result is that each
infected endpoint’s virus signature is unique and will never again be seen in
the world. Signature-based antivirus software cannot deal with that and has
therefore run its course.
For decades, a thorny problem with endpoint and end-user management lay
in the capability of end users. In earlier versions of Microsoft Windows, end
users were automatically given the role of “local administrator.” This had
two primary implications:
End users were able to install programs, install drivers, and change system
configuration at will, thereby relieving the IT service desk of having to do
these actions themselves. While this practice relieving the service desk of
drudgery, if an end user botched an install or destroyed the system’s
registry, service desk personnel had to recover the end user’s system, which
sometimes required hours of work.
Malware often executes at the same privilege level as the end user, so when
the end user is a local administrator, malware has the run of the machine
and can do anything it needs, without restriction. This can make malware
attacks far more potent, because the malware can alter any portion of the
operating system.
Assisting workers whose accounts have been locked out for various reasons
Analysis of all users with a particular set of access rights to one or more
information systems
ACCUMULATION OF PRIVILEGES
Users who work in an organization for many years may, during their tenure,
hold a number of positions in one or more departments. When a user moves
from one department to another, the user will require access to new roles or
information systems. Over many years, a user may have access to many
more information systems and roles than are needed in his or her current
role. This phenomenon is known as accumulation of privileges.
The user may be training a user who replaced them in their prior position.
The user may be in the middle of a project that they will complete.
User and entity behavior analytics (UEBA) is functionally similar (if not
identical) to EUBA and UBA.
Managed SIEM
Access management
Data classification
Backup and Recovery Many types of events can damage information, and
some circumstances compel an organization to revert to earlier versions of
information. It’s essential that copies of stored information exist elsewhere
and in a form that enables IT personnel to load this information easily into
systems so that processing can resume as quickly as possible.
Backup to Tape and Other Media In organizations still utilizing their own
IT infrastructure, tape backup is just about as ubiquitous as power cords.
From a disaster recovery perspective, however, the issue probably is not
whether the organization has tape backup but whether its current backup
capabilities are adequate in the context of disaster recovery. There are times
when an organization’s backup capability may need to be upgraded:
If the system lacks flexibility with regard to disaster recovery (for instance,
a high level of difficulty would be required to recover information onto a
different type of system)
While tape has been the default backup medium since the 1960s, using
hard drives and solid-state drives (SSDs) as backup media is growing in
popularity: hard disk transfer rates are far higher (and SSDs higher still),
and disks/SSD are random-access media, whereas tape is a sequential-
access medium. A virtual tape library (VTL) data storage technology sets
up a disk-based storage system with the appearance of tape storage,
permitting existing backup software to continue to back data up to “tape,”
which is really just more disk storage.
Backup Schemes Three main schemes are used for backing up data:
Incremental backup A copy of all data that has changed since the last full
or incremental backup
Differential backup A copy of all data that has changed since the last full
backup
Recovery requirements
An organization that is creating a backup scheme usually starts with the
most common scheme, which is a full backup once per week and an
incremental or differential backup every day. However, as stated previously,
various factors will influence the design of the final backup scheme. Here
are some examples:
A small data set could be backed up more than once a week, while an
especially large data set may be backed up less often.
Backup Media Storage Backup media that remains in the same location as
backed-up systems is adequate for data recovery purposes but completely
inadequate for disaster recovery purposes: any event that physically
damages information systems (such as fire, smoke, flood, hazardous
chemical spill, and so on) is also likely to damage backup media that is
stored nearby. To provide disaster recovery protection, backup media must
be stored off site in a secure location. Selection of this storage location is as
important as the selection of a primary business location: in the event of a
disaster, the survival of the organization may depend upon the protection
measures in place at the offsite storage location.
EXAM TIP CISM exam questions relating to offsite backups may include
details for safeguarding data during transport and storage, mechanisms for
access during restoration procedures, media aging and retention, or other
details that may aid you during the exam. Watch for question details
involving the type of media, geolocality (distance, shared disaster spectrum
such as a shared coastline, and so on) of the offsite storage area and the
primary site, or access controls during transport and at the storage site,
including environmental controls and security safeguards.
The criteria for selection of an offsite media storage facility are similar
to the criteria for selection of a hot/warm/cold recovery site, discussed in
Chapter 7. If a media storage location is too close to the primary processing
site, it is more likely to be involved in the same regional disaster, which
could result in damage to backup media. However, if the media storage
location is too far away, it may take too long for a delivery of backup
media, which would result in an unacceptably long recovery operation.
Another location consideration is the proximity of the media storage
location and the hot/warm/cold recovery site. If a hot site is being used,
chances are there is some other near real-time means (such as replication)
for data to get to the hot site. But a warm or cold site may be relying on the
arrival of backup media from the offsite media storage facility, so it may
make sense for the offsite facility to be near the recovery site.
Static DLP These tools are used to scan unstructured data storage systems
for sensitive information. They can be effective at discovering sensitive
data that personnel copy to file servers. Often, users will export sensitive
data out of a business application to a spreadsheet and store that data on a
file server or cloud-based file storage service. Sometimes this sensitive data
is readable by most or all organization personnel and even personnel
outside of the organization.
Dynamic DLP These tools reside in, or communicate with, file storage
systems, USB-attached removable storage devices, and e-mail systems, and
they are used to detect and even block the movement of sensitive data.
Depending on the nature of the data being moved, users may be warned of
the activity they are undertaking or their actions may be blocked.
These uses are proprietary and exist as islands of control, as there are no
standards that work across multiple technologies or uses.
Cryptography
With encryption, best practices call for system designers to use well-
known, robust encryption algorithms. Thus, when a third-party intercepts
encrypted data, the third party can know which algorithm is being used but
still not be able to read the data. What the third party does not know is the
key that is used to encrypt and decrypt the data. How this works will be
further explained in this section.
Images
Digital signature The result of encrypting the hash of a message with the
originator’s private encryption key, used to prove the authenticity and
integrity of a message. This is depicted in Figure 6-11.
Images
Secure Key Exchange Secure key exchange refers to methods used by two
parties to establish a symmetric encryption key securely without actually
transmitting the key over a channel. Secure key exchange is needed when
two parties, previously unknown to each other, need to establish encrypted
communications where no out-of-band channel is available. Two parties can
perform a secure key exchange if a third party intercepts their entire
conversation. This is because algorithms used for secure key exchange
utilize information known by each party but not transmitted between them.
The most popular algorithm is the Diffie–Hellman key exchange protocol.
Key Pair The encryption keys used in public key cryptography are called
the public key and the private key. Each user of public key cryptosystems
possesses this key pair. The two keys require different handling and are
used together but for different purposes, as explained in the following
paragraphs. When a user generates a key pair, the key pair will physically
exist as two separate files. The user is free to publish or distribute the public
key openly; it could even be posted on a public web site. This is in contrast
to the private key, which must be well protected and never published or sent
to any other party. Most public key cryptosystems utilize a password
mechanism to further protect the private key; without its password, the
private key is inaccessible and cannot be used.
User A creates a message and encrypts it with User B’s public key and
sends the encrypted message to User B.
User B decrypts the message with his private key and is able to read the
message.
Note that only User B’s encryption key is used in this example. This
method protects the message from eavesdroppers, but it is not used to verify
the authenticity of the message.
Public key cryptography can also be used to verify the authenticity and
integrity of a message—to verify that a specific party did, in fact, create the
message. The procedure is as follows:
User B retrieves User A’s public key and saves it for later use.
User A creates a message and digitally signs it with his private key and then
sends the signed message to User B.
User B verifies the digital signature using User A’s public key. If the
message verifies correctly, User B knows that the message originated from
User A and has not been altered in transit.
User A retrieves User B’s public key, and User B retrieves User A’s public
key.
User A creates a message, signs it with his private key and encrypts it with
User B’s public key, and then sends the message to User B.
User B decrypts the message with his private key and verifies the digital
signature with User A’s public key.
Certificate authority (CA) A public key that has been obtained from a
trusted, reputable CA can be considered genuine.
E-mail address Public keys used for e-mail will include the user’s e-mail
address. If the e-mail address is part of a corporate or government domain
(for example, apple.com or seattle.gov), then some level of credence can be
attributed to the successful exchange of messages with that e-mail address.
However, since e-mail addresses can be spoofed, this should be considered
a weak method at best.
NOTE When issuing a public key, it is essential that the requestor of the
new public key be authenticated, such as by viewing a government-issued
ID or by contacting the owner at a publicly listed telephone number.
It is infeasible to find any two messages that will have the same hash.
The sender publishes his public key to the Internet at a location that is easily
accessible to recipients.
The recipient retrieves the sender’s public key and saves it for later use.
The sender creates a message (or file) and computes a message digest
(hash) of the message and then encrypts the hash with his private key.
The sender sends the original file plus the encrypted hash to the recipient.
The recipient receives the original file and the encrypted hash. The recipient
computes a message digest (hash) of the original file and sets the result
aside. She then decrypts the hash with the sender’s public key. The recipient
compares the hash of the original file and the decrypted hash.
If the two hashes are identical, the recipient knows that (a) the message in
her possession is identical to the message that the sender sent, (b) the sender
is the originator, and (c) the message has not been altered.
The sender and recipient agree that the sender will transmit a large message
to the recipient.
The sender sends the encrypted message (encrypted with the session key)
and the encrypted session key (encrypted with the recipient’s public key) to
the recipient.
The recipient decrypts the session key with his private key.
Key Protection Private keys used in public key cryptosystems and keys
used in symmetric cryptosystems must be continuously and vigorously
protected. At all times, they must be accessible only to the parties that are
authorized to use them. If protection measures for private encryption keys
are compromised (or suspected to be), it will be possible for a key
compromise to take place, enabling the attacker to view messages encrypted
with these keys and create new encrypted messages in the name of the key’s
owner. A key compromise is any event whereby a private encryption key or
symmetric encryption key has been disclosed to any unauthorized third
party. When a key compromise occurs, it will be necessary to re-encrypt all
materials encrypted by the compromised key with a new encryption key.
Key Custody Key custody refers to the policies, processes, and procedures
regarding the management of keys. This is closely related to key protection
but is focused on who manages keys and where they are kept.
Key Rotation Key rotation is the process of issuing a new encryption key
and re-encrypting data protected with the new key. Key rotation may occur
when any of the following occurs:
Secure Sockets Layer and Transport Layer Security Secure Sockets Layer
(SSL) and Transport Layer Security (TLS) are the encryption protocols
used to encrypt web pages requested with the Hypertext Transfer
Protocol/Secure (HTTPS) protocol. Introduced by Netscape
Communications for use in its own browser, SSL and its successor, TLS,
have become de facto standards for the encryption of web pages.
Control Monitoring
A control needs to have been designed so that monitoring can take place. In
the absence of monitoring, the organization will lack methodical means for
observing the control to determine whether it is effective. For example,
suppose an organization identified a risk during a risk assessment that
indicated that its user accounts were vulnerable to brute-force password
guessing. The organization decided to change the login process on affected
systems so that incorrect passwords would result in a small delay before the
user could re-attempt to log on (to counter machine-driven password
guessing) and that user accounts would be temporarily locked out after five
unsuccessful attempts within a five-minute period. To facilitate monitoring,
the organization also changed the login process to create audit log entries
each time a user attempted to log in, regardless of the outcome. This
provided the organization with event data that could be examined from time
to time to determine whether the control was performing as intended.
Security Reviews
Security reviews are generally less rigorous than security audits. Security
reviews are generally devoid of rules for evidence collection, types of
testing, or sampling techniques. For instance, a security review of a firewall
configuration may glance at its rules, whereas an audit may examine each
individual rule: its purpose and meaning, who approved it, and when it will
next be reviewed.
Audits
There are generally two parties in an audit: the auditor and the auditee.
This is true whether the audit is formal or informal and whether it’s internal
or external. In terms of the context of an audit, there are two types: internal
audit and external audit. These have to do with who performs the audit and
why. Otherwise, the methodologies and techniques used in auditing are the
same.
NOTE For a more complete discussion on audits and auditing, see CISA
Certified Information Systems Auditor All-in-One Exam Guide, Fourth
Edition (McGraw Hill, 2020).
Purpose The auditor and the auditee must establish why an audit is to be
performed. The purpose for a particular audit could be to determine the
level of compliance to a particular law, regulation, standard, or contract.
Another reason could be to determine whether specific control deficiencies
identified in past audits have been remediated. Still another reason is to
determine the level of compliance to a new law, standard, or contract that
the organization may be subject to in the future.
Scope The auditor and the auditee must also establish the scope of the
audit. Often, the audit’s purpose will make the scope evident, but not
always. Scope may be multidimensional: it could involve a given period in
which the body of evidence includes records spanning from a start date to
an end date, or it could involve geography (systems in a particular region or
locale), a technology (systems using a specific operating system, a database,
application, or other aspect), a business process (systems that support
specific processes such as accounting, order entry, or customer support), or
a segment of the organization.
Audit procedures The purpose and scope of the audit may help to define
the procedures that will be required to perform the audit. For a compliance
audit, for example, there may be specific rules on sample sizes and
sampling techniques, and auditors may be required to possess specific
qualifications. A compliance audit may also specify criteria for determining
whether a particular finding constitutes a deficiency. There may also be
rules for materiality and additional steps to follow if material weaknesses
are identified.
Resources The auditor must determine what resources are needed and
available for the audit. In an external audit, the auditee (a client
organization) may have a maximum budget figure available. For an external
or internal audit, the auditor needs to determine the number of person-hours
that will be required in the audit and the various skills required. Other
resources that may be needed include specialized tools to gather or analyze
information obtained from information systems—for example, an analysis
program to process the roles and permissions in a database management
system to identify high-risk areas. To a great degree, the purpose and scope
of the audit will determine which resources are required to complete it.
Schedule The auditor needs to develop an audit schedule that includes
enough time for interviews, data collection and analysis, and report
generation. Additionally, the schedule could also come in the form of a
constraint, meaning the audit must be complete by a certain date. If the
auditor is given a deadline, she will need to see how the audit activities can
be made to fit within that period. If the date is too aggressive, the auditor
will need to discuss the matter with the auditee to make required
adjustments in scope, resources, or schedule.
Audit Objectives The audit objectives are the specific goals for an audit.
Generally, the objective of an audit is to determine whether controls exist
and whether they are effective in some specific aspect of business
operations in an organization. An audit is often performed as a requirement
of regulations, compliance, or other legal obligations. It may also be
performed in the aftermath of a serious incident or event to determine
whether any additional weaknesses are found elsewhere in the organization
that could also suffer an event. Sometimes, an organization will initiate an
internal audit of relevant systems if a competitor or other similar
organization has suffered an incident; the purpose here is to determine
whether the organization is likely to suffer the same fate.
Depending on the subject and nature of the audit, the auditor may
examine the controls and related evidence herself, or the auditor may
instead focus on the business content that is processed by the controls. In
other words, if the focus of an audit is an organization’s accounting system,
the auditor may focus on financial transactions in the system to see how
they affect financial bookkeeping. Or the auditor could focus on IT
processes that support the operation of the financial accounting system.
Formal audit objectives should make such a distinction so that the auditor
has a sound understanding of the objectives. This tells the auditor where to
look and what to look at during the audit. Of course, the type of audit being
undertaken helps too.
Audit objective Identify the purpose of the audit. For example, the audit
may be required by a law, regulation, standard, or business contract, or to
determine compliance with internal control objectives to measure control
effectiveness.
This and other information will enable the auditor to determine the skills
required to examine and evaluate processes and information systems. The
auditor will be able to establish an audit schedule and will have a good idea
of the types of evidence that are needed. The IS audit may be able to make
advance requests for certain other types of evidence even before the onsite
phase of the audit begins.
Precede the audit itself with a risk assessment to determine which processes
or controls warrant additional audit scrutiny.
Audit Statement of Work For an external audit, the auditor may need to
develop a statement of work or engagement letter that describes the audit
purpose, scope, duration, and costs. The auditor may require a written
approval from the client before audit work can officially begin.
Regular written status reports that include activities performed since the last
status report, upcoming activities, and any significant findings that may
require immediate attention
Regular status meetings where audit progress, issues, and other matters may
be discussed in person or via conference call
Contact information for both IS auditor and auditee so that both parties can
contact each other quickly if needed
Report Preparation The auditor needs to develop a plan that describes how
the audit report will be prepared. This will include the format and the
content of the report, as well as the manner in which findings will be
established and documented. The auditor must ensure that the audit report
complies with all applicable audit standards, including ISACA IS audit
standards. If the audit report requires internal review, the auditor should
identify the parties that will perform the review and make sure they will be
available at the time when the auditor expects to complete the final draft of
the audit report.
Schedule a closing meeting so that the results of the audit can be discussed
with the auditee and so that the auditor can collect feedback.
Update PBC documents if the auditor anticipates that the audit will be
performed again in the future.
Collect feedback from the auditee and convey to any audit staff as needed.
Post-audit Follow-up
After a given period (which could range from days to months), the auditor
should contact the auditee to determine what progress the auditee has made
on the remediation of any audit findings. There are several good reasons for
doing this:
Objectivity
Timing
Gathering Evidence The auditor must understand and be experienced in
the methods and techniques used to gather evidence during an audit,
including the following:
Review of IS standards
Personnel interviews
Passive observation
Real tasks The auditor should request to see some functions actually
being carried out.
Skills and experience The auditor should ask each interviewee about his
or her career background to determine the interviewee’s level of experience
and career maturity.
Reporting Audit Results The work product of an audit project is the audit
report, which describes the entire audit project, including audit objectives,
scope, controls evaluated, opinions on the effectiveness and integrity of
those controls, and recommendations for improvement. While an auditor or
audit firm will generally use a standard format for an audit report, some
laws and standards require that an audit report regarding those laws or
standards contain specific information or be presented in a particular
format. Still, there will be some variance in the structure and appearance of
audit reports created by different audit organizations. The auditor is
typically asked to present findings in a closing meeting, where he can
explain the audit and its results and be available to answer questions about
the audit. The auditor may include an electronic presentation to guide
discussion of the audit.
Structure and Contents While there are often different styles for
presenting audit findings, as well as regulations and standards that require
specific content, an audit report will generally include several elements:
Cover letter
Introduction
Summary
Listing of interviewees
When the auditor is creating the report, she must make sure that it is
balanced, reasonable, and fair. The report should not just be a list of
everything that was wrong; it should also include a list of controls that were
found to be operating effectively. The auditor also needs to take care when
describing recommendations, realizing that any organization is capable of
only so much change in a given period. If the audit report contains many
findings, the auditor should realize that the organization may not be able to
remediate all of them in an elegant manner. Instead, the organization will
need to understand which findings should be remediated first—the audit
report should provide this guidance.
Cyclical controls testing (SOX, ISO/IEC 27001, and OMB Circular A-123,
for example)
TIP The Institute of Internal Auditors (IIA) has excellent guidance for
audit planning at www.theiia.org.
Time What is the time period for the audit? This generally involves the
acquisition of evidence in the form of business records associated with
controls that auditors will want to examine.
Resources What resources will be required for the audit? For external
audits, this includes office space for one or more auditors, access to
workspaces, and access to networks and systems for the acquisition of
evidence.
Schedule When will the audit start? When will specific activities take
place during the audit? When is it expected to be completed?
Audit firm and auditor qualifications Has the firm or auditor conducted
the type of audit before? If so, how many audits have they done and in what
business segments was the audit conducted? Organizations should assess
the quality of the firm and the people conducting the audit when using
external audit firms.
Personnel What internal personnel will be needed for the audit? This
includes process and system owners that auditors will want to interview,
plus any administrators or coordinators who will manage the scheduling of
internal personnel as well as meeting spaces.
Organizations undergoing any particular audit for the first time generally
plan much further ahead. In many cases, a pre-audit will get a preliminary
idea of the results that will be achieved in the actual audit. Organizations
planning a pre-audit need to ensure that the same techniques used in the
pre-audit will be used in the audit. This is a common mistake in a pre-audit.
If the pre-audit is less rigorous and thorough than the audit, the organization
may have a false sense of confidence in a favorable audit outcome; they
will be surprised that the audit went poorly while the pre-audit was
seemingly successful.
Organizations should ensure that personnel are ready for the audit. In
particular, personnel who have never worked with external auditors need to
be coached as follows:
Personnel should answer only questions that auditors ask. Personnel should
be trained in the skill of active listening so that they understand what the
auditor is asking, prior to giving an answer.
Personnel should not express their opinions about the subject matter.
Determination of the effectiveness of a control is the auditor’s job, not that
of the control owner or other person providing information.
Management may spend considerable time and energy making sure that
personnel understand one thing when dealing with auditors: they should
specifically answer the question that the auditor asked, not the question the
auditor should have asked, and they should not volunteer any information.
Control Self-Assessment
CSA may be considered an attempt by the auditor to shrug off his or her
own responsibilities.
Identify and assess risks Operational risks are identified and analyzed.
Identify and assess controls Controls to manage risks are identified and
assessed. If any controls are missing, new controls are designed.
Awareness training This activity is carried out through every phase of the
life cycle to keep personnel informed about the activities in the various
phases.
Corporate workers All use computers, and most use mobile devices for
e-mail and other functions.
Retail floor managers These people work in retail store locations and use
computers daily in their jobs.
Retail floor cashiers All work in retail store locations and do not use
computers, but they do collect payments by cash, check, and credit card.
Retail floor workers All work in retail store and warehouse locations and
do not use computers.
Technical Workers
Software Developers
Cryptographic failures
Vulnerabilities that permit injection attacks
Insecure design
Security misconfiguration
Cross-site scripting
Underprotected APIs
This list is adapted from the “Top 10 Web Application Security Risks,”
published by the Open Web Application Security Project (OWASP), at
https://owasp.org/www-project-top-ten/. This organization is dedicated to
helping software developers better understand the techniques needed for
secure application development and deployment.
Security training for software developers should also include protection
of the software development process itself. Topics in secure software
development generally include the following:
Protection of systems used to store source code, edit and test source code,
build applications, test applications, and deploy applications
Third Parties
New Hires
Training takes time, and people tend to put it off for as long as possible.
This is easy to understand, because training takes time away from other
important work tasks. Still, the security manager and the organization must
ensure that as many workers as possible complete the training. Workers can
be offered incentives to complete their training: for example, all workers
who complete their training in the first week can be entered into a random
drawing for gift cards or other prizes.
Internal web site Organizations with internal web sites or web portals
may from time to time include information security messages.
TPRM extends the techniques used to identify and treat risk within the
organization to include risks present in other organizations that provide
services. TPRM exists because of the complexities associated with
identifying risks in third-party organizations and because of risks inherent
in doing business with third parties. At the core, TPRM is similar to other
risk management, but the difference lies in the solicitation of information to
identify risks outside of the organization’s direct control.
Risks of Outsourcing
Higher than expected costs Reduced costs were the main driver for
offshore outsourcing that began in the 1990s. However, many organizations
failed to anticipate the actual operational realities and/or the cost savings.
For instance, after U.S.-based organizations outsourced to overseas
operations, IT personnel had to make many more expensive trips than
expected. Also, changes in international currency exchange rates can
transform this year’s bargain into next year’s high cost.
Poor quality The work product produced by a third party may be lower
than was produced when the function was performed in-house.
Accounts payable Sometimes the only way to learn about some third
parties’ involvement is to find out what third parties are being paid for the
products or services they provide. Typically, the accounts payable function
will remit funds only to organizations that are registered as vendors in the
organization’s financial accounting system.
Location-specific leaders The saying goes, “The farther away one is from
corporate headquarters, the more that business is conducted by expediency
than by policy.” In other words, workers in satellite offices are more apt to
conduct business with unique, local-to-them third parties that may not be
identified otherwise. Security managers may need to tread lightly here so
that their quest for information about third parties does not represent a
threat to their ongoing internal business relationships and operations.
Allgress
CyberGRX
KY3P
Lockpath
Prevalent
RSA Archer
ServiceNow
Note that the values in Tables 6-14 and 6-15 are not absolutely consistent
across different service providers. Instead, these tables serve to illustrate the
nature of shared responsibilities between a service organization and its
customers. The specific responsibilities for operations and security between
an organization and any specific service provider can vary somewhat. It is
vital that an organization clearly understand its precise responsibilities for
each third-party relationship so that no responsibilities are overlooked or
neglected; otherwise, risks may be introduced to the organization’s
operations and/or security. The organization is ultimately responsible for
ensuring that specific areas are addressed, because if a breach occurs, the
organization will be held responsible in the eye of shareholders, board of
directors, and customers.
TPRM has been the subject of many standards and regulations that
compel organizations to be proactive in discovering risks present in the
operations of their critical third-party relationships. Historically, many
organizations were not voluntarily assessing their critical third parties.
Statistical data about breaches over several years has revealed that more
than half of all breaches are caused by inappropriately managed third
parties. This statistic illuminates the magnitude of the third-party risk
problem and has resulted in the enactment of laws and regulations in many
industries that now require organizations to build and operate effective
TPRM programs in their organizations. This has also garnered innovation in
the form of new tools, platforms, and services that help organizations
manage third-party risk more effectively.
Onboarding
Legal Agreement
Before services can commence, the organization and the third party will
negotiate a legal agreement that describes the services provided, service
levels, quality, pricing, and other terms. Based on the details discovered in
the assessment phase, the organization can develop a section in the legal
agreement that addresses security and privacy, which will typically cover
these subjects:
Security and/or privacy program The third party must have a formal
security and/or privacy program including but not limited to governance,
compliance, policy, risk management, annual risk assessment, internal
audit, vulnerability management, incident management, secure
development, security awareness training, data protection, and third-party
risk.
Security and/or privacy controls The third party must have a control
framework, including linkages to risk management and internal audit.
Security incident response The third party must have a formal security
incident capability that includes testing and training.
Security incident notification The third party will notify the organization
in the event of a suspected and confirmed breach, within a specific time
frame, typically 24 hours. The language around “suspected” and
“confirmed” needs to be developed carefully so that the third party cannot
sidestep this responsibility.
Right to audit The third party will permit the organization to conduct an
audit of the third-party organization without cause. If the third party will not
permit this, the organization may insist on the right to audit in the event of a
suspected or confirmed breach or other circumstances. Further, the contract
should include the right for a competent security professional services firm
to perform an audit of the third-party security environment on behalf of the
organization (useful for several reasons, including geographic location and
that the external audit firm will be more objective). The cost of the audit is
usually paid for by the organization, and in some cases the organization will
provide credits or compensation for the time incurred by the third party’s
team.
Periodic review The third party will permit an annual onsite review of its
operations and security. This can give the organization greater confidence in
the third party’s security and operations.
Cyber insurance The third party must carry a cyber-insurance policy with
minimum coverage levels and will comply with all requirements in the
policy to ensure payout in the event of a security event. A great option is to
have the organization be a named beneficiary on the policy, in case a
widespread breach results in a large payout to many customers.
Physical access The degree to which a vendor has physical access to the
organization’s information processing centers or work centers can be rated
together or separately. For instance, technical support vendors may have
physical access to information systems in a data center, or service vendors
may have physical access to work centers, such as freight delivery,
janitorial, plant care, office supplies replenishment, or IT service vendors
who maintain copiers, scanners, and other office equipment.
From time to time, some third parties will need to be reclassified from
one risk level to another. For example, suppose a third-party service
provider is hired to perform low-risk services, and its initial risk
classification is low. However, that third party might earn more business
that represents high risk; unless some triggering mechanism (such as the
negotiation of an additional legal contract) is in place, the organization
would need to analyze the relationship with each of its third parties
annually (or more often) to confirm their risk ratings. Similarly, if a third
party is originally classified as high risk but later discontinues performing
high-risk services, the third party should be reclassified at a lower risk tier;
otherwise, the organization is spending too much effort assessing the third
party.
Geopolitical risk
Inherent risk
Lawsuits
Operational effectiveness/capabilities
These and other factors can influence the overall risk to the organization,
which can manifest in various ways, including degradations in overall
security, failures to meet production or quality targets, and even business
failure.
Security policy
Security controls
New-hire checklists
Risk Treatment
Service level agreement The SLA should provide details on every avenue
of work performance and communication, including escalations and
problem management.
Quality Depending upon the product or service, this may translate into an
error or defect rate, a customer satisfaction rate, or system performance.
Employee integrity The contract should define how the outsourcing firm
will vet its employees’ backgrounds so that it is not inadvertently hiring
individuals with a criminal history and so employees’ claimed education
and work experience are genuine.
Roles and responsibilities The contract should specify in detail the roles
and responsibilities of each party so that each will know what is expected of
them.
Schedule The contract must specify when and how many items of work
products should be produced.
Regulation The contract should require both parties to conform to all
applicable laws and regulations, including but not limited to intellectual
property, data protection, and workplace safety.
Dispute and resolution The contract should contain provisions that define
the process for handling and resolving disputes.
Payment The contract should specify how and when the outsourcing
provider will be paid. Compensation should be tied not only to the quantity
but also to the quality of work performed. The contract should include
incentive provisions for additional payment when specific schedule,
quantity, or quality targets are exceeded. The contract should also contain
financial penalties that are enacted when SLA, quality, security, audit, or
schedule targets are missed.
Security Incidents
Security Operations
Security operations are associated with much of the action-oriented
activities in an information security program, through its monitoring and
response processes. Communications and reporting from security
operations may include the following:
Risk Management
Risk management, the risk analysis and risk treatment function that deals
with emerging risk, should periodically produce management reports so that
executive leaders can stay informed on many aspects of cyber risk in the
organization. Risk management reporting consists of a periodic snapshot of
the risk register, including changes in overall security posture, new risks,
changes in existing risks, and those risks that have been treated. Reporting
would also include tracking of risk remediation and whether it is being
performed on schedule and within budget.
Internal Partnerships
No security manager can hope to accomplish much if they work alone.
Effective information security and information risk is a team sport, and each
player on the team can help the security manager in different ways. Further,
communication with other corporate departments and business units helps
to keep the security manager informed on matters of importance.
Legal
Human Resources
Facilities
NOTE Although personnel security is cited last in this list, the safety of
personnel should be the highest priority in any organization.
Information Technology
Systems Development
Security and privacy by design Several activities ensure that all new
offerings, components, features, and improvements incorporate security and
privacy as part of the design process. This can help the organization avoid
issues later in the development process that may be more costly to
remediate.
Secure development Secure coding ensures that all new and changed
software is free of exploitable defects that could result in security incidents.
Security testing Several activities fall under the security testing function,
including code-scanning tools used by each developer’s integrated
development environment (IDE), unit and system testing to confirm the
correct implementation of all security requirements, static application
security testing (SAST) scanning tools that are run as part of a nightly build
process, and dynamic application security testing (DAST) scanning tools
that identify security defects in running applications.
Procurement
Internal Audit
Virtually all U.S. public companies, and many private companies, have an
internal audit (IA) function whose main mission is assurance through
independent audits of policies and controls. Although IA departments
cannot stipulate how controls, policies, and processes should be designed
and operated, IA can still be a collaborative partner on controls, policies,
and processes by telling IT, information security, and others whether those
controls, policies, and processes can be audited as designed.
Business Unit Managers
It has been said that a security manager can protect the organization only to
the extent that he understands how it works. Naturally this necessitates that
the security manager communicate and develop relationships with business
unit and department managers and leaders throughout the organization.
These partnerships help the security manager understand how each business
unit and department functions, and it helps identify critical personnel,
processes, systems, and outside partners. The main purpose of these
partnerships is not for the security manager to inform business unit
managers and leaders how security works, but rather to help the security
manager negotiate the best and most transparent ways to respond to
management as security matters occur within the organization. As these
strategic relationships develop, business unit managers and leaders will
begin to trust, share information with, and include the security manager in
key conversations and processes. Trust leads to conversations on sensitive
security topics, resulting in minor and sometimes significant improvements
to the business and its security.
External Partnerships
Law Enforcement
Canada The Royal Canadian Mounted Police (RCMP) and city and
provincial cybercrime units
Standards Organizations
Professional Organizations
Security professional services vendors can also assist with a strategy for
the acquisition, implementation, and operation of security tools. Trusted
advisors who are familiar with security tools can often help a security
manager identify the better tools that are more likely to work in their
environments.
Compliance Management
COMPLIANCE OR SECURITY
Applicability
Compliance Risk
As the security manager performs risk assessments and populates the risk
register with risk matters requiring discussion and treatment, the security
manager should not overlook compliance risk. Compliance risk is
associated with any general or specific consequences of the failure to be
compliant with an applicable law or other legal obligation.
Sensitive data exposure The risk register indicates that such sensitive
data could be misused by internal personnel, and it may be discovered by a
malicious outsider. The costs associated with a forensic investigation, along
with potential mitigation costs such as payment for credit monitoring for
victims, would be included in the total cost incurred by the organization
should this information be compromised.
Fines and sanctions The risk register notes that the organization could
face fines and other sanctions should the organization’s PCI regulators
(namely, banks and payment processors) learn of this. The fines and other
sanctions are the potential unplanned costs that the organization may incur
upon regulators’ discovery of this.
Compliance Enforcement
As the security manager reviews the results of internal and external audits,
control self-assessments, and other examinations of systems and processes,
she will need to weigh not only the direct risks associated with any negative
findings but also the compliance risk. The security manager can apply both
of these considerations in any discussions and proceedings during which
others in the organizations are contemplating their response to these
compliance items.
Employees trained
Technical Architecture
Personnel Management
In all but the smallest organizations where the security manager acts alone,
personnel management is an important aspect of information security
management. In many organizations, information security is staffed with a
team ranging from two to dozens of people. The security manager is
responsible for all aspects of the security team, starting with identifying and
hiring candidates, assigning and supervising work, developing new skills,
and developing the security team’s “culture within a culture.” All of this
requires intentional communication and monitoring.
Security managers who are looking to grow their security team or fill
open positions often need look no further than their own organization: one
or more people in the IT department may aspire to join the security team.
Many—if not most—IT security professionals “crossed over” from
corporate IT to information security, and this is still a common source for
new recruits. People transferring over from IT are already familiar with the
business and with IT’s operations and practices. If they are looking to grow
into a security career, they’re probably going to be willing to work pretty
hard to succeed.
Job Descriptions
Culture
NOTE With our codes of ethics from ISACA and other security
professional organizations, we are obligated to conduct ourselves according
to a higher standard, which is a part of the reason for the culture within a
culture.
Professional Development
Risk management
Risk analysis
Penetration testing
Malware analysis
Security engineering
Security architecture
Secure development
Forensics
Cryptography
Threat intelligence
Third-party risk
Privacy
Personnel-Related Reporting
Reporting that is related to personnel management and development may
include the following:
The result of this phenomenon of continuous change is the fact that most
organizations undertake several information security projects each year. In
many organizations, information security personnel are spending more time
in projects than they are in routine daily operations. For many security
managers, continuous change is the only constant.
Budget
Equipment
Software tools
Travel
Contingencies
IT Service Management
IT service management (ITSM) is the set of activities that occur to ensure
that the delivery of IT services is efficient and effective, through active
management and the continuous improvement of processes. ITSM consists
of several distinct activities:
Service desk
Incident management
Problem management
Change management
Configuration management
Release management
Service-level management
Financial management
Capacity management
Availability management
Often known as the help desk, the IT service desk handles incidents and
service requests on behalf of customers by acting as a single point of
contact. The service desk performs end-to-end management of incidents
and service requests (at least from the perspective of the customer) and is
also responsible for communicating status reports to the customer.
The service desk can also serve as a collection point for other ITSM
processes, such as change management, configuration management,
service-level management, availability management, and other ITSM
functions. A typical service desk function consists of frontline analysts who
take calls from users. These analysts perform basic triage and are often
trained to perform routine tasks such as password resets, troubleshoot
hardware and software issues, and assist users with questions and problems
with software programs. When analysts are unable to assist a user, the
matter is typically escalated to a subject-matter expert who can provide
assistance.
Incident Management
Service outage
Service slowdown
Software bug
While ITIL may have its roots in the United Kingdom, it has very much
become an international standard. This is because ITIL was adopted by the
International ISO/ IEC, in the ISO/IEC 20000 standard, and because IT
management practices are becoming more standardized and mature.
Problem Management
When several incidents have occurred that appear to have the same or a
similar root cause, a problem is occurring. ITIL defines a problem as “a
cause of one or more incidents.” ISO/IEC 20000-1:2011 defines a problem
as the “root cause of one or more incidents” and continues by stating, “The
root cause is not usually known at the time a problem record is created and
the problem management process is responsible for further investigation.”
Change Management
Verification After the implementers have completed the change, they will
perform the verification procedure to make sure that the change was
implemented correctly and that it produces the desired result. Generally,
this will involve one or more steps, including the gathering of evidence (and
directions for confirming correct versus incorrect change) that shows the
change was performed correctly. This evidence will be filed with other
records related to the change and may be useful in the future, especially if
the change is suspected to be the root cause of any problems encountered in
the system where this change is made.
Emergency Changes
Although most changes can be planned in advance using the change
management process described here, there are times when IT systems need
to be changed right away. Most change management processes include a
process for emergency changes that details most of the steps in the
nonemergency change management process, but they are performed in a
different order. The steps for emergency changes are as follows:
Verification Staff members verify that the change produced the expected
result. This may involve other staff members from other departments or end
users.
Configuration Management
Release Management
Release management is the ITIL term used to describe the portion of the
SDLC where changes in applications are placed into production service.
Release management is used to control the changes that are made to
software programs, applications, and environments.
Testing When the developers have finished coding and unit testing, a more
formal and comprehensive test phase is performed. Here, analysts,
dedicated software testers, and perhaps end users will test all of the new and
changed functionality to confirm that it is performing according to
requirements. Depending on the nature of the changes, some amount of
regression testing is also performed, where functions that were confirmed to
be working properly in prior releases are tested again to make sure that they
continue to work as expected. Testing is performed according to formal,
written test plans that are designed to confirm that every requirement is
fulfilled. Formal test scripts are used, and the results of all tests should be
recorded and archived. The testing that users perform is usually called user
acceptance testing (UAT). Often, automated test tools are used, which can
make testing more accurate and efficient. After testing is completed, a
formal review and approval are required before the process is allowed to
continue.
Service-Level Management
Financial Management
Budgeting
Capital investment
Expense management
Capacity Management
Systems with severe capacity issues may take excessive time to respond to
user requests. In some cases, systems may malfunction or users may give
up. Often, users will call the service desk, resulting in the logging of
incidents and problems.
Availability Management
Asset Management
Continuous Improvement
Continuous improvement represents the desire to increase the efficiency and
effectiveness of processes and controls over time. It could be said that
continuous improvement is a characteristic of an organization’s culture. The
pursuit of continuous improvement is a roundabout way of pursuing quality.
Chapter Review
After a control has been designed, it should be put into service and then
managed throughout its life. Depending upon the nature of the control, this
could involve operational impact in the form of changes to business
processes and/or information systems. Changes with greater impact will
require greater care so that business processes are not adversely affected.
Controls that have been placed into service will transition into routine
operations. Control owners will operate their controls and try to be aware of
any problems, especially early on. Whether controls are automatic or
manual, preventive or corrective, their owners are responsible for ensuring
that their controls operate correctly in every respect.
Third parties are assessed mainly through the use of questionnaires and
requests for evidence that are sent to them by organizations. Most
organizations depend on large numbers of third-party services, so they
employ a risk tier scheme to identify the third parties that are the most
critical to the organization. Third parties at a higher level of risk undergo
more frequent and rigorous risk assessments, while those at lower levels
undergo less frequent and less rigorous risk assessments.
Notes
Data backup has always been critical, but the rise in ransomware attacks is
highlighting the value of backups for business owners.
Questions
Organization maturity
Industry relevance
Risk tolerance
Risk appetite
The life-cycle process that influences controls over time is known as:
External audit
Risk management
Internal audit
The main reason that preventive controls are preferred over detective
controls is:
Controls that are general in nature and implemented across all systems
Which of the following is the best reason for adopting a standard control
framework?
All of the following statements about ISO/IEC 27002 are correct except:
ISO/IEC 27002 can be crosswalked to NIST SP 800-53.
Choose either HIPAA or PCI DSS and use those controls to protect both
ePHI and cardholder data.
Enact individual HIPAA and PCI DSS controls per a risk assessment.
Define the applicability of HIPAA and PCI DSS to those portions of the
business where ePHI and cardholder data are used.
Which of the following statements correctly describes the link between risk
management and controls?
What organization is the governing body for the PCI DSS standard?
ISO
NIST
Which of the following solutions is most suitable for the following control
statement: “Safeguards prevent end users from visiting hazardous web
sites”?
Antimalware
Transitive Trust
Zero Trust
An audit
An activity review
A recertification
A corrective control
Control self-assessment
Audit
Review
Investigation
The most favored practice for security awareness training is:
Annual training
Reading assignments
Answers
C. The risk management life cycle, over time, will have the greatest
influence on an organization’s controls. Newly discovered risks can be
managed through the enactment of new controls, for example.
D. Backing up data to offline media is the best of these choices. For the
most part, ransomware targets live data storage. Often, data replication
capabilities result in the replication of the encryption to secondary storage
systems.
C. ISO/IEC 27002, as well as other ISO standards, are not available free of
charge and must be purchased for individual users or with a site license.
A. In the risk management life cycle, risk assessments are performed and
new risks are identified. In risk treatment, sometimes the agreed-upon
course of action is the enactment of a new control to mitigate a new risk.
C. The PCI Security Standards Council, a consortium of the world’s leading
credit card brands (VISA, MasterCard, American Express, Discover, and
JCB), is the governing body for the PCI DSS standard and related standards
such as PA DSS.
B. A web content filter is the best solution for a control that protects users
from visiting hazardous web sites.
D. Zero Trust (ZT) is the philosophy that focuses on system and data
protection, where trust is not granted implicitly but must be continually
evaluated at all layers.
Incident Management
Classifying incidents
Supporting Tasks in the CISM job practice that align with the Incident
Management / Incident Management Readiness domain include:
Establish and maintain an incident response plan, in alignment with the
business continuity plan and disaster recovery plan.
Our world is full of surprises, including events that disrupt our plans and
activities. In the context of IT and business, several unexpected events can
cause significant disruption to business operations, even to the point of
threatening the ongoing viability of the organization itself. These events
include:
Natural disasters
Human-made disasters
Malicious acts
Cyberattacks
These examples should give you an idea of the nature of a security incident.
Not all represent cataclysmic events. Other types of incidents may also be
considered security incidents in some organizations.
Actions on objective The intruder proceeds with the attack plan, which
may consist of stealing data, damaging or destroying data, or disrupting the
operations of one or more systems.
This model makes it easy to imagine an intruder following each of the
steps in an attempt to break into a system. The main point of the model is to
help security professionals better understand a typical intrusion, as well as
develop defenses to stop each phase of an intrusion.
Here is how the kill chain is used: For each phase, analysts examine their
detective and preventive capabilities that are relevant to the types of
activities that an intruder would be performing. This helps an organization
better understand ways in which they could detect or prevent an attack in
each of its phases.
As for any emergency, the best time to plan for security incident response is
prior to the start of any actual incident. During an incident is a poor time to
analyze the situation thoughtfully, conduct research, and work out the
sequence of events that should take place to restore normal operations
quickly and effectively; emotions may run high, and there may be a
heightened sense of urgency, especially if there has been little or no
advanced planning.
Effective incident response plans take time to develop. A security
manager who is developing an incident response plan must first thoroughly
understand the organization’s business processes and underlying
information systems and then discover resource requirements,
dependencies, and failure points. A security manager may first develop a
high-level incident response plan, which is usually followed by the
development of several incident response playbooks, the step-by-step
instructions to follow when specific types of security incidents occur.
Objectives
Maturity
Resources
Forensics These persons use tools and techniques to collect evidence that
helps the organization better understand the nature of the incident. Some
evidence may be protected by a chain of custody in anticipation of later
legal proceedings.
Plan Development
Playbooks
Communications
Recordkeeping
Critical vulnerability
DoS attack
Unauthorized access
During a serious incident, emotions can run high, and personnel under
stress may not be able to remember all of the steps required to handle an
incident properly. Playbooks help guide experienced and trained personnel
in the steps required to examine, contain, and recover from an incident.
They are commonplace in other industries: pilots and astronauts use
playbooks to handle various emergency situations, for example, and they
practice the steps to help them prepare to respond effectively when needed.
Service outage
Service slowdown
Software bug
When IT incidents are combined with security incidents, an organization
will be prepared to respond to most any type of IT or security incident.
The first step in a BIA is the identification of key business processes and
supporting IT systems. Within the overall scope of a BCP project, the
objective is to establish a detailed list of all identifiable processes and
systems. The process usually begins with the development of a
questionnaire or intake form that is circulated to key personnel in end-user
departments and also within IT. Figure 7-2 shows a sample intake form.
Figure 7-2 BIA sample intake form for gathering data about key processes
TIP Use of an intake form is not the only accepted approach when
gathering information about critical processes, dependencies, and systems.
It’s also acceptable to conduct one-on-one interviews or group interviews
with key users and IT personnel to identify critical processes, dependencies,
and systems. I recommend the use of an intake form (whether paper-based
or electronic), even if the interviewer uses it herself as a framework for
note-taking.
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 begin designing more
robust system architectures and to tinker with replication and backup
capabilities before key facts are known. In the case of BCP and DRP,
completion of the BIA and other analyses is critical, as they help to 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
departments or functions that are affected by the unavailability of a specific
IT system. Include the geography of affected users and functions if that is
appropriate. Here are example statements of impact on 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.
Statements of impact for business processes might cite the business
functions that would be affected. Here are some example statements of
impact:
Inability to place orders for appliances will cost the rate of $12,000 per
hour.
Dependencies on systems
Dependencies on suppliers
Criticality Analysis
When all of the BIA information has been collected and charted, a
criticality analysis 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 a risk analysis that focuses on key processes and
systems. The criticality analysis should also include a vulnerability analysis
(aka vulnerability assessment), an examination of a process or system to
identify vulnerabilities that, if exploited, could incapacitate or harm the
process or system.
Single points of failure, such as only one staff member who knows how to
perform a key procedure.
Table 7-2 Example Threat Analysis Identifying Threats and Controls for
Critical Systems and Processes
In Table 7-2, notice the following:
Multiple threats are listed for a single asset. Only nine threats are included,
and for all the threats but one, only a single mitigating control is listed. For
the extended power outage threat, two mitigating controls are included.
Cost of downtime wasn’t listed. For systems or processes with a cost per
unit of time for downtime, this should be included, along with some
calculations to show the payback for each control.
Some mitigating controls can benefit more than one system. This may not
be obvious in this example, but many systems can benefit from a UPS and
an electric generator, so the cost for these mitigating controls can be
allocated across many systems, thereby lowering the cost for each system.
Another similar example, though not included in the analysis example, is a
high-availability storage area network (SAN) located in two different
geographic areas; though initially expensive, the SAN can be used by many
applications storage, and all will benefit from replication to the counterpart
storage system.
The length of the outage was not included. This should be included,
particularly if you are quantifying downtime per hour or other units of time.
Obviously, a vulnerability analysis, threat analysis, and the
corresponding criticality analysis can get complicated. The rule here should
be this: the complexity of the vulnerability, threat, and criticality analyses
should be proportional to the value of the assets (or revenue, or both). For
example, in a company at which 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, a variety of mitigating
controls, and to work out which ones are the most cost-effective. On the
other hand, for a system or business process with a far less costly outage
impact, a lot less time may be spent on the supporting analyses.
EXAM TIP Test-takers should ensure that any question dealing with BIA
and criticality analysis places the business impact analysis first. Without
this analysis, criticality analysis is impossible to evaluate in terms of
likelihood or cost-effectiveness in mitigation strategies. The BIA identifies
strategic resources and provides a value to their recovery and operation,
which is, in turn, consumed in the criticality analysis phase. If presented
with a question identifying BCP at a particular stage, make sure that any
answers you select facilitate the BIA and then the CA before moving on
toward objectives and strategies.
NOTE Like MTD, MTO is not a target, but when MTO is set, recovery
targets such as recovery time objective (RTO), recovery point objective
(RPO), service delivery objective (SDO), recovery consistency objective
(RCO), and recovery capacity objective (RCapO) can be established.
When the cost or impact of downtime has been established and the cost and
benefit of mitigating controls have been considered, some key targets can
be established for each critical process. The two key targets are RTO and
RPO, which determine how quickly key systems and processes are made
available after the onset of a disaster and the maximum tolerable data loss
that results from the disaster. Following are the key recovery targets:
Recovery time objective (RTO) The maximum period that elapses from
the onset of a disaster until the resumption of service
Recovery point objective (RPO) The maximum data loss from the onset
of a disaster
Once these objectives are known, the business continuity team can
develop contingency plans to be followed when a disaster occurs, and the
disaster recovery team can begin to build system recovery capabilities and
procedures that will help the organization to realize these recovery targets
economically.
The RCO comes into play in organizations that decide to scale back the
replication of features and functionality at a recovery site versus the
primary processing site. For instance, a recovery site may lack detailed
reporting capabilities because of the cost of software or service licensing.
An organization may have to pay for a second, expensive license for a
recovery site that would rarely be used. Instead, management may decide
that users or customers can go without those or other functions at a recovery
site, instead focusing on core functions.
NOTE SDO, RTO, RPO, and RCapO are related to one another.
Organizations are free to construct recovery target models in ways that
work for them. One organization may start with SDOs and derive
appropriate RTO, RPO, and RCapO targets, while others may start with
RTO and RPO and figure out their SDOs.
BCP reduces risks related to the onset of disasters and other disruptive
events. BCP activities identify risks and mitigate those risks through
changes or enhancements in business processes or technology so that the
impact of disasters is reduced and the time to recovery is lessened. The
primary objective of BCP is to improve the chances that the organization
will survive a disaster without incurring costly or even fatal damage to its
most critical activities.
The activities of BCP development scale for any size organization. BCP
has the unfortunate reputation of existing only in the stratospheric thin air
of the largest and wealthiest organizations. This misunderstanding hurts the
majority of organizations that are too timid to begin any kind of BCP
efforts, because they believe that these activities are too costly and
disruptive. The fact is that any size organization, from a one-person home
office to a multinational conglomerate, can successfully undertake BCP
projects that will bring about immediate benefits and take some of the sting
out of disruptive events that do occur.
Disasters
Floods Standing or moving water spills out of its banks and flows into and
through buildings and causes significant damage to roads, buildings, and
utilities. Flooding can be a result of locally heavy rains, heavy snow melt, a
dam or levee break, tropical cyclone storm surge, or an avalanche or
landslide that displaces lake or river water.
Wildfires Fires in forests, chaparral, and grasslands are part of the natural
order. However, fires can also damage buildings and equipment and cause
injury and death, such as in the 2017 wildfires in California. Figure 7-4
shows a map of Sonoma County and nearby wildfires, as seen from the
NASA Aqua satellite that year.
Figure 7-4 Wildfires in California (Source: NASA)
Tropical cyclones The largest and most violent storms are known in
various parts of the world as hurricanes, typhoons, tropical cyclones,
tropical storms, and cyclones. Tropical cyclones, such as Hurricane Harvey,
consist of strong winds that can reach 190 mph, heavy rains, and storm
surges that can raise the level of the ocean by as much as 20 feet, all of
which can result in widespread coastal flooding and damage to buildings,
houses, roads, and utilities and in significant loss of life.
Ice storms When rain falls through a layer of colder air, raindrops freeze
onto whatever surface they strike, resulting in widespread power outages
after heavy ice coats power lines, causing them to collapse. A notable
example is the Great Ice Storm of 1998 in eastern Canada, which resulted in
millions being without power for as long as two weeks and in the virtual
immobilization of the cities of Montreal and Ottawa.
Tsunamis A series of waves that usually result from the sudden vertical
displacement of a lake bed or ocean floor can also be caused by landslides,
asteroids, or explosions. A tsunami wave can be barely noticeable in open,
deep water, but as it approaches a shoreline, the wave can grow to a height
of 50 feet or more. Recent notable examples are the 2004 Indian Ocean
tsunami and the 2011 Japan tsunami. Figure 7-5 shows coastline damage
from the Japan tsunami.
Figure 7-5 Damage to structures caused by the 2011 Japan tsunami
Pandemic Infectious diseases may spread over a wide geographic region,
even worldwide. Pandemics have regularly occurred throughout history and
are likely to continue occurring, despite advances in sanitation and
immunology. A pandemic is the rapid spread of any type of disease,
including typhoid, tuberculosis, bubonic plague, or influenza. Pandemics
include the 1918–1920 Spanish flu, the 1956–1958 Asian flu, the 1968–
1969 Hong Kong “swine” flu, the 2009–2010 swine flu, and the COVID-19
pandemic, which began at the end of 2019. Figure 7-6 shows a field
hospital during the pandemic.
Figure 7-6 A field hospital in Brazil during the 2019 COVID pandemic
(Image courtesy of Gustavo Basso)
Figure 7-7 Empty grocery store shelves exhibiting the lack of available
baby formula.
Services and supplier shortage Even if a disaster does not directly affect
an organization, critical suppliers affected by a disaster can cause problems
for business operations. For instance, a regional baker that cannot produce
and ship bread to its corporate customers will soon result in sandwich shops
without a critical resource.
Train personnel.
BCP Policy A formal BCP effort must, like any strategic activity, flow
from the existence of a formal policy and be included in the overall
governance model discussed throughout this chapter. BCP should be an
integral part of the IT control framework, not lie outside of it. Therefore,
BCP policy should include or cite specific controls that ensure that key
activities in the BCP life cycle are performed appropriately. BCP policy
should also define the scope of the BCP strategy, so the specific business
processes (or departments or divisions within an organization) that are
included in the BCP effort must be defined. Sometimes the scope will
include a geographic boundary. In larger organizations, it is possible to “bite
off more than you can chew” and define too large a scope for a BCP
project, so limiting the scope to a smaller, more manageable portion of the
organization can be a good approach.
The specific COBIT controls that are involved with BCP are contained
within objective DSS04, Managed Continuity. This objective lists eight
specific controls that constitute the entire continuity life cycle:
These controls are discussed in this chapter and also appear in COBIT
2019.
Responsibilities
Contact information
Recovery procedures
Continuing operations
Restoration procedures
Visitors know how to evacuate the premises and the location of sheltering
areas.
Signs and placards are posted to indicate emergency evacuation routes and
gathering areas outside of the building.
Emergency food and drinking water are available when personnel must
shelter in place.
Pulling the Trigger When disaster declaration criteria are met, the disaster
should be declared. The procedure for disaster declaration could permit any
single core team member to declare the disaster, but it may be better in
some organizations to have two or more core team members agree on
whether a disaster should be declared. All core team members empowered
to declare a disaster should have the procedure on hand at all times. In most
cases, the criteria should fit on a small, laminated wallet card that each team
member can carry with him or have nearby at all times. For organizations
that use the consensus method for declaring a disaster, the wallet card
should include the names and contact numbers of other core team members
so that each will have a way of contacting others.
Next Steps Declaring a disaster will trigger the start of one or more other
response procedures, but not necessarily all of them. For instance, if a
disaster is declared because of a serious computer or software malfunction,
there is no need to evacuate the building. While this example may be
obvious, not all instances will be this clear. Either the disaster declaration
procedure itself or each of the subsequent response procedures should
contain criteria that will help determine which response procedures should
be enacted.
False Alarms Probably the most common cause of personnel not declaring
a disaster is the fear that an event is not an actual disaster. Core team
members empowered with declaring a disaster should not necessarily
hesitate, however. Instead, core team members could convene with
additional team members to reach a firm decision, provided this can be
done quickly. If a disaster has been declared and it later becomes clear that
a disaster has been averted (or did not exist in the first place), the disaster
can simply be called off and declared to be over. Response personnel can be
contacted and told to cease response activities and return to their normal
activities.
TIP Depending on the level of effort that takes place in the opening
minutes and hours of disaster response, the consequences of declaring a
disaster when none exists may or may not be significant. In the spirit of
continuous improvement, any organization that has had a few false alarms
should seek to improve its disaster declaration criteria. Well-trained and
experienced personnel can usually avoid frequent false alarms.
All roles will be staffed by people who are available; remember that
many of the “ideal” people to fill each role may be unavailable during a
disaster for several reasons:
TIP Although the first person on the scene may be the person in charge
initially, as more personnel show up and the nature of the disaster and
response solidifies, qualified assigned personnel will take charge and
leadership roles may then be passed among key personnel.
Scribe It’s vital that one or more people document the important events
continually during disaster response operations. From decisions, to
discussions, to status, to roll call, these events must be recorded so that the
details of disaster response can be pieced together afterward. This will help
the organization better understand how disaster response unfolded, how
decisions were made, and who performed which actions—all of which will
help the organization be better prepared for future events.
Broadcast alerts Sent via text, voice, or mobile app, these help inform
large numbers of personnel about events affecting the organization.
Customers
Suppliers
Partners
Insurance companies
Shareholders
Neighbors
Regulators
Media
Legal and Compliance Several needs may arise during a disaster that
require the attention of inside or outside legal counsel. Disasters present
unique situations, such as the following, that may require legal assistance:
Interpretation of regulations
Data and Records This function is responsible for access to and re-creation
of electronic and paper business records. This business function supports
critical business processes, works with database management personnel,
and, if necessary, works with data-entry personnel to rekey lost data.
Applications This function is responsible for recovering application
functionality on application servers. This may include reloading application
software, performing configuration, provisioning roles and user accounts,
and connecting the application to databases and network services, as well as
other application integration issues.
An example is useful here. Acme Rocket Boots determines that its order-
entry business function is highly critical to the ongoing viability of the
business and sets recovery objectives to ensure that order entry would be
continued within no more than 48 hours after a disaster. Acme determines
that it needs to invest in storage, backup, and replication technologies to
make a 48-hour recovery possible. Without these investments, IT systems
supporting order entry would be down for at least ten days until they could
be rebuilt from scratch. Acme cannot justify the purchase of systems and
software to facilitate an auto-failover of the order-entry application to hot-
site disaster recovery servers; instead, the recovery procedure would require
that the database be rebuilt from replicated data on cloud-based servers.
Other tasks, such as installing recent patches, would also be necessary to
make recovery servers ready for production use. All of the tasks required to
make the systems ready constitute the body of recovery procedures needed
to support the business order-entry function.
Unavailable transportation
Lack of communications
A disaster can also prompt employees to report to a work location (at the
primary location or at an alternate site), where they may remain for days at
a time, even around the clock if necessary. A situation like this may make
the need for emergency supplies less critical, but it still may be beneficial to
the recovery effort to make supplies available to support recovery
personnel.
Drinking water
Food rations
First-aid supplies
Blankets
Flashlights
Public safety Police, fire, and other public safety authorities may need to
be contacted, not only for emergency operations such as firefighting but
also for any required inspections or other services. It is important that
“business office” telephone numbers for these agencies be included on
contact lists, as 911 and other emergency lines may be flooded by calls
from others.
Media Media outlets such as newspapers and television stations may need
to be notified as a means of quickly reaching the community or region with
information about the effects of a disaster on organizations.
Figure 7-11 shows an example wallet card. Organizations may also issue
digital versions of wallet cards for people to store on mobile devices.
Figure 7-11 Example of a wallet card for core team participants with
emergency contact information and disaster declaration criteria
Electronic Contact Lists Arguably, most IT personnel and business leaders
have smartphones and other mobile devices with onboard storage that is
available even when cellular carriers are experiencing outages. Copies of
contact lists and even disaster response procedures can be stored in
smartphones to keep this information handy during a disaster.
Criticality analysis
Documents defining recovery targets such as RTO, RPO, RCO, and RCapO
Security incident response plan This describes the steps required to deal
with a security incident that could reach disaster-like proportions.
When a disaster strikes, often one of the effects is no access to even the
most critical IT systems. In a 40-hour workweek in an organization with on-
site personnel, there is roughly a 25 percent likelihood that critical
personnel will be at the business location when a disaster strikes (at least
the violent type of disaster that strikes with no warning, such as an
earthquake—other types of disasters, such as hurricanes, may afford the
organization a little bit of time to anticipate the disaster’s impact). The point
is that the chances are good that the personnel who are available to respond
may be unable to access the procedures and other information that they will
need, unless special measures are taken.
Hard copy While many have grown accustomed to the paperless office,
disaster recovery and response documentation is one type of information
that should be available in hard-copy form. Copies, even multiple copies,
should be available for each responder, with a copy at the workplace and
another at home, and possibly even a set in the responder’s vehicle.
Soft copy Traditionally, soft-copy documentation is kept on file servers,
but as you might expect, those file servers may be unavailable in a disaster.
Soft copies should be available on responders’ portable devices (laptops,
tablets, and smartphones). An organization can also consider issuing
documentation on memory sticks and cards. Depending upon the type of
disaster, it can be difficult to know what resources will be available to
access documentation, so making it available in more than one form will
ensure that at least one copy of it will be available to the personnel who
need access to it.
DRP is undertaken to reduce risks related to the onset of disasters and other
events. It is mainly an IT function to ensure that key IT systems are
available to support critical business processes. DRP is closely related to,
but somewhat separate from, BCP: the groundwork for DRP begins in BCP
activities such as the business impact analysis, criticality analysis,
establishment of recovery objectives, and testing. The outputs from these
activities are the key inputs to DRP:
The BIA and criticality analysis help to prioritize which business processes
(and, therefore, which IT systems) are the most important.
The relationships between BCP and DCP were discussed in detail earlier
in this chapter and depicted in Figure 7-3.
Disaster recovery plans need to specify the teams that are required for
disaster response, as well as each team’s roles and responsibilities. Table 7-
3 describes several teams and their roles. Because of variations in
organizations’ disaster response plans, some of these teams will not be
needed in some organizations.
Table 7-3 Disaster Response Teams’ Roles and Responsibilities
NOTE Some roles in Table 7-3 may overlap with responsibilities defined
in the organization’s BCP. Disaster recovery and business continuity
planners should work together to ensure that the organization’s overall
response to disaster is appropriate and does not overlook vital functions.
Recovery Objectives
During the BIA and criticality analysis phases of a business continuity and
disaster recovery project, the speed with which each business activity (with
its underlying IT systems) needs to be restored after a disaster is
determined. The primary recovery objectives, as discussed in detail earlier
in this chapter, are as follows:
RTO
RPO
RCO
RCapO
If the storage system for an application takes a snapshot every hour, the
RPO could be one hour, unless the storage system itself was damaged in a
disaster. If the snapshot is replicated to another storage system four times
per day, the RPO might be better expressed as six to eight hours. This
brings up an interesting point. There may not be one golden RPO figure for
a given system. Instead, the severity of a disrupting event or a disaster will
dictate the time to get systems running again (RTO) with a certain amount
of data loss (RPO). Here are some examples:
A server’s CPU or memory fails and is replaced and restarted in two hours.
No data is lost. The RTO is two hours, and the RPO is zero.
TIP When publishing RTO and RPO figures to customers, it’s best to
publish the worst-case figures: “If our data center burns to the ground, our
RTO is X hours and the RPO is Y hours.” Saying it that way would be
simpler than publishing a chart that shows RPO and RTO figures for
various types of disasters.
Organizations that publish RCO and RCapO targets will need to include
the practical meaning of these targets, whether they represent an exact
match of capacity and integrity or some reduction. For example, if an
organization’s recovery site is engineered to process 80 percent of the
transaction volume of the primary site, an organization should consider
stating that processing capacity at a recovery site may be reduced.
Table 7-4 The Lower the RTO, the Higher the Cost to Achieve It
The BCP project team needs to understand the relationship between the
time required to recover an application and the cost required to recover the
application within that time. A shorter recovery time is more expensive, and
this relationship is not linear. This means that reducing RPO from three
days to six hours may mean that the equipment and software investment
could double, or it may increase eightfold. So many factors are involved in
the supporting infrastructure for a given application that a BCP project team
must knuckle down and develop the cost for a few different RTO and RPO
figures.
The business value of the application itself is the primary driver in
determining the amount of investment that senior management is willing to
make to reach any arbitrary RTO and RPO figures. This business value may
be measured in local currency if the application supports revenue, but the
loss of an application during a disaster may harm the organization’s
reputation, which is difficult to monetize. Management must decide how
much it is willing to invest in disaster recovery capabilities that bring RTO
and RPO figures down to an acceptable level. Figure 7-12 illustrates these
relationships.
Figure 7-12 Aim for the sweet spot and balance the costs of downtime and
recovery.
When management has chosen specific RPO and RTO targets for a given
system or process, the BCP project team can then roll up its sleeves and
devise some ways to meet these targets. This section discusses the
technologies and logistics associated with various recovery strategies. This
will help the project team decide which types of strategies are best suited
for their organization.
—Mike Tyson
When developing contingency plans, disaster recovery planners should
keep in mind that contingency plans won’t always work out. This is
especially true in situations that are more regional in nature. For instance, in
a region impacted by a widespread natural disaster, recalling backup tapes
by courier may be problematic because transportation infrastructure may be
impacted. After the September 11, 2001, attack on the World Trade Center
in New York, shipping anything by air was out of the question, because the
airspace throughout North America was closed for several days. During the
COVID-19 pandemic, shipping was severely hampered at times because of
shortages of pilots, drivers, and fuel.
Hot Sites A hot site is an alternate processing center where backup systems
are already running and in some state of near-readiness to assume
production workload. The systems at a hot site most likely have application
software and database management software already loaded and running,
perhaps even at the same patch levels as the systems in the primary
processing center. A hot site is the best choice for systems whose RTO
targets range from zero to several hours, perhaps as long as 24 hours.
A hot site may consist of leased rack space (or even a cage for larger
installations) at a co-location center. If the organization has its own
processing centers, a hot site for a given system would consist of the
required rack space to house the recovery systems. Recovery servers will be
installed and running, with the same version and patch level for the
operating system, DBMS (if used), and application software.
The organization sends one or more technical staff members to the hot
site to set up systems; once the systems are operating, much or all of the
system- and database-level administration can be performed remotely. In a
disaster scenario, however, the organization may need to send the
administrative staff to the site for day-to-day management of the systems.
This means that workspace for these personnel needs to be identified so that
they can perform their duties during the recovery operation.
TIP Hot-site planning needs to consider work (desk) space for on-site
personnel. Some co-location centers provide limited work areas that are
often shared and offer little privacy for phone discussions. Also,
transportation, hotel, and dining accommodations need to be arranged,
possibly in advance, particularly if the hot site is in a different city from the
primary site.
The primary advantage of a warm site is that its costs are lower than for
a hot site, particularly in the effort required to keep the recovery system up-
to-date. The site may not require expensive data replication technology, but
instead, data can be recovered from backup media.
Cold Sites A cold site is an alternate processing center where the degree of
readiness for recovery systems is low. At the least, a cold site is nothing
more than an empty rack or allocated space on a computer room floor. It’s
just an address in someone’s data center or co-location site where
computers can be set up and used at some future date. Often, cold sites
contain little or no equipment. When a disaster or other highly disruptive
event occurs in which the outage is expected to exceed 7 to 14 days, the
organization will order computers from a manufacturer or perhaps have
computers shipped from some other business location to arrive at the cold
site soon after the disaster event has begun. Then personnel would travel to
the site and set up the computers, operating systems, databases, network
equipment, and so on, and get applications running within several days.
The advantage of a cold site is its low cost. The main disadvantage is the
time and effort required to bring it to operational readiness in a short period,
which can be costly. But for some organizations, a cold site is exactly what
is needed.
Table 7-6 Detailed Comparison of Cold, Warm, Hot, and Cloud Sites
NOTE With the wide use of Internet co-location centers, reciprocal sites
have fallen out of favor. Still, they may be ideal for organizations with
mainframe computers that are otherwise too expensive to deploy to a cold
or warm site.
Geographic Site Selection An important factor in the process of recovery
site selection is the location of the site. The distance between the main
processing site and the recovery site is vital and may figure heavily into the
viability and success of a recovery operation. A recovery site should not be
located in the same geographic region as the primary site, because the site
may be involved in the same regional disaster that affects the primary site
and may be unavailable for use. By “geographic region,” I mean a location
that will likely experience the effects of the same regional disaster that
affects the primary site. No arbitrarily chosen distance (such as 100 miles)
guarantees sufficient separation. In some locales, 50 miles is plenty of
distance; in other places, 300 miles is too close—it all depends on the
nature of disasters that are likely to occur. Information on regional disasters
should be available from local disaster preparedness authorities or from
local disaster recovery experts.
Figure 7-14 Direct connectivity scenarios for disaster recovery with SaaS
providers (Source: Peter Gregory)
Right to audit The organization should have a “right to audit” clause in its
contract to verify the presence and effectiveness of all key controls in place
at the recovery facility.
Table 7-7 lists the pros and cons of these strategies. Warm-site strategy is
not listed because an organization could purchase hardware either in
advance of the disaster or when it occurs. Because cold, hot, and cloud sites
are deterministic, they are included in the table.
Table 7-7 Hardware Acquisition Pros and Cons for Hot/Warm, Cold, and
Cloud Recovery Sites
The main reason an organization chooses to employ a cloud hosting
provider is to eliminate capital costs. The provider supplies all hardware
and charges organizations when the hardware is used. The primary business
reason for not choosing a hot site is the high capital cost required to
purchase disaster recovery equipment that may never be used. One way
around this obstacle is to put those recovery systems to work every day. For
example, recovery systems could be used for development or testing of the
same applications that are used in production. This way, systems that are
purchased for recovery purposes are being well utilized for other purposes,
and they’ll be ready in case a disaster occurs. When a disaster occurs, the
organization will be less concerned about development and testing and
more concerned about keeping critical production applications running. It
will be a small sacrifice to forgo development or testing (or whatever low-
criticality functions are using the recovery hardware) during a disaster.
Does the technology help the information system achieve the RTO, RPO,
and RCapO targets?
Does the technology fit well into the organization’s current IT operations?
Will operations staff require specialized training to use the technology for
recovery?
RAID 1 This creates a mirror, where data written to one disk in the array
is also written to a second disk in the array. RAID 1 makes the volume
more reliable through the preservation of data, even when one disk in the
array fails.
RAID 4 This level employs data striping at the block level by adding a
dedicated parity disk, which permits the rebuilding of data in the event one
of the other disks fails.
Storage systems are hardware devices that are entirely separate from
servers—their only purpose is to store a large amount of data. They are
highly reliable through the use of redundant components and the use of one
or more RAID levels. Storage systems generally come in two forms:
Storage area network (SAN) This stand-alone storage system can be
configured to contain several virtual volumes and can be connected to
several servers through fiber-optic cables. The servers’ operating systems
will often consider this storage to be “local,” as though it consisted of one
or more hard disks present in the server’s own chassis.
Replication can take place from one system to another system, called
primary-backup replication, and this is the typical setup when data on an
application server is sent to a distant storage system for data recovery or
disaster recovery purposes. Replication can also be bidirectional between
two active servers; this is known as multiprimary or multimaster
replication. This method is more complicated, because simultaneous
transactions on different servers could conflict with one another (such as
two reservation agents trying to book a passenger in the same seat on an
airline flight). Some form of concurrent transaction control would be
required, such as a distributed lock manager.
In terms of the speed and integrity of replicated information, there are
two types of replication:
NOTE Replication is often used for applications where the RTO is smaller
than the time necessary to recover data from backup media. For example, if
a critical application’s RTO is established to be two hours, recovery from
backup tape is probably not a viable option unless backups are performed
every two hours. While more expensive than recovery from backup media,
replication ensures that up-to-date information is present on a remote
storage system that can be put online in a short period.
A DRP effort starts with the initial phases of the BCP project, the BIA and
criticality analysis, which lead to the establishment of recovery objectives
that determine how quickly critical business processes need to be back up
and running. With this information, the disaster recovery team can
determine what additional data processing equipment is needed (if any) and
establish a road map for acquiring that equipment. Note that “equipment”
may represent physical hardware or virtual assets in public or private cloud
environments.
Disaster recovery plans should consider all the likely disaster scenarios
that may occur to an organization. Understanding these scenarios can help
the team take a more pragmatic approach when creating response
procedures. The added benefit is that not all disasters result in the entire
loss of a computing facility. Most are more limited in their scope, although
all of them can still result in a complete inability to continue operations.
Some of these scenarios are as follows:
These scenarios are probably more likely to occur than a catastrophe such
as a major earthquake or hurricane (depending on where a data center is
located).
The system lacks flexibility with regard to disaster recovery (for instance, a
high degree of difficulty is required to recover information onto a different
type of system).
Incident Classification/Categorization
No two security incidents or disasters are alike: some may threaten the very
survival of an organization, while others are minor, bordering on
insignificant. The degree and type of response must be appropriate for the
severity of the incident in terms of mobilization, speed, and
communications. Further, an incident may or may not have an impact on
sensitive information, including intellectual property and personally
identifiable information (PII).
Organizations generally classify incidents according to severity, typically
on a 3-, 4-, or 5-point scale. Organizations that store or process intellectual
property, confidential data about their employees, or sensitive information
about clients or customers often assign incident severity levels according to
the level of impact on this information. Tables 7-8 and 7-9 depict two such
schemes for classifying security incidents.
Like any procedure, incident response goes far better if responders have
been trained prior to an actual incident occurring. Unlike many security
procedures, during a security incident, emotions can run high, and those
unfamiliar with the procedures and principles of incident response can get
tripped up and make mistakes. This is not unlike the emotion and stress that
other types of emergency responders, such as firefighters and police
officers, may experience.
Incident response training should cover all of the scenarios that the
organization is likely to face, ranging from the not-so-dire events such as
stolen mobile devices and laptop computers to the truly catastrophic events
such as a prolonged DDoS attack, destructive ransomware, or the
exfiltration of large amounts of sensitive data.
Several forms of training can be made available for personnel who are
expected to be available if a disaster strikes, including the following:
All of the test levels that need to be performed to verify the quality of
response plans are also training opportunities for personnel. The
development and testing of disaster-related plans and procedures provide a
continuous learning experience for all of the personnel involved.
These tests should be performed once each year or even more often. In
the walk-through and simulation tests, someone should be appointed as a
note-taker so that any improvements will be recorded and the plan can be
updated. Tests should include incidents addressed in each playbook and at
each classification level so that all procedures will be tested. Regardless of
the type of test conducted, an after-action or lessons-learned session should
be conducted. Any identified recommendations or remedial actions should
be incorporated into incident response plans and supporting documentation.
If the incident response plan contains the names and contact information
of response personnel, the plan should be reviewed more frequently to
ensure that all contact information is up to date.
It is amazing how much can be accomplished if no one cares who gets the
credit.
—John Wooden
Business continuity and disaster recovery plans may look elegant and even
ingenious on paper, but their true business value is unknown until their
worth is proven through testing. The process of testing these plans uncovers
flaws not only in the plans but also in the systems and processes that they
are designed to protect. For example, testing a system recovery procedure
might point out the absence of a critically needed hardware component, or a
recovery procedure might contain a syntax or grammatical error that
misleads the recovery team member and results in recovery delays. Testing
is designed to uncover these types of issues.
Walk-through
Simulation
Parallel test
Cutover test
TIP Usually, an organization should perform the less intensive tests first to
identify the most obvious flaws, followed by tests that require more effort.
Test Preparation
Facilities For all but the document review test, proper facilities, such as a
large conference room or training room, should be identified and set up. If
the test takes several hours, one or more meals and refreshments may be
needed as well.
Scripting The simulation test requires some scripting, usually in the form
of one or more documents that describe a developing scenario and related
circumstances. Scenario scripting can make parallel and cutover tests more
interesting and valuable, but this can be considered optional.
Recordkeeping For all tests except the document review, one or more
people should take good notes that can be collected and organized after the
test is completed.
The owner or document manager for the organization’s BCP and DRP
project should document which people review which documents and
perhaps include the review copies or annotations. This practice will create a
complete record of the activities related to the development and testing of
important DRP and BCP documents. It will also help to capture the true
cost and effort of the development and testing of BCP capabilities in the
organization.
To make the simulation more credible and valuable, the chosen scenario
should have a reasonable chance of actually occurring in the local area.
Good choices would include an earthquake in San Francisco or Los
Angeles, a volcanic eruption in Seattle, or an avalanche in Switzerland. A
poor choice would be a hurricane or tsunami in Central Asia, because these
events would never occur there. A simulation can also go a few steps
further. For instance, the simulation can take place at an established
emergency operations center, the same place where emergency command
and control would operate in a real disaster. Also, the facilitator could
change some of the participants’ roles to simulate the absence of certain key
personnel to see how the remaining personnel may conduct themselves in a
real emergency.
NOTE The facilitator of a simulation is limited only by her own
imagination when organizing a simulation. One important fact to remember,
though, is that a simulation does not actually affect any live or disaster
recovery systems—it’s all as pretend as the make-believe cardboard
television sets and computers in furniture stores.
Every type and every iteration of disaster recovery plan testing needs to be
documented. It’s not enough to say, “We did the test on September 10,
2021, and it worked.” First of all, no test goes perfectly—opportunities for
improvement are always identified. But the most important part of testing is
to discover what parts of the plan or the test should be reworked before the
next test (or a real disaster) occurs.
Recording and comparing detailed test results from one test to the next
will also help the organization measure progress. By this, I mean that the
quality of disaster response plans should steadily improve from year to year.
Simple mistakes of the past will not be repeated, and the only failures in
future tests should be in new and novel parts of the environment that
weren’t well thought out to begin with. And even these should diminish
over time.
Obtain the most recent BIA and accompanying threat analysis, risk
analysis, and criticality analysis. Determine whether these documents are
current and complete, and whether they support the business continuity
strategy. Also determine whether the scope of these documents covers those
activities considered strategic according to high-level business objectives.
Finally, determine whether the methods in these documents represent good
practices for these activities.
Verify whether a process is in place for the regular review and update of
business continuity documentation. Evaluate the process’ effectiveness by
reviewing records to determine how frequently documents are reviewed.
Determine whether all documents are clear and easy to understand, not just
for primary responders, but for alternate personnel who may have specific
relevant skills but less familiarity with the organization’s critical
applications. In some disaster scenarios, primary responders may be
unavailable to carry out disaster response activities.
Contact some or all of the response personnel who are listed in emergency
contact lists. Interview them to see how well they understand their disaster
response responsibilities and whether they are familiar with disaster
response procedures. Ask each interviewee whether they have a copy of
these procedures, and ask whether their copies are current.
Determine whether a process exists for the formal review and update of
business continuity documentation. Examine records to see how frequently,
and how recently, documents have been reviewed and updated.
Examine records for tests that have been performed over the past few years,
and determine the types of tests that were performed. Obtain a list of
participants for each test. Compare the participants to lists of key recovery
personnel. Examine test work papers to determine the level of participation
by key recovery personnel.
Determine whether a formal process exists for recording test results and for
using those results to make improvements in plans and procedures.
Examine documents and records to determine the types of changes that
were recommended in prior tests. Examine business continuity documents
to determine whether these changes were made as expected.
Considering the types of tests that were performed, determine the adequacy
of testing as an indicator of the effectiveness of the business continuity
program. Were only document reviews and walk-throughs performed, for
example, or were parallel or cutover tests conducted?
If tests have been performed for two years or more, determine whether
continuous improvement in response and recovery procedures exists.
The knowledge and experience of key personnel are vital to the success of
any business continuity operation. Interviews will help determine whether
key personnel are prepared and trained to respond during a disaster. The
following will guide discussions:
Ask whether he or she has received any training. Request evidence of this
training (certificate, calendar entry, notes, and so on).
Does the service provider have its own disaster recovery capabilities that
will ensure its ability to deliver critical services during a disaster?
Is recourse available should the supplier be unable to provide goods or
services during a disaster?
Evaluate the methods used to store critical information offsite (which may
consist of offsite storage, alternate data centers, replication, or e-vaulting).
Note whether offsite or alternate site locations are within the same
geographic region, which could mean that both the primary and alternate
sites could be involved in common disaster scenarios.
Determine whether all documents are clear and easy to understand, not just
for primary responders, but for alternate personnel who may have specific
relevant skills but less familiarity with the organization’s critical
applications. Remember that primary responders may be unavailable in
some disaster scenarios, and that others may need to carry out disaster
recovery plan procedures.
If the organization has a warm site, examine the procedures used to bring
standby systems into operational readiness. Examine warm-site systems to
see whether they are in a state where readiness procedures will likely be
successful.
Determine whether a process exists for the formal review and update of
business continuity documentation to ensure continued alignment with
DRP. Examine records to see how frequently, and how recently, documents
have been reviewed and updated. Determine whether this is sufficient and
effective by interviewing key personnel to understand whether significant
changes to applications, systems, networks, or processes are reflected in
recovery and response documentation.
Examine records for tests that have been performed over the past year or
two. Determine the types of tests that were performed. Obtain a list of
participants for each test, and compare the participants to lists of key
recovery personnel. Examine test work papers to determine the level of
participation by key recovery personnel.
Determine whether there is a formal process for recording test results and
for using those results to make improvements in plans and procedures.
Examine work papers and records to determine the types of changes that
were recommended in prior tests. Examine disaster recovery documents to
see whether these changes were made as expected.
Considering the types of tests that were performed, check the adequacy of
testing as an indicator of the effectiveness of the disaster recovery program.
Did the organization perform only document reviews and walk-throughs,
for example, or did the organization also perform parallel or cutover tests?
If tests have been performed for two years or more, check for continuous
improvement in response and recovery procedures.
Determine whether any tests included the retrieval of backup data from
offsite storage, replication, or e-vaulting facilities. See what disaster
scenarios were tested and the types of recovery procedures that were
performed.
If possible, visit the facility and examine its physical security controls as
well as its safeguards to prevent damage to stored information in a disaster.
Consider the entire spectrum of physical and logical access controls.
Examine procedures and records related to the storage and return of backup
media and other information that the organization may store there. If it is
not possible to visit the facility, obtain copies of audits or other attestations
of controls effectiveness.
Determine how often the organization performs its own inventory of the
facility and whether steps to correct deficiencies are documented and
remedied.
Obtain information related to the manner in which backup media and copies
of records are transported to and from the offsite storage or e-vaulting
facility. Determine the adequacy of controls protecting transported
information.
Obtain records supporting the transport of backup media and records to and
from the storage facility. Examine samples of records and determine
whether they match other records, such as backup logs.
Determine the types of natural and human-made events likely to take place
at the alternate processing facility. Determine whether there are adequate
controls to mitigate the effect of these events.
The steps and details for evaluating security incident response plans are
virtually the same as those of evaluations of BCPs and DRPs: plans should
be thorough, specific, business aligned, and maintained. Various exercises,
from document walk-throughs to live-fire testing, should be performed to
ensure that plans are accurate and that personnel use them correctly. After-
action reviews should be performed, with follow-through on all action items
that were identified.
Chapter Review
Business continuity plans define the methods the organization will use to
continue critical business operations after a disaster has occurred. Disaster
recovery plans define the steps that will be undertaken to salvage and
recover systems damaged by a disaster. Both BCP and DRP activities work
toward the restoration of capabilities in their original (or replacement)
facilities.
Notes
Questions
Training session
Penetration test
Vulnerability assessment
Gap analysis
Walk-through
Simulation
Parallel test
Cutover test
Time zone
Natural hazards
An organization has established a recovery point objective of 14 days for its
most critical business applications. Which recovery strategy would be the
best choice?
Mobile site
Warm site
Hot site
Cold site
Server clustering
Transaction monitoring
Backup media rotation may result in loss of data backed up several weeks in
the past.
Corruption of online data will require rapid data recovery from offsite
storage.
Ensuring that an automatic failure to the recovery site will occur because
personnel may be slow to respond
Ensuring that visitors know how to evacuate the premises and that they are
aware of the locations of sheltering areas
Ensuring that data replication to a recovery site has been working properly
After-action reviews
Test results
Training records
Mobile site
Warm site
Hot site
Cold site
Answers
D. RTO is the maximum period of time from the onset of an outage until the
resumption of service.
D. An organization that has a 14-day recovery time objective (RTO) can use
a cold site for its recovery strategy. Fourteen days is enough time for most
organizations to acquire hardware and recover applications.
B. The safety of personnel is always the top priority when any disaster
event has occurred. While important, the condition of information systems
is a secondary concern.
D. The best approach for protecting data from a high-velocity attack such as
ransomware is to back up the data to offline media that cannot be accessed
by end users. Replicating data to another storage system may only serve to
replicate damaged data to the secondary storage system, making recovery
more difficult or expensive.
C. It is apparent that the security incident response plan does not have
severity levels. One property of severity levels is the frequency and level of
internal communications. For instance, executives are spared from being
informed about minor incidents while they occur. Higher severity incidents
include notifications to managers higher in the organization, and more
frequent notifications.
C. An organization that has a four-hour recovery time objective (RTO)
should use a hot site for its recovery strategy. Only a hot site would be able
to perform primary processing within that period of time.
CHAPTER 8
Incident Management Operations
Attorney–client privilege
One Supporting Task in the CISM job practice aligns with the Incident
Management / Incident Management Operations domain:
Planning
Detection
Initiation
Analysis
Containment
Eradication
Recovery
Remediation
Closure
Post-incident review
Retention of evidence
Planning
Detection
Anonymous tips
Initiation
Analysis
In this phase, response team members collect and analyze available data to
understand the incident’s cause, scope, and impact. This may involve the
use of forensic analysis tools to understand activities on individual systems.
During this phase, partners or vendors may be engaged to collect
information from their systems to determine the extent of the compromise.
Containment
Eradication
Recovery
When the incident has been evaluated and eradicated, there is often a need
to recover systems or components to their pre-incident state. This can
include restoring data or configurations or replacing damaged or stolen
equipment.
Remediation
This activity involves any necessary changes that will reduce or eliminate
the possibility of a similar incident occurring in the future. This may take
the form of process or technology changes.
Closure
Post-incident Review
Shortly after the incident closes, incident responders and other personnel
meet to discuss the incident: its cause, impact, and the organization’s
response. Discussion can range from lessons learned to possible
improvements in technologies and processes to improve defense and
response further.
Retention of Evidence
Incident responders and other personnel direct the retention of evidence and
other materials used or collected during the incident. This may include
information used in legal proceedings such as prosecution, civil lawsuits,
and internal investigations. A chain of custody may be required to ensure
the integrity of evidence.
Incident declaration Some personnel are granted roles that can formally
declare a security incident. They are usually trained to recognize various
types of incidents and follow procedures to notify others of an incident.
Incident declaration formally triggers the performance of incident response
procedures and communications.
Scribe One or more scribes maintain records of all the proceedings. This
includes but is not limited to actions taken by all incident response
personnel, decisions, communications, and the location of records such as
retained logs and artifacts from forensic analysis.
Forensic analysis Many security events require one or more people with
expertise in computer and/or network forensics who seek to determine the
cause of an incident and methods that can be used to contain and eradicate
it. Because some security incidents may result in subsequent legal
proceedings, forensic analysts employ evidence preservation techniques and
establish a chain of custody to ensure that evidence is not altered.
Dedicated personnel The staff at an MSSP have only one job: monitoring
customers’ systems to identify and respond to security incidents. Unlike an
organization’s security staff, the personnel at an MSSP are not distracted by
other activities or projects, other than the continuous improvement of event
monitoring.
Cost control The fees charged by MSSPs may be less than the salaries,
benefits, tools, workspaces, and other costs required for in-house staff,
mainly because of economies of scale: MSSP personnel typically perform
security monitoring for numerous organizations.
Threat Hunting
The practice of threat hunting is used proactively to look for signs of
intrusions. Rather than passively monitoring systems, threat hunters use
tools to hunt for indicators of compromise (IOCs). The objective of threat
hunting is the earliest possible detection of intrusions. When an intrusion is
detected early, its impact on the organization may be low, particularly if an
attack is detected prior to the intruder achieving her attack objective. Threat
hunting is often carried out by organizations with mature event monitoring
programs. In other words, organizations considering threat hunting should
do so only after achieving a moderate to high level of maturity in their
monitoring tools and practices.
Depending upon the nature of a security incident, the security firm may
send forensic experts to the client’s location to perform forensics, or, if the
incident does not require onsite work, the client organization may send
malware samples, incident logs, or other digital information to the security
firm, where analysis can be performed remotely. In some cases, the
organization experiencing an incident may need a security firm to act as an
incident commander who may fulfill the role of managing the
organization’s activities in response to the incident.
Incident Detection
FALSE ALARMS
Some people are concerned with the prospect of declaring an incident when
no incident is taking place—in other words, a false alarm. Organizations
need to understand that a false alarm from time to time may be acceptable,
especially considering that the opposite problem of not recognizing and
declaring an incident may be far more harmful to the organization. It’s
better to roll the fire trucks and later discover that the alarm was caused by
a faulty smoke detector than to use valuable time confirming the presence
of a fire, which could result in more property damage and threat to human
life.
Incident Analysis
Forensic Investigations
After a security incident has occurred, the organization may determine that
an investigation is needed to determine the incident’s cause and effects. A
forensic investigator gathers, studies, and retains information that may be
needed in a court of law should the incident result in legal proceedings.
Because the information collected in an investigation may later be used in a
legal proceeding, a forensic investigator must understand the requirements
regarding the chain of custody and other evidence protection activities that
ensure that evidence can be used in court.
Prosecution of perpetrators
Investigations by regulators
Several major considerations determine the effectiveness of a forensic
investigation:
Some law firms also have in-house or retained forensics experts to assist
in investigations. The outside law firm can operate under attorney–client
privilege, which would also protect the information obtained by the forensic
investigator and her final report.
FORENSICS CERTIFICATIONS
Privacy Breaches
A breach of privacy is a unique type of security incident. In a privacy
breach, an attacker may steal or compromise sensitive or private data about
employees, customers, or other persons. The steps taken during incident
response will be largely the same as those for breaches of other types of
information. There are, however, two differences to keep in mind:
Incident containment includes the steps taken to prevent the incident from
spreading further. Containment requires knowledge of the particulars of the
incident and is most successful after the incident is examined and its
techniques identified in the assessment phase. Containment is distinct from
eradication, which is the removal of threats or threat actors from the
environment. When containment has been completed, the threat still exists,
but it cannot further proceed because containment measures have been
taken.
When an attack has been identified, and once the organization has
collected available information about the attack, the attack can be
effectively contained by severing most or all network communications from
the target system. This may, however, also impair incident responders from
carrying out subsequent eradication and restoration steps if they cannot
communicate with the system.
In such cases, if disaster recovery cannot rapidly recover the system, this
will also precipitate the activation of a business continuity plan (BCP),
which may include one or more contingency plans for continuing to operate
critical business processes without one or more supporting systems in place.
For instance, if the attacker compromised a retail store’s point-of-sale back
office server, and if point-of-sale systems cannot function without that
server, the retail store may have to resort to manual methods of completing
customer purchase transactions.
ATTORNEY–CLIENT PRIVILEGE
Regulatory Requirements
A “security incident” is the legal term that is often defined in privacy and
cybersecurity laws, regulations, and legal agreements between
organizations. Hence, organizations should use these and other words
carefully to avoid being prematurely required to make disclosures. Some
organizations avoid using “security incident” altogether, instead referring to
an incident as a “security event” and its written procedures as “security
event response procedures.” The rationale is this: Many regulations and
legal agreements require disclosure of a security incident within so many
hours of its declaration. Implicitly, if an organization is following a security
incident response procedure, it must already know that a security incident is
underway. Shifting the nomenclature from “security incident” to “security
event” helps protect an organization from prematurely disclosing the matter.
Recordkeeping
Typical incident response plans often direct that all proceedings of incident
response be recorded, so that post-incident activities can be informed by the
steps taken during the incident. This recordkeeping should include e-mails,
notifications, decisions, artifacts, reports, and virtually everything
connected with the incident.
Incident number
Incident date
Incident name
Short description
Metrics
Dwell time (time from the start of the incident to the time the organization
became aware of the incident)
Reporting
Incident Eradication
Fileless malware
Hiding data in memory, slack space, bad blocks, hidden partitions, or the
registry
Hiding “below” the operating system in the master boot record, in a virtual
machine hypervisor, or the system’s Basic Input/Output System (BIOS) or
unified extensible firmware interface (UEFI)
The personnel who examine infected systems must have up-to-date skills
and experience to identify and remove malware and other attack artifacts.
NOTE Certain classes of malware, such as multipartite viruses, contain
multiple components that work together to help the malware resist removal.
Incident Recovery
Incident Remediation
I stated that recovery is the action of returning a system or asset to its pre-
incident state, but you must understand a slight, but critical, nuance: we
don’t want to restore the system to its exact pre-incident state, but to a state
where the system functions as before the incident, but with one or more
immediate safeguards to prevent recurrence of the same or similar attack.
This is where recovery leads to remediation. Incident responders understand
that the intruder may not be satisfied that he was eradicated from target
systems. If any of the same vulnerabilities still exist, the intruder may
attempt to re-establish a foothold to resume the intrusion in support of its
original objective.
A key part of the investigation into the security incident must include an
identification and detailed analysis of the factors or vulnerabilities that led
to the incident’s occurrence. The key question that incident responders and
investigators should ask is what weakness(s) permitted the attack or
intrusion to succeed, and what should be done to the system to prevent the
same or similar attack from succeeding in the future? In this context,
remediation is more about fixing whatever was broken that permitted the
attack or intrusion, rather than re-engineering overall defenses. The latter is
generally addressed in a post-incident review that includes
recommendations for long-term improvements.
After the affected systems and devices have been eradicated of their attack
artifacts and recovered to normal use, incident response moves into a post-
incident phase. Incident responders and other key security and IT personnel
will close the active portion of incident response and begin discussions that
will hopefully lead to the generation of ideas to improve defenses and
response.
Closure
After an incident has been identified, its causes eradicated, and any affected
systems remediated and recovered, the incident can be closed. Mainly this
is a “back to business as usual” declaration. Some activities are necessary
for full closure:
Archival of forensic evidence All information and records obtained
through forensic analysis must be archived. The chain of custody must
continue, however, should any legal proceedings occur in the future.
Report issuance Formal reports are produced for internal and external
audiences that describe the incident and all of the steps of detection,
response, eradication, remediation, and recovery.
Post-incident Review
Chapter Review
Notes
Questions
Dwell time
Lag time
Lead time
Propagation
Walk-through
Simulation
Parallel test
Cutover test
Ensure that an automatic failure to the recovery site will occur as personnel
may be slow to respond.
Ensure that visitors and personnel know how to evacuate the premises and
are aware of the location of sheltering areas.
Ensure that data replication to a recovery site has been working properly.
Ensure that backup media will be available at the recovery site.
Purchase a SIEM.
Double locked
Chain of custody
Wait until the security incident is over, and then activate business continuity
and disaster recovery plans.
A disaster that damages computer systems can also damage backup media.
Backup media rotation may result in loss of data backed up several weeks in
the past.
Corruption of online data will require rapid data recovery from off-site
storage.
Contain and close the incident, and then notify the cyber-insurance
company.
Answers
B. Human safety is always the top priority when any disaster event has
occurred. Although important, the condition of information systems is a
secondary concern.
B. A SIEM is a central event log processing system that correlates events
among various devices. It produces alerts that may represent intrusions and
other types of security incidents.
D. The best approach for protecting data from a high-velocity attack such as
ransomware is to back up the data to offline media that end users cannot
access. Replicating data to another storage system may only serve to
replicate damaged data to the secondary storage system, making recovery
more difficult or expensive.
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 check your browser’s security settings or try using another
browser until the problem is resolved.
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.
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.
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.
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.
Your purchase of this McGraw Hill product, including its access code,
through a retail store is subject to the refund policy of that store.
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
Technical Support
acceptable use policy (AUP) A security policy that defines the types of
activities that are acceptable and those that are unacceptable in an
organization, written for general audiences and applying to all personnel.
access control Any means that detects or prevents unauthorized access and
that permits authorized access.
access control policy A statement that defines the policy for granting,
reviewing, and revoking access to systems and work areas.
audit plan A formal document that guides the control and execution of an
audit. An audit plan should align with audit objectives and specify audit
procedures to be used.
audit procedures The step-by-step instructions and checklists required to
perform specific audit activities. Procedures may include a list of people to
interview and questions to ask, evidence to request, audit tools to use,
sampling rates, where and how evidence will be archived, and how
evidence will be evaluated.
audit program The formalized and approved plan for conducting audits
over a long period.
backup media rotation Any scheme used to determine how backup media
is to be reused.
botnet A collection of bots that are under the control of an individual. See
also bot.
bring your own app (BYOA) A practice whereby workers use personally
owned applications for company business.
bring your own software (BYOS) See bring your own app (BYOA).
call tree A method for ensuring the timely notification of key personnel,
such as after a disaster.
career path The progression of responsibilities and job titles that a worker
will attain over time.
chief information risk officer (CIRO) The typical job title for the
topmost information security executive in an organization. Generally, this
represents a change of approach to the CISO position, from protection-
based to risk-based. See also chief information security officer (CISO).
chief information security officer (CISO) The typical job title for the
topmost information security executive in an organization.
chief risk officer (CRO) The typical job title for the topmost risk
executive in an organization.
chief security officer (CSO) The typical job title for the topmost security
executive in an organization.
cold site An alternate processing center where the degree of readiness for
recovery systems is low. At the least, a cold site is nothing more than an
empty rack or allocated space on a computer room floor.
contact list A list of key personnel and various methods for contacting
them, often used in a response document. See also response document.
continuous log review A process whereby the event log for one or more
systems is being continuously reviewed in real-time to determine whether a
security or operational event warranting attention is taking place. See also
security information and event management (SIEM).
contract A binding legal agreement between two or more parties that may
be enforceable in a court of law.
control A safeguard enacted to ensure compliance with a policy, to ensure
desired outcomes or to avoid unwanted outcomes.
control risk The risk that a significant or material error exists that will not
be prevented or detected by a control.
cutover The step in the software development life cycle where an old,
replaced system is shut down and a new, replacement system is started.
data acquisition The act of obtaining data for later use in a forensic
investigation.
data debt The state of being hampered by data models of older vintages
that are no longer business aligned, often resulting in the fracturing of data
into an increasing number of silos. See also technical debt.
data governance Management’s use of policies, metrics, and monitoring
to enforce proper and appropriate access and use of data.
data restore The process of copying data from backup media to a target
system for the purpose of restoring lost or damaged data.
digital signature The result of encrypting the hash of a message with the
originator’s private encryption key; used to prove the authenticity and
integrity of a message.
disk array A chassis in which several hard disks can be installed and
connected to a server.
distributed denial of service (DDoS) A denial-of-service (DoS) attack
that originates from many computers. See also denial of service (DoS).
dwell time The period of time that elapses from the start of a security
incident to the organization’s awareness of the incident.
exposure factor (EF) The financial loss that results from the realization of
a threat, expressed as a percentage of the asset’s total value.
fiduciary A person who has a legal trust relationship with another party.
file activity monitoring (FAM) A program that monitors the use of files
on a server or an endpoint as a means for detecting indicators of
compromise.
file server A server used to store files in a central location, usually to make
them readily available to many users.
first in, first out (FIFO) A backup media rotation scheme by which the
oldest backup volumes are used next. See also backup media rotation.
Foreign Corrupt Practices Act of 1977 (FCPA) A U.S. law that forbids
persons and organizations from bribing foreign government officials.
general data protection regulation (GDPR) The European law that took
effect in 2018 that protects the privacy of European Union residents.
hot site An alternate processing center where backup systems are already
running and in some state of near-readiness to assume production workload.
The systems at a hot site most likely have application software and database
management software already loaded and running, perhaps even at the same
patch levels as the systems in the primary processing center. See also cold
site, warm site.
impact The actual or expected result from some action such as a threat or
disaster.
impact analysis The analysis of a threat and the impact it would have if it
were realized.
incident Any event that is not part of the standard operation of a service
and that causes, or may cause, interruption to or a reduction in the quality of
that service.
inherent risk The risk that material weaknesses are present in existing
business processes with no compensating controls to detect or prevent them.
key generation The initial generation of an encryption key. See also key
management.
key rotation The process of issuing a new encryption key and reencrypting
data protected with the new key. See also key management.
log correlation The process of combining log data from many devices to
discern patterns that may be indicators of operational problems or
compromise.
log server A system or device to which event logs from other systems are
sent for processing and storage. See also centralized log management,
security information and event management (SIEM).
macro virus Malicious software that is embedded within another file, such
as a document or spreadsheet.
mobile site A portable recovery center that can be delivered to almost any
location in the world.
offsite media storage The practice of storing media such as backup tapes
at an offsite facility located away from the primary computing facility.
operational risk The risk of loss resulting from failed controls, processes,
and systems; internal and external events; and other occurrences that impact
business operations and threaten an organization’s survival.
Operationally Critical Threat Asset and Vulnerability Evaluation
(OCTAVE) A qualitative risk analysis methodology developed at Carnegie
Mellon University.
out of band Communications that take place separately from the main
communications channel.
policy A statement that specifies what must be done (or not done) in an
organization. A policy usually defines who is responsible for monitoring
and enforcing it.
project plan The collection of documents that describe the stages and
oversight of a project. A project plan outlines the sponsor, stakeholders,
goals, milestones, tasks, resources, risks, constraints, and timelines needed
to accomplish the stated objective(s).
quarantine A holding place for e-mail messages that have been blocked by
a spam or phishing filter.
recovery time objective (RTO) The period from the onset of an outage
until the resumption of service, usually measured in hours or days.
residual risk The risk that remains after being reduced through risk
treatment options.
right to audit A clause in a contract that grants one party the right to
conduct an audit of the other party’s operations.
risk Generally, the fact that undesired events can happen that may damage
property or disrupt operations; specifically, an event scenario that can result
in property damage or disruption.
risk appetite The organization’s overall acceptable level of risk for a given
business venture.
risk assessment An activity where risks, in the form of threats and
vulnerabilities, are identified for each asset.
risk transfer The risk treatment option involving the act of transferring
risk to another party, such as an insurance company or service provider.
risk treatment The decision to manage an identified risk: mitigate the risk,
avoid the risk, transfer the risk, or accept the risk.
secure coding The practice of developing program source code that is free
of security defects. See also secure development training.
service desk The IT function that handles incidents and service requests on
behalf of customers by acting as a single point of contact. See also IT
service management (ITSM).
single loss expectancy (SLE) The financial loss that results from the
realization of a threat. SLE is defined as asset value (AV) × exposure factor
(EF). See also asset value (AV), exposure factor (EF).
skills matrix A chart that includes names of staff members and their
relevant skills as axes, with indicators on which staff members have which
skills, and with what levels of proficiency.
steganography Any technique that hides data within another data file.
three lines of defense A functional model that defines roles related to the
development, operation, and assurance of controls and policies.
vendor standard A standard that specifies which suppliers and vendors are
used for various types of products and services.
war room A meeting room or other place where incident responders gather
to coordinate incident response activities.
whaling Spear phishing that targets executives and other high-value and
high-privilege individuals in an organization. See also business e-mail
compromise, phishing, spear phishing.
cceptance of risk
description, 116
esidual, 173
ccess administrators, 27
acilities, 366
ccountability
olicies, 43
RACI charts, 16
ecurity strategy, 54
ction plans
Cybersecurity Framework, 264
dministrators, access, 27
dvisories
lerts
roadcast, 441
lignment
BMIS architecture, 77
valuating, 492
T operations, 446
nalysis
ncidents, 509–513
isk. See risk assessment and analysis
ntimalware
metrics, 225
ntivirus software
usiness alignment, 9
pplication servers
lusters, 470
pplications
ncryption, 321
whitelisting, 296
rchitectures
ssessment
gap, 56–59
lassification, 202–208
hardware, 199–200
nformation, 201
valuation, 209–210
virtual, 201–202
sset management
TSM, 394
usiness alignment, 8
dentification, 136
ssets
acilities, 367
ecurity strategy, 47
ssistants, 14
ecurity strategy, 38
udiences
uditors
artnerships, 371
elf-assessment, 339
udits
ontrols, 322–323
vidence, 329–331
xternal, 335–336
gap assessment, 57
methodology, 327–329
monitoring, 29
bjectives, 325
utsourcing, 347
ecurity strategy, 53
echniques, 324–325
TPRM, 353
ypes, 325–327
uthentication
ncryption, 310
dentity and access management, 299
utomation
BMIS model, 77
valanches, 428
voidance, risk
description, 117
SO/IEC 27005, 123
wareness
wareness training
udiences, 340–343
ommunications, 343–344
gap assessment, 58
bjectives, 339–340
eporting, 375–376
B
ncryption, 307
ecords, 308
eplication, 308–309
otation, 305–306
chemes, 305
ape, 304
ehavioral skills, 46
ig data architects, 24
oards of directors
oles, 16–18
ecurity strategy, 39
reaches
rivacy, 512
hird-party, 49
ecurity strategy, 50
udgets
ecurity strategy, 70
usiness alignment
riticality, 39
gap assessment, 56
ecurity strategy, 38
usiness analysts, 29
esponsibilities, 503
ecurity governance, 7
raining, 476–477
omponents, 451–452
onsiderations, 447–451
development overview, 436
disasters, 427–434
valuating, 484–487
gap assessment, 58
maintaining, 453–454
olicies, 434–435
rocess, 434
oles, 27
esting, 478–483
ig picture, 417
ecurity strategy, 50
usiness processes
ecurity strategy, 50
ecurity strategy, 50
ategories
CSF functions, 86
ncidents, 473–475
trategic objectives, 55
tandards, 43
ertifications
orensics, 512
ontrols, 63
TSM, 386–388
rganizational inertia, 72
iphers, 313
iphertext, 311
tandards, 43
lassification
ssets, 202–208
acilities, 207
ncidents, 473–475
nformation, 203–205
ersonnel, 207–208
ystem, 206–207
vendor, 354–356
lients for incident reporting, 508
losure
ctivities, 522
loud
usiness titles, 26
description, 371–372
loud sites
hardware, 466
CM (configuration management)
TSM, 388–389
oding
canning, 151
tandards, 151
old sites
hardware, 465–466
disasters, 440–441
udgets, 382–383
acilities, 366–367
monitoring, 30
olicies, 42
rocurement, 369
roject and program management, 382
ecurity governance, 6
udits, 326
disasters, 442
nsurance, 48
metrics, 227
monitoring, 375
utsourcing, 347
verview, 373–374
olicies, 43
onfiguration
aults, 127
tandards, 64
TSM, 388–389
onsultants
RACI charts, 16
ontact lists
ontainment
methods, 513–515
ontent
ontent filters
web, 289–290
ontext
ontingencies
BCP and DRP plans tests, 479–480
ontinuing operations
disasters, 446
ontractors
n workforce, 29
ontractual obligations
COSO, 267
CSA, 270
mapping, 250–251
NERC, 267–269
verview, 248
ecurity strategy, 63
electing, 248–249
tandards, 64
verview, 212–213
rinciples, 267
monitoring, 322
eviews, 322–323
ontrols
BMIS model, 77
ategories, 245
lasses, 243–245
lassification, 242–243
developing, 272–275
disaster recovery sites, 465
gap assessment, 57
mplementation, 275
monitoring activities, 29
bjectives, 245–246
verview, 145
urpose, 242
isk assessment for third parties, 52
ecurity governance, 6
elf-assessment, 337–339
tandards, 72–88
TPRM, 352
ypes, 243
ontrols analysts, 25
ontrols managers, 26
osts
BMIS architecture, 77
utsourcing, 345–346
quantitative risk analysis, 141
ecurity strategy, 70
risis communications
management, 515–516
ole, 27
riteria
uccess, 91
riticality
usiness alignment, 39
rosswalks, 250
ryptography
verview, 310
description, 371–372
ulture
usiness alignment, 8
onstraints, 69
rganizational, 9–11
ustodial responsibilities, 21
utover tests
raining, 477
yber insurance
MSSPs, 506
ctivities, 262–264
omponents, 215–216
highlights, 86–87
verview, 85–86
urpose, 218
teps, 87–88
data acquisition
data debt, 45
data governance
data managers, 24
data scientists, 24
database analysts, 24
database architects, 24
ncidents, 409
declaration of incidents
esponsibilities, 502
decryption, 312
design
rchitecture issues, 44
destruction
ackups, 308
destructware, 295–296
detection
developing, 471–472
valuating, 488–492
gap assessment, 58
hardware, 465–466
nputs, 455
verview, 406–408
esults, 490
oles, 27
ecurity governance, 7
trategies, 459–460
esting, 478–483
disasters
ffects, 433–434
human-caused, 431–432
natural, 428–431
esponsibilities, 439–445
ncidents, 409
document reviews
raining, 477
documentation
isk, 182
due diligence
nboarding, 352
TPRM, 353–354
duties
RACI charts, 16
dwell time
educing, 508
rotecting, 290–292
ublic key cryptosystems, 316
ncryption
pplications, 321
ackups, 307
ncidents, 409
malware, 295–296
argets, 294
VDIs, 297
whitelisting, 296
nterprise governance, 3
notes, 31–32
eview, 30–31
ecurity, 4–9
description, 111
nvironment
BMIS model, 79
quipment
disaster recovery sites, 464–465
acilities, 366
radication
rocess, 519–520
description, 111
valuation
isk, 144
monitoring, 276–277
vidence
udits, 329–331
gap assessment, 58
xecutive management
esponsibilities, 18–19
ecurity strategy, 39
xternal audits
easons, 335–336
eports, 57
TPRM, 353
xternal communications
disasters, 442
xternal partnerships
aw enforcement, 370–371
xternal services
utsourcing, 345–348
verview, 344–345
acilities
s asset, 199
lassification, 207
alse alarms
ear culture, 69
iduciary responsibility
oards of directors, 17
ilters
DNS, 290
hishing, 290–292
inance managers, 29
irewalls
metrics, 225
udits, 326
ertifications, 512
hain of custody, 510
orensics analysts, 27
rameworks
management, 218
mitigation, 168
NIST CSF. See Cybersecurity Framework (CSF)
olicy development, 62
tandards, 64
Zachman, 81–82
goals
utsourcing, 347
governance
ctivities and results, 7–8
BMIS model, 76
defined, 3
ntroduction, 4–6
easons, 6–7
oles, 26
oles, 26
guidelines
gap assessment, 57
ackups, 304
ncryption, 295
hardening
hardware
ssets, 199–200
disasters, 445
ections, 266
hot sites
hardware, 466
ce storms, 429
dentification
verview, 300–301
mpact
dentifying, 137
isk, 138–139
mplementation
ontrols, 275
ncident management
arts, 302
ommunications, 515–517
notes, 524
verview, 499
hases, 499–502
questions, 524–528
ecovery, 520–521
emediation, 521–522
eview, 523–524
notes, 494
verview, 405–406
questions, 494–498
eview, 493–494
raining, 475–477
ncident response
valuating, 492–493
verview, 408–410
laybooks, 411
ecurity governance, 7
TPRM, 353
raining, 475–477
developing, 411–417
scalation, 416–417
maturity, 412
bjectives, 411–412
verview, 406–410
laybooks, 414–415
esources, 412–414
esting, 477–483
updates, 415
nalysis, 509–513
losure, 522
detection, 507–508
nitiation, 509
emediation, 521–522
esponse. See incident response; incident response plans
ecurity strategy, 67
nertia, organizational, 72
nfinite regress, 52
ommunication, 367–368
gap assessment, 58
perations roles, 25
nitiation, incident
esponse, 500
teps, 509
nnovation and learning in balanced scorecards, 233
nsurance
TPRM, 353
ntegration
ontrols, 272
ntegrity
ntellectual property
s asset, 201
ntelligence
AI, 253
nternal audits
monitoring, 29
verview, 333–335
eports, 57
nternal communications
disasters, 441
nternal partnerships
verview, 364
nterviews
BMIS, 73–74
ertifications, 372
governance description, 76
ections, 83–85
description, 213
bjectives, 254–259
methodologies, 121–124
ctivities, 383–384
mportance, 384
ob descriptions, 377–378
ob titles, 13
key personnel
vailability in disasters, 447
nterviewing, 486–487
metrics, 225
verview, 180–181
keyloggers, 296
xchanging, 313–314
generating, 319
rotecting, 320
metrics, 225
verview, 180–181
aw enforcement
ommunication with, 370–371
aws
eadership
eading indicators
KRIs, 181
metrics, 226
egal counsel
xternal, 506
egal departments
egal issues
disasters, 442
usiness alignment, 8
ecurity strategy, 71
ife cycles
BCP, 434–435
BMIS, 81
CSA, 337–338
governance, 88
ikelihood of risk
onsiderations, 137–138
og servers, 276
ogs
malware
description, 409
management
rameworks, 218
maturity
media managers, 25
methodologies
CSA, 337
CVSS, 278–279
OCTAVE, 143
tandards, 64
metrics
ontrols, 274
gap assessment, 57
monitoring, 30
equiring, 174
missions
usiness alignment, 8
utsourcing, 347
mitigation
OCTAVE, 142
monitoring
udits, 29
ncidents, 505–507
metrics, 226
esponsibilities, 29–30
isks, 180–182
equiring, 174
multimaster replication, 308
National Institute for Standards and Technology (NIST) standards, 43, 118
ublications, 371
SP 800-30, 119
SP 800-37, 108
SP 800-171, 215
SP 800-207, 293
natural disasters, 428–431
nfrastructure, 267–269
network administrators, 25
network architects, 24
network engineers, 24
network protection
CASB, 290
DDoS, 285
-mail, 290–292
irewalls, 282–284
DSs, 285
PSs, 284–285
NAC, 292
NTA, 285–286
verview, 282
egmentation, 283–284
wireless, 287–288
networks
disasters, 444
NIST. See National Institute for Standards and Technology (NIST) standards
nfrastructure, 267–269
bjectives
ecurity governance, 5
bjectivity
utsourcing, 345
ffsite storage
disasters, 444–445
valuating, 491–492
nboarding
urpose, 365
TPRM life cycle, 352
perating systems
perational criticality
perations
ontrols, 275–276
perations analysts, 25
perations managers, 25
pportunities
SWOT analysis, 60
SOAR, 277
thics, 10–11
rganizational roles
ustodial responsibilities, 21
data management, 24
general staff, 29
T operations, 25
miscellaneous, 28
verview, 12–14
quality assurance, 28
RACI charts, 15–16
ecurity audit, 28
ecurity operations, 27
ervice desk, 28
ystems management, 25
utages, 431
utsourcing
enefits, 345
isks, 345–346
wnership
ontrols, 274
arallel tests
raining, 477
artnerships
xternal, 370–373
nternal, 364–370
perational, 303
atch management
description, 249
bjectives, 217
tructure, 264–266
description, 249
bjectives, 217
tructure, 264–266
PCI Forensic Investigator (PFI), 265
enetration testers, 27
enetration tests
erformance
monitoring, 30
ecurity strategy, 38
ersonnel
s asset, 199
lassification, 207–208
ritical, in disasters, 448
nterviewing, 486–487
MSSPs, 505
ulture, 378
ob descriptions, 377–378
hysical security
disasters, 443
laintext, 311
udits, 327
usiness cases, 91
olicies
gap assessment, 56
olicy managers, 26
osition benchmarking, 30
ost-incident reviews
ractices, 522–523
rinciples
usiness alignment, 8
COBIT, 267
COSO, 267–268
SOC 2, 271
rior incidents, insurance costs related to, 49
rivacy
reaches, 512
CPOs, 23
rivilege accumulation
description, 300
robability
roblem management
rocedures
gap assessment, 57
rocesses
rocurement
ertifications, 379–381
raining, 381
rchitectures, 218–220
harters, 194
guidelines, 223
metrics, 225–233
notes, 236
utcomes, 193–194
questions, 237–240
equirements, 223–224
esources, 192–199
eview, 233–235
cope, 195
ecurity governance, 6
tandards, 223
echnologies, 196–198
rends, 192–193
rogram management
ntroduction, 241–242
MSSPs, 302–303
notes, 396–397
questions, 397–401
eview, 394–396
roject management
ommunications in, 382
ecurity governance, 6
roject managers, 29
rotocol standards, 64
QA managers, 28
QC managers, 28
quality issues
utsourcing, 346
questionnaires
nboarding, 352
anks
ncidents, 509
isk, 144
ansomware
ncidents, 409
nsurance, 49
ecordkeeping
ecords
pproaches, 520–521
verview, 423–425
ricing, 458
verview, 423–424
ricing, 458
ontrols, 242
gap assessment, 59
ecurity strategy, 71
egulators
emediation
ncidents, 521–522
eplication
ackups, 308–309
disaster recovery plans, 468–469
equirements
usiness cases, 91
esidual risk
isk registers, 150
esilience
BMIS architecture, 77
usiness, 27
esource access
oards of directors, 17
metrics, 228
ecurity governance, 7
esponsibilities
disasters, 439–446
xecutive management, 19
meaning, 14
monitoring, 29–30
ersonnel management, 377
RACI charts, 16
ecurity strategy, 65
esults
isk
ontrols, 274
mpact, 138–139
ikelihood, 137–138
utsourcing, 345–346
wnership, 144–145
isk appetite
usiness alignment, 9
udits, 324
ontrols, 242
gap assessment, 57
mportance, 102–103
evels, 111–112
mandatory, 176
notes, 159–160
bjectives, 103
utcomes, 103
questions, 160–164
eview, 157–158
ecurity strategy, 41
echnologies, 104–105
isk management
ecurity governance, 7
echnologies, 104–105
methodologies, 117–126
rocess, 115–117
NIST, 118–121
ontext, 109–110
rameworks, 108–109
mplementing, 105–106
utcomes, 103
trategies, 106–108
isk managers, 26
isk registers
lements, 177–178
gap assessment, 57
tructure, 146–147
cceptance, 170–171
voidance, 169–170
gnoring, 171
mitigation, 167–168
notes, 183
eview, 182–183
ransfer, 168–169
isk tiering
utsourced services, 52
isk treatment
ctions, 166–167
nsurance, 49
oles
disasters, 439–446
ecurity strategy, 65
ootkits, 296
otation
keys, 320
verview, 423–425
ricing, 458
verview, 423–424
ricing, 458
ules
-mail, 291
irewalls, 283
Sarbanes-Oxley Act, 17
calability
BMIS architecture, 77
cans
chedules
cope
udits, 53, 324, 327, 335
cribes
ecurity
BMIS architecture, 77
s business prevention, 9
ecurity analysts, 27
ecurity architects, 27
ecurity auditors, 28
gap assessment, 58
rainers, 26
ecurity engineers, 27
ecurity governance
BMIS model, 76
defined, 3
ntroduction, 4–6
easons, 6–7
ecurity guards, 367
ontrols, 277
ncident logs, 51
ecurity managers
ecurity operations
oles, 27
ecurity orchestration, automation, and response (SOAR) platform, 277
ecurity policies
gap assessment, 56
tructure, 221–222
ecurity scans
rchitecture, 44–45
ssets, 47
udits, 53
onstraints, 68–72
ontrols, 45
ulture, 53–54
developing, 55–68
nsurance, 48–49
ntroduction, 37
maturity, 54
metrics, 46
notes, 93–94
bjectives, 38–39
articipants, 39–40
olicies, 42–43
questions, 94–98
esources, 40–55
eview, 91–93
isk appetite, 55
isk assessments, 41
kills, 46
tandards, 43
hreat assessments, 42
vulnerability assessments, 48
ecurity teams, 40
Security+ certification, 380
egregation of duties
RACI charts, 16
elf-assessment
uditors, 339
ontrols, 337–339
ervice-level management
TSM, 391–392
ervice organization controls, 270–272
ervice providers
udits, 326–327
hadow ITs
description, 9
ontrols, 277
ncident logs, 51
ignatures
ntimalware, 296
ryptography, 312–317
imulations
raining, 477
kills
or attacks, 138
utsourcing, 345
RACI charts, 16
mishing, 291
niffers, 287–288
oftware
s asset, 199–200
onfiguration items, 388
oftware development
oles, 23–24
oftware engineers/developers, 23
oftware testers, 23
pim, 291
pyware, 295
tandards, 43
oding, 151
onfiguration, 64
ontrols, 64, 72–88
gap assessment, 57
NIST. See National Institute for Standards and Technology (NIST) standards
olicy development, 62
ecurity governance, 6
teering committees
esponsibilities, 19–20
torage
disasters, 444–445
valuating, 491–492
torage engineers, 25
trategic alignment
metrics, 226–227
trategic planning
trategies
usiness alignment, 8
ecurity governance, 5
trictness of policies, 42
trong culture, 69
tructure
udit reports, 332–333
description, 249
ystems administrators, 25
ystems analysts, 23
ystems engineers, 25
ystems operators, 25
ape backups
verview, 304
eams
ecurity strategy, 40
echnical architecture
metrics, 230
echnologies
BMIS model, 75
kills for, 46
elecom engineers, 25
emps, 29
enure in skills, 46
errorism, 432
esting
ackups, 304
hird parties
ssessing, 356–360
dentifying, 348–350
hird-party risk
gap assessment, 58
ecurity strategy, 51
MSSPs, 506
hreat identification
ctors, 136
merging, 135–136
xternal, 132–134
nternal, 130–132
verview, 129–130
hreat intelligence
hreats
ssessments, 42
SWOT analysis, 60
60 feedback, 30
itles
loud, 26
ontrols, 274
osition, 13–14
anks, 22
raining
disasters, 445
gap assessment, 58
ncident logs, 51
ransfer, risk
description, 117
ribal knowledge
gap assessment, 59
utsourcing, 346
Trojans, 295–296
sunamis, 429–430
value delivery
metrics, 228
ecurity strategy, 38
vendor managers, 28
vendors
ailures, 347
tandards, 64
TPRM classification of, 354–356
verification
viruses
volcanos, 428
vulnerabilities
orms, 127–128
hird-party, 129
vulnerability assessment
ecurity strategy, 48
TPRM, 352
vulnerability management
ontrols, 277–282
TPRM, 352
walk-throughs
raining, 477
wallet cards
disasters, 450–451
hardware, 465
weak culture, 69
weaknesses
SWOT analysis, 59
undiscovered, 128
verview, 289–290
whitelists
pplications, 296
-mail, 291
wildfires, 428–429
windstorms, 429
wiperware, 409