Managing and Organizing Security

🚀 As explained by Laura

Welcome to the Stage of Organized Security

Like with most parts of your business, the time has come to get organized. You are probably already familiar with the benefits of increasing organization as you scale, but in case you need a recap:

• Spot mistakes and issues faster. The more consistent and organized you are, the easier it is to spot when things are going wrong and adapt quickly—minimizing the impact.

• Work as a team. Moving things from ad-hoc to managed processes enables you to engage the wider team and share the load—freeing you up to be the leader you need to be at this stage (or to take a holiday or a sick day).

• Simplify communication. Managed processes make communicating your practices to stakeholders such as customers, compliance regimes, and shareholders easier and more consistent, saving both time and ambiguity.

At this stage, this process of formalization is probably happening throughout your organization. Other areas of your business that often require a more strategic and considered approach as you grow include hiring and team management, health and safety, and sales and marketing. Security is no different.

​Definition​ Before you panic and think this means jumping straight into the realms of compliance regimes, audit programs, and the mother of all spreadsheets—take a breath. Organization just means having a system and a plan, not necessarily having the same system or plan as many enterprise organizations would need. We call defining and implementing this process security management. The trick here, like most parts of this book, is to find the right amount and right kinds of security management for your company and iterate on this as you continue to grow.

Risk as the Foundation of Security Management

The first rule of security management is that you can’t address all of the security vulnerabilities your organization is exposed to. As mentioned in in the introduction, these are called risks.

​Definition​ The process of identifying, measuring, and prioritizing our approach to these issues is called risk management and is the mechanism we use to decide what to deal with and what to record.

Before you are ready to build your security management system, you need to:

• define how you will measure and calculate risk

• create a mechanism for recording, communicating, and reviewing risks.

Let’s take a look at these in more detail.

Calculating Risk

Thankfully, we don’t all have to be trained actuaries to calculate security risks. While the actuarial field is a well-established practice for calculating the risk of just about anything, and it’s used around the world in insurance companies and the wider financial sector, in security we have less sophisticated approaches.

While this might sound negative, don’t be put off by it. By simplifying the risk calculation process, we are able to demystify it and share it with our wider team. We don’t need a chartered accountant in a dark room with a book of formulas, we just need a repeatable system we can all understand and that we can apply whenever and wherever we need it.

We calculate risk by considering a vulnerability in the context of its likelihood and its impact on us. This crude calculation allows us to identify the risk as high (important) or low (not important):

Thinking About Risk Likelihood

Likelihood in this context is the probability or chance that someone or something will expose or exploit this weakness.

For example, if only two keys exist for a lock, the likelihood of someone breaking into that lock with one of those keys can be determined by examining:

• Who has access to the keys?

• Where are the keys stored?

• How hard is it to bypass these protections?

• Who else knows this lock exists (and these keys)?

• Are we certain there are no more keys?

• Where is the lock located and how is it protected?

The answers to each of these questions (and the many we will have missed) affect the likelihood of the risk being exploited.

If something is easy to find, easy to access, and unsecured or otherwise uncontrolled, the likelihood is probably high. If something is hard to find, requires specialist tools and knowledge, and can only be accessed in a specific set of circumstances, then the likelihood is probably much lower.

To calculate the likelihood of a risk for your organization, first you need to articulate the factors that will affect the probability, much like we have in the example above. Then use those criteria to place it on a scale of 1 to 10, from easy to find (most likely to be exploited) to hard to find (least likely to be exploited).

Risk Impact: Confidentiality, Integrity, and Availability

Impact is how we measure the effect of exploiting a flaw in our security. It helps us understand what will happen; what systems, processes, and people are involved; and the effect this exploitation may have on our wider organization.

In security, we often start examining impact by looking at the effect on the confidentiality, integrity, and availability of operations, systems, or services. These effects can be on a system-by-system level or on an organization-wide level.

Let’s get familiar with each of these impacts.

Confidentiality

​Definition​ Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes.*

​Definition​ A confidentiality agreement is a system of rules controlling who is authorized to access or interact with our data or systems.

Imagine you’re in an office; we’re going to explore the difference between an implicit and an explicit confidentiality requirement.

A colleague wants to share something confidential with you. They whisper their secret to you. Now, what do you do at this point? How long do you keep it secret for? Who are you allowed to tell? Who are you not allowed to tell? Navigating this is called an implicit confidentiality agreement.

So what would you do? Who can you tell the secret to? How long do you need to keep this information secret for? And in what circumstances can you share it with other people?

Some of you will decide that, well, it’s a secret, so it’s confidential and you will keep it this way forever. Nobody needs to know that you ever knew this information. Some of you will listen to the noise in the office, and if it feels like other people are already talking about it, then you’ll start to loosen up your controls on your confidentiality. Some of you won’t share it at all in the office, but might go home and tell a loved one what you’ve heard.

​Definition​ An implicit confidentiality agreement, like the one in our scenario, is when we have expected or assumed rules. They are dynamically assessed by people and they vary from person to person. So in our office environment, this is how we end up with gossip that everyone knows, but everyone pretends that it’s a secret.

​Definition​ In security, we prefer explicit confidentiality agreements. These are objective statements or rules that are defined or documented and can often be checked programmatically. It’s yes or no, good or bad, pass or fail.

Aim to make explicit confidentiality rules for your organization so that you can measure the impact of incidents and actions.

Integrity

Integrity is interesting. We’re used to talking about integrity when it comes to people. For example, this person has really good integrity. I can trust them. Their character is good. However, that’s not the sort of integrity we’re talking about here. We’re talking about the integrity of the data in our systems and whether it can be trusted.

​Definition​ Integrity (or data integrity) in a system refers to maintaining the accuracy and completeness of data over its entire lifecycle. Integrity requires protection of system data from intentional or accidental unauthorized changes.

The clearest example of systems that require good integrity are banks. For example, if we have some incorrect data and that gets into the database controlling our interest rates, that interest rate can then affect our home loans, our credit cards, or our savings. An incorrect interest rate affects whether people are earning more or less money on the pennies that they’ve squirreled away for a rainy day.

It’s very important that we understand the integrity of our systems because of the significant impact of compromises to data integrity. We don’t want to have to undo our decisions later, as that’s very expensive for our organizations.

Availability

​Definition​ Availability in our systems means ensuring that the systems remain open for business as and when they are required to be, and that they remain accessible for all users.

Even as late as 15 years ago, availability in many of our systems revolved around standard operating hours for a business, such as 9 a.m. to 5 p.m. in office environments.

We now live in a time where availability is expected to be far broader than this, with many online operations having customer service 24/7 or at times they would never expect to see physical traffic from a person.

Security is about balance. It cannot come at the cost of availability.

Availability is incredibly valuable to our organizations. This means we can’t simply put in a security control to improve the safety of our data and our systems if it means the systems cannot be accessed anymore. A secure system allows people to use it 24 hours a day, seven days a week if that’s what they need, and it allows them to do what they need to do safely and securely. And that’s a difficult balance to achieve indeed.

Risk Impact: Understanding the Cost

While confidentiality, integrity, and availability are all important parts of how we examine the impact of a security event or risk, there is one last step we need to take. We need to translate these systems, or process-level impacts, into the overall effect that this event will have on our organization, data, or customers. This is a less technical, more business-focused assessment that is often used to communicate risk to senior leaders and directors. You should consider the following factors.

• Loss of revenue. Your organization makes less money.

• Increased operating costs. It costs more to keep your business operating than it did before, which will impact its decisions about hiring and buying new things.

• Reputational damage. People trust your organization less, so they might not sign on or may churn, or they might give your business a different risk rating or change their behavior with you.

• Increased legal and audit obligations and costs. Governments and regulators often increase controls when organizations have repeated security vulnerabilities.

• Harm to health or loss of life. People are hurt or killed.

Be honest when you look at this list of impacts. For most of us, if the company makes a loss or less money, we don’t want this to happen long term, but we’re probably still going to sleep at night.

However, if the result or the impact of a security vulnerability was loss of life or harm to human health, we might be more worried. Whatever context you’re in, you need to understand and make sure you’re focusing on the right impact.

Understanding impact is essential to calculating risk and communicating why it is important that we act. The better you can understand the impact that it would have on your organization, the easier it will be to communicate to the team why you need to act and what you need to do. If you can communicate this well, they will be able to support you with budget, team members, or any other resources you might need.

Risk Criticality

​Definition​ Once we have assessed the likelihood and impact of our risk, the result is known as the criticality. This is often a numerical value or label that we give to a risk that communicates how serious it is and how quickly we need to act.

While the exact terminology and labels may vary between companies, the general principle is captured in this diagram.

Figure: A commonly used set of labels for risk criticality.

Criticality is a scale ranging from critical to informational. Each stage of this scale has a set of criteria such as how many customers are affected, how much money would be lost, how long would the issue take to resolve, and how many systems would be at risk.

The higher the criticality in your risk assessment, the more urgent the need to act. As you drop down the levels, the urgency decreases and you may be able to address risks as part of normal prioritized processes.

​important​ Define your own criticality levels before you need them. It is important to define your organization’s definitions for these levels in advance. By defining them in advance (when you aren’t dealing with an issue or incident), you can calmly discuss their values with the wider team. The last thing you want to spend time on during a security event is defining your criteria for assessing risk!

Risk Is Not Static

Much like your business is rapidly changing, the world in which it operates is changing too. In fact, all of the elements that you used to calculate your risk will change. We should consider a risk calculation to be correct for a particular moment in time, rather than something final that will remain unchanged forever.

Many factors can cause risk to change. Try to find ways to identify these changes and how they might affect risk for your company.

• Increased brand awareness and publicity. For those of us who are building product- or marketing-led businesses, this is the security curse of our approach. The more well known we become, the more at risk we are. Simply put, attackers have to know you exist before they will try to cause you harm. You may find your success leads to increased security pressure and risk.

• Using a very well-known or popular technology. Remember that our attackers can sometimes favor the easiest route. They will often spend time finding vulnerabilities in popular technologies so that they can potentially attack more targets. If you are using a very popular technology or framework, such as WordPress, this could lead to increased risk.

• Global events, politics, and pandemics. From political unrest to pandemics, many global events impact how our people feel and change the way they interact with others. In some cases, these events may stir up unrest or potential for attack, particularly if your business could be seen as being on the “wrong side” of current events.

Whatever is going on around your organization, keep a close eye on how those events may impact your security risk. You may need to reassess and take further action.

As well as updating your risks when the world changes, you may choose to hold regular review sessions to review the risks you have listed and see if any changes are needed. Typically this would happen every six months.

Keeping a Record of Your Risk

You have a great memory, you have made a successful company from your plucky spirit and ability to juggle many complex tasks at once … resisting the formalization and documentation of things like risks is a natural urge. After all, you haven’t been hacked yet, so why change?

Recording (or making a written record of) risks shouldn’t be a laborious process. It’s not about killing the joy and culture of your team, and it’s certainly not about slowing down or being more wary of the world. Recording risks is simply a mechanism for making consistent decisions about how you will approach a challenge, sharing that decision with those who need to be aware of it, and remembering that decision so that if times or circumstances change, it can be revisited and allow us to ensure it remains the right course of action.

​Definition​ We call this documented record of risk decisions a risk register.

Creating a Risk Register

Like most things in the world of process, creating a risk register can be as simple or complex as you make it. The important part is the calculation and recording of risk decisions, not which fancy tool you have used to store this information.

Whether it’s a spreadsheet or a Trello board, a custom-built database or an off-the-shelf risk management system, there is no right or wrong tool. In fact, the right tool is the one you have at hand and remember to use.

Let’s take a look at the key items you need to record and why they are important.

Example: An Entry in the Risk Register

Creating a Risk Review Process

So you’ve created a wonderfully detailed risk register! Congratulations, auditors everywhere will rejoice. Just kidding.

​important​ Creating your register is a great first step, but risk registers are living and evolving records. Just as your business, its operations, and operating environment change over time, so do the risks and their impacts.

Risks must be reviewed regularly to ensure that the assessment remains valid and to ensure the company is made aware if any changes are needed to their mitigations or controls.

When you are setting up your risk review process, here are some things to consider:

• Choose the frequency. You need to review your risks regularly. This frequency will depend on the sensitivity, frequency of change, and environment your organization operates in. Quarterly is a good starting point.

• Consult with the right people. Make sure you have senior representatives from key areas involved in the review. If the risk is specific to a project, keep this list of people related. If the risk involves the wider organization, ensure that the executive team is involved in the review.

• Record your review. It’s important to update your risk register every time you identify a change. These notes will help to track the evolution of risks and when decisions regarding them are made.

• Be prepared to do ad hoc reviews. Sometimes circumstances will change so suddenly and dramatically that we need to break from our review schedule and carry out an ad hoc review. Don’t be afraid to do this if you believe you need to. It’s better to review and find out it wasn’t serious after all, rather than to wait too long and miss your chance to take action.

Common Challenges with Risk Registers

At a high level, many people would agree that risk registers are simple documents that are fairly easy to understand and manage. After all, we are used to the idea of tracking issues with our systems or tracking items on our to-do list, and this is just another thing for us to record and manage.

While this is indeed true, there are a number of areas that trip people up when they are managing their risk registers.

• Keeping them up to date. As we have covered on many occasions, your brain doesn’t like boring, repetitive tasks. Remembering to check and review your risk register is unlikely to excite it. However hard it might be, keeping them up to date and regularly reviewing them is essential. Risk changes as your business and its operating environment changes, this change can impact the severity of the issue and how it could affect your organization.

• Reducing fear. Once upon a time, a security manager for a high-growth company was approached by the executive team about a risk register they had recently submitted. The manager was distraught, as they had worked hard on the document and thought it was pretty good, despite the high number of issues they had identified. The executive team had one comment: “Can you make it less … red?”

  You see, for the executive team, the color red was so alarming that it shut down conversations and triggered fear responses in the discussions.

  Whether it’s the fonts you use, the color code you implement, or the language you use, everything you do to communicate risk needs to be right. Too alarmist and you may cause people to shut down and disconnect, not strong enough and they may miss the important messages.

• Choosing who to share it with. In younger, smaller companies, there is often a high level of transparency. Most documents are available to anyone who looks, and there is a high level of trust to support this. As you grow, however, this changes. You can introduce risk by sharing your risk register too widely in the organization. (Oh, the painful irony.)

  In the wrong hands, risk registers can be misinterpreted, over shared (perhaps outside the company), or used naively to impact projects and operational systems.

  As you grow, it’s important to make sharing documents like your risk register conscious and consistent. Use the policies we talked about earlier to define and guide this.

Communicating Risk to Leadership

While you may handle the day-to-day responsibilities of managing security in your organization, your executive and board members hold the accountability and overall responsibility for them, and all other sorts of risks faced by the business.

This role is well defined by both national and international directors’ institutes and is governed by law in most countries. In fact, a director’s responsibility is so well defined and important that many organizations take out specific insurance to cover this risk.

​important​ It is this legal responsibility that makes choosing when and how you communicate security risks with your board of directors and executive teams incredibly important. Once a director has been informed of a risk, they must take actions to either mitigate, reduce, or otherwise eliminate it. It’s not optional, it’s their legal obligation to do so.

How to Create a Security Board Update

Let’s say that you found that one of your live production systems is using a third-party library with a known critical vulnerability.

When communicating with your development leads and team to get it addressed, you may provide a technical brief on the issue and a proposed solution. This issue will get recorded on the backlog and will be prioritized along with the other issues and tickets of a similar priority.

What would be different about communicating this to the executive team and board?

In this case, the executive team is less concerned about the technical brief that you would give the development team. They want to understand:

• What is the issue?

• What is the risk associated with this issue?

• How long has this been an issue and how long have we known about it?

• What are the impacts of this issue?

• Is this a notifiable event (an event that is serious enough that it needs to be disclosed to the public/market/shareholders)?

• What steps have been taken to address this issue?

• When will it be resolved?

Please understand, while some of these seem like the same level of detail you would give to your development team, they are not the same.

The focus in these answers is to be concise, objective, and fact based. Remember, your board members are non-technical and focused on the risk to the organization. They are taking a much higher-level view than your implementation team.

You should also remember that anything formally reported to the board is recorded as part of the board records. These records are then visible to shareholders and stakeholders at certain times of the company’s life and may be analyzed by potential investors and acquirers. This is not the place for careless words that will trigger questions later.