Before we get into some heavier topics, first, we need to establish a common set of terms and ensure we're speaking the same language in order to simplify the ideas in this book. Otherwise, this book could become too complex, or even nearly impossible to decode as a result. My intention for this book is to reduce ambiguity and ensure you're right here with me. 

For example, on the first page, I said that this book is going to help you with "making a difference in your day-to-day work at your organization." In that sentence, we can see a common InfoSec term: organization. Whether your information security knowledge is being utilized by a corporation, government, small business, firm, non-profit, extracurricular group, or some other structure, they all fit under the umbrella term of "organization," and that's the one we're going to use in this book. 

Let's look at a few other basic terms. How about information? Information includes data but can also include common knowledge or intellectual property. For example, the new company slogan that is written down on a whiteboard after a brainstorming session is now "information," which should be protected, even if it isn't "data" in terms of it sitting on a hard drive in ones and zeros. 

That logically brings me to security, or the state of protection. Information has the ability to be secured in various ways, most commonly noted as a triangle or "triad" of concepts called the CIA Triad. You'll remember this from other InfoSec books and training you have done, but CIA stands for confidentiality, integrity, and availability. They're extremely important in navigating the day-to-day of information security, and that's why they're being brought up again:

Figure 1.1 – The CIA Triad

Confidentiality is the concept of keeping information secret and ensuring only those that have been authorized to can see it. Integrity is the concept of being sure the information hasn't been changed without permission. Availability means that those with permission to access the information can access it in a timely fashion. The reason the CIA Triad is often represented as a triangle (as in the preceding diagram) is because the three principles work together as an interconnected system that represents the security of an asset, or group of assets.

The often-forgotten "N" in the CIA Triad is non-repudiation, which is a way of saying that if an entity has authored (or changed) some information, it is authoritatively indisputable. It is the ability to prove the origin of said data.

Now that we've covered some of the basics, I'd like to discuss why risk management is important to you and your organization.

In this book, we've going to keep referencing risk. To ensure we're on the same page, it's worthwhile taking the time to define and discuss various risk management topics, and why they're important.

First, we're going to define risk as the potential for loss. The components that make up risk are assets, threats, vulnerabilities, likelihood, and impact, each of which we will define and explore in this section, and continually reference throughout this book.

For the time being, information security risk can be summarized like so:

"Information security risk is the potential for loss, as measured through the combined impact and likelihood of a threat exploiting a vulnerability in one or more information system assets."

Imagine that by understanding the likelihood of a threat exploiting a vulnerability, combined with the impact of that threat exploiting that vulnerability, you can measure the level of risk associated with that security event. Your organization faces many risks on a daily basis, and those risks may or may not already have risk scores and annualized costs associated with them, as determined by performing a risk assessment to determine the impact of the threat exploiting a vulnerability, and the likelihood that the threat will exploit that vulnerability.

Consider the following simplified formula:

Risk = Impact x Likelihood

Organizations are interested in minimizing their potential for loss through a process called risk management, by which they identify, evaluate, and prioritize risks, and implement layers of mitigating controls that reduce the impact and likelihood of a loss.

So, why is risk management important for information security? Risk management isn't about removing all the risk an organization faces, or adding bureaucracy for bureaucracy's sake. Risk management provides transparency and accountability into the daily operations of an organization, and aligns the organization's risk with its strategic objectives. Risk management also helps organizations prepare for adverse events that could negatively impact its success.

In the modern context, information systems are central to the ways in which most organizations do business, and so information security risk management is becoming a larger part of every organization's overall risk management focus.

In order to cover risk management effectively, it's important to go into a few key risk topics and definitions first. Let's get started!

Understanding assets

Let's look at that long sentence I wrote out earlier to summarize risk:

"Information security risk is the potential for loss, as measured through the combined impact and likelihood of a threat exploiting a vulnerability in one or more information system assets."

Looking at the structure of what comprises a risk, we can see that, first, you cannot have a risk without an asset. Your organization has many assets: digital assets, physical assets, and even reputational assets. For this book, I'm going to use the definition of assets as anything of value to the organization. Different assets have different risks associated with them, because different assets have different threats, different vulnerabilities, and different levels of impact in the event of loss of, exposure of, or making modifications to that asset (or the processing it performs).

Now, there are some company assets that will not have a significant information security risk associated with them, such as a box of T-shirts from a company picnic a couple years ago. Let's focus on documenting your organization's "crown jewel" information assets into an asset register to start; we can always add more assets to the register as we go along. 

An asset register or asset inventory is a document that lists the organization's assets. Creating a document like this (and keeping it up to date) is going to help with various aspects of the risk management process, because inside this asset register, you will begin to structure various organizational aspects surrounding how assets are handled, and identify risks based on those assets. The information inside this document could include asset owners, asset classification, asset value, and so on.

Before we get too complex, I believe it's worthwhile to show how we might create an extremely simple asset register for our organization. It might look something like this to begin with:

Essentially, in this document, we're going to give each asset an ID, a short name, a description, and any notes that may be associated with that asset. We could add columns for "asset owners," "asset classification," or "asset value" as required. It depends on your requirements and how you would like to structure the various documents we will cover in this book.

If you're looking for some inspiration for what assets you might put into your asset register, some example information assets could include information systems, such as servers, software, payment terminals, routers, or laptops. However, this can also include information itself, such as datasets, images, blueprints, formulas, or other intellectual property or (IP), for example.

Now that we've covered assets, let's move on to understanding threats.

Understanding threats

Looking back at that one long sentence about risk, we can see that you also cannot have a risk without a threat. Threats and their threat actors (the perpetrators of acts that represent threats) could include malicious hackers gaining access to company records, a rogue employee selling secrets to competitors, severe storms obliterating your office locations, or the nice lady in accounting opening a PDF file that releases ransomware across the entire organization's estate.

Each asset can have multiple threats associated with them, and each threat actor could have different goals and abilities, which means they can utilize different methods of exploitation. With different methods comes different likelihoods and different mitigation controls, so each viable threat should be considered for each asset in an activity called threat modeling, where we document the various threats and threat actors that the assets at our organization face.

To start with a default set of threats, consider the following: malicious outsiders, malicious insiders, and accidental insiders have threat actors, while environmental threats do not.

When thinking about threat actors, consider their ability, their interest, and their tactics. Taking malicious outsiders as an example, you could also get more detailed and split them up further; for example: 

• Sole actors could be experienced or inexperienced, but with the public release of sophisticated tools from major hacking groups and governmental organizations, even those actors that used to be called "Script Kiddies" are going to be able to access or change your information, or even make it unavailable. 
• Group actors are a potentially distributed team with funding, and could include hacktivists, criminal organizations, or even competitors. 
• State-sponsored actors have time, state-sponsored funding, and state-sponsored tools, and are the most sophisticated threat, but they have specific interests that might not be shared with the other two groups. 

Let me stress that there is no clear-cut "right way" to do this, so you need to make sure to create something that suits your organization. If state-sponsored actors aren't currently a relevant threat actor for your organization, you could create a placeholder for them in your documentation, and note that they are not currently a relevant threat. In the future, if a previously non-relevant threat does become relevant, you already have the placeholder ready to be changed with new information.

Another thing to mention here is that (obviously) weather patterns such as hurricanes and floods don't have threat actors, and therefore don't have interests or tactics. However, they do have the ability to impact information security, through availability outages or outright data loss. You can understand their likelihood and if your assets are affected by them as a result. Floods cause damage in basements, which means the information assets that are stored in your basement have a higher likelihood of being affected by that threat.

We're going to look deeper into threats, including the various threat actor categories and their motivations, in Chapter 3, Designing Secure Information Systems, so let me get back to discussing the basics around risk.

Understanding vulnerabilities

Now that we've covered assets and threats, the next piece of a risk we must understand is their vulnerability. You can't have a risk without a vulnerability due to the following (as we've mentioned previously):

"Information security risk is the potential for loss, as measured through the combined impact and likelihood of a threat exploiting a vulnerability in one or more information system assets."

So, with vulnerabilities, we're talking about the weakness of an asset that can be exploited by a threat. Vulnerabilities can vary by asset category, with hardware assets being susceptible to overheating or wear and tear, while software assets can be vulnerable through flawed code. We will delve deeper into what constitutes a vulnerability and how to mitigate them throughout this book, so I'm going to stop myself at that simplified definition before going down that rabbit hole.

We have now covered some of the key concepts in risk management, and why risk management is important as an information security professional. The next thing I'd like to cover is how we might actually perform a very basic risk assessment in practice, and how we can use risk assessments to understand the risks that our organization faces.

In this section, we're going to briefly cover how we might calculate a risk score in practical terms by utilizing the previously mentioned formula of Risk = Impact x Likelihood. By covering this now, we'll be able to dive deeper into this topic in Chapter 2, Protecting the Security of Assets, and be able to answer questions such as the following:

"Which mitigating controls do we have in place to protect our organization's three most valuable assets?"

However, from the perspective of what we've covered so far, we simply aren't ready to delve deeper into the topic of how we might implement an Information Security Management System (ISMS) into our organization. With that being said, we will be, by the end of the next chapter! Until then, it's worth covering how we can assess risk in a very simplified fashion.

Let's imagine that you've been hired as an information security officer for The Ketchup Company. Your crown-jewel asset at The Ketchup Company is your secret recipe for ketchup. Consider that The Ketchup Company's top competitor (who sells absolutely terrible ketchup) somehow manages to gain access to your organization's secret recipe and steal it for themselves. What would the impact of that happening be? What is the likelihood of that being possible?

We know that risk is the combined impact and likelihood of a threat exploiting a vulnerability. By understanding our assets, their vulnerabilities, and the threats they may face, we can begin to calculate the risk.

Just for this example, I can tell you now that The Ketchup Company's ketchup recipe is stored on the organization's network attached storage (NAS), which is accessible from the outside world by visiting the domain "http://networkstorage.theketchupcompany.com" through a web browser, with no username or password required for access. Furthermore, I can say that our top competitor being able to access the secret ketchup recipe would cost The Ketchup Company over 5% of its annual revenue per year. 

First of all, I'd like to take this opportunity to add two assets to our asset register at The Ketchup Company, like so:

Okay; some basic housekeeping is in order. Now, let's use this example scenario to perform a basic risk assessment, and practically cover some of the concepts we've gone into so far.

Defining and calculating impact

In order to calculate risk, we need to define the way your organization sees the various levels of impact that it could potentially face as a result of a security event. These values will depend on your organization and should be discussed with the appropriate stakeholders, who have a detailed understanding of its finances and operations.

For a simple starter, try this:

The organization losing 5% or more of its annual revenue due a security event is considered "catastrophic," while 3%-5% is "high," 1%-3% is "medium," 0%-1% is "low," and under $300 is "negligible."

Using those definitions, we can create an impact definition table, like so:

This is a considerably basic and immature example of how we might go about defining the potential impact of a security event occurring. Percentage of revenue might not be the best measure, so you can always consider defined sum ranges, or percentage of net income, and so on. It's not necessarily perfect, but this example lets us dip our toe into risk management, to set the scene for expanding various risk-based topics in rest of this book.

Defining and calculating likelihood

Next, in order to understand likelihood, we must define the way our organization sees various levels of likelihood. Is one occurrence per year a high level of likelihood, or a low level of likelihood for your organization?

For a simple starter, try this example:

A likelihood score of 5 is defined as "once per year or more," a score of 1 is "once every 10 or more years," and the years in-between get 2, 3, and 4.

Refer to the following table for an example of a likelihood definition table:

With that, we've successfully defined the way we score likelihood for The Ketchup Company. Remember, it's up to you to determine the best way to define impact and likelihood at your organization, but again, as we've said, this is just to set the scene for expanding various risk-based topics in the rest of this book.

Calculating risk

Now, we can go back to our example, where we will try to determine the likelihood and impact scores of a competitor accessing The Ketchup Company's secret recipe for ketchup. Using the details I provided earlier, we know that the recipe is stored on the company's NAS, and that this NAS can be reached from the outside world. Actually, we know that anybody who visits the domain "http://networkstorage.theketchupcompany.com" in their browser can access the recipe, without any username or password requirements, and we know that a competitor being able to access this recipe would cost the company over 5% of its annual revenue. 

First, let's determine this example's impact. Referring to the table that we created for our impact definitions, we can see that a 5% loss of annual revenue would mean the impact score related to that event is "5," or "Catastrophic."

I've included the table for illustration purposes here:

Now that the impact score has been determined, the next step would be to determine the likelihood of that event occurring. One way you might try to determine likelihood is through historical records. You might ask the following questions to stakeholders at your organization:

• Has this event happened before?
• How often has it happened?
• When was the last time it happened?

Sometimes, there is no historical data available, if your organization hasn't previously kept a record of breaches or information security events, or they haven't had the adequate level of visibility to know if an event has occurred.

Sometimes, your organization gains a new asset with new vulnerabilities, or maybe new threats arise, and therefore new risks arise as well.

In these cases, it's important to investigate and understand the implications of assets, their threats, their vulnerabilities, and the impact and likelihood of various risk events. We will be doing this as often as necessary to understand the risks the organization faces.

Let's look at our example system. Essentially, accessing the recipe can be done from a web browser. The URL for accessing the recipe could easily be shared outside the organization for anybody to see. Additionally, it might be able to be found via Google search results, or an automated system finding the networkstorage subdomain for our theketchupcompany.com domain. No username or password is required for anyone to access the recipe.

In this circumstance, let's say that we consider our threat actor's motivation (in this circumstance, a competitor with absolutely terrible ketchup) and capability (it has been previously rumored they've stolen their mustard recipe from The Mustard Company). With that information, we can determine that with the current configuration, and the current lack of any security controls to protect the recipe from unauthorized access, our competitor is likely to find the recipe within the next year.

If we refer to the likelihood definition table we created earlier and consider the information surrounding likelihood we provided previously, we can determine that the likelihood score associated with this specific example is a "5."

See the following table for a reminder:

So, we now have both an impact score and a likelihood score for our example. Next, we must calculate the risk. Before we do that, it is worth showing a visual representation of the risk score, based on varying levels of impact and likelihood. If we were to illustrate the previously mentioned formula of Risk = Impact x Likelihood as a risk matrix, we would see something similar to the following:

Figure 1.2 – Risk matrix

Let's dissect this diagram:

• The x axis represents impact, including the numerical "score" associated with each of the defined levels of impact from our previous table.
• The y axis represents likelihood, including the numerical "score" associated with each of the defined levels of likelihood from our previous table.
• By multiplying a number from the impact axis with a number from the likelihood axis, you get a risk score. In this case, it ranges from 1 to 25.

This is a common way of illustrating the risk formula we've mentioned several times in this chapter, as it helps visualize the incremental increase in the level of risk based on the various levels of impact and likelihood.

If we were to perform the calculation for our example, where we determined the impact of the event to be a score of "5" and the likelihood of the event to be a score of "5," how would we do that? Yes – it's as simple as multiplying "5" by "5," in order to arrive at a risk score of "25."

Okay, but now what do we do? Is that level of risk okay? Is it unacceptable? Let's look into the next steps.

Risk appetite, risk treatment, and risk acceptance

It's up to your organization's stakeholders to determine the acceptable level of risk, which is also referred to as the organization's risk appetite.

Obviously, we are going to want to appropriately define our impact and likelihood to reflect the risk appetite of the organization. If a risk is determined to have the highest score possible, as with our example, but the stakeholders don't seem to mind, this means that their definitions of impact and likelihood aren't being reflected appropriately in our tables defining each.

One more thing we might notice in the risk matrix diagram is the dark black line that separates the risk scores above "7" from the others. This is the risk appetite or risk acceptance level being represented visually on the risk matrix. In this circumstance, the organization's stakeholders have decided that any risk with a risk score above "7" is considered unacceptable, and requires further risk treatment.

Risk treatment is the way we select controls to modify the risk level. We can "avoid," "reduce," "transfer," and "accept" risk. Let's take a look:

• Risk avoidance is achieved by removing the likelihood of the risk entirely, generally by not performing any of the actions that would lead to the risk.
• Risk reduction is performed by reducing either the impact or likelihood levels, generally through mitigating controls.
• Risk transfer is done by shifting all or part of the risk to a third party, through outsourcing and insurance, for example.
• Risk acceptance occurs once the organization acknowledges that a risk doesn't require further mitigation, or it is unfeasible to mitigate the risk further.

Mitigating controls are the methods by which we try to protect each asset from threats. They can include all kinds of methods and tools, but if we continue using the example of The Ketchup Company's ketchup recipe being accessible over the web, a form of risk reduction could be to implement a mitigating control that requires a password in order to access the secret recipe.

Once that mitigating control is implemented, your residual risk is the risk level after the mitigating control is applied, because the mitigating control has modified the risk by reducing the likelihood of the threat being able to access the recipe.

Once the residual risk has been reduced below the risk acceptance level, we can consider the residual risk level to be acceptable, and therefore we achieve risk acceptance.

Let's consider further vulnerabilities, such as the following:

• A flawed password entry page
• A weak password, "hunter2"
• A direct link to the recipe that doesn't require us to log in

We will need to calculate risk scores for each of these to understand the risk facing the organization. To document the various risks, we can create a risk register for the organization. By doing so, we will be building out the organization's ISMS. Doesn't that sound like the most fun you've ever had?

Like we said at the start of this section, we will delve deeper into how to go about structuring both an asset register and a risk register in Chapter 2, Protecting the Security of Assets. For now, it makes sense to move on and discuss another concept that is going to prove to be useful for the next chapter: the various legal regulations and compliance requirements facing an information security professional.

In information security, there are some red tape and regulatory structures that can be tricky to navigate, or stressful to be a part of. When we're considering compliance, in terms of regulatory and legal requirements, audits, questionnaires, and responsibilities, it might seem like an entirely different job all in itself. Oftentimes, organizations aren't going to have somebody who is focused entirely on those compliance structures, and as a result, you are going to need to feel comfortable in navigating, potentially more than anybody else in the organization.

I would like to discuss how these structures will be a part of your day-to-day responsibilities, and how we can leverage the predefined requirements to determine an acceptable level of risk for our organizations. Furthermore, before we conclude this section, I would like to highlight the importance of continual improvement as a requirement for compliance, and how this requirement enables optimization to be a key focus for you and your team.

Compliance structures

Something that we need to cover is the functionality of the information security team in terms of understanding the requirements for your organization's information security program. These could be from governmental authorities and legislation or certification bodies. For some standard examples, a huge share of organizations are responsible for being compliant with regulations and acts for privacy when it comes to processing the personal data of individuals. There are hundreds currently in place globally, and there will be even more by the time you are reading this book. For a few examples of privacy regulations, we can look at the following:

• The General Data Protection Regulation (EU) (EU GDPR)
• The Children's Online Privacy Protection Act (COPPA)
• The Health Insurance Portability and Accountability Act (HIPAA)
• The California Consumer Privacy Act (CCPA)

These acts and regulations are seen as legal obligations, and there can be huge financial and reputational repercussions for not complying with their requirements.

Most of the privacy regulations have a focus on transparency when it comes to processing Personally Identifiable Information (PII) or Protected Health Information (PHI). Some are focused on young people, while others are focused on people in specific jurisdictions, such as California, Brazil, or the EU. Most of them will require you to give your data subjects the ability to review and revoke access to any personal data that is being processed by your organization, as well as requiring your organization to be open about how and where the information is being processed, and by whom.

In addition to those governmental compliance requirements, there are standards that are offered by bodies such as the International Organization for Standardization (ISO), which aim to create a baseline of minimum viable levels of information security. These could include standards such as ISO 27001, which we've briefly mentioned already, which focuses on how to manage information security, or ISO 27018, which focuses on providing a code of practice for cloud privacy, and so on. Generally, organizations that comply with the requirements set forth in the standard are able to be audited by a third-party certification body, and certifications or accreditations can be earned for compliance with the requirements of that standard.

These certifications are highly valued by customers (both potential and existing) and partner companies, especially in the Business-to-Business (B2B) world, as a testament by a third party that the minimum baseline of security at the organization has been achieved. Many organizations that are selling their SaaS to other businesses, for example, will show that they hold a ISO 27001 certification from a certification body such as the British Standards Institute (BSI), Deloitte, or a similar consulting firm. The various standards have different purposes and suit different organizations.

In order to stay on top of all the requirements, it's highly valuable to use a structured solution to catalogue any and all the requirements at your organization, and quickly report on the current compliance of your environment. Changes to these regulations can occur on a daily basis, and depending on your organization, this could mean that keeping up to date requires a team of people to be distributed globally, working full time and translating legal requirements to a singular compliance requirements matrix, which is then internally audited by the organization. At the time of writing, there are over 200 updates per day from 750 regulatory bodies.

There are many software solutions that are currently offered by various suppliers. Essentially, what they do is simplify your compliance management process by providing automated and continuous assessment scans through your environment(s) to monitor your data protection controls, as well as giving you the functionality to assign tasks and record progress against each requirement. The tools may give you recommended actions and instructions for how to implement controls that improve your compliance posture, and map your existing controls to any new requirements in the evolving compliance landscape. Large organizations are continually being exposed to compliance risk, which could spell millions of dollars/euros/pounds per year being lost, so paying for a tool such as this makes sense for many businesses.

Understanding legal and regulatory requirements

A lot of the requirements in regulations or standards are not exactly the type of thing a software solution is even able to automatically track. How could a software solution know if you, for example, turn off access to all accounts and services during the exit interview of an employee that is leaving the company? Keeping on top of how your organization actually manages the various compliance requirements often requires working with every team in your organization. Yes, this does include legal and HR teams, and will include doing internal audits to ensure your organization does what it says and says what it does.

All these controls are relevant to your information security program and should be documented and reviewed with updates on a regular basis. When I say on a regular basis, you can take that however you want, but keep in mind what the compliance requirements are for your organization. Some standards require proof of annual review and updates to policies and controls, for example.

So, imagine that the employees at The Ketchup Company are on a bit of a hot streak, and they have managed to move what turned out to be a huge amount of PII into the cloud. Some of the data subjects are EU citizens, while others are based in California, and as a result the lead-up to this migration has included determining the following:

• The type of processing and storage that was being done
• The reasons for this processing and storage
• The basis for which they were legally allowed to process and store the data
• Updates to privacy policies and documentation
• Notifying the data subjects regarding the change

Most of the data subjects were probably surprised that their favorite ketchup company held data on them, but in this data-driven society, it would be irresponsible for The Ketchup Company to not understand their customers.

A few of the data subjects decided they didn't want their data being stored by The Ketchup Company and filed a subject access request (to which The Ketchup Company complied with in the permitted timeframe), as well as a data deletion request for their data (to which, again, they complied with in the permitted timeframe). It sounds like The Ketchup Company has their privacy compliance requirements running smoothly and efficiently!

Compliance isn't all about privacy or certifications to standards, however. As we mentioned previously, there are many different types of requirements from acts and regulations globally, such as the Sarbanes-Oxley Act (SOX), which requires companies to retain their financial records for up to 7 years, or the Federal Information Security Modernization Act (FISMA), which mandates all federal agencies to develop protection methods for their information systems. Understanding how the various frameworks, standards, regulations, and laws apply to your organization is an important task for the information security team at your organization, in order to avoid fines and penalties, as well as to provide a good baseline for protection against information security risk.

Responding to and undertaking investigations

Even if you're part of a simple organization with very few employees, there is still a chance that events will either occur on your estate (or in a way that is related to your estate) that require further investigation by yourself, somebody in your organization, or by another organization. This could include anything from finding out who deleted a file from a shared drive to a legal investigation on insider trading, or handing over server logs to law enforcement for them to perform forensics. It is your responsibility as not only an employee, but also as a law-abiding citizen, to comply with these requests to the extent in which you are legally obligated. The last thing you want is to be found obstructing an investigation; it's just simply not worth it.

Many solutions exist so that you can comply with these types of requests, including actions such as placing legal holds on email inboxes to "freeze" activity, or storing snapshots, or ensuring that items such as emails or files aren't actually "deleted" when an employee deletes them. Organizations have more control than ever before, with the help of software and information systems, to ensure that their employees are abiding by the both the law and the protocols devised by the senior managers in the company's defined policies.

When it comes to internal investigations on unauthorized access, or some sort of integrity issue, sometimes, it might be important to ensure that those aiding your investigation aren't able to find out who and what is being investigated. It sounds extremely tricky, but again, there are tools that provide pseudonymization, which gives us a way to track the activity of users by assigning aliases. This prevents investigator bias or collusion with the subject.

Another interesting legal aspect of the information security compliance domain is that of eDiscovery, or electronic discovery. eDiscovery is a way to identify and deliver information that can be used as legal evidence. By leveraging eDiscovery tools, you can find content in mailboxes, shared groups, Teams/Slack/Skype chats, shared drives, and device hard drives. You can finely filter your search results in order to identify and hold and share the results with the parties required, but not extra data that isn't relevant to the investigation. It reduces costs, time, and complexity to use eDiscovery tools during these events. If you are aiding in this process, you will be working with people who make it their business to be great at this work, and providing your knowledge of your estate and its structure is likely going to be your responsibility.

Further compliance optimization

Remember, a huge part of most information security standards is the principle of continuous improvement. We have a long way to go in order to make operating in a digital environment secure, and optimization needs to occur constantly! We need to put ourselves into an engineer's state of mind and see the world through those critical eyes. Throughout the rest of this book, I'm going to be reminding you of the requirements for continuous improvement, as well as give you examples to apply to your estate.

For a quick example, let's go back to our example organization, The Ketchup Company. Imagine you (as the information security manager) run through an incident response playbook for restoring from a backup in the event that an on-premises server for running a few applications has a hard drive failure. During the simulation, you notice that the spare hard drives that you have stored for this event will be at 90% capacity once the data is restored from backup. You also note that a better state of redundancy than RAID-0 would have prevented this from happening in the first place.

First, you take a look at your risk register, and you notice that you overlooked this previously. You add the details of the risk to the register, and perform a risk assessment to calculate the risk score determined from the impact and likelihood scores, and find that the level of risk is above the formally defined risk acceptance level for The Ketchup Company.

After going through some discussions with team members, as well as giving it some individual thought, you decide that at the moment, with the budget you have available, you can buy some hard drives and set up some redundancy as a mitigation tactic. You make a support ticket to purchase enough hard drives to quadruple the capacity, create another one to add them to the server, and then increase the redundancy to RAID-1. Is it the perfect solution? No; it's an incremental optimization that reduces the risk of downtime on your server and allows your staff to focus on important things for the future, rather than fighting fires in the present.

Are you done? Of course not. From that optimization activity, you now have some updates for your asset register and risk register, as well as some further investigation for other servers and systems. If you find that one of your servers was running RAID-0, is that likely to be isolated to just that single server? Or are you going to lift the curtain and find that The Ketchup Company has absolutely no redundancy in any of its servers and backups, and now there's a high-priority IT operation required to prevent a catastrophic failure? It's going to be somewhere in-between those two extremes, most likely… but the investigation and findings lead to a project for your organization that can be broken down into small, achievable goals that amass together to form a sum greater than its individual parts. An optimized solution is something you can get funding for by presenting the level of risk facing the organization if the vulnerability is level unmitigated.

Once the project is completed, you perform another risk assessment to see if that new optimized level of redundancy mitigates the risk of data loss to an acceptable level, record your results, and present the results of the project and the economic impact of the improvements to the relevant stakeholders. It sounds like you're using ideologies from risk management and continually improving your organization's risk posture – nice work!

In this section, we're going to cover some proven methodologies that ensure a high level of success for creating an information security strategy. We'll discuss creating information security policies, procedures, and playbooks, as well as establishing and maintaining a security awareness program, managing third-party risk as a responsibility for any information security professional, and reporting and continual improvement as a focus for highlighting the progress that's been made, which is something an information security professional must consider in an era of growing cyberattacks and increased reliance on digitalization. With these topics in mind, you are setting yourself up for success, with the opportunity to improve and cater the strategy to any long-term goals or changes to the landscape. Let's begin by talking about creating an ISMS.

Creating InfoSec policies, procedures, and playbooks 

Information security policies, standards, baselines, guidelines, procedures, and playbooks are the backbone of any information security strategy. We have already established that point in this chapter. With that said, how do you make those? How can an individual person manage to create all these documents, full of terms, guidance, and policies for an organization such as The Ketchup Company?

Creating an ISMS is an important undertaking for you and your organization to have the appropriate level of visibility into its information security risk. I am going to cover the process of creating an ISMS further in Chapter 2, Protecting the Security of Assets.

Until then, keep in mind that the key to finishing a marathon, a hill climb, or any other metaphor for the daily slog of your job is the same: you begin by taking a single step. Taking each hour at a time, and plugging away at creating a structure suitable to your organization, is going to ensure better visibility and fewer unknowns. When you encounter information security-related topics in your day-to-day conversations and experiences at work, write them down and keep notes. Notice what people say, do, and what happens most often, and use that information to help in your ISMS project.

Establishing and maintaining a security awareness, education, and training program

The information security policies need to be understood by all the members of the organization. The requirements need to be established immediately to any new member, and regular reminders need to be provided afterward. Furthermore, keep in mind that you will need to train key staff members on the entire information security program, and other staff members on key points that cater to their jobs. You want to make sure the organization isn't relying on you (and only you) in the event of any outage. You do want to be able to take a holiday, don't you? Beyond that, you want the business to be able to react even after you're long gone, and you want staff members to be aware of their responsibilities when it comes to various information security topics and scenarios.

As a result of that, you are going to want to create training materials to ensure the members of your organization are educated and trained on their requirements from an InfoSec perspective. With new members, depending on the nature of your organization and its size, you might set aside a few hours to introduce yourself and talk about the information security policies of the organization, or you might need to formalize the process a bit more into documents or training videos in order to scale. Generally, new members of an organization will sign an agreement to uphold the policies and practices that have been covered, and that agreement is kept on record and updated annually.

Many people in this industry say that employees are the biggest vulnerability to your organization, and imply that it's the fault of the employee if they are tricked by a phishing scam, for example. To that, I say, "How can we blame the victim?" Let's look at a few questions we might want to ask:

• Was there adequate training in place?
• Were there phishing simulations conducted to identify the at-risk employees?
• In their day-to-day work, was there a secure method of performing their tasks available to them?

It is likely that the information security team's responsibility is to ensure the members of the organization are educated on the threats they face. There are so many effective ways to turn a person who would have originally been a liability into a champion for your security strategy, just by showing them how interesting the field is, and by providing incentivization. This is the value of creating engaging and interesting training materials, and this idea should never be neglected in your overall information security strategy.

Managing third-party risk 

To be perfectly honest, the cloud is the way things are headed. Newsflash, right? Even the slowest, most risk-averse businesses are heading to the cloud. Banks are moving to the cloud! Governments are moving to the cloud! You name it. From Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure for hosting, to Office 365 and G Suite for documents, to millions of different SaaS products for project management, source code repositories, accounting software, HR management, data loss prevention, SIEM, and the list goes on and on, the solutions that are being offered to manage information in the modern era are increasingly shifting toward the Shared Responsibility model, and part of the risk your organization faces becomes a third-party responsibility to mitigate. How does that third-party cloud accounting software secure their estate? Do they make that information available? Just because you're not hosting the software on your own servers doesn't mean you are relinquished from all responsibilities when it comes to security, compliance, due diligence, and risk reduction. Your organization's data is being processed by assets under the third-party's control, but it's still important to consider as part of your responsibility.

Utilizing various Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS) solutions presents new requirements: crossing international borders with PII is now potentially breaking the law. A third party storing your organization's data in plaintext could be catastrophic in the event of an insider threat viewing that information. Running your platform on a third-party server that, unbeknownst to you, is unpatched and vulnerable to exploits that are readily available on the web? There's another risk to your organization's success. How can you possibly mitigate this? Isn't it the responsibility of the cloud service provider (CSP) to update their systems or encrypt your data? Not unless they have agreed to such, most likely. How can you ensure an organization says what it does and does what it says?

First of all, you'll be happiest when you have legally binding Service-Level Agreements (SLAs). SLAs are a promise from a third party that they will keep their service to a certain standard of availability, confidentiality, and integrity, among other things. As an example, often, a cloud IaaS SLA might deem that in the event of an outage that causes availability to drop below 99.9% (or 99.99%, or 99.999%) for the month or year, the third-party will reduce the costs to their client. This is sometimes referred to as "three nines," "four nines," and so on. It's a way for your organization to mitigate availability risk by offsetting the monetary loss experienced from that loss of availability. In a way, your SLA is a legally binding control that you are able to report on and ensure is effective. SLAs are negotiable in the sales process and can sometimes go back and forth between the client and supplier multiple times, with redlining and pushing back from either side before an agreement is made. If you work at a CSP, you might find yourself as the information security professional who's responsible for negotiating the SLAs on the other side as well.

In addition to SLAs, you could use what is known as a Vendor Security Assessment Questionnaire (VSAQ), which is able to be completed by any current vendors or prospective vendors. What these VSAQs do is ask a standard set of questions for due diligence purposes and record-keeping. The response to these questionnaires should be considered during the procurement phase, with risk as the backbone of that analysis. Generally, a VSAQ will go over the security program of the vendor, any controls they have put into place for protecting their estate, the training and awareness that the employees undertake, and the types of audits (along with the audit results) that the vendor regularly undergoes. VSAQs are a way to get an account on record from the person in charge of information security at the company you're paying to process or store your organization's confidential data, business processes, and PII or PHI.

It is your obligation to show that due diligence and due care has been put into each and every decision for outsourcing data processing and storage to a third party. In the event of a breach at the third party's estate, you want to be able to show that you made an informed decision based on the testimony of the third party's questionnaire answers. If they don't treat a specific threat the way you would like, make a note of it, and potentially even discuss the matter with their information security team. You might find out that further improvements are actually on the roadmap.

Don't worry about being a pain when discussing SLAs or VSAQs. Any vendor worth your time has had to answer similar questions and negotiate similar terms with other organizations, and might even have those answers prepared. If you're working at a CSP and are responsible for answering these VSAQs yourself, then you would be very right in cataloguing your responses to those questionnaires, along with creating a VSAQ FAQ. It will save you countless painful hours of repetitive work. In previous roles at SaaS vendors, I've had a privacy and security whitepaper prepared, which answered every question asked in the VSAQs, with drawings and technical details provided, which I would then initially pass to each prospective customer for them to look through and fill their own questionnaires out. It was very helpful in the months leading up to GDPR's effective "start date," where a thousand customers were scrambling to prove due-diligence and due care by crafting their own version of a VSAQ and sending it out to all their suppliers.

Google's VSAQ web app (https://opensource.google/projects/vsaq) allows a vendor to either complete their answers via the app or load their answers from a file, and then submit their responses to standard VSAQ questions. Unfortunately, I haven't seen nearly enough vendors or customers using this format. It would save so much time to just standardize and create the "gold standard" VSAQ and let us all get on with making our organizations more secure. Another type of questionnaire is the Cloud Security Alliance Consensus Assessments Initiative Questionnaire (CAIQ), available at https://cloudsecurityalliance.org/artifacts/consensus-assessments-initiative-questionnaire-v3-1/.

Keeping this information in your ISMS is important in the event of a third-party breach. As we mentioned previously, you want to be able to show an appropriate level of due care. If you can show that the risk has been measured and deemed acceptable, it could help show that you weren't being negligent. It may seem redundant, but regulators and stakeholders will want to know the details that led to a decision, because they may have to answer to board members, stakeholders, customers, regulators, law enforcement, or governmental entities on the matter.

Continual improvement and reporting

Another important thing to remember is the ideology of continual improvement. New exploits become available, new techniques surface, and systems change constantly. As new vulnerabilities are discovered, and as new threats arise, all of the implemented structures and controls for reducing information security risk at your organization need to get better. It's important to keep up to date with what is happening from a threat and vulnerability point of view, as well as ensuring your asset and risk registers are up to date.

If any of the organization's controls fail or can be circumvented, where does that leave you? If the answer is "wide open," then you don't have a sufficient amount of defense-in-depth. It's an important concept to grasp: double-locking. Adequate defense-in-depth might not reduce risk, but instead allows for a control to fail and you to still have a reduced residual risk.

In addition to defense-in-depth, looking at the world through an engineer's lens is highly beneficial to an information security professional. You can improve processes and systems to make things more lightweight, faster, automated, effective, scalable, accessible, and less expensive with fewer errors. Reducing the costs of one control allows you to build more defense-in-depth and reduces complexity, which is the enemy of security.

In order to chart your progress, you could keep legacy versions of your risk register, potentially by financial quarters, or halves, or years. It will give you a great dataset for the impact you've made at your organization, and will help you justify that pay rise they've been hanging over your head for the past year. Make graphics, put them into PowerPoint presentations, and regularly update your stakeholders at your organization with the progress, wins, and blockers. Depending on your organization, and if you're sitting in the top information security role, you could include the CIO, CTO, CFO, and potentially even CEO in these conversations. Also, the legal and HR departments will have an interest in the topic of insider threats, legal obligations, and other compliance requirements. Don't waste their time, and make sure to keep things non-technical and high-level, catered for C-levels who only care about the bottom line: "How much does this cost, and how much does this save?" You can show your program's return on investment by utilizing risk reporting.

Sometimes, you'll find some really interested stakeholders in these meetings, who are impressed with the findings. Other times, you'll find some people who don't really care, and are just there because they have to be. Make sure to give all your audience members a reason to care. The CFO is going to care about different things than the CTO, but they both have their own reasons for wanting to keep the lights on and the money coming in.

This chapter has gone over the major topics that heavily influence decisions made by information security professionals: risk management and governance structures. When I introduced this, I said that it probably didn't sound like a barnburner, full of thrills and excitement, but I'm sure now that you're reading this summary, your view on the matter has changed slightly. I would say that with a bit of practice in mastering the basics found in this chapter, my promise to you that you will be a highly effective, well-oiled risk management machine in no time will come true.

In the next chapter, we'll be looking at protecting the security of assets, which is now a much more achievable task. You have an understanding of various core concepts, and we're going to proceed toward leveraging everything we have covered in this first chapter to create a more mature ISMS, as well as develop your skills further by focusing on effective processes to ensure you can identify and protect your organization's assets throughout their life cycle, avoiding some common pitfalls that information security professionals often run into.

Let's do this!