Risk Assessment of Information System Security Risks (Due 27 March) (5 Pages) (5 References)

EnterpriseSecurityRisManagmentChap4-9.pdf

Home >Information Systems homework help >Risk Assessment of Information System Security Risks (Due 27 March) (5 Pages) (5 References)

Part 2

The Fundamentals of ESRM In Part 1, you gained an overall view of what ESRM is and how it can benefit your security program. Specifically, you saw how it can benefit in your ongoing security career. Now we will delve into how to begin your ESRM journey. In Part 2 of this book, you will learn about activities to get you, your department, and your enterprise ready to follow an ESRM program. You will also explore further details about the ESRM cycle that was introduced in Part 1.

In This Part:

• Before You Begin • The ESRM Cycle – An Overview • The ESRM Cycle – Step 1 – Identify and Prioritize Assets • The ESRM Cycle – Step 2 – Identify and Prioritize Security Risks • The ESRM Cycle – Step 3 – Mitigate Prioritized Risks • The ESRM Cycle – Step 4 – Improve and Advance

Allen, Brian J., and Rachelle Loyear. Enterprise Security Risk Management : Concepts and Applilcations, edited by Kristen Noakes-Fry, Rothstein Associates, Incorporated, 2017. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/trident/detail.action?docID=5166413. Created from trident on 2021-03-20 10:15:23.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Preparing for an ESRM Program

Now that you have a start on understanding ESRM and how it differs from traditional security management methods, you are ready to move into the implementation process. In this chapter, we will help you begin your ESRM journey by covering the preparation steps to follow as you introduce ERSM into your security organization. We will also discuss the people across the rest of your enterprise whom you will need to involve in ESRM and how you can get their cooperation for your program.

This chapter will help you to: • Do the up-front research to embark on an ESRM program. • See how to relate your security program to your business environment. • Identify the stakeholders in your security program, and understand their needs. • Understand the difference between an asset owner and a risk stakeholder, and determine how to best

work with each. • Understand corporate culture, which will be the foundation for a risk-based security program.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

4.1 Understand the Business and its Mission The first activity in an ESRM implementation process, before even entering the steps of the cycle itself, is to spend time investigating your enterprise and truly understanding it. It is impossible to know the measures you will need to take to evaluate, mitigate, and protect against enterprise risks unless you know what those risks are. You cannot understand those risks unless you understand the business, what it does, and why it does it.

An analysis by the leading consulting firm PricewaterhouseCoopers explains in detail why risk management activities (like ESRM) need to consider the overall business context:

“It is important to begin by understanding the relevant business objectives in scope for the risk assessment. These will provide a basis for subsequently identifying potential risks that could affect the achievement of objectives, and ensure the resulting risk assessment and management plan is relevant to the critical objectives of the organization.…The focus on business objectives helps ensure relevance and facilitates the integration of risk assessments across the organization.” (PwC, 2008, p.21-22).

Figure 4-1. Businesses in the global economy are complex and highly interconnected and require an understanding of many “moving parts.” 4.1.1 Holistic Understanding of Risk Figure 4-1 shows why understanding your business is going to be a complicated undertaking that involves many complex and interconnected parts. But that understanding is necessary for implementing a successful security program.

For example, to protect the supply chain that begins with parts in Asia and ends with a finished product on the shelf in Canada, it is imperative that you know:

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

• The path that the parts take. • The environments they are moving through. • Which parts are time sensitive and critical, and which have schedule flexibility. • Who in the business is dependent or interdependent on the parts. • What the finished product is and does. • How consumers use the product. • Whether the product is an essential good or a luxury item, and how the customers view it. • How disruptive it would be if the supply chain were interrupted.

Those are just a few of the things you need to understand about one type of business. A financial firm or a bank has aspects to understand that are different from a chain of convenience stores, and understanding an entertainment company is far different from the discovering the details of a medical facility.

The common link that they all have is: • A product or service that they provide (or other reasons for conducting operations). • Employees (or volunteers) doing tasks that contribute to the enterprise objective. • Consumers or recipients of the end-product or service. • An environment they operate in. • People who are authorized to make decisions on behalf of the organization. • Risks.

Finding the specifics of your organization is the starting point of implementing an effective, risk-based security program.

Even if you have been working at a company for a very long time – perhaps especially if you have been working there for a very long time – it is imperative to take a good look at how the business is functioning now. Enterprises’ missions change constantly. Some of the ways in which your organization might have changed since the last time you assessed it might be: • Older products and services become less valuable, and so less critical in the business risk profile. • New products and services are brought to market. • Industry drivers such as supply-and-demand change constantly. • Competitive threats and opportunities change along with these other changes.

You should think about all these factors during any business assessment; your understanding of the business needs to be continuously updated, revised, and refined to ensure that the program can align with business changes up front, rather than as an afterthought.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for the Security Practitioner • “Do I truly understand the overall business model and the ins and outs of my organization?” • “When was the last time I investigated how my organization works, and what operations are

happening in various locations?” • “If an outsider asked me a question about an area of my organization that was not related to

security, could I answer them?”

4.1.2 The Needs of Your Business Through years of managing security organizations and speaking with countless security practitioners, an important lesson we have learned is:

If your security program is not clearly and realistically aligned with the needs of the business, it will be considered out of touch at best, and a liability at worst.

If you cannot show that you fully grasp the needs of your potential strategic partners in protecting the enterprise, they will have no real reason to trust or rely on you to help them continue those operations.

Case Study: Understanding the Unfamiliar Carol D., a very experienced IT security manager, spent years working for a company in the midwestern US that specialized in cloud-based hosted network services. She was responsible for securing the internal network and data center, the hosted data and applications, as well as disaster recovery. Her success got her noticed, and a headhunter approached her about a very different job: director of security for SecStat, a company helping small-to-midsized businesses (SMBs) to deploy and integrate physical security systems on their premises.

Overnight, Carol went from protecting mostly intangible virtual assets, using electronic means like encryption and intrusion detection systems, to being responsible for securing SecStat’s offices, making sure the company’s employees were safe, running background checks on installation personnel, and many more of the usual “traditional” security practices. While Carol did have a solid background in overall security management and was familiar with many of the more physical-based security disciplines from her years in the industry, her knowledge was not at the level her new position required. “The first time I talked with one of the senior business leaders,” she remembers, “I felt like Alice stepping through the looking glass. He was talking about camera apertures and lumens of lighting and security bollards – stuff I didn’t know about in any kind of detail, but that they knew intimately because it is the product and service they sold.”

Carol knew she needed a “crash course” in what her new company did and how it did it. To her credit, she wasn’t afraid to go to her new colleagues and managers and ask questions – even questions that were so simple, so basic, that they embarrassed her. (“A little honest ignorance will take you a long way,” she says now.) And, somewhat to her surprise, she found that people – from design engineers, to product marketing managers, to senior executives – were more than happy to talk about what they did, why it mattered, and what was most important to them.

The result was that she developed strong working relationships with her new business partners, understood and prioritized their needs, and developed effective risk mitigation methods to recommend to them. She even found that a lot of her “virtual” security expertise could be leveraged to protect physical business assets.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

4.1.3 Sources of Information There are many ways to approach understanding an enterprise and its mission, but through years of working in our own business environment and talking with other security professionals, we can distill the process to three basic ways of understanding the enterprise and the associated risk environment:

1. Listen to insiders. 2. Examine the enterprise’s internal and external messaging. 3. Listen to outsiders.

4.1.3.1 Company Insiders The simplest, most straightforward way to understand what is critical to the business is to engage with the people who are running it day-to-day. They know how the business works; they know what is important; they know what assets represent the greatest business risks and business opportunities. Hearing what key executives and managers say about the business’s mission and objectives is essential. It will help you understand other strategic partners’ priorities, and understand how their concerns and priorities fit in the overall work of the enterprise.

It is not always easy to communicate with people in other parts of the enterprise who have vastly different responsibilities. To make it easier to start the conversation, below are a few examples of key stakeholders, and some questions you could use, or adapt, to open a meaningful dialogue.

The Chief Risk Officer (CRO): • “What are the risks you are most worried about right now, and what is just at the edge of your radar

screen?” • “What risks are you possibly spending extra time and effort on that may not be so important as to

justify that extra time and effort?” The Chief Compliance Officer (CCO): • “What regulatory and other compliance bodies and frameworks do you have to report to and interact

with?” • “How are those relationships working? Are some especially difficult or sensitive?” • “What are the consequences of failing to meet certain regulatory requirements?”

The Chief Operating Officer (COO): • “How does security impact the overall efficiency of the business?” • “Is security helping, or hindering, or some of both?” • “How do you think security is perceived by line-of-business managers and other operational heads?” The Corporate Legal Counsel: • “What are your biggest concerns related to security and risk?” • “What legal liability could our security measures potentially be exposing the company to?” • “Should we involve the legal department each time we suspect criminal activity? If not, how serious

should the alleged infraction be before we contact you?” • “How can we assist with the legal mission, and how can we support or assist with litigation and

liability reduction efforts?”

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

One simple, powerful question – which has certainly helped us repeatedly in our security careers -- that you can use when speaking with any stakeholder at any level is:

“How can I help you to be successful?”

Once you have heard what the executives have to say, talk to the people who run the enterprise’s various lines of business. Here are a few sample questions you can ask them: • “What product or service does your organization deliver, and what role does that play in the

business’s overall mission and goals?” • “What is your organization’s most important contribution to the business?” • “How does your product or service work, and what resources – for example, skills, physical assets, or

intellectual property – does your organization need to make it work?” • “What are your organization’s most urgent priorities, and what environmental factors do you see

potentially changing those priorities?” • “What security risks are you most concerned about right now?”

In many cases, your internal strategic partners are already aware of many of the risks they face, and can lay them out for you very clearly. In others, your discussions will be a starting point to educate you about the business, and to educate your partners about risks and about your role in security risk management.

This process of getting to know your internal business partners and what they need is a critical building block of the relationships – the strategic partnerships – that ESRM both creates and depends on to drive success in the security program.

Questions for the Security Practitioner • “Who are the critical internal partners I should speak with to learn more about the enterprise I work

for, the business it is in, and the environment it operates in?” • “Would the security organization benefit from an inventory of information sources which everyone

in security could consult, from experienced practitioners to new hires?” • “What topics do I already know I should talk to company subject matter experts about to learn

more? What topics do I think my strategic partners might benefit from hearing more about from me?”

4.1.3.2 Company Published Communications Enterprises today spend an enormous amount of time, effort, and money communicating with the outside world. They communicate with their: • Customers. • Clients. • Partners. • Vendors. • Regulatory agencies. • Government bodies. • Shareholders if they are publicly traded. • Industry analysts.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

All the information your corporate communications and public relations teams produces is important to the business. These can include press releases, annual reports, marketing collateral, and regulatory filings. These documents, though intended for others, can also be valuable to you as a security practitioner to help you understand the business environment.

Many enterprises also have internal communications organizations that work to provide information to employees about distinct aspects of the company. The information they produce – on intranet sites, in training materials, and in policy manuals – can be an invaluable resource for the security practitioner.

Some examples are: • Vision, mission, and business goals. • Values (often expressed in a mission statement). • Organizational structure. • Business plans and budget projections. • Policies and procedures.

4.1.3.3 Outsiders and The Media A third way to understand the enterprise business organization is to see what other people – customers and clients, industry analysts, or the public – are saying about it. An online search will reveal many different perspectives on the enterprise and help identify some of the less easy-to-find reputational or industry-specific risks that exist.

Here are just a few of the places you can begin looking: • Mainstream news sources, like newspapers and online news sites. • Specialized industry publications focusing on your enterprise’s target markets (or adjacent markets). • The financial media. • Consumer and lifestyle publications and websites that feature both professional and nonprofessional

product and service reviews. • Competitors’ advertising, especially if it offers different product or service comparisons • Online user communities. • Social networks, like Facebook and Twitter.

Of course, the relevant sources of information, and the types of information available will vary depending on the enterprise and the industry. But one thing that will not vary is your need to seek out external points of view, which can broaden and deepen your understanding of the business you are in, and how it is being perceived in the real world.

4.1.3.4 Observing Non-Verbal Communication – The Underlying Culture We mentioned three sources of information that you can seek out and gather input from, but there is also one last, non-verbal, usually undocumented source that you should pay attention to. Every enterprise, every organization, has its own very specific culture, and the rules of that culture are not always, if ever, written down anywhere. There tends to be an assumption that “everybody knows” how things work, and for that reason, there is usually no formal documentation of the enterprise culture.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Here are a few questions you could ask yourself while you are observing everyday interactions in the business: • “Is this a suit-and-tie enterprise, or more of a jeans and tee-shirts outfit?”

o Dress codes can offer a clue to corporate culture. Be aware that a highly regimented, disciplined enterprise like a financial institution will likely be more receptive to a rigorous set of policies and procedures to mitigate security risk. A more casual, freeform environment – possibly like a technology startup – may take more persuasion when it comes to accepting security edicts.

• “Is the enterprise historically resistant to change, or does it willingly embrace innovative ideas and ways of thinking?”

o Because security changes are like any other type of change – new, uncomfortable, and sometimes threatening – you need to understand how open to change your strategic partners really are. You may observe that they are more open to new ideas in their own technology than they are with new policies and procedures handed down from above.

• “How much risk is the company willing to take regarding certain vulnerabilities?” o Understanding how risk-averse or risk-tolerant the enterprise and its decision-makers are will

be central to the effective application of ESRM principles. • “Will some business units and other internal organizations be more responsive to the idea of working

with the security organization than others? If so, why?” o This is an especially vital concern, because you need a clear-eyed view of where you can

begin your ESRM efforts and where you can assist the business by most effectively prioritizing security investments.

Corporate culture is not necessarily uniform or consistent. The unspoken, undocumented attributes that we are talking about can vary widely across the enterprise and even within internal organizations. The larger and more complex the enterprise is, the more likely this is to be the case. Part of your role as a security practitioner will be recognizing – and accommodating – the differences in these cultural environments.

Corporate culture matters because you cannot expect to force a security culture onto the business. A security organization operating on ESRM principles needs the skills to adapt the security culture to the business culture. Cultural understanding is essential to reaching that point.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Case Study: Adapting to the Culture Since around the year 2000, for a retail outlet to operate without an online presence has become an unworkable business model. Mac B. was an accomplished security professional who spent years in the retail industry running a world-class loss prevention program for a significant department store chain in Canada. During the initial migration from brick-and-mortar storefronts to maintaining that critical web presence, he found himself in a completely new security environment. He was hired to implement a security program at SymDev, a new and fast-growing startup company that was moving into the market of selling vitamins and supplements online. The corporate culture came as a real shock to him. He was used to making rules and having people obey them without question in his old environment, but that wasn’t the way things worked at SymDev.

Mac started out doing things the way he always had: making sure doors were locked, that access was restricted, and that employees were where they were supposed to be and nowhere else. He ensured that the warehouse was secure and that products were tracked meticulously. But SymDev’s employees – most of whom were decades younger than Mac – simply were not cooperating. They were hired to work in an environment based on collaboration, openness, sharing, and teamwork, and they did not want to change. In fact, the founder of the company even encouraged employees to take samples of the product from the warehouse to share with friends. Mac very quickly realized that he was the one who had to change and adapt.

How did he do that? By trying to understand what was going on around him. Now clearly, some of the behaviors he observed in SymDev’s culture presented serious security risks. The company knew that – and the leadership especially knew they had both physical and intellectual property that had to be protected if the company were to stay ahead of its competitors. After all, that was why they hired a security professional. But before Mac could work to secure the company’s critical business assets, he had to understand what they were and how they were created. The “looseness” that was so alien to him was essential to the company’s creative processes. As he gained that understanding, Mac came to realize that some doors – literally and metaphorically – simply had to be left open. But he was also able to show SymDev’s business leaders that some security risks were unacceptable – that some doors had to be closed, for example, to prevent access by outsiders. And even though employees were encouraged to give out product samples, those needed to be tracked properly to prevent other types of loss. He showed that the security measures he was recommending were both appropriate and acceptable.

4.2 Understand the Business Environment When we discuss the environment that you need to understand, it encompasses a number of significant factors, which can include: • The building or buildings that the business operates in. • The physical environment (urban/rural, foreign/domestic, subtropical/arctic, etc.). • The geographic environment (city/state/country). • The accessibility needs of employees, customers, and others.

Enterprise environments vary widely, and as a result, their required levels of security vary widely. For example, compare the security environment on a university campus with that of a defense contractor’s manufacturing plant. A university is explicitly intended to be open, to encourage social interaction and the

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

free exchange of ideas and has the dual responsibility of ensuring the safety of both students and visitors, while protecting information assets. On the other hand, a defense plant is almost exactly the opposite: a closed environment where workers, materials, and intellectual property are closely monitored to protect against espionage (including industrial espionage), sabotage, industrial accidents, and other disruptions. Security professionals designing policies and practices for such widely varying environments cannot do that effectively unless they understand those environments.

4.2.1 Examining the Environment the Business Operates In As with the questions to ask about the business organization and mission, you will need to ask key questions about the environment in which the enterprise operates. Here are just a few basic questions you could ask about the environmental aspects of the enterprise to understand more about how to protect it from harm: • “What kind of area is the building or campus located in?”

o Many universities – however open and welcoming they may try to be – are in areas with high crime rates that need to be considered.

• “Is there a significant amount of traffic – on foot or in vehicles – in and out of the environment?” o In some environments, people will be permitted to move freely on and offsite, while in

others, IDs will have to be checked and possibly bags searched. • “How many authorized people need to be on the site each day?”

o Some enterprise environments, like shopping malls and government offices, are de facto public spaces, and will be visited by thousands of people every day – people who do not need explicit authorization to be there. Security measures for these environments, though obviously still very important, will necessarily be much more relaxed than in truly private environments.

• “How much public access is required for the business to operate?” o A defense plant can afford to keep visitors waiting while their identities are checked and to

escort visitors while onsite, but a retail store cannot. • “How sensitive and critical are the business processes and assets that are onsite?”

o The more sensitive the operation, the more likely it is that risks will need to be mitigated rather than accepted.

• “What are the expectations of the employees and management?” o Many employers go to great lengths to accommodate the lifestyle choices of their employees,

as a way of recruiting and retaining the best and the brightest. (This is especially true of high- tech firms and their young knowledge workers, who can often pick-and-choose in a highly competitive market for talent.) That means it is essential to use non-intrusive security measures.

• “Will there be significant numbers of special needs persons coming in and out?” o Accessibility sometimes requires special entrances and special accommodations, such as

checkpoints with ramps and wide enough openings to accommodate wheelchairs, or personnel available to guide people with visual or auditory impairments.

This environmental understanding will be constantly evolving, because environmental aspects and needs can change very significantly, especially after a dramatic event. For example, Virginia Polytechnic

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Institute and State University (Virginia Tech), like most universities, had an open environment. Following the mass shooting on April 16, 2007, that cost 32 people their lives, the administration and the campus security team certainly reassessed their environment and approach to security. Elementary schools now routinely issue panic buttons to teachers and practice lockdown drills with students, especially following the murders of 26 students, teachers, and administrators at Sandy Hook Elementary School in Newtown, CT, on December 14, 2012. As you can see from these examples, even places like schools, which have historically been dedicated to openness and freedom of expression, must now balance those values against the need to protect the environment, the people, and assets within.

Decisions balancing openness, access, and security aren’t always easy, and neither is understanding the environment in which they will be made. Here’s an example of two environments with very similar demographics – both completely centered around children – but with almost diametrically opposed security and risk requirements.

Case Study: Environmental Differences Drive Security Concerns Here are two environments with some striking similarities: They are both designed to accommodate children and their parents, they are both high-volume, high-traffic, and high-density. They both have a profound interest – professional, operational, and ethical – in protecting children. Yet it is almost impossible to imagine two more diverse environments from a security and risk perspective.

The amusement park (see Figure 4-2.) is a vast, sprawling space that can function only with high, mostly unrestricted traffic flow through open spaces. Its visitors do not want to feel that they are constantly watched or followed, nor to have their access in any way restricted. That is not the experience people are looking for when they take their families to such a park, and a restricted experience would not be good for an amusement park’s business.

Figure 4-2. An amusement park is an open environment that must protect patrons while still ensuring a free flow of traffic.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

A children’s hospital, by contrast, is a far less open space, with far more barriers to entry, both external and internal (see Figure 4-3). Many of the areas in the hospital will be restricted to cardholders or other authorized personnel, and many will be openly monitored by uniformed security personnel and video cameras. Most visitors will not be bothered in the least by these security measures. In fact, they will likely expect to show ID before being allowed to visit a child’s room, and they may well feel comforted by the presence of visible signs that their children are being protected.

These approaches to security and risk management couldn’t be more different, but neither is right or wrong. They are simply different – and the difference is based entirely on an informed understanding of the differences in the two environments.

Questions for the Security Practitioner • “How does the environment my organization operates in impact how we conduct our business?” • “How does the physical environment I currently work in differ from the environments of places I

have worked in the past? Has this impacted how I do my job?” • “Are the people who drive my enterprise’s business young or old, formal or informal, suit-and-tie or

jeans-and-tee-shirts? How does that impact their relationship with the security organization, and vice versa?”

4.3 Understand Your Stakeholders Once you have developed an understanding about the “what” of the business – the mission, processes, goals, and environment – it is time to work on the “who” of the business. That means asking questions like: “Who owns the business, or a specific segment of it?” “Who runs the business and which parts?” “Who controls the assets that need to be protected?” “Who makes the final decisions about those assets?” These are critical questions because they will help you identify the people who are the key stakeholders in the process of protecting the business.

Figure 4-3. A children's hospital must allow access, but at the same time restrict traffic to sensitive areas of the facility and provide enhanced levels of security for patients.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

4.3.1 What is a Stakeholder? Stakeholder is a word we will use throughout this book. It is a central ESRM concept. It can mean different things in different environments, but here is one excellent business-oriented definition:

Stakeholders are individuals or groups who have an interest or some aspect of rights or ownership in the project, can contribute in the form of knowledge or support, or can impact or be impacted by, the project (Bourne, 2005).

A stakeholder is also a person who ultimately has a primary responsibility for an asset involved in a project or business. That asset can be almost anything: money, data, brand reputation, or even a relationship (for example, with a regulatory agency) which could be damaged if it is not managed appropriately. Because many individuals and roles can have that “concern or interest” noted in the definition above, a single asset can have many stakeholders.

Whoever owns a business asset will ultimately be a risk decision-maker, either individually or together with others, sometimes many others. It is imperative to identify these people because ESRM is built on the concept of placing security and risk decision-making in the hands of people who are responsible for those assets. You cannot do that if you do not know who they are.

Questions for the Security Practitioner “In my organization, who always has the “inside track” about what is going on? Are they a key

stakeholder?” “Who can help me identify the ‘hidden stakeholders’ in my organization, if they are not immediately

obvious?” “When I have a question about the best way to get something done, who do I go to? Are they a

stakeholder?” “What are the relationships between departments, their roles, responsibilities, and status within the

organization?” 4.3.1.1 Finding Your Stakeholders: A Closer Look Learning about and understanding the enterprise will give you a very good start on identifying your key ESRM stakeholders, but it is only a start. Think of all the people or groups who will be impacted by the security program or any specific project: Who will have influence over the completion of your projects? Who will have an interest in the success or failure of the program? These stakeholders may have a range of roles, including senior executives, individuals within the project, within client organizations, or system developers.

Consider who is impacted by the enterprise security program or specific project, and ask yourself: “Who stands to gain from this project, and who might be worried about losing?” “Who controls the necessary resources, and who has the ultimate authority for the risk decision? Are they

different people or roles?” “Who has influence – as opposed to authority?” “What is my relationship with the stakeholder? Am I able to influence this person? Is it a reporting

relationship?” “How much will I need to rely on influence – as opposed to direct authority – in working with the

stakeholder?”

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

It is important to identify stakeholders who have a vested interested in the success of your program. But it is every bit as important to identity any who may see security practices, specifically your recommendations, as an impediment to the success of their goals.

Stakeholders are, as defined above, the people who have primary responsibility for various business assets, or are the additional risk decision-makers associated with those assets. There may – in fact, there probably will – be times when you find that an asset does not have a clear owner. In the ESRM process, it is essential to identify an asset owner who is also a risk stakeholder, to have an appropriate person to make decisions about risk tolerance, acceptance, or mitigation options. If an asset has no identified stakeholders, you must search for the right person. At times, this may mean you must go up the organization’s hierarchy to identify the asset owner or stakeholder, or to have the ultimate business function leader designate one. It is not your role as a security practitioner to decide who is an asset owner; that decision must come from the enterprise. As with most of ESRM, your role is to work through the process to ensure that each asset that needs protection has an asset owner identified, and that your discovery process for stakeholder identification is thorough.

Think About It: Customer Personal Data – Whose Asset is It? Customer data is a critical asset for almost every business organization in existence, but here we will be more specific, considering an account-based service: your local phone company. It stores and manages – and must protect – an enormous amount of sensitive personal data about its customers, including names, addresses, calling records, metadata, billing information, credit information, and stored payment methods.

Clearly, all this customer data is a critical business asset; so it is crucial to find the appropriate stakeholder or stakeholders to make the risk decisions associated with it. But who is that?

Is it the CIO, because the data resides on the IT organization’s servers? Is it the Customer Care department because it owns the customer relationship? Is it sales, because sales mostly gathered the information in the first place? Is it the Chief Privacy Officer, because that role is to ensure that the company is

protected from privacy liability issues?

What is the answer? All the above (and probably quite a few more).

If there were a data breach, for example, all those people and organizations would be engaged because they would all have a role to play in the response, control, and aftermath of the event. If they have a role to play in a breach response, then they clearly should also have a role in the decisions about how to protect, mitigate, and/or accept the risks associated with the data asset.

4.3.2 Why Stakeholders Matter As we have discussed, stakeholders are essential decision-makers. Knowing their level of risk acceptance is crucial to your ESRM program because ESRM is both art and science. It requires you to balance an extraordinary range of security and risk priorities – to protect the enterprise against threats while still allowing it to function. To take an extreme example, the simplest way to protect a building is to not allow anyone into it, or near it. But, of course, that is almost always out of the question, because it would completely choke off the business’s ability to operate and meet its objectives.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

In ESRM, your role is to listen to your risk stakeholders, then design and implement security measures that they believe address their risks without impinging too far on their business mission. You must balance the need for acceptable security risk protections against the needs of the business and the people who make it work. That balance – and recognizing that the tipping point is stakeholder risk acceptance – is a major part of the art and science of ESRM practice.

Think About It: Stakeholders and Decision-Making One problem that many food service companies face these days, from the nationwide franchise operations to neighborhood mom-and-pop places, is that in which locations do you offer delivery services? It is an especially tricky question to answer in transitional neighborhoods, with wealthy and safe enclaves right next door to high-crime areas. If your nationally known pizza company has an outlet in an area like this, and some of your delivery people have been robbed or even assaulted, can you, as a security practitioner, decide to deliver to some addresses in the area but not others?

It seems like a simple enough decision – especially if you have had problems at some of those addresses – but it really is not simple. For one thing, refusing to offer business services to certain addresses could be defined as race-based “redlining,” which is explicitly prohibited by US federal and state law and covered under the EU right against indirect discrimination. And yet, you still have a responsibility to protect your employees’ safety to the best of your ability.

Balancing those concerns while avoiding the brand damage that could come from your company being perceived as accepting racial profiling will be a complex process involving stakeholders across many parts of the company, including the legal, compliance, safety, HR, corporate communications, and public relations organizations.

4.3.2.1 Risk Stakeholder Conflict The role of the stakeholder in ESRM is vital – making the crucial decisions on questions of risk treatment, risk appetite, and risk acceptance. But as a security practitioner, what do you do when the stakeholders cannot all agree on the appropriate treatment of risks?

For example, consider a customer data scenario in an online stock trading service. In a service-based model like online trading, where the customer data is a key asset of the firm, the company’s chief privacy officer will specifically want to ensure that customer data is securely protected and accessed appropriately, by the right people, at the right time, for the right reasons. He or she may request an extensive login or validation process with several steps (possibly involving two-factor authentication). But the customer service department has a different key focus; they have a critical interest in ensuring that the customer has a pleasant user experience which is informative, timely, satisfying, and hassle-free. This means easier access to personal information. They may request a streamlined online experience. Clearly, these two stakeholders have very different, possibly even opposing, interests.

What is your role as a security practitioner in this scenario?

It is hard not to take sides with one stakeholder or another, but it is vital that you take into account the objectives of the business as a whole. If your advice is objective, given in the context of a risk based conversation, and you identify the potential costs and impacts for both parties, then you are also free – and expected – to give your professional security opinion on the best mitigation. However, the ultimate

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

decision must come from the stakeholders. To keep consistent with ESRM practice, you must manage the security risk process using risk principles: 1. You have identified the asset at risk – the customer data. 2. You have looked at the risks to that data. 3. You have properly identified the risk owners: the chief privacy officer and the leader of the customer

service department (and probably others, as well). 4. You have identified their business needs and concerns about the asset in question.

Now, finally, you can help those stakeholders find the best, most balanced, most workable solution to all their issues.

Helping stakeholders find the balance among their differing needs is the essence of ESRM. For example, as the security professional in this scenario, you might suggest enforcing a password strength-level that would satisfy the chief privacy officer while permitting the customer to use only a single authentication step. Whatever the final decision, the best way to reach the goal is by facilitating a conversation and reaching agreement. If no agreement is reached, you may need to escalate the decision to the appropriate management level for a final decision. More senior management will have a broader view of the business with a wider focus, thus avoiding a decision determined by the more personal goals of the disagreeing stakeholders.

Key Thought: Risks That Cannot Be Accepted We have talked a lot about risk acceptance in this chapter and in earlier ones, but there is one thing that about which we must be absolutely clear.

Some risks should NEVER be accepted by any risk owners.

We like to call these “orange jumpsuit risks” because they have legal or regulatory implications that could result in someone going to jail. One of the most important and necessary parts of your role as a security professional is to be aware of the kinds of activities that are 100% illegal and to prevent your strategic partners from conducting them, or attempting to conduct them. If you are ever unsure, or if it is not clear whether an activity has serious legal implications, it is important to appropriately escalate to a knowledgeable stakeholder.

Sometimes, your role in ESRM compels you to step in and prevent something from happening. For example:

You work for a financial institution, and someone reports to you that funds from new investors are being used to pay off earlier investors and make their returns appear better than they really are. If someone – anyone, right up to the CEO – tells you that this is okay and that you shouldn’t investigate further, you simply cannot accept that answer. What is going on is known as a “Ponzi scheme,” and it is completely illegal. If people are signing off on false statements, even if they are completely unaware that the statements are false, they could go to jail.

In the course of handling a routine technical support issue, an IT department found child pornography on a company-owned computer used by an employee. Following established procedure, they have reported this to human resources (HR). An HR

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

manager calls you, understandably disturbed, and tells you that she wants to send the files to the police immediately. This sounds like the right thing to do, right? Except that – because of the content – transmitting those files electronically, no matter what the reason, would be a very serious criminal offense in almost any jurisdiction. You cannot allow HR to do that.

You might want to ask yourself whether orange is a good color for you. Picture this: If you know that illegal activity is going on and do nothing about it – or do the wrong thing, as in the case of the employee with child pornography on his computer – you could be wearing a jumpsuit yourself.

Chapter Review In Chapter 4 you learned: • To successfully manage security risks, it is important for you to understand the business: who owns

the assets, who the security risk stakeholders are, and what the stakeholder role is. • As successful security practitioner in an ESRM environment, you need to understand the

environment, the business mission, and who the strategic partners and enterprise decision-makers are. • As a security practitioner, to be considered a strategic partner, you must communicate your role in the

business environment. Your partners must understand what the security department’s role is.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Looking Forward In Chapter 5, we will: • Explore the ESRM life cycle and introduce what each segment of the cycle entails. Further chapters

will explore details of the steps individually.

Practitioner steps to consider before moving on to Chapter 5:  Reach out to operational groups and ask if they have job shadowing programs, which would

allow you to experience their operations for a day. This is especially useful to learn about business processes that you are less familiar with.

 If you do not already have a background in business finance, take an online course on the subject to gain understanding.

 Review risk and the aspects of the risk triangle, if you do not already know them.

Security Program Self-Assessment In this self-assessment, think about the answer to the questions posed to see where your program is on the identified ESRM spectrum.

Question Y/N Is This ESRM? Does your security program regularly reach out to business functions to understand their security needs?

□Yes □No

NO: If you have never reached out to an internal department to inquire how security can help them, this is a great place to start your ESRM program. PARTIAL: If you are reaching out to internal business units to get updated asset lists for protection, personnel access needs, or updated floor layouts for video coverage, you are part of the way to an ESRM implementation. YES: If you are reaching out to determine the goals of their business operation, the environment they operate in, and what they consider are the priorities for protection, you are practicing ESRM.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for Discussion

1. Under what circumstances should stakeholders be ignored in favor of your security expertise? What are the ramifications of that? How might it damage the relationship between stakeholders and your security program if you attempt to override their decisions?

2. If a stakeholder opts out of the risk management process, how can this harm your program and the enterprise by leaving them out?

3. Can you think of examples where an organization would have security needs in one location that are different in another location? How might this cause conflict in setting security risk priorities?

4. What are some effective ways to manage the conflict between a stakeholder’s risk tolerance and their needs? How do you ensure that all stakeholders understand the ultimate outcome of any security decision?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

References

Bourne, L. (2005). Project relationship management and the stakeholder circle (Doctoral dissertation). Retrieved from http://www.stakeholder-management.com/Papers/P021_L_Bourne_Thesis.pdf

PricewaterhouseCoopers (2008). A practical guide to risk assessment: How principles-based risk assessment enables organizations to take the right risks. Retrieved from https://web.actuaries.ie/sites/default/files/erm- resources/A%20practical%20guide%20to%20risk%20assessment.pdf

Learn More About It For further reading about risk assessment, see: American National Standards Institute (ANSI)/ASIS International /The Risk Management Society (RIMS). (2015, August). Risk assessment. Alexandria, VA: ASIS International.

Committee of Sponsoring Organizations of the Treadway Commission (COSO). (September 2004). COSO enterprise risk management – Integrated framework (2004). Durham, NC: American Institute of Certified Public Accountants [AICPA].

ISO/IEC, (2009). ISO/IEC 31000:2009 Risk management – Principles and guidelines. Geneva, Switzerland: ISO/IEC.

National Institute of Standards and Technology (NIST). (2012). Guide for conducting risk assessments (NIST Special Publication 800-30). Gaithersburg, MD: Author.

For further reading about stakeholders, see: Bourne, L. (2008, May). SRMM: The five stages of stakeholder relationship management maturity.

Available at http://www.stakeholdermapping.com/index.php/download_file/view/30/92/

Kenny, G. (2014, March). Five Questions to Identify Key Stakeholders. Harvard Business Review. Available at https://hbr.org/2014/03/five-questions-to-identify-key-stakeholders/

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

http://www.stakeholder-management.com/Papers/P021_L_Bourne_Thesis.pdf

The ESRM Cycle – An Overview

In Chapter 4, you explored the things that you need to do to prepare yourself and your security program to implement a risk-based management model. Now that the preliminary steps are taken care of, you are ready to move into the ESRM cycle itself. In the next four chapters, you will get a detailed look at what is involved at each step of the process. However, before that, we will introduce you to the cycle at the holistic level, and walk through an example of how the ESRM life cycle differs from the more traditional approach.

This chapter will help you to: • Understand the overall ESRM life cycle. • Compare the ESRM life cycle to other industry life cycles and models. • Get a view of the ESRM cycle in action.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

5.1 What is ESRM? – A Closer Look In the last chapter, we covered the steps of how to prepare for an ESRM implementation. Now we will take a closer look at exactly what ESRM is, how it impacts your job as a security practitioner, and how it will protect your enterprise. ESRM represents a fundamental change in the way many enterprises – and organizations and individuals within those enterprises – conduct security operations. The implementation of an ESRM program takes time and commitment; above all, it is a process – an ongoing life cycle, as shown in Figure 5-1.

Figure 5-1. The ESRM Life Cycle

This is a life cycle, not a linear, one-time process. These steps are all critical to protecting the enterprise. They are conducted on an ongoing basis, sometimes in line, sometimes simultaneously, always continuously. (That’s why they are shown as a circle in Figure 5-1.)

The steps in the ESRM life cycle will look familiar to you as an experienced security practitioner, and those shown in the diagram may appear to be fundamentally basic. For example, if you manage network security and you are configuring firewalls, you are already implementing a mitigation plan. The same is true if you manage an enterprise continuity program and have plans in place to respond to certain

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

identified risks. But this is crucial to holistic ESRM practice: doing any of these steps individually without continuing with the others – without taking into account the entire life cycle – is merely managing or performing a security task. However, simply performing tasks is not practicing security in a risk-based management paradigm. When you implement the complete, holistic program life cycle, you realize the full benefits of ESRM, and move from task-based security to risk-based management.

5.1.1 Similarities to Industry Life Cycles The ESRM life cycle is like other risk management cycles with which you may already be familiar. In Table 5-1, we present a few similarities between the ESRM life cycle and other life cycle models.

Table 5-1. Risk Standards with Life Cycle Models Like ESRM

Industry Standards with Life Cycles Like ESRM Steps Comparison

ISO/IEC 31000:2009 Risk Management – Principles and Guidelines.

Figure 5-2. Risk Assessment and Treatment Steps of ISO 31000: 2009 (ISO/IEC 2009, 5.4 to 5.6)

ESRM Step ISO/IEC 31000 Step Identify and Prioritize Assets

Risk Identification Risk Analysis

Identify and Prioritize Risks

Risk Identification Risk Analysis

Mitigate Prioritized Risks

Risk Evaluation Risk Treatment

Improve and Advance

Monitor and Review

NIST Framework for Improving Critical Infrastructure Cybersecurity.

Figure 5-3. NIST Cybersecurity Framework Functions (National Institute of Standards and Technology, 2014, p. 19)

ESRM Step NIST Cyber Security Framework Step

Identify and Prioritize Assets

Identify

Identify and Prioritize Risks

Identify

Mitigate Prioritized Risks

Detect Protect

Improve and Advance

Respond Recover

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

NIST Guide for Conducting Risk Assessments

Figure 5-4. NIST Risk Management Process (National Institute of Standards and Technology, 2012, p. 4)

ESRM Step NIST Risk Management Step

Identify and Prioritize Assets

Frame Assess

Identify and Prioritize Risks

Assess

Mitigate Prioritized Risks

Respond

Improve and Advance

Monitor

COBIT 5: A Business Framework for the Governance and Management of Enterprise IT.

Figure 5-5. COBIT 5 Continual Improvement Life Cycle (ISACA, p. 37)

ESRM Step COBIT 5 Step Identify and Prioritize Assets

Assess Current State Define Target State

Identify and Prioritize Risks

Assess Current State Define Target State

Mitigate Prioritized Risks

Build / Implement Improvements

Improve and Advance

Operate and Measure Monitor and Evaluate

Table 5-1 shows that the underlying concepts of ESRM and other standards are not particularly different – these other models have distinct similarities to ESRM. However, the ESRM model is a distillation of what we and other industry experts have been working with over many years in the security industry, and it is uniquely suited to the overarching management of enterprise security risk.

In Table 5-2, we list a few more widely used security models. You will see similarities between all these models in the ways they identify assets and risks, set priorities, create and implement mitigation plans, and respond to security incidents.

These other models are all very useful, and offer the security practitioner great insight. (We hope you will refer to them as you enhance and refine your understanding of security and risk principles.) But the ESRM model has different priorities, different applications, and different goals from these other models. ESRM represents a comprehensive method of engaging asset owners and other stakeholders in the

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

process of making security risk decisions. It also facilitates partnering with other business function leaders to make security work an integral component of the enterprise.

Table 5-2. Other Widely Used Risk Models

Model Web Site

European Union Agency for Network and Information Security (ENISA) Risk Management/Risk Assessment (RM/RA) Framework

https://www.enisa.europa.eu/topics/threat- risk-management/risk-management/current- risk/enterprise-process-integration/the-enisa- rm-ra-framework

Carnegie Mellon Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework

http://www.cert.org/resilience/products- services/octave/

Federation of European Risk Management Associations (FERMA) A Risk Management Standard

http://www.ferma.eu/app/uploads/2011/11/a- risk-management-standard-english- version.pdf

EU Solvency II Directive (2009/138/EC) http://eur-lex.europa.eu/legal- content/EN/TXT/HTML/?uri=CELEX:32009L 0138&from=en

OCEG GRC Capability Model 3.0 (Red Book) http://www.oceg.org/resources/red-book-3/

5.1.2 Application of the ESRM Model Part of applying the ESRM model – and one of the ways it differs from other models – is that the cycle requires a security practitioner to manage security risks both proactively and reactively. ASIS International’s CSO Roundtable Group published some of the earliest papers on the topic of ESRM, stressing this same idea, that ESRM is:

• Proactive in that it continuously assesses the full scope of security-related risks to protected assets.

• Reactive in how it responds to security incidents. It mitigates the impact, and then assesses residual risk to minimize exposure to recurrence, while learning how a risk may have changed, and how it could affect the risk assessment progress and thinking, all over again. (CSO Roundtable, 2015)

This double approach enables you and partners within your organization to work together to develop security strategies and address unacceptable risks, accept minimal risks to the enterprise, and continually monitor both for any changes. ESRM principles help the enterprise to take advantage of risks, and add real value to the business by doing so.

Questions for the Security Practitioner • “Where could the ESRM process begin in my working environment?” • “Which parts of my existing security program align with the steps of the ESRM life cycle?” • “How can I communicate the tasks that I perform in my security role through the lens of the

ESRM model?”

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

https://www.enisa.europa.eu/topics/threat-risk-management/risk-management/current-risk/business-process-integration/the-enisa-rm-ra-framework

http://www.ferma.eu/app/uploads/2011/11/a-risk-management-standard-english-version.pdf

http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32009L0138&from=en

5.2 The ESRM Life Cycle Model in Action To see how the ESRM model functions in a working environment, we will look at two examples of using the life cycle approach vs. not using the cycle, in two different disciplines:

1. Physical security with the task of assigning a security guard to a new facility. 2. Cyber security with the task of securing information in a point of sale system.

5.2.1 A Task Management Approach In a task management approach, the security department may be told of a new retail facility that is coming online that requires security services.

Physical Security Responds The facility is a high value retail location and has requested security guards to protect the facility. An assessment is done to determine hours of operation, needed coverage, level of officer skill needed, and more. The guards are assigned and begin covering the location when it opens, according to the post orders given to them. Cyber Security Responds The facility will process sales on site, as well as allow customers to come in to make payments or inquiries on billing accounts. The IT team assesses the requirements, then designs and installs an encrypted network and role-based access system, which meets the stringent requirements of the payment card industry and the internal company requirements for protecting customer personal information.

In the task-managed approach to security, these are both fine outcomes. Protections have been put in place and the facility’s project manager is happy to check off the project task of security implementation.

5.2.2 An ESRM Approach In the ESRM life cycle, it is imperative to think of implementing a risk mitigation such as assigning a guard to a facility or implementing strong customer information protections as a series of steps, which will ensure the tasks performed by the security team are always optimal and necessary. While the application and assessment of facts will change, and the mitigation actions for the risks will be different, the thought process and steps will always remain the same. In the ESRM life cycle model, you would: • STEP 1: Identify and Prioritize Assets.

• Determine what the asset priority is by asking questions, such as: • What functions are in the facility? • What is stored there? • What is sold there? • What information is processed there? • What data is stored there? • Who are the stakeholders? • Who has a stake in making sure it is secure? • What’s the importance of this asset?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

• STEP 2: Identify and Prioritize Security Risks. • After determining the stakeholders and the impact of the asset to business operations, an

assessment of the risks is next, with questions like: • What could cause harm to this facility? • Is it a target for certain types of crime? • Is it in a location with physical risks? • Are there regulatory requirements that must be met? • How would a data theft or breach impact the enterprise?

• STEP 3: Mitigate Prioritized Risks. • Working with the stakeholders previously identified in Step 1, determine the stakeholder’s

tolerance for risk. • Determine if that tolerance justifies less physical security. • Tailor the levels of security guard activity and assign the number of guards needed to

mitigate any of the risks identified in Step 2. • The Payment Card Industry rules require certain technology mitigations, so:

• Determine the requirements to protection of the network and data processing. • Propose a cyber security implementation, which meets the required levels of • protection as defined by the enterprise stakeholders.

It is likely that as an experienced security practitioner – even in a task-managed security environment – you have done something like the three steps above, whether thinking of it as risk management or not. Security assessments are generally performed to determine security needs. Security is applied according to the assessment results. So far, in ESRM, we are merely formalizing these steps that you are probably already doing, and ensuring that they happen in every security endeavor. We are also ensuring that they are done in partnership with functional leaders as mitigations to risks that fall outside their acceptable tolerance. (Although, you will notice that the security risks were all discussed together, not in a siloed, separate approach that sometimes comes in the more traditional model.

The next step in the life cycle, is where ESRM truly comes into play as a risk-management model. Without Step 4, you would not really be managing the risks, merely putting in needed protections and moving on to the next task on the list. If you never revisit the risk that caused you to make the initial decision, then eventually your mitigation plan may no longer be appropriate for the risk. Thus, ESRM includes the “Improve and Advance” phase. • STEP 4: Improve and Advance. • Incident Response.

• If an incident occurs, in addition to responding immediately to the incident, you also investigate to define the underlying root cause that allowed the incident to happen.

• Root Cause Analysis and Assessment. • As part of the overall improvement process, analyze each root cause to determine if it has

changed the security equation. This enables you to find new risks, or to see that perhaps some previously acceptable risks are now falling outside of tolerance.

• Ongoing security risk assessment.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

• Is the location is no longer important enough, or sensitivity enough, to justify the cost of a guard?

• Has the location become more sensitive, meaning that the guards in place do not have the skills, training, or experience appropriate to the new risk profile?

• Has the company determined that billing or payment activities will no longer happen at the location?

• Have regulations become more stringent about protecting information? • Is there emerging technology, which makes it easier to break into networks that previously

met the original design parameters, but have not been upgraded? • Has the company profile changed in some that increases or lessens it as a target to bad actors?

Every enterprise is different, with different security and risk requirements, and that means there will always be variations in the design and implementation of the ESRM life cycle, and especially in the level of detail involved. But there are some things that every application of the ESRM life cycle will have in common, and one of the most important is that it will be a step-by-step process, with every step having an influence on all the steps that follow. If you keep this basic principle in mind – if you always think in terms of moving through the steps of the life cycle in order – it will become an ingrained habit that you can apply to every security and risk issue you deal with, however large or small.

The example above is just a high-level walk-through of the cycle. In the following chapters, we will dive more deeply into all the steps.

5.3 ESRM is Cyclical, But Not Always Sequential Throughout this book, we will refer to the beginning and end of the ESRM life cycle, but it is important to understand that you will not always begin with Step 1. (As you can see in Figure 5-6, your organization may already have completed Step 1 [Identifying and Prioritizing Assets], possibly without even thinking about it in those terms.) In addition, you may find that after you have completed Step 2 [Identifying and Prioritizing Risk], a new risk will materialize or be identified, perhaps because of an unforeseen event, or because someone read something concerning in the news. Or crucially, a new risk may be identified simply because of the ongoing activities in the ESRM program – for example, as the unexpected result of an investigation into an unrelated event.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Figure 5-6. The Life Cycle Doesn’t Always Start at Step 1.

The ESRM cycle can also be engaged when there is a change in management mindset, whether the change is driven by a security practitioner, a business leader in the enterprise, external pressure from customers, clients, or the community, or even government or regulatory pressures.

Think About It: Changing Risks, Changing Minds As an example of how a change in mindset can cause a re-engagement of the ESRM cycle, consider how differently security threats were treated and tolerance levels were established in the United States on September 10, 2001, compared and contrasted to September 12, 2001.

Parts of one very significant external action, the attacks on the World Trade Centers in New York City and on the Pentagon in Washington DC caused risk tolerance levels to shift dramatically among multiple groups overnight. Enterprise managers, shareholders, boards of directors, customers, clients, and government officials suddenly placed an enormous focus on physical security and organizational continuity. Laws were passed, policies changed, and responsibilities were increased. That kind of systemic change has an immediate impact on security risk decisions. While a task-based security program might respond to a significant event with recommendations about budget, personnel, and equipment, the ESRM model would instead call for a re-examination of assets, risk, tolerance levels, and priorities. This would lead to recommendations for risk owners to make decisions, and become educated about a changed state of security risk.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

While 9/11 is a significant example of this level of immediate and high impact mindset change in relatively recent history, there are other examples of events that have had significant impacts on organizational risk tolerance and required a new risk examination in line with the steps of the ESRM model. In 2013, Edward Snowden’s revelations about the NSA certainly had a global societal impact on the conversation around privacy and government access to personal data. The concepts of privacy and information security were redefined in 2013 with the Snowden release. Companies around the world had to reassess how they secured and potentially shared (or would share in the future) any personal information with their governments.

Chapter Review In Chapter 5 you learned: • The ESRM life cycle is always ongoing. • ESRM is a working philosophy to manage and respond to security risks, and it will guide the

practitioners through every aspect of their daily functions. • ESRM helps the security practitioner remain closely tied to the enterprise and consistently focused on

the most relevant roles and responsibilities. • The ESRM life cycle can start and end at any point. The process is flexible, should always be

adaptable, and it should never come to an end. Looking Forward • In Chapters 6 through 9, we will delve more deeply into the steps of the ESRM cycle and look at

some of the techniques and standards that apply to fully implementing the ESRM cycle.

Practitioner steps to consider before moving on to Chapter 6:  Ensure a clear understanding of why managing risk, in partnership with enterprise

stakeholders, is so important to overall organizational success and begin to communicate that to your stakeholders.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Security Program Self-Assessment In this self-assessment, you should think about the answer to the questions posed; and then see where your program is on the identified ESRM spectrum.

Question Y/N Is This ESRM? Do you review security programs that are in place and then adjust them to meet changed needs?

□Yes □No

NO: If you do not have a regular annual review or any process in place to adjust security implementations in response to enterprise needs, or if changes only occur when budget changes dictate them, this is a suitable place to start your ESRM program. PARTIAL: If you have regularly scheduled risk reviews or adjust programs when the enterprise makes requests, you are part of the way to an ESRM implementation. YES: If you have regularly scheduled risk reassessments, you proactively reach out to your enterprise partners to ensure your program is meeting organizational needs, and you are regularly adjusting your security program based on risks identified or changes in asset priority as part of security incident reviews, you are practicing ESRM.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for Discussion 1. In the ESRM life cycle, in which areas can you identify potential starting points, other than the

initial identification of assets? 2. What documented standards do you currently use in your enterprise or security environment? Can

you relate the ESRM life cycle to any or all of them? 3. How is continual improvement the key to risk-based security management? 4. Does the ESRM life cycle always work in a linear fashion? Why or why not?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

References CSO Roundtable of ASIS International. (2015). Enterprise security risk management: A holistic

approach to security. Retrieved from https://cso.asisonline.org/esrm/Documents/Enterprise%20Security%20Risk%20Management-- Overview%20and%20Case%20Studies%20pt%202.pdf

ISACA. (2012). COBIT 5: A business framework for the governance and management of enterprise IT. Rolling Meadows, IL: Author.

ISO/IEC. (2009). ISO 31000:2009, Risk management – Principles and guidelines. Geneva, Switzerland: Author.

National Institute of Standards and Technology (NIST). (2014). Framework for improving critical infrastructure cybersecurity. Gaithersburg, MD: Author.

National Institute of Standards and Technology (NIST). (2012). Guide for conducting risk assessments. NIST Special Publication 800-30, Version 1. Gaithersburg, MD: Author.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

The ESRM Cycle – Step 1: Identify and Prioritize Assets

In the last chapter, you saw how the steps of the life cycle work together as a whole, and that each step of the cycle has its own set of considerations to look at. In this chapter, you will begin to work through the life cycle at Step 1 to identify and prioritize all the assets in your enterprise that eventually will need to be protected through the rest of the ESRM risk assessment and management process.

This chapter will help you to: • Explore and identify what is an asset for risk management purposes. • Find all the stakeholders associated with any specific asset. • Assign business value to assets, in partnership with the asset owners. • Recognize the role of security, and the role of the asset owner in determining asset priorities.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

6.1 Step 1 – Identify and Prioritize Assets The first step in the ESRM cycle is to identify the enterprise assets that will need to be protected by your security program, and understand why they are important to your strategic partners for meeting their business goals and objectives (see Figure 6-1.)

In Chapter 4, we discussed the difference between the primary asset owner and the other risk stakeholders who might have some interest or interaction with the assets. We also discussed who might also need to be involved in the risk process. Excellent books, such as The Manager’s Guide to Risk Assessment: Getting it Right by Douglas Henderson (Rothstein Publishing, 2017) take you through risk assessment processes in detail. Step 1 of the ESRM cycle deals with both asset owners and other stakeholders. In this step, you: 1. Find all the assets. 2. Identify the primary asset owner. 3. Find all the stakeholders who should be involved in risk decisions for those assets. 4. Finally, work with all of them to understand the actual business impact, and importance of each asset. Most enterprises want to protect the most critical assets before those with less impact on the enterprise. Prioritizing enterprise assets, in partnership with the asset owners and stakeholders, is the beginning of that decision-making process.

Figure 6-1. The first step of the ESRM Life Cycle is to identify and prioritize assets.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

6.2 What is an Asset? When looking for assets, some will be unmistakably clear and easy to find and understand. These could be things like computer hardware, retail inventory, manufacturing facilities: these are called tangible assets. Unfortunately, other assets might be tougher to define as assets. These are intangible assets – for example, the way a company carries out business processes, critical data, the good reputation of the firm, or proprietary training materials. These are also assets that need to be protected, even if they do not take up physical space. A thorough exploration of all assets will provide you with new perspectives on the enterprise, mission, and resources needed to do business.

6.2.1 How Do You Identify Business Assets? Critical to the ESRM process is a systematic effort to discover all the assets, and a continual review of the assets within the context of how the business uses them. The enterprise’s business assets will change over time, and this asset discovery will be an ongoing process. This is where the relationships you have built inside your company can help. Your strategic partners can help you find the less obvious assets, but you will need to be diligent in your asset investigation.

Case Study: Counting All the Assets George P. has just been hired as the director of the new security organization at Vancouver Pool Supply, a Canadian manufacturer of pumps, hydratic systems, and other technologies used in swimming pools, saunas, and fitness facilities. He has worked to identify the enterprise assets – spread across the company’s corporate headquarters in Vancouver, three warehouses across Canada, seven sales offices in Canada and the US, and a manufacturing plant in China. He believes it is a comprehensive list. When he takes it to his boss, Leslie U., the company’s general counsel, she points out that the list does not include one critical technology asset that she is aware of – a significant amount of customer data in a data warehouse/sales platform, which not only stores critical information but has an online ordering component as well. All that data is valuable in terms of marketing and customer care and even in terms of regulatory compliance. Leslie wanted to know why George had not listed that IT system and the included data as an asset to be protected.

George went back to investigate further and eventually came up with an answer. When doing the asset identification process, George had spoken to both marketing and customer care, and neither organization had identified the ordering system as an asset. In his discussions with IT, they had identified company computers, servers, local network hardware in facility data rooms, as well as the applications that all that hardware ran, including the internal billing system. So why had no one mentioned this business-critical system?

It turns out that the data warehouse and online order platform are part of a third-party software-as-a-service (SaaS) model, accessed via the web and hosted by the SaaS provider – a vendor. Nobody at Vancouver Pools considered themselves the owners of the systems; so, when asked about their assets, nobody ever mentioned it. But clearly, this asset was real and needed to be considered and assessed for risk.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

You cannot have a comprehensive understanding of the risks you will need to address until you have the same complete understanding of the assets you need to protect. This understanding does not come without digging past the more obvious assets and truly understanding all the parts and pieces of the enterprise.

6.2.1.1 Finding Tangible Assets When you are examining your enterprise to find all the tangible assets, you can look for and ask your strategic partners about these categories:

• Accounts receivable. • Buildings and facilities. • Cash and cash equivalents. • Computer equipment. • Equipment. • Fixtures. • Furniture • Inventory. • Investments. • Land. • Machines. • Manufacturing materials. • Plant. • Stored resources. • Vehicles.

6.2.1.2 Finding Intangible Assets Finding intangible assets is harder, but when you are looking for intangible assets, your investigation can include these types: • Brand related:

o Brand reputation. o Internet domain names. o Logos. o Mastheads. o Name recognition. o Trademarks.

• Contract related: o Licensing agreements. o Service contracts. o Leases. o Franchise agreements. o Use rights.

• Customer related: o Customer lists. o Goodwill. o Relationships.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

o Customer reputation • Intellectual-property related:

o Trade secrets (such as secret formulas and recipes).

o Processes and procedures. o Institutional knowledge.

• Technology related:

o Patents on technology. o Computer software/code. o Data. o Critical access credentials.

6.2.2 Who Really "Owns" an Asset? Once you have identified stakeholders and assets, you can begin to determine who the owner of any given asset really is. Figuring out who that person is isn’t always easy. Many assets will have a primary asset owner (often the person with budgetary control over the assets), but these assets may also have many stakeholders who could be impacted by any incident or action involving that asset, and they all need to be consulted on questions of security risk. We will often refer to the impacted decision-makers interchangeably, using the terms “stakeholders” or “owners.”

In the following sections are a couple of seemingly simple examples that show how complicated it can be to identify an asset owner and stakeholder.

6.2.2.1 A Building This might at first seem like an easy answer. It is a physical asset, and the facilities organization mostly takes care of maintenance, upkeep, that sort of thing, so facilities should be the asset owner, right?

But what if the building is leased? Is the landlord the asset owner? Or is it the department that holds the contract with the landlord?

Now, think about what goes on in the building: the people, processes, and business functions that are housed there. If it is a manufacturing plant or a warehouse, then procurement management may be the primary owner of the asset, because of the building’s place in the company’s supply chain. But if it is a call center, the customer service organization may have the biggest stake. If the building houses a data center, then IT and information security must be considered as potential asset owners. If the building contains multiple internal organizations (as shown in Figure 6-3) there are certain to be multiple assets owners and stakeholders. Of course, Human Resources would be stakeholders in any building that houses employees, and ultimately (mostly as an escalation point in any risk decision conflict), senior executives would be the final layer of responsibility for the entire company. The question can be quite complex of who owns a facility as the most responsible stakeholder. and what other stakeholder might also need to have input on any security risk discussions.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

6.2.2.2 A Server This server example, at first glance, seems even simpler. As you can see in Figure 6-4, a server is simply a computing device; so, the assumption is often that its owner should be someone in the IT organization that is responsible for keeping it up and running.

Figure 6-3. A facility can have multiple asset owners, depending on what functions are housed in it. Retrieved from https://commons.wikimedia.org/wiki/File%3AGeneral_Research_Building%2CKyutech.JPG

Figure 6-4. A server or other data center device will have multiple asset owners, depending on the function of the device and the data housed on it. By Michael Jastremski. Retrieved from https://commons.wikimedia.org/wiki/File%3AServer_Linux.jpg

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

But all that changes when you start to think about the applications that may be running on the server, the processes that depend on it, and crucially, the information that passes through it.

Does the server hold payroll software? Then the accounting department obviously has a stake, and so does HR. Is it running computer-aided design (CAD) software? Then the design, engineering, and manufacturing organizations may all be owners or stakeholders. And if the server stores sensitive personal data, it is almost certain that the regulatory compliance organization is one of the stakeholders, along with the legal organization, and possibly the government relations organization.

6.2.2.3 The Web of Assets and Asset Owners/Stakeholders Sometimes the obvious asset owner and the risk stakeholder are the same person or the same organization. But that is not always the case. Enterprises are complicated webs of interdependencies on many levels. Oftentimes, assets provide benefits to multiple processes, workflows, and organizations. Assets typically work together in a system where, if one asset is compromised, the impact can cascade through multiple areas waiting on upstream and downstream inputs and outflows. Figure 6-5 is a simple diagram of interactions between a few departments and activities, showing that flow.

When you are determining who needs to have input about any one asset to the enterprise, you will need to consider many pieces. Otherwise, an asset that seems unimportant to one person in the web (and therefore able to handle more exposure to risk) might actually be important in another context and be impacted by an unmitigated security risk. In such a situation, during the time needed for the impact to the asset (which was deemed not critical by one person in the chain) to be corrected, every other process it affects in the web will come to a halt.

Figure 6-5. Assets, teams, and processes work together in a web of inflows and outflows.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

https://commons.wikimedia.org/wiki/File%3AGeneral_Research_Building%2CKyutech.JPG

https://commons.wikimedia.org/wiki/File%3AServer_Linux.jpg

Questions for the Security Practitioner • “What are some examples of assets in my organization whose owners might be different what is

initially apparent?” • “Do I have a method for determining who in my organization is most responsible for

assets/facilities/processes?”

6.3 How Do You Assign Value to Assets? Your enterprise cannot determine its tolerance for risk to assets that they do not know the value of. The value of some assets – especially tangible ones – is easier to determine than others, using common quantitative methods. We will not go into detail about this process here – partly because these methods are discussed in any basic accounting book, and partly because this is a process that must be worked out with the business asset/risk owners, and probably with the finance organization as well. The following is an overview of some widely used valuation methods that your business probably uses.

6.3.1 Simple Tangible Asset Valuation (Two Methods) • The Cost Method. This method – probably the easiest to use – values an asset based on its purchase

price. It is most useful when applied to stand-alone assets that have no complex dependencies on other assets (for example, in a supply chain). Example: This shipping container full of manufactured plastic widgets cost the company $3 million. Therefore, because of the cost, the asset is valued at $3 million.

• The Market Value Method. This approach values an asset based on its current market price, determined by one of two standards: 1. Replacement Value – how much it would cost to replace the asset.

Example: This software cost us $400,000. But the company went out of business; so, if this program needs to be replaced, we will need to pay a new company $650,000. Therefore, the asset is valued at $650,000.

2. Net Realizable Value – how much the asset could be sold for. Example: This painting on the wall in the office cost us $500. But the artist became very popular and then died. We could now sell the painting for $375,500. Therefore, the asset is valued at $375,500.

6.3.2 Complex Tangible Asset Valuation Sometimes assets carry special dependencies – circumstances that make valuing them more complicated and more difficult. Look at Figure 6-6, as an example. A gear in a machine used on a manufacturing assembly line may have cost just $300 when purchased from a custom manufacturer. But if it fails, or is damaged from some risk impact, ordering a new one could take days, weeks, or even months, resulting in significant downtime and disruption, not to mention the work involved in replacing it and any other parts that might need to be replaced. And the manufacturer’s customers may have service-level agreements (SLAs) written into their contracts that set financial penalties for failure to deliver products on time. Any one of these factors would make the gear’s business value far higher than the $300 replacement cost. That is why you need to take all associated costs and expenses into account. And getting that right depends heavily, if not entirely, on input from the business owner.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

6.3.3 Intangible Asset Valuation (Three Methods) As discussed above, valuing tangible assets can be a complex process. However, valuation of intangibles is far more difficult.

While tangible asset methods of valuation all rely in some way on the principle of economic substitution (the ability to swap another asset in the place of the one you are valuing at some price point or cost), that is not possible with many intangible assets. In fact, the process is nearly impossible with intangible assets, such as goodwill or reputation, and is still difficult with others, like the value of an existing customer base.

To ensure the proper valuation of intangible assets – information, brand reputation, regulatory compliance, and other types – you will need to involve a broad range of stakeholders, including (but not be limited to): • Business leaders. • The legal organization. • The customer service organization. • The corporate communications, public relations, and public affairs organizations. • The corporate compliance organization. Once these people are engaged in the conversation around valuing the intangible assets, questions that should be answered include:

Figure 6-6. The value of a seemingly simple piece of hardware can escalate, depending on the impact of the item on the systems around it.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

• What is the life of this asset? (Is it to the end of a contract, or to the perceived horizon that a specific reputation status will remain?)

• What portion of your business mission or function is enabled directly or indirectly by this asset? (Can a monetary value be put on it?)

• Is this asset listed anywhere with a value on the company financial reports? • In the case of intangible assets like goodwill or reputation, how much would you pay if this item were

something you could specifically purchase for the firm? Intangible assets might be more difficult to value, but there are some generally accepted practices that can help, even here. 1. The Market method. This valuation method involves doing some research and attempting to find

transactions in the market where a similar asset was involved in a transaction. A similar value can be assigned to the asset. Example: The company name is registered as a domain name. A recent sale of a registered URL that is a common misspelling of a competitor’s name was completed for $235,000. Therefore, the asset can be roughly valued at $235,000 to $250,000.

2. The Income method. If the intangible asset generates income or significantly contributes to activities that generate income, then the estimated future income generated can be used as the value. Example: By owning the licensing rights to a song, the royalty payments from its use are expected to be $25,000 over the next 5 years. Therefore, the asset can be roughly valued at $25,000.

3. The Cost method. For assets such as intellectual property created by the firm, the cost method allows you to compile the associated costs such as development man hours, research costs, etc. Example: This internally developed engineering design required 560 man-hours to develop at a cost of $240 per hour. Therefore, the asset can be roughly valued at $135,000.

Just as in the methods we described for tangible asset valuation, these methods are common accounting practices that your organization’s accounting group ought to be able to assist with.

Think About It: Valuing Data in the Real World Here is a real-world example of assigning value to intangible assets. The retail chain Target suffered a massive, highly publicized data breach during 2013 holiday season, with the credit and debit cards of more than 40 million customers exposed to potential fraud. Target’s CEO eventually valued the cost of the data breach at $148 million (Prince, 2015). It is extremely difficult to say how he arrived at that figure. Did it reflect just the value of the information that was compromised, at the time it was compromised? Did it factor in the presumed impact of the breach on Target’s revenue? The fines the company would be exposed to? The cost of legal actions? The loss of customer confidence? It is impossible for us, as outsiders, to answer those questions with any certainty. But we as security professionals can still learn from Target’s experience by understanding that even things that are hard to place a value on will certainly reflect a value if they are harmed as part of some security risk impact.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for the Security Practitioner • “If I were asked to value a specific business asset, how would I be able to identify the best

valuation method? What are some possible methods?” • “Who would I ask for help to develop a real-world valuation, and what questions would I ask?” • “Who are the strategic partners in the accounting and finance group who might have already

developed asset valuation models that are accepted in my organization?” • “Is there a standard asset list already created by some other function in the organization that can

assist with the valuation process? Who would have such a list?”

6.3.4 Business Impact Analysis (BIA) Another methodology for determining the value of assets – one that is used in many different risk-related programs – is the business impact analysis (BIA). In an ESRM program, a BIA focuses mainly on assets, to determine how critical it is to protect an asset, based on the impact that the loss or compromise of that asset would have on the business’s identified requirements, objectives, and needs. Like the other asset valuation methods that we discussed, BIA is the subject of entire books and websites. You may have teams in your company, or even already reporting to you in the security group, who perform disaster recovery, business continuity, financial, or other types of risk management, and who can help you with the BIA process. The International Organization for Standardization (ISO) has a standard, ISO 22301, that goes into the BIA process in depth. Also, books such as Business Continuity Management: Global Best Practices, 4th edition, by Andrew Hiles (Rothstein Publishing, 2014) can provide valuable insight. In addition, we list other resources in the Learn More About It section at the end of this chapter.

Think About It: What Is “It” Really Worth? Did you know that in October 2014, a lost Apple iPhone prototype sold online for $84,000? (Walker, 2014) Seems like a lot for a smartphone that, when completed and released, would retail for $500 or so. But somebody obviously thought it was worth a lot more. Why might that have been? Was the buyer just a collector with more money than sense? Or was it another smartphone manufacturer that wanted an advance look at where the market was headed, and maybe even the opportunity to reverse-engineer some of the technology in the prototype? We do not know the answer to those questions, but here’s one thing we do know: Someone thought that iPhone was worth more than $500. A lot more.

Additionally, many industry observers felt that Apple completely overreacted to the loss (which it considered a theft of valuable intellectual property), obtaining a search warrant for the home of at least one person suspected of being responsible. The public and media backlash to their reaction was harsh and immediate – and Apple’s director of security resigned in the face of intense criticism of the company’s perceived overreaching. When you consider the damage to Apple’s corporate reputation and brand image, clearly there were more assets involved in this incident than an iPhone prototype; and they were more valuable than Apple’s security organization and stakeholders recognized.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

6.4 How Do You Prioritize Assets for Protection? The outcome of the asset valuation process is a figure, which can be used to determine the priority or level of protection needed for each asset. It seems obvious that assets with little or no real-world impact on the business should have less rigorous protections than high-impact assets. Although it might be tempting to simply list all the assets in ascending value order, and then protect them accordingly, the priority of assets is, of course, ultimately up to the business owners. That is one of the most fundamental principles of ESRM, and one we cannot lose sight of. However, the list of assets and associated values is a key piece of information that you, as a security practitioner, can share with your strategic partners to help them make the right decisions in the risk mitigation process.

Your role is to help the asset owner understand the information you present, and its implications. That means making sure the business units: • Are aware of the impact of a possible security failure. • Are aware of all the different opinions on the impact. • Are aware of your professional security-based opinion about what protecting that asset might include. • Consider any future impact of the asset.

6.5 How Do You Deal with Conflicts in Asset Valuation and Prioritization? As we have seen, a specific enterprise asset can have multiple owners and stakeholders. Unfortunately, owners sometimes disagree on the value of the asset. As a security practitioner, your role in the valuation process is to guide the business and stakeholders through a conversation that is informed by your analysis of asset value and associated risk. Then you must help them find agreement on the appropriate level of risk the business is prepared to accept, and the appropriate protections to put in place to address that level of risk.

Case Study: Asset Valuation Conflicts at Waters & Frank Sporting Goods Matt M. is a security manager with a small sporting goods company, Waters & Frank (W&F), which does some of its sales online. The online sales manager, Karen P., considers W&F’s public-facing website her top asset. Her annual sales performance bonus is 75% of her total compensation, and it is based almost entirely on website traffic and sales. This is obviously what makes the website absolutely her top priority. She urgently wants the asset to be protected with significant data security and business continuity controls, including fully redundant servers and continuous backup of databases. But Fred C., the IT director, thinks the existing failover backup solution is adequate and does not want to incur the significant costs of the additional protections.

Matt knows these assets need to be valued in real-world business terms. So, he consults senior business leaders, and he discovers that the website accounts for less than 10% of the company's total sales. The online sales that are so important to Karen simply aren’t a core part of the company's current strategy – at least for now. Therefore, Matt is faced with the challenge of helping the business balance the costs of protections against the potential risk impacts.

Matt sets up a meeting with Fred, Karen, and other relevant stakeholders to allow them to discuss what the protections she wants would cost vs. the amount of revenue that online sales brings in. Karen agrees to a suggestion that Fred makes to leave the protections in place that he thinks are adequate for now and to revisit revenues on a quarterly basis to determine the cost/benefit ratio of increasing security on Karen’s asset.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

As shown in the example above, it is important to prioritize resources in line with the overall business mission and with goals that have already been thoroughly investigated and are clearly understood by the asset owners and all other stakeholders.

Chapter Review In Chapter 6, you learned: • Asset valuation and prioritization is the first step of the ESRM life cycle. • Many common accounting and risk assessment methodologies can be employed when valuing your

enterprise assets. • The security practitioner plays a vital role in collecting asset value information, ensuring all

stakeholders are engaged in the valuation and prioritization process, and mediating conflicts in asset prioritization.

Looking Forward In Chapter 7, you will: • Explore Step 2 of the ESRM process – Risk identification and Prioritization.

Practitioner steps to consider before moving on to Chapter 7:  Reach out to your strategic partners in finance or risk, to determine whether some or all assets are

covered in an existing asset registry for the company.  Research common finance/accounting methods, to become familiar with terms you’ll need to

discuss with your strategic partners in the finance world.

Security Program Self-Assessment In this self-assessment, you should think about the answer to the questions posed, and then see where your program is on the identified ESRM spectrum.

Question Y/N Is This ESRM? Do you have a list of assets and the associated impacts, values, and priorities for your enterprise?

□Yes □No

NO: If you have never compiled a comprehensive asset valuation list, this is a suitable place to start your ESRM program. PARTIAL: If you have a general understanding of the company priorities on protecting assets, and understand who the most impacted groups are for each asset, you are part of the way to an ESRM implementation. YES: If you have a formal process for compiling and regularly re- assessing a list of the value of company assets, in partnership with the key asset stakeholders, you are practicing ESRM.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for Discussion 1. In a business environment, what factors might get in the way of gaining a true understanding of

all the enterprise assets? 2. Why might an asset have more than one asset owner? Can you think of more examples of this? 3. How might corporate “politics” interfere with the security practitioner’s ability to understand all

enterprise assets? Can you think of any ways to work through these issues? 4. In your opinion, what is the best place to start when developing asset valuations: Begin with the

simplest ones, or with the ones that you intuitively think are the most important? 5. What is the role of the security practitioner in determining asset prioritization? What is the role of

the security practitioner in mediating conflicts in asset prioritization? How do these roles work to help the asset owners in their areas of business?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

References

Prince, B. (2015, February 26). Target data breach tally hits $162 million in net costs. Security Week. Retrieved from http://www.securityweek.com/target-data-breach-tally-hits-162-million-net-costs

Learn More About It For further reading about asset valuation and other accounting methods see: Bragg, S. (2013, October 24). Fair value accounting. Available at

http://www.accountingtools.com/questions-and-answers/fair-value-accounting.html

CGMA. (2012). Three approaches to valuing intangible assets. Available at http://www.cgma.org/Resources/Tools/DownloadableDocuments/valuing-intangible-assets.pdf

Maher, M., Stickney, C. P., & Weil, R. L. (2012). Managerial accounting: An introduction to concepts, methods and uses. Mason, OH: South-Western Cengage Learning.

For further reading about business impact analysis see: ISO/IEC. (2012). ISO/IEC 22301:2012 Societal security – Business continuity management systems.

Geneva, Switzerland: Author.

ISO/IEC. (2009). ISO/IEC 31000:2009 Risk management – Principles and guidelines. Geneva, Switzerland: Author.

Hiles, A. (2014). Business continuity management: Global best practices (4th ed.). Brookfield, CT: Rothstein Publishing.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7 The ESRM Cycle – Step 2: Identify and

Prioritize Security Risks

Now that you have asset identification and prioritization taken care of, it is time to determine the risks that the prioritized assets are exposed to. Then, also, to determine the priority that those risks have in the overall risk picture for your enterprise. The combination of Steps 1 and 2 will leave you with a comprehensive view of the assets that are most important to your enterprise strategic partners and the most critical risks that those assets are exposed to. This will prepare you for the next step of planning how to treat and mitigate the risks.

This chapter will help you to: • Clearly communicate the difference between a threat and a risk to your stakeholders. • Follow a clearly defined risk assessment process based on an industry standard. • Prioritize risks in partnership with the business leaders of your organization to protect your enterprise

in line with set tolerances.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.1 Identify and Prioritize Security Risks Once you have the prioritized list of assets, you can use it to determine which of the assets are important enough and have sufficient impact on the enterprise to move into Step 2 – assessing the risks to each asset (see Figure 7-1).

The ESRM risk assessment approach recognizes that not all enterprise assets are equal. The time and resources needed to do a risk assessment are not trivial; spending them assessing risk on assets that the business has already determined are less important is not the best use of limited bandwidth. Assessing risks on enterprise assets in the order of identified priority is one way that ESRM makes the security organization more efficient and responsive to the overall needs of the business.

7.2 What is Risk? At first, this question might seem entirely self-evident. However, we want to quickly revisit the topic of what exactly constitutes a true risk to an asset. Some risks might have a significant impact, but may be very unlikely to occur, while others might have a small impact, but occur all the time. Your strategic partners will need your help in understanding just exactly what kinds of risk their assets face.

One way to make sure that your audience understands the risk messages you are conveying is by using the concept of the risk triangle.

Figure 7-1. ESRM Life Cycle Step 2 is Identifying and Prioritizing Risks.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.2.1 The Risk Triangle To understand the risk to their assets, your internal strategic partners need to understand the components that make up the risk triangle – seen below in figure 7-2. • Threat.

o Something that could potentially cause harm to the asset.

o Examples: theft, cyber-attack, fraud, fire, flood, vandalism, data breach, etc.

• Exposure. o The level to which any specific threat

might actually happen to the asset in question.

o Example: a technology asset not connected to any network has lower exposure to hacking.

• Impact. o A consequence of the threat happening. o Example: financial or operational, or

even an intangible impact such as reputational damage.

For a perceived or thought-of risk to be a true risk to the business, it must have all three sides of the triangle to stand on. The threat of flood, for example, does not impact an asset that is far from any flood zone. This is because there is no second part of the triangle – Exposure. But exposure is also not enough. An asset may be near a river, and therefore exposed to the threat of flood, but if it is submersible, or housed in a watertight unit, there is no impact to it and thus still no risk. Only when the three aspects come together does the risk materialize as an item to be considered in the assessment process.

In Figure 7-3, we show a decision tree that walks through how to determine whether something is a risk that must be mitigated. Visual decision trees like this one can help you to communicate these risk concepts to any of your partners who may not be familiar with risk assessment.

Figure 7-2. The Risk Triangle

Figure 7-3. All three sides of the risk triangle must exist to be considered “a risk.”

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.3 The Risk Assessment Process The process of identifying, associating, and prioritizing risk – most commonly known as risk assessment – is a common topic in many disciplines, not just ESRM. For example, the International Organization for Standardization (ISO) Risk Standard 31000 is applicable to many disciplines (ISO/IEC, 2009): • Financial risk. • Operational risk. • Project risk. • Resource risk.

Risk assessment and management are not limited to the security function, and as security risk managers, we can learn valuable lessons from other risk management disciplines and standards, and apply them to security risks as well. The ISO 31000 is the most comprehensive standard, with the widest application across industries and the globe, but we have listed several web sites at the end of this chapter with additional standards.

7.3.1 ISO Standard and Good Practices The ISO Risk Standard (ISO/IEC, 2009) defines a risk assessment as, “the overall process of risk identification, risk analysis, and risk evaluation.” • Risk identification is finding, recognizing, and detailing the risks that could impact the asset under

consideration, or the objectives that it is used to reach. • Risk analysis is understanding the nature, causes, and origination points of the identified risks, and

estimating the level of risk. Analysis also includes determining the potential impact of the risk to the business, whether financially, or through operational impacts, or even intangible impacts, such as reputational effect. Finally, it includes identifying any existing controls that the business might already have in place for the risk.

• Risk evaluation compares the results of the analysis with the overall defined company risk tolerance level and management acceptance criteria, then determines if a risk is tolerable or must have mitigation steps identified.

In the next few sections, we will break down how you perform these steps to devise a plan that will allow business owners to understand the risks, and either accept or mitigate the discovered security risks.

7.3.1.1 The ESRM Difference Although the ISO standard provides good guidance and best practices in risk management principles, we show in Table 7-1 that it is not precisely the same as the ESRM process.

Table 7-1. ISO 31000 Risk Assessment Steps vs. ESRM International Standards Organization Risk Assessment ESRM Risk Assessment

1. Risk Identification 2. Risk Analysis

1. Risk Identification

3. Risk Evaluation 2. Risk Prioritization

In the ESRM life cycle, we first look at risk identification, which is a simpler and somewhat more accelerated process than the ISO way of breaking things up. ESRM combines the first two ISO concepts of identifying and analyzing risk into the single step of Risk Identification – those two ISO recommended

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

steps are easily combined when you consider all risk from the outset using the risk triangle model. ISO’s concept of risk identification is truly more like listing potential threats, while the analysis part determines whether the threat has exposure, and impact, and is truly a risk. ESRM simply combined this.

Once the risks are identified, ESRM then looks at risk prioritization. This is called risk evaluation by the ISO standard, but is essentially the same process of determining the level of risk vs. the enterprise tolerance for risk, and then prioritizing treatment based on the gaps between the two.

Questions for the Security Practitioner • “What might be the best published standard to apply to my enterprise?” • “Could I leverage the work of other people in my enterprise who manage other types of risk to

begin my security risk assessment?”

7.4 Risk Identification – Finding all the Risks Just as you saw when identifying the assets owned by your enterprise, the process of identifying all the potential risks to those assets is an investigative one that involves, among other things:

• Research into historic security incidents to determine existing risks. • Discussions with asset owners to identify their risk concerns. • Identifying risks from existing risk registers – local threat data from government agencies, or

insurance companies.

Some risk assessments are simple and straightforward. Tangible assets, like buildings, are exposed to a readily identifiable set of environmental risks, based on their location. Some risks are obvious, simply because of the nature of the enterprise’s business. A defense contractor that handles classified government data must be deeply concerned with information security, while a gold or diamond mine is likely far more concerned with the risk of physical theft.

Not all risks are as obvious as these, however. An effective way to find the less obvious risks is to approach risk assessment from the point of view of some other key stakeholders. Looking at your organization from other’s points of view allows you to see what their priorities are, and to focus on threats that could potentially harm their ability to meet those priorities. • Think like a CEO.

o The CEO’s “big picture” point of view will center around security risks that could impact the company’s ability to carry out its mission, cause it to lose customers or market share, and keep it from being profitable.

• Think like a shareholder. o Of course, the first concern of most shareholders is the profitability and sustainability of the

company they’ve invested in. But another thing to consider is that many investors today are “activist” investors. Is your firm one that fits a profile, such as being “green,” which could be an exposure to consider?

• Think like a customer. o Put yourself in the place of your organization’s customers, and imagine what their major

concerns might be. Is it their personal safety when they are on your premises? Is it keeping their personal information out of the hands of thieves?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

These are all numerous ways of looking at assets that might be at risk, and of seeing what the impact might be if exposure to a threat caused an occurrence of that threat – a security incident. These do not necessarily contradict one another. The CEO, the shareholder, and the customer – and many other stakeholders – all have their own “right” ways of looking at a risk to an asset. From an ESRM perspective, what matters is considering all their viewpoints so that, as a security practitioner, you can conduct a thorough and meaningful risk assessment.

Questions for the Security Practitioner • “Do I have any direct contact with my enterprise’s customers or clients, so that I can fully

understand their view of my organization?” • “How can I leverage my information gathered prior to beginning the ESRM program, so that it will

assist me in identifying all the risks?

7.5 Prioritizing Risks for Mitigation So far in the ESRM process, you have: • Developed a comprehensive understanding of your enterprise. • Identified your strategic partners and stakeholders. • Identified and placed a business value on enterprise assets, in partnership with your stakeholders. • Examined and identified risks to those assets. That all feeds the next activity – placing priorities on the risks to plan for appropriate mitigation. It’s time to ask: • Which risks are the most impactful to critical assets? • Which risks most urgently require mitigation plans? • Which risks might be less impactful than thought at the beginning of the risk identification? • Which risks might be within risk tolerance and acceptable to the business? You have gathered the information about corporate culture, acceptable levels of risk, what is most important to the stakeholders, what exposures each asset has, and what impact the loss of the asset might be on the business. That all comes together now to inform you in planning a security strategy to protect your enterprise, to make recommendations about the importance of any risk, and to prioritize the order in which it should be considered.

Of course, your strategic partners in the business – business function leaders and other stakeholders – must be fully engaged in discussions at this point, to determine how the business sees the risk, and whether they are willing to accept the risk or they wish to find a method for dealing with it.

7.5.1 Presenting a Risk Matrix It can be very helpful to build a risk matrix or a threat “heat map” to present to your strategic partners to inform their decisions while determining the need for security risk mitigation strategies. These documents simplify what can often be a complex message. The simpler you make your security risk message, the easier it will be for your non-security colleagues to understand. In turn, this will make it easier for you to explain your recommendations, and enable the risk owners to be truly educated on the risk topics prior to making your decision.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.5.1.1 Education vs. Fear In ESRM, 100% of the goal is to ensure that your risk owners are fully educated, and that they truly understand the risks that could affect their business objectives. In the past, we have unfortunately met occasional security practitioners who use security jargon, confusing terminology, inflated numbers, and hyperbole to convince the enterprise to implement their security recommendations. This is a common tactic used in sales called, “The FUD Factor.” It stands for: • Fear. • Uncertainty. • Doubt.

FUD is a disinformation strategy that is designed to manipulate the human fear of the unknown, rather than letting the person reach a factual and educated decision. Using this technique is a real danger to your credibility as a security professional, since you are making a case for a security strategy based on fear, rather than on concrete assessments of potential impacts. Using FUD communicates a lack of business modeling and acumen, and it is difficult to defend when questions come up about hard facts.

Additionally, there is plenty of ammunition for security mitigation planning using real-life risk information, with no need to play on any fears or use confusing tactics. Of course, people do like to hear stories of why they should consider things, and executives are no different. There is a time and place to use anecdotes, to point out incidents in other companies, and imagine risks that might apply to your own enterprise. As we will discuss in Chapter 9, this is part of ongoing risk awareness. But relying too much on “The FUD Factor” is never a winning approach.

Questions for the Security Practitioner • “Have I ever used scare tactic to describe a potential impact from a threat, because I thought the

facts of the risk were not sufficient to have my plan implemented?” • “How do I communicate the existence of security risks to my stakeholder audience currently?”

7.5.1.2 Building a Matrix In Figure 7-4, we show a simple, factual, risk matrix that you can use to educate your strategic partners about: • Risks that could impact their critical assets and business goals. • The identified potential exposure to and impact of the risk. • Potential mitigation options for each risk, and the associated costs and effects. (This is also related to

Step 3 in the ESRM cycle – Mitigating the prioritized risks.)

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Critical Asset Risk Matrix Asset: ___________________ Risk Stakeholders: ______________________ ______________________ ______________________ ______________________ Completed By: _____________ Date Completed: ______________________

Ref # Risk Description

Impact Rating

Exposure Rating

Notes on Impact/Exposure Ratings Mitigation Options

Post Mitigation Impact Level

Post Mitigation Exposure Level Notes

Figure 7-4. Risk Matrix.

This type of matrix is the starting point of discussions with your strategic partners. It can be quite simple, or you can add additional information as needed for your enterprise environment. The choices you make must be based on your organizational culture. For example, the impact and exposure ratings we recommend are: • High. • Medium. • Low. These make sense to most people and the meaning is easily communicated. However, some organizations might want impact measured on a scale of 1 to 10, or in financial terms such as: • <$50,000. • $50,000–$100,000. • $100,000–$500,000. • > $500,000. The message you present must be the one best heard by your audience. The business leaders in your organization should be the main drivers in defining any risk measurement thresholds and terminology – this is a natural extension of their role in the process as the ultimate decision makers on all security risks.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.5.1.3 Building a Heat Map While a risk matrix can be a very simple way to educate your strategic partners on the risks that could impact their assets, an even simpler and predominantly visual way to show them the risks they face is a heat map.

Figure 7-5. Risk Heat Map

A heat map is typically a grid with colors ranging from green in the bottom left to red in the upper right, along axes of impact and likelihood. In Figure 7-5, you can see a typical heat map with some example security risks that would be common to a shipping and receiving warehouse for a pharmaceutical company. In this image, we depict the colors in shades of grey, but we would recommend using colors to call attention to the most serious threats in red.

7.5.1.4 Security Risk Decision-Making Once you have presented your strategic partner with a picture of the risks that their assets are exposed to, and depending on the level of formality within your organization, you may need to move forward with a decision paper on each mitigation plan. This is a formal written yes/no statement from the business owner regarding the mitigation plan. Alternatively, you may be able to simply have a verbal “go ahead” from the risk owner to move forward with the plan. Whatever the case, the key in ESRM is that you have the risk conversation. The owners of those risks are the ones who make the final decision on whether to implement a mitigation plan, and how to go about it. As long as you provide them with correct, clear, factual information, in the ESRM paradigm, you have done your job, no matter what their final decision may be.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.5.2 Conflicts in Risk Prioritization Of course, the world of decision making is not always so black and white. Just as we saw in asset prioritization, you may run into any number of issues when you have these risk prioritization conversations with your colleagues. You might see any or all of the following: • Different risk owners finding different levels of risk tolerable. • Partial or non-risk owners attempting to use finance/budgets to control risk priority decisions. • Different risk owners wanting specific risks considered over others. • Personnel without the authority to state risk tolerance attempting to accept risks as tolerable.

As you implement and work through the ESRM process, we can practically guarantee that you will see all these conflicts, and probably others. However, as the security practitioner, the ESRM philosophy gives you the authority to work with all those involved, and reach a solution which will meet all the needs of the enterprise. In fact, in ESRM it is your main requirement as the security practitioner, to manage the risk process in partnership with the enterprise. Managing risk includes resolving conflicts that are based on differing viewpoints.

Think About It: Varying Views of the Same Risk Picture Different assets will have different risks, but there can be different risks, even for the same asset, based on the stakeholder’s point of view when looking at the risk and the surrounding circumstances. Here is a thought exercise that shows how different the risk priorities can be and how they can change.

Let’s say you are working for a major lending institution. A mortgage broker is suspected of setting up fraudulent accounts, collecting sales commissions on the mortgages associated with those accounts, then letting them go into default for nonpayment.

An investigation establishes that the broker did, in fact, commit the fraud, and he is immediately fired.

Now, from your security perspective, does that mean there is no longer any risk, or is it still a priority?

You, the brokers in that department, their managers, the sales executives, company executives, and your security investigators all see this from their own unique, and very different, perspectives.

The Sales Team The salespeople, brokers, and sales managers probably just want to get back to work; so they’re likely to see that all was needed was the firing of that one employee, and that action would mitigate the risk that the fraud presented. They might see the risk as a low priority. But is that their decision to make? Or, to put the question in ESRM terms, do they own the risk?

The Senior Executives What if further investigation showed that more than just that one employee was using the same fraudulent process? What if the fraud represented something close to 5% of company sales? Would that make the risk a higher priority and warrant escalation of the issue to senior executives? What if the fraud was on such a large scale that it might force

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

the company to restate its quarterly earnings? This would clearly not be the low priority that the sales team might consider it.

The US SEC and DOJ And it could grow beyond that scope. What if the investigation showed that certain managers on the sales team had known about the fraud and covered it up so that the company wouldn’t have to restate its earnings? Wouldn’t everyone's perspective change at that point? Remember that senior corporate officers in the US sign off on Sarbanes- Oxley forms, saying that those earnings reports are accurate. If they are not, the managers and the company both face liability for very serious civil and even criminal penalties from the SEC and DOJ.

These are a lot of “What if?” questions and speculation. But asking “What if?” is what risk identification and prioritization is all about. As the security practitioner, you must ensure that the “what if” does not wander into “FUD Factor” territory but that it still explores the realistic and possible risks that the enterprise faces every day.

Wells Fargo – Fraud Scandal The example we described here was echoed in real life events in 2016, when the CEO of Wells Fargo was called to testify in front of the US Congress regarding a decade’s worth of fraudulent account activity related to sales processes in the firm. The Wells Fargo fraud scandal led to the CEO stepping down and the company paying roughly $185 million in fines and restitution, in addition to enormous stock value losses. Each step along the way, the sales personnel, managers, and executives all had their own perspective on the practices being performed. But ultimately, the impact was larger than likely any of them anticipated it would be.

As you can see, there are a lot of moving pieces in the risk prioritization discussion. There are a few things to keep in mind, though. • The enterprise can tolerate and accept risk, and can consider it to not be a priority at all, if the person

with authority to do it chooses to. • Conflicts will eventually occur with personnel who all have a legitimate stake in the risk priority

decision.

Questions for the Security Practitioner • “Is there disagreement in my enterprise over prioritizing one risk over another when leadership is

planning budgets, and so on, around security?” • “If I needed to at this time, would I be able to impartially mediate a disagreement between two

equally authorized stakeholders on a risk priority? What if I agreed more with one, but both had the same authority?”

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

7.5.2.1 The Role of Security We discussed some of the concepts in handling stakeholder conflict in chapter 6 when exploring conflicts in asset valuation, but the risk discussion is slightly different, more complicated, and the stakes of putting the right security measures in place to mitigate risk can be much higher than a conflict in how much an asset is worth to the organization. Your role is to help the business come to an agreed upon decision accepted by the people with authority to do so. All final risk priority decisions, while heavily influenced by the expertise of the security leader, must be made by the business function leaders whose assets and objectives are impacted by the risks.

The various risk decision roles are outlined below in Table 7-2.

Table 7-2. The Role of the Security Practitioner in Risk Decision Conflicts Your Role as a Security Risk Manager Not Your Role and a Security

Risk Manager Yes Provide clear, factual risk descriptions, and outline

possible mitigation options. No Make unilateral risk priority

decisions without stakeholder involvement and agreement. Yes Ensure that all stakeholders who are exposed to the

risk are part of the risk priority decision. Yes Ensure that stakeholders have the appropriate role and

authority to make any risk decisions. Yes Coordinate meetings between stakeholders who have

conflicting opinions on risk prioritization, and mediate the conversation to allow them to come to agreement.

No Make final risk priority decisions in situations where stakeholders disagree.

Yes Escalate to higher management when risk priority conflicts cannot be resolved.

Yes Escalate to higher management when persons without true authority to make a risk tolerance decision attempt to accept a risk outside of their role.

In some cases, the roles as outlined above can be tricky to perform. Conflict can inherently get into the murky waters of organization politics, and competing stakeholder interests can certainly make for contentious discussions sometimes.

The work you have done of building a professional reputation and solid relationships with all the stakeholders will facilitate your role of providing the best information, and any mediation needed. This will ultimately ensure that the enterprise is protected appropriately, according to the tolerance for risk and the need for critical asset protection.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Case Study: Risk Tolerance – When Priorities Collide Shawn R. has recently been promoted to the position of chief security officer (CSO) with Draper Logistics, a London-based firm that specializes in assisting small and midsize businesses with logistics, transportation, and resource issues. He has been with Draper for three years in a series of increasingly responsible security positions, and in that time, he has consistently communicated his view that security risk belongs to everyone in the company and that his colleagues must be the key drivers in protecting the company assets from harm. When he began his tenure as CSO, it was with a clear understanding from the company’s CEO, Phil C., that his mission was to implement and sustain a risk management-based security culture.

Shawn’s first step in this direction is to revisit the company’s business impact analysis, which was completed right before he joined Draper. His team works with functional leaders across the company to identify the assets they are responsible for, and to determine how critical each one is to the business. The result is a report sent out to the managers of those assets, letting them know how heavily the company relies on the assets. To Shawn’s surprise, that turns out to be his first big challenge in his new role.

Draper’s chief technology officer (CTO), Tony K., disagrees with the criticality ratings that the report assigns to several of the IT systems he is responsible for. The report says that those systems require higher availability, with stronger backup and recovery capacity, than they currently have. Tony simply changes the ratings and sends the report back to Shawn.

Shawn immediately meets with Tony, explaining that the risks outlined in the report were gathered directly from business leaders, and that the ratings can’t simply be changed without further discussion and input. Tony’s reply is a stark contrast to Shawn’s collaborative approach. He says he has been in IT for decades, that he knows what is important and what is not, and that the IT systems belong to him.

Shawn makes it clear that this is unacceptable, He says he will point out to the CEO that Tony has changed the report over his objections, that Tony has disregarded the input of the impacted business leaders and is exposing the company to risks that aren’t his risks to accept. The discussion becomes quite heated, with Tony repeatedly saying that the business leaders just don’t “get” IT. This eventually emerges as Tony’s overriding concern, that other department heads have no idea how much it costs to maintain their systems in the highest classification tier.

Finally, Shawn offers to arrange meetings between Tony and the individual business leaders, whose classifications he does not agree with. That way, the business leaders can explain why they consider the applications to be critical, and Tony can discuss the costs associated with that tier. In the course of these meetings, one business leader does acknowledge that the cost of criticality on her application is not worth the return. Two others show Tony that their applications support critical business, and he was unaware of the value of those applications. He also learns that a failure of those applications would cost Draper millions. With Tony’s initially reluctant approval, those leaders and Tony go to Phil and find the necessary budget to apply additional risk mitigations to the systems.

It is an awkward situation and an uncomfortable one for Shawn. After all, he is still very new to his job. But the outcome is the right one: All the impacted stakeholders have come to an agreement about risk acceptance. And although he was prepared to, Shawn didn’t need to take the uncomfortable step of escalating the issue to the CEO.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

The role of the security practitioner in ESRM can sometimes be complicated. But ultimately, the bedrock foundation of the ESRM philosophy is knowing that you have provided the best information you can to the decisions makers and that you have helped them come to the final decision of how to handle a risk.

7.5.2.2 The Role of the Asset Owner In making a risk decision in the ESRM model, the role of the risk owner/stakeholder can be easily described, but it still a significant responsibility in protecting the enterprise from the harm that might come from security risks.

Quite simply, the role of the risk owner is to make educated decisions. That simple statement involves the roles as outlined below in Table 7-3.

Table 7-3. The Role of the Risk Owner in Risk Priority Conflicts Role of the Risk Owner/Stakeholder Not the Role of the Risk

Owner/Stakeholder Yes Fully understand the risk to the enterprise

as presented to them by the security leader. No Make unilateral security risk priority

decisions, without all stakeholders’ involvement and agreement.

Yes Escalate the decision, or accept the escalation of the security manager, when the level of risk decision-making exceeds their authority.

No Exceed their authority in risk tolerance decision-making.

Yes Come to agreement with other risk stakeholders on all security risk priority decisions.

No Make security risk decisions, without involving security or other stakeholders.

According to ESRM, risk owners and stakeholders must understand both their roles, and the role of the security practitioner in security risk management. This is the reason it is critical that you communicate the role of security consistently and clearly, and also the roles of your strategic partners on a regular basis.

Chapter Review In Chapter 7, you learned: • The risk triangle requires a threat, exposure, and impact for a threat to be considered a real risk. • The ESRM cycle calls for identifying all possible risks, and then working with business stakeholders

to prioritize the risks. • Conflicts can occur when prioritizing risk, and the role of the security professional is to help the

business leaders and stakeholders come to agreement on a priority.

Looking Forward In Chapter 8, we will move on to the next step in the ESRM cycle – choosing and implementing the appropriate response to the identified and prioritized risks.

Practitioner steps to consider before moving on to Chapter 8:  Consider looking at language used to communicate risk in other risk or financial documents in your

organization to best describe, identify, and prioritize risks.  Consider asking other departments that deal with risk in your enterprise whether risks are typically

accepted, transferred, or mitigated to get a better understanding of typical decisions.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Security Program Self-Assessment In this self-assessment, you should think about the answer to the questions posed, and then see where your program is on the identified ESRM spectrum.

Question Y/N Is This ESRM? Do you ask department leaders in your organization to provide support at the executive level during annual budgeting processes?

□Yes

□No

NO: If you have never engaged internal departments to support you in implementing a new program, or in supporting the budget of an existing program, this is a suitable place to start your ESRM program.

PARTIAL: If you ask for input from impacted departments when implementing a program, but do not engage ongoing support from strategic partners when budgeting for security, you are part of the way to an ESRM implementation.

YES: If you present your strategic partners with risk matrices and maps to educate them on their risks, and also have a formal process for internal departments “sponsoring” each policy, standard, or program in your department, and you can call on strategic partners to defend the programs to senior management if needed, you are practicing ESRM.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for Discussion 1. How can the reputation of the security practitioner impact perceptions of the risk information that

is presented to the asset owners and risk stakeholders? 2. Why are conflict-resolution skills important in the risk prioritization process? 3. How can the security practitioner best ensure that the asset owners and stakeholders truly

understand the security risks that the enterprise faces?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

References

ISO/IEC. (2009). ISO/IEC 31000:2009 Risk management – Principles and guidelines. Geneva, Switzerland: Author.

Learn More About It For further reading about performing risk assessments see: Tucker, E. & Broder, J. (2012). Risk analysis and the security survey (4th ed.). Waltham, MA:

Butterworth-Heinemann.

Vellani, K. (2007). Strategic security management: A risk assessment guide for decision makers. Waltham, MA: Butterworth-Heinemann.

For further reading about risk standards see these web sites: • Carnegie Mellon Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE).

o http://www.cert.org/resilience/products-services/octave/ • European Union Agency for Network and Information Security (ENISA) Risk Management/Risk

Assessment (RM/RA) Framework. o https://www.enisa.europa.eu/topics/threat-risk-management/risk-management/current-

risk/business-process-integration/the-enisa-rm-ra-framework • National Institute of Standards and Technology (NIST) Cybersecurity Framework.

o https://www.nist.gov/cyberframework • ISACA Control Objectives for Information and Related Technology (COBIT 5) Framework.

o https://www.isaca.org/cobit/pages/cobit-5-framework-product-page.aspx • ASIS/RIMS ANSI Risk Assessment Standard. • https://www.asisonline.org/Standards-Guidelines/Standards/published/Pages/Risk-Assessment.aspx

(available for purchase).

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

http://www.cert.org/resilience/products-services/octave/

https://www.enisa.europa.eu/topics/threat-risk-management/risk-management/current-risk/business-process-integration/the-enisa-rm-ra-framework

https://www.isaca.org/cobit/pages/cobit-5-framework-product-page.aspx

https://www.asisonline.org/Standards-Guidelines/Standards/published/Pages/Risk-Assessment.aspx

The ESRM Cycle – Step 3: Mitigate Prioritized Risks

In Step 3 of the ESRM cycle, the identification and prioritization of assets and risks comes together, and allows security professionals to take action to deal with the identified risks. This is called risk treatment in many risk management standards. We refer to this step as risk mitigation because this step will primarily involve putting in place mitigating plans and actions, which will lower the exposure and impact of identified threats. However, your strategic business partners might sometimes choose another treatment option. We will review those options in this chapter as well, to ensure that you are familiar with the other available choices.

In this step of the ESRM cycle, you can really communicate the difference between ESRM and traditional security to your partners. Risk mitigation activities, such as physical security, investigations, access management, etc., are often the processes used to define the security department and its role. In this step, you can discuss these mitigation processes as part of the ESRM model and risk paradigm – focusing on aspects of overall security risk management, rather than on the tasks that define the security function.

This chapter will help you to: • Clarify the definition of risk mitigation within the larger context of risk treatment. • Explore the ESRM approach to presenting mitigation activities as risk response. • Explain to your strategic partners the roles of security and of the business stakeholders in making risk

mitigation decisions.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

8.1 Mitigate Prioritized Risks Step 3 of the ESRM cycle, as shown in Figure 8-1, is to mitigate the prioritized risks. It means working with your strategic partners to choose and implement the preferred business response to the risks that you have identified and prioritized with them.

Some examples of risk mitigation plans and activities are: • Maintain access control. • Use locks and keys. • Install network firewalls. • Post guards. • Use and manage passwords. • Plan for crisis management and response. • Conduct investigations. • Monitor facilities with closed circuit video.

Figure 8-1. Step 3 of the ESRM Life Cycle is to mitigate the prioritized risks

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

These are tasks that you and your security team are likely already doing. This part of the ESRM cycle allows you to reframe the tasks through the risk mitigation lens, and it helps you to validate with the stakeholders that the correct activities are being done to meet risk tolerance. We cannot to tell you exactly what the mitigation response should be used for your enterprise security risks. At this step in the cycle, you and your stakeholders will come together to determine those choices.

8.2 Risk Management and Mitigation Responses in Existing Industry Standards Risk mitigation planning is not only a critical component in security, but in many business functions. Many published standards deal with risk mitigation, and many industries and professions that deal with risk regularly have their own specific standards and practices. In Table 8-1, we outline a few profession- and industry-specific risk management standards. Use these for additional ideas on handling risk and understanding how your strategic partners in other functions within your organization look at risk.

Table 8-1. Professional Standards for Risk Mitigation Profession Organization and

Standard Excerpt on Risk Management

Project Management

Project Management Institute (PMI) www.pmi.org A Guide to the Project Management Body of Knowledge, 5th edition, 2013, pp. 310-311.

11. Project Risk Management Project risk management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project…. To be successful, an organization should be committed to address risk management proactively and consistently throughout the project. A conscious choice should be made at all levels of the organization to actively identify and pursue effective risk management during the life of the project.

Internal Audit The Institute of Internal Auditors (IIA) www.theiia.org International Standards for the Professional Practice of Internal Auditing Standards, 2012, p. 13.

2120 – Risk Management The internal audit activity must evaluate the effectiveness and contribute to the improvement of risk management processes. Interpretation: Determining whether risk management processes are effective is a judgment, resulting from the internal auditor’s assessment that:

• Organizational objectives support and align with the organization’s mission.

• Significant risks are identified and assessed. • Appropriate risk responses are selected that align

risks with the organization’s risk appetite. • Relevant risk information is captured and

communicated in a timely manner across the organization, enabling staff, management, and the board to carry out their responsibilities.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Fraud/Accounting Chartered Institute of Management Accountants (CIMA) www.cimaglobal.com Fraud risk management: A guide to good practice, 2009, p. 21.

Analyzing Fraud Risks Fraud risk is one component of operational risk. Operational risk focuses on the risks associated with errors or events in transaction processing or other business operations. A fraud risk review considers whether these errors or events could be the result of a deliberate act designed to benefit the perpetrator. As a result, fraud risk reviews should be detailed exercises conducted by teams combining in-depth knowledge of the business and market with detailed knowledge and experience of fraud. Risks such as false accounting or the theft of cash or assets need to be considered for each part of the organization’s business. Frequently, businesses focus on a limited number of risks, most commonly on third- party thefts. To avoid this, the risks should be classified by reference to the possible type of offence and the potential perpetrator(s). Fraud risks need to be assessed for each area and process of the business, for example, cash payments, cash receipts, sales, purchasing, expenses, inventory, payroll, fixed assets, and loans.

Human Resources Society for Human Resource Management (SHRM) www.shrm.org The SHRM Body of Competency and Knowledge 2016, p. 54.

Functional Area #13: Risk Management HR develops and implements strategies to prevent and reduce the occurrence of risks and adverse events, and to minimize associated harm to the organization and its employees. Key Concepts:

• Approaches to qualitative and quantitative risk assessment (e.g., single loss expectancy, annualized loss expectancy).

• Business recovery and continuity-of-operations planning.

• Emergency and disaster (e.g., communicable disease, natural disaster, severe weather, terrorism) preparation and response planning.

• Enterprise risk management processes and best practices (e.g., understand context, identify risks, analyze risks, prioritize risks) and risk treatments (e.g., avoidance, reduction, sharing, retention).

• Legal and regulatory compliance auditing and investigation techniques.

• Quality assurance techniques and methods. • Risk sources (e.g., project failures) and types

(e.g., hazard, financial, operational, strategic). • Security concerns (e.g., workplace violence, theft,

fraud, corporate espionage, sabotage, kidnapping and ransom) and prevention.

(SHRM, 2017. P54)

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

All these standards provide helpful information to the security professional as background research. However, the ESRM philosophy does not require any one specific standard or practice when mitigating the risks faced by your enterprise. ESRM is a flexible philosophy, and can easily leverage any specific risk mitigation standard that you choose as applicable to your organization. For example, the health-care field has vastly different security risks from the financial field. If your business is in manufacturing, it will have a different outlook on risk than a business in the services or retail industry. The requirement from the ESRM standpoint is that some kind of response to risk must be undertaken. The one thing we cannot do as security professionals is ignore the risk – that is never an appropriate option.

Questions for the Security Practitioner • “What industry or professional standard might be the most appropriate to consider for my

enterprise?” • “Are there specific laws in my country or specific regulations in my industry regarding risk that I

must consider at this point in the ESRM cycle?”

8.2.1 The ISO Risk Management Standard It is important to understand that ESRM is agnostic in how it chooses a standard to follow in your enterprise risk model. With that in mind, we will once again discuss the ISO Risk Management Standard 31000:2009 as the closest thing to a universally applicable standard.

The ISO considers mitigation as part of a larger topic of “risk treatment.” The standard tells us that risk treatment is a “process to modify risk.” It goes on to modify that broad definition with a few clarifying notes. Note 1: Risk treatment can involve:

• Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk. • Taking or increasing risk to pursue an opportunity. • Removing the risk source (2.16). • Changing the likelihood of risk (2.19). • Changing the consequences of risk (2.18). • Sharing the risk with another party or parties (including contracts and risk financing). • Retaining the risk by informed decision.

Note 2: Risk treatments that deal with negative consequences are sometimes referred to as: • Risk mitigation. • Risk elimination. • Risk prevention. • And risk reduction.

Note 3: Risk treatment can create new risks or modify existing risks (ISO, 2009).

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

8.2.2 The ESRM Difference Slightly different from the ISO standard, the ESRM life cycle model refers to “mitigation” rather than “treatment,” because mitigation is the most typical response to security risk when using the steps of the ESRM cycle. Why? Because the ESRM process of identifying asset and risk priorities before the mitigation step means that items which make it to the priority list will typically fall outside of the tolerance of any option other than a mitigation action. However, since it is still possible that your strategic partners might choose not to mitigate the risks, we will briefly explore the other options outlined in much of the existing risk management literature.

8.3 Risk Treatment Options The final decision on how to treat a security risk is up to the asset owner and the risk stakeholders of that risk. Still, it is important that you are able to provide options to assist the business owner in making that decision.

Typically, you have four options for dealing with any security risk. 1. Accept the risk.

The business owners have ultimate responsibility for their own areas, and the risks associated with them. They may choose to accept a given risk, if they think it is appropriate, and if they have the proper authority to accept the risk

2. Stop the activity that causes the security risk. This is always an option that may be considered by the enterprise when faced with a risk – security or otherwise. Is the activity that the business is engaged in worth the risk inherent in doing that activity? For example, is it worth the risk to operate a retail store in a high crime area when the business handles cash and other valuables? Perhaps the answer is yes. The outlet may be highly profitable, or there may be legal or regulatory obstacles to refusing to operate in an under-served area. For many reasons, the business might decide to operate that outlet, despite the risks. But if the impacts from risk outweigh the gains, the risk owner could also decide that some risk is unacceptable, and mitigate it by simply ceasing operations.

3. Transfer the risk to another party. Simply put, this is typically a matter of purchasing insurance to share the monetary impact of a risk with a third party. Alternately, a partnering company could indemnify your enterprise against a risk. The impact might still occur, but if the asset in question is easily replaced and not time-critical, transferring the risk might be a good option.

4. Mitigate the exposure to or impact of the security risk. Mitigation is the area where your skills and knowledge as a security practitioner will likely prove to be most valuable, and it is the option that will be taken most of the time in the ESRM cycle. You can identify the threat, and then you can determine what security measures could lessen the enterprise’s exposure to the threat. This will reduce the likelihood that it will occur, and will lessen the impact if it does happen. This requires developing business-case-based mitigation recommendations for the risk owners to consider.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

8.4 Risk Mitigation Decisions As a security practitioner, your role is to manage the process of dealing with risk, so that the risk owner can make the final decision on the appropriate risk mitigation plan. However, that means that you are the subject matter expert in security plans, and the one who implements the security tactics, programs, and tasks that are chosen by the business to be put in place. Because of the trusting relationships you will have with your colleagues as part of the ESRM program, they ought to understand that your recommendations and solutions are key to the process.

You have the expertise to show your stakeholders what options will provide protection to the business. Sometimes, small steps might provide enough protective benefit. Your risk owners might feel it is enough and will not implement a larger project. If it is truly their risk to decide about, and if they truly understand what they are accepting, then implementing their chosen option is the correct path.

In Table 8-2 and Table 8-3, we outline the roles of the security risk manager, the asset owners, and risk stakeholders in the risk mitigation process.

Table 8-2. The Role of the Security Practitioner in Risk Mitigation Decisions Your Role as a Security Risk Manager Not Your Role and a Security

Risk Manager Yes Provide clear, factual risk descriptions, and recommend

mitigation options. No Make unilateral risk mitigation

decisions without stakeholder involvement and agreement. Yes Provide subject matter expertise and experienced

advice in all security mitigation planning decisions. Yes Ensure that all stakeholders exposed to the risk are part

of the risk mitigation planning. Yes Ensure that stakeholders have the appropriate role, and

authority to make any risk mitigation decisions. Yes Coordinate meetings between stakeholders who have

conflicting opinions on appropriate risk treatment plans, and mediate the conversation to allow them to come to agreement.

No Make final risk mitigation decisions in situations where stakeholders disagree.

Yes Escalate to higher management when risk decision conflicts cannot be resolved.

Yes Escalate to higher management when persons without authority to make a risk mitigation decision attempt to do so outside of their role.

Table 8-3. The Role of the Asset Owner in Risk Mitigation Decisions The Role of the Asset Owner/Stakeholder Not the Role of the Asset

Owner/Stakeholder Yes Understand fully the risk to the enterprise, and the

mitigation options as presented to them by the security leader.

No Make unilateral security risk decisions without all stakeholder involvement and agreement.

Yes Decide on mitigating the risk that best protects the enterprise assets within the risk tolerance level of the organization.

No Exceed their authority in risk tolerance decision making.

Yes Escalate the decision, or accept the escalation of the security manager, when the level of risk decision making exceeds their authority.

No Make security risk mitigation decisions without involving security or other stakeholders.

Yes Come to agreement with other risk stakeholders on all security risk mitigation decisions.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

8.4.1 Conflicts in Risk Mitigation Decisions In Chapters 6 and 7, we discussed the types of conflicts you might run into Steps 1 and 2 of ESRM life cycle. Step 3 of the cycle is no less prone to creating conflict. Some of the conflicts you might run into when choosing mitigation tactics are listed here: • Finance or budget owners who attempt to cut security implementations, even though they are not the

only impacted stakeholders. • Stakeholders having different opinions on the best mitigation tactics. • Risk stakeholders who might not truly understand the risk, or see no need to mitigate it. • Risk stakeholders without the authority to make mitigation decisions, but who think it is their

decision to make. • Potential mitigation activities that might slow other projects, causing risk stakeholders to object.

Unfortunately, managing security risk involves many moving parts – different assets, stakeholder interests, people, personalities, and budget limits – making running into conflicts an inevitable part of the decision-making process. This is to be expected, but the ESRM practice and philosophy makes dealing with conflict less contentious. That is because your role in managing the risk process is to ensure that the correct people come to the table, are properly educated on the risks, and that they make the decision that best serves their business interests. As the security professional, you will be able to provide expertise and a mediation role when faced with conflicting opinions about the right thing to do. We discussed tactics for dealing with such conflicts in the last two chapters. These tactics work just as well with mediating conflict over mitigation as they do with other risk stakeholder conflicts you might run into.

Remember that in Chapter 3, we talked about Rick M and the missing network card in the data center. His mitigation recommendations were denied. Then when the risk he was trying to mitigate occurred, he had the feeling of “I told you so.” ESRM frees the security practitioner from that feeling, because security risk mitigation decisions are always made by the person who is most responsible for it, with the proper processes followed, and known tolerances kept in mind. The asset owner knows the stakes, so the security expert can rest assured, knowing that no matter whether any recommendation is followed or not, the ultimate decision will agree the way the organization wishes to manage their risk.

Questions for the Security Practitioner • “Do I feel like I am able to escalate security risk mitigation conflicts to the appropriate level in the

organization if necessary?” • “Do I have a clear understanding of the risk tolerance of my enterprise, and do I know what level of

the organization is proper for risk decision making when it exceeds stated tolerance?”

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Chapter Review In Chapter 8, you learned: • Step 3 of the ESRM cycle is to choose and implement the appropriate response for dealing with the

risks as prioritized by the business. • Options for treating risk include accepting the risk, stopping the risky activity, transferring the risk, or

mitigating the risk. • In risk mitigation, the security practitioner’s role is to work with the business to find the most

appropriate risk solution for the enterprise.

Looking Forward In Chapter 9, we will move on to the last piece of the ESRM cycle – Improve and Advance. This step is the ongoing activity that will enable your program to continually improve, identify, and mitigate new risk, and protect your enterprise on an ongoing basis.

Practitioner steps to consider before moving on to Chapter 9:  Think about the culture of your organization, and imagine how needed escalated risk decisions

might play out in different parts of your enterprise.  Consider the security programs you already have in place. How are those already mitigating

risks to critical assets of the enterprise?

Security Program Self-Assessment In this self-assessment, you should think about the answer to the questions posed, then see where your program is on the identified ESRM spectrum.

Question Y/N Is This ESRM? Do you have a process for documenting risk management decisions in your organization?

□Yes □No

NO: If your department has no formal risk management process or documented steps for risk decision making, then this is a suitable place to start your ESRM program. PARTIAL: If your department sometimes requires written documentation of a risk decision (normally when you disagree with the decision), then you are part of the way to an ESRM implementation. YES: If you have a formal documented process where all risk response decisions and activities are documented with the response and approval, and if the activities and tasks are perceived as mitigation steps in managing security risks, and if the organization doesn’t define the security organization solely based on those tasks, then you are practicing ESRM.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for Discussion 1. In the security area, why is the most common response to risk to mitigate the risk? Are there

places where other options might be acceptable if explored? How might risk acceptance with monitoring sometimes be a better option?

2. As a security practitioner, how does having a trusted relationship with your strategic partners benefit the business when conflicts arise between stakeholders?

3. If you are dealing with a risk stakeholder who is attempting to accept a risk that exceeds their authority, what are some ways you can think of to escalate the risk decision to the appropriate level, without damaging the relationship with the stakeholder?

4. If a risk owner refuses all your security risk mitigation recommendations, and they have the appropriate authority to do so, then in the ESRM philosophy, you have successfully completed your role. How does that differ with the traditional security role?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Learn More About It For further reading about standards for risk mitigation, see: ISO/IEC. (2009). ISO/IEC 31000:2009 Risk management – Principles and guidelines. Geneva,

Switzerland: Author.

Lees, G. (2012, January). Fraud risk management: A guide to good practice. London, UK: Chartered Institute of Management Accountants.

Project Management Institute. (2013). A guide to the project management body of knowledge. Newtown Square, PA: Author.

Society for Human Resource Management (SHRM). (2017). The SHRM body of competency and knowledge 2017. Available at https://www.shrm.org/certification/Documents/SHRM- BoCK-FINAL.pdf

The Institute of Internal Auditors. (2012, October). International standards for the professional practice of internal auditing (standards). Available at https://na.theiia.org/standards- guidance/Public%20Documents/IPPF%202013%20English.pdf

For further reading about conflict resolution, see: Moore, C. (2014). The mediation process: Practical strategies for resolving conflict (4th ed). San

Francisco, CA: Jossey Bass.

Patterson, K., Grenny, J., McMillan, R., & Switzler, A. (2011). Crucial conversations: Tools for talking when stakes are high. New York, NY: McGraw Hill Education.

Stone, D., Patton, B. & Heen, S. (2010). Difficult conversations: How to discuss what matters most. New York, NY: Penguin Books.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

https://na.theiia.org/standards-guidance/Public%20Documents/IPPF%202013%20English.pdf

The ESRM Cycle – Step 4: Improve and Advance

Now that you have worked through the beginning steps of your ESRM cycle, it’s time to move into the ongoing operational phase of ESRM. Step 4, Improve and Advance, is the ongoing, day-to-day activity that will enable your ESRM program to be nimble, responsive, and above all, to continually improve to meet the needs of your enterprise strategic partners.

That we are moving on does not mean you will never revisit Steps 1 to 3. If you need to reassess the entire enterprise, if you have an identified enterprise change, or when you receive a request from a business leader to add security coverage to a new segment of the business, these steps will need to be taken at regular intervals.

This chapter will help you to: • Understand how the ESRM cycle continues to identify and mitigate new risk. • Discover how root cause analysis as the primary driver of investigations helps protect the enterprise

from residual risk. • Identify ways of detecting new risks in the enterprise environment.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

9.1 Improve and Advance Unfortunately, risk mitigation is not the end of the risk process. Risk to the organization and business processes can never be eliminated, and however sound your security and risk process and practices are, bad things will, inevitably, happen. That is simply the nature of the security business.

The last step in the ESRM cycle is the core of your program. It is a cycle-within-a-cycle of improving and advancing your program in the face of what will be a continually shifting security risk landscape. As shown in Figure 9-1, improving your ESRM program is a continuous, ongoing process, involving: 1. Incident Response. 2. Root Cause Analysis and Improvement. 3. Ongoing Security Risk Assessment.

Figure 9-1. ESRM Life Cycle Step 4 is to Improve and Advance the program.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

9.2 Incident Response Continually improving and advancing your ESRM program requires that you and your strategic partners in the organization recognize the inevitability of security incidents occurring, and have plans to respond to them when they do.

Incident response can mean one of two things: 1. A reactive response is reacting to an incident of harm coming to the enterprise. 2. A proactive response is reacting to the identification of potential harm that could occur, due to

some activity that is actively occurring, and then mitigating it.

In the first type, an “event” will occur and need to be dealt with in some way. This could be anything. It could be an angry customer in a retail environment who needs to be escorted off premises. It might be responding to a bank robbery (if your security team is trained and tasked with such things). It could even be responding to a DDOS attack, or a data breach. All these kinds of events must be addressed in the moment.

The second type of incident response is where information is brought to the security department about behavior or activity that is not actively causing harm (that is known of), but has the potential to do so if it is not dealt with. Examples that fall into this category are reports of concerning behavior in the “red flags” zone on the workplace violence spectrum, or perhaps it is a report of network activity that looks suspicious, but may or may not be an actual cyber-attack.

Both types of incidents are things that the security team will react to and provide protective action for the enterprise. We call it an incident response because the activity is brought to the attention of the security team and a response is made.

Questions for the Security Practitioner • “Are all security or security-related incidents being reported to my security department for

response? If not, what types of incidents are directed to other groups, such as HR or Audit?” • “What methods of reporting exist within my enterprise to ensure that employees can escalate

potential incidents and concerning behavior to the security team?”

Incident response is one way to create and maintain awareness of impacts to the enterprise from previously unknown or residual risk. • Previously unknown risk is something that you will inevitably run across in your security program,

unfortunately. This is simply a security impact that went undiscovered in the asset identification phase, or it is a risk from a threat that was completely unforeseen. Your security incident response program should always be ready to handle these unexpected impacts.

• Residual risk is an impact from a risk that was considered, and it was either accepted as within tolerance, or it was partially mitigated. Just because a mitigation plan is in place or a risk is acceptable does not mean that the impact associated with that risk will never occur. There is no “perfect” mitigation, and accepting a risk means just that – accepting that the impact might occur. In either case, your security incident response team will typically be the first line of defense or of recovery.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

When an incident has occurred, after the immediate response of life safety and damage control, and once the active impact is stopped, the next step in the continual improvement process is to perform an investigation to discover the root cause of the incident.

9.3 ESRM Investigations and Root Cause Analysis Investigations are a core part of all security programs, not only ESRM. They can drive overall improvement of the security environment in any organization. However, in the ESRM model, the goal is slightly different. Although investigations to determine the perpetrator of an incident are part of the security incident response, the main goal of all ESRM investigations is to discover the underlying root cause of the incident – to understand the risk that was behind it, to determine whether residual risk still exists, and if it does, to work through a re-assessment process by following the risk cycle again.

Just as we discussed two types of incident response, we need to consider two types of investigations: • A reactive investigation is performed to analyze either a reactive or proactive incident response.

These investigate the facts surrounding an incident impact, such as determining who perpetrated a theft, what circumstances may have contributed to an incident occurring, an investigation into reported suspicions based on a tip about possible sales fraud, or time-card issues based on questionable management of forms.

• A proactive investigation is the process of scanning the environment for threats from inside or outside. These could involve gathering intelligence on internal personnel who may be exploiting vulnerabilities of the business, looking at the changing demographics of an area that may lead to new risk, monitoring virus registries to understand emerging cyber threats, or learning about the latest social engineering hacks.

In the ESRM paradigm, the goal of both types of investigation are driven by the need to determine the security risk at the foundation of the incident or potential incident. According to Fred Forck’s Cause analysis manual: Incident investigation method & techniques, a root cause analysis (sometimes called a “postmortem report” or “incident investigation”) is a “structured search for the underlying fixable reasons explaining the…factors that resulted in an adverse condition or critical incident” in the interests of preventing such conditions recurring in the future (Forck, 2017, p. 296). Thus, such an analysis is vital to continually improve your enterprise security program by identifying and mitigating residual risks.

Think About It: Why Do We Dig Deeper? As security professionals, we already understand that bad actors will never stop finding new and imaginative ways to do bad things; so, a crucial part of preventing bad actors from exploiting that specific situation again is to dig into each incident, and then determine exactly what circumstances allowed it to happen.

As an example:

A software engineer inserted some malicious code (malware) into a mobile app she developed – a backdoor that would allow criminals to access or even take control of a user’s phone or tablet. Then, when her employer’s quality control processes caught the bad code, an investigation identified the guilty party. She was quickly fired, and the malware removed.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

That is a good outcome, but it is also an incomplete one.

Rather than stopping at the point of identifying and firing the guilty party, a root cause investigation (also called a postmortem analysis) could identify residual risks that did not disappear once the rogue employee was walked out the door.

A look at the company’s hiring practices, for example, might show that a background check was never conducted on her. The postmortem might show that she had a criminal record that no one was aware of.

The residual risk in this instance – which is the goal of the postmortem – was not that one “bad actor” was hired, but that the employee who was caught may not be the only criminal who is writing apps for the company, because a risk mitigation process of checking backgrounds was not in place.

A root cause analysis of process-based risk might find that the company’s coding and QA processes themselves were at fault and should have caught the malware before it could go live. That leaves open the possibility – the residual risk – that more undetected bad code could be hidden in the app.

Neither of these findings is designed to blame or point fingers, but it is merely to assist the enterprise in closing potential gaps in the security posture.

9.3.1 Performing a Root Cause Analysis A root cause analysis includes asking follow-up questions, and delving into the answers to determine root cause, uncovering residual risk left from that cause, and actions that might prevent the incident from reoccurring. The follow-up questions may include: • What happened? • What were the time lines of the event? • How did it happen? • Could this happen again? • What was the threat? • Has the threat changed? • What was the exposure? • Has the value of the asset changed? • What was the attack path or vector? • Were there any controls in place? • If so, what controls were circumvented or failed? • Do the same vulnerabilities still exist? • Could the same vulnerabilities be exploited again? • Do changes need to be made to mitigate the probability and potential impact? • Is accepting the same risk acceptable again?

Once the root cause analysis is complete, you will provide a report to the impacted business units, and other asset and risk stakeholders, as part of your ongoing strategic partnership to continue the cycle of improvement to enterprise security. The report will make your partners aware of any previously unknown or residual risks that were discovered in the investigation. It will also allow them to assess and potentially

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

treat those risks (either to mitigate or accept them), just as they had that opportunity in the first pass through the ESRM cycle. This is how the enterprise remains vigilant for new risks, and can protect operations from new or previously unknown threats.

Think About It – A Legal Responsibility to Find the Root Cause Root cause analysis not only protects the enterprise from residual risk, but it is essentially a legal requirement for proper business practice due to two legal concepts.

Foreseeability • This concept means that a reasonable person or entity ought to understand the likely

consequences of an action (or lack of action). Root cause analysis will allow you to understand the root action that led to the consequence under investigation.

In the legal system, this concept is tied to:

Heightened Liability • Liability means that a person or organization is responsible for harm caused to

another. In the case of heightened liability, it refers to something that has already happened once. Thus, by the definition of foreseeability, if it happens again, it makes the responsible party “more” responsible, since the responsible party ought to have been able to understand the consequences and should have done something to avoid the cause or action.

9.4 Ongoing Security Risk Assessment Incident responses, investigations, and a root cause analysis all feed directly into the last piece of continual improvement, which is constantly assessing and updating the company’s picture of risk.

Ongoing risk assessments involve the same parts of the original assessment process that we discussed in Chapter 7. A reassessment identifies the assets, threats, and impacts, and then drives out what is truly a risk, prioritizes the risks, and presents them back to the risk stakeholders for their decision on how to deal with them. Ongoing risk reassessments are also good for the program overall, because if ESRM is a continual process, each iteration involves less time and effort than a full assessment “from scratch” would require.

When doing a reassessment, some of the questions to ask are: • What’s new in the environment?

o What assets have been purchased? o Has the business mission changed? o Has the business reorganized into different business units? o Has the business launched any new products? o What new projects are in the beginning phases that the security group could provide input on

from the start? o Have new regulations from external agencies been released?

• Are there any new risks? o Have previously identified risks become more significant? o Are there new mitigation tools that would be more effective and efficient to minimize risk?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

o Have previously implemented mitigation plans and/or tools become outdated and no longer effective against an existing risk?

o Are there any emerging risks that should be anticipated? • What’s been depreciated or retired since the last assessment?

o Have any products been pulled from the market? o Are some services no longer being offered? o Have any systems been replaced or retired completely? o Have policies or procedures been retired or changed?

• Have postmortem recommendations been followed or completed? o Has the mitigation process been completed for risks found through the last assessment? o If not, why are open issues still open?

The answers to these questions will lead you to new stakeholders to talk to, or perhaps will help you identify stakeholders who can be removed from the list. They will help you narrow down where to look for new assets, or will allow you to remove some assets from the assessment list. You can use these questions to drive discussions with business units to see if their goals and objectives have remained the same, and if their appetite for risk has been impacted by any of the changes.

Questions for the Security Practitioner • “Do I have a defined reassessment program for assets in the enterprise that have been through an

initial assessment?” • “Once a security program is implemented, have I gone back on a regular basis and reviewed the

metric of efficiency or effectiveness of that program?”

9.4.1 Sources of Risk Awareness Investigations and reassessing internal processes are one way to find new risk, but there are many external sources of risk awareness that you can use daily to determine what might be a potential impact to your enterprise. Some examples are: • Media

o Daily TV and radio news shows, newspapers, and websites are excellent sources of identifying new risk. In the security business, we must unfortunately recognize the fact that risk is often discovered through impact. News stories will help you learn about risks that have impacted other enterprises, and think about whether those same threats might impact your own, and to what extent.

o Popular culture can also impact your organization’s tolerance of risk. Movies and TV shows can make what might have seemed a small risk loom much larger in the minds of executives. Keeping an eye on what is in the media can help you prepare for questions about risks shown in fictional works as well.

• Legal Opinions/Regulatory Trends o If a new law or regulation is released or passed, it is important to be aware of the

ramifications for the enterprise. • Government Sources

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

o Many government entities provide feeds of new and emerging security situations. Law enforcement agencies and other defense groups in many countries are excellent sources of awareness.

• Security Industry Associations o Security industry organizations often provide valuable information and analysis of emerging

security risks to their members, as a benefit of membership. There are organizations for many different disciplines.

• Industry Publications o Most industries have specific publications, journals, magazines, and web sites that provide

news, and updates specific to that industry. We encourage you to pay close attention to the ones that are aligned with your enterprise to ensure an overall awareness of industry trends.

• Subscription Awareness Tools o There are many firms that provide security incident awareness emails or real-time feeds of

information from around the globe. While we do not endorse any specific tool, we would recommend considering the available options.

9.4.2 Reporting and Employee Vigilance One of the most effective ways of ensuring that you receive early warnings on new internal risks is through a mandatory reporting program and a security awareness campaign. If employees understand that they are also responsible for ensuring the security of the enterprise by following good security practices and reporting violations, then they will be valuable allies to you in the job of protecting your enterprise from harm.

One note to remember about encouraging reporting. With awareness efforts, you will often find that reporting increases, and so do your false alarms. However, in risk management, it is better to investigate 10 false reports to find and mitigate a true risk, than it is to have no awareness of the potential threat at all.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Chapter Review In Chapter 9, you learned: • Responding to and investigating incidents that harm the enterprise is the beginning of discovering

new risks or residual risk, leading to further improvement of the risk management program. • Root cause analysis is the key goal of ESRM investigations, driving further risk decision-making by

your strategic partners. • Continually scanning the internal and external environment to discover new potential threats to your

enterprise is an ongoing activity in the ESRM paradigm. Looking Forward In Part 3 of the book, we will look at designing and building an ESRM program that specifically fits your organization’s culture, mission, and needs. In Chapter 10, we will look at a concept called design thinking. We will examine how businesses use it for process development and see how design thinking can help you to roll out an ESRM program that your strategic partners will accept and embrace.

Practitioner steps to consider before moving on Chapter 10:  Consider joining relevant industry associations.  Update information feeds and subscriptions to include new risk information.  Find out if your enterprise has a stated non-retaliation policy for incident reporting. If not,

consider implementing one.

Security Program Self-Assessment In this self-assessment, you should think about the answer to the question posed, and then see where your program is on the identified ESRM spectrum.

Question Y/N Is This ESRM? Do all events that your security group responds to go through a formal root cause analysis?

□Yes □No

NO: If your department has no formal process for analyzing root causes to flush out residual risk, this is a suitable place to start your ESRM program. PARTIAL: If your department sometimes does a root cause analysis, depending on the event and severity of impact, or for “political” reasons, you are part of the way to an ESRM implementation. YES: If you have a formal documented process where all events undergo a root cause analysis and a report is made to impacted stakeholders, you are practicing ESRM.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

Questions for Discussion 1. Why is root cause analysis so critical to security program improvement? Do you think it’s

possible to improve and advance without this aspect? 2. Why is it important to the ongoing improvement of the security program that all security

practitioners continually scan the internal and external environment for new risks? 3. What are some ideas for encouraging all enterprise personnel to take an active role in

securing the environment and to report any incidents or potential security issues they are aware of?

4. What is your best source of information on internal threats and potential risks? How do you make sure you are hearing the information?

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

References Forck, F. (2017). Cause analysis manual: Incident investigation method & techniques.

Brookfield, CT: Rothstein Publishing.

Learn More About It For further reading about Security Incident Response and Management, see: Fay, J. (2011). Contemporary security management (3rd ed.). Burlington, MA: Butterworth-Heinemann. Kral, P. (2012). The incident handlers handbook. The SANS Institute. Available at

https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901

Roberts, S. J., Maxwell, K. R., & Brown, R. (2017). Intelligence-driven incident response: Outwitting the adversary. Sebastopol, CA: O’Reilly Media.

For further reading about Investigations see: American National Standards Institute (ANSI) & ASIS International. (2015, August). ANSI/ASIS

investigations standard, ANSI/ASIS INV.1-2015. Available for purchase at http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FASIS+INV.1-2015

Association of Certified Fraud Examiners (AFCE). (2017). 2017 Fraud examiners manual, U.S. edition.

Austin, TX: Author.

Ferraro, E. F. (2012). Investigations in the workplace (2nd ed.). Boca Raton, FL: CRC Press.

For further reading about Root Cause Analysis, see: ABS Consulting. (2008). Root cause analysis handbook: A guide to efficient and effective incident

investigation (3rd ed.). Brookfield, CT: Rothstein Publishing.

C op

yr ig

ht ©

2 01

7. R

ot hs

te in

A ss

oc ia

te s,

In co

rp or

at ed

. A ll

rig ht

s re

se rv

ed .

http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FASIS+INV.1-2015