Federated Cyber Risk™

In most organizations, cyber risk is managed by a central team, one system at a time.

But what do you do when that arithmetic fails?

A university, a state government or a health system can have thousands of systems, programs and vendors, run by hundreds of teams the security office does not manage. A central team that works carefully might cover a few hundred of them. The rest carry risk that nobody has assessed.

The usual answer is a questionnaire sent to every unit every few years. Many come back late, generic or not at all, and the security office has neither the context nor the hours to act on the ones that do. The program narrows to the risks that are already known.

In FCR, a resource team assesses its own resource, decides whether the risk is acceptable, and builds its security plan on that. The security office stops being the place where every decision queues up. Its job becomes building the programs, standards and guidance that make those decisions sound, and watching the results across the whole organization.

Read “What Federated Cyber Risk Is”

FCR covers the administrative work of a cyber risk program for the resources an organization runs itself. Each practice is federated the same way: the team that knows the resource does the work, inside standards the security office sets.

The first two are done together, and that is what makes a plan risk-informed.

A resource is anything a team is responsible for protecting. It is often a system, and it can also be a program or a process, where most of the risk lies with people.

All four practices draw on one record: the control inventory a team keeps for each resource.

1. Form the team

   A resource team is the people responsible for a resource: its owner, someone who leads the risk work, and the people who know the details.

2. Describe the resource

   The team records what the resource is, what it holds, and which kinds of harm would matter most.

3. Document the controls

   The team records the controls it has in place, once. The inventory carries forward from year to year and is updated when something changes.

4. Review the risks

   Gaps in the inventory are matched to the threats that exploit them and the harm that could follow. The team sees its risks in order of importance.

5. Decide and plan

   The team chooses what to fix, what to compensate for and what to accept. The security plan records those decisions: the controls in place and the ones planned.

6. Keep it current

   The work is continuous. A plan is revised when the resource changes, not when an assessment cycle comes round.

Because the inventory is kept once, it can be read many ways: as a list of risks, as a security plan, as a position against any baseline, and as a record of remediation.

Everything else is read from the inventory, so it has to be something the people who run a resource can fill in truthfully. FCR makes that possible for people with no security training.

Questions a non-specialist can answer

Assessments are written for whoever on the team is responsible for the resource. They assume knowledge of the team's own processes and nothing more. Turning a control framework into those questions follows the same four steps each time:

1. Fit

   Decide whether each control applies in this context, in whole or in part.

2. Objectives

   Break each control into objectives. An objective is one thing a person could do, perform or complete.

3. Grouping

   Group objectives by how related they are, not by which control they came from, so that each group supports one question.

4. Language

   Write the question and its help text in the language of that context, just long enough for a non-specialist to answer with confidence.

What an answer means

• Yes. The objective is met, whether by the team's own configuration, by a shared service, or by a compensating control.
• No. The objective applies and is not met. That includes the case where the product cannot do it.
• Not applicable. The thing the control governs does not exist in this resource.

A missing capability is never a reason to mark something not applicable. The gap is compensated for, or accepted on the record.

Risk management comes first.

It tells a team which of its gaps matter most, and its security plan is built on that.

The team that owns a resource owns its risk. So that team assesses the risk and decides whether it is acceptable, including the decision to operate. The security office provides the method and the programs that help teams decide well.

What a risk is made of

FCR is concerned with administrative controls: the processes and practices that people carry out. A risk has three parts.

• A weakness. A control that is missing or only partly in place.
• A threat. Something that takes advantage of that weakness.
• An impact. The harm that follows.

Plain answers in, ranked risks out

A team is never asked to estimate a probability. It says what it has in place and which kinds of harm matter most to it. A clinic may care most about the confidentiality of patient records, and a finance office about the integrity of its transactions. The analysis is built into the framework the security team configures, and it weighs four things:

• how much protection the control provides when it is in place
• how active the threat is at present
• how severe the harm would be, given what the team said matters most
• how much of the control is already in place

The last one is what makes progress visible. A control is made up of objectives, and each objective a team meets lowers its exposure. A half-finished control counts for something.

A model that is kept current

The ratings behind the analysis are maintained centrally and revised as threats change. When they move, each team's risks are ranked again, and the team does not have to redo its work.

A security plan built on the team's own picture of its risk is a risk-informed plan.

It puts the effort where the risk is.

Risk management and security planning draw on the same inventory, and FCR has a team do them together. Risk management ranks the gaps and records what the team decides about each one. Security planning turns those decisions into a plan: the controls in place, the controls to be added, and the order to add them in.

What each loses without the other

• A plan with no risk picture works through a list of controls from the top and treats every gap as equal.
• A risk assessment with no plan is a list of concerns that changes nothing.

Doing them in one pass, on one record, closes that gap. The team that has just seen its risks in order is the team that decides what goes into the plan.

QuickPlans

A QuickPlan is a guided plan for a common situation, such as a team using an ordinary cloud application. A team can complete one in under an hour, where a plan built the traditional way took five people sixteen hours or more.

A plan built in an hour is not a shortcut. It records what is known now, including what is missing, and it grows from there. The larger risk is the plan that is never started.

Where the shared services and vendors a team relies on have already been documented, much of its plan arrives answered. That is one of the advanced topics.

A baseline is a framework or policy expressed as the controls it requires. Laid over a team's control inventory, it shows where that team stands against it. An organization can turn on as many baselines as it is held to, and the team documents its controls only once.

Compliance Checkups

A Compliance Checkup compares a team's inventory with a baseline whenever the team asks. It gives a team a safe way to work toward compliance. The result is a list of what remains, not a finding, and a team can run it as often as it likes.

The team that owns a gap plans and carries out the response. A gap has five honest outcomes:

• Fix it. Implement the control.
• Compensate for it. Put another control in place that offsets the gap.
• Accept it. Record the decision to carry the risk, and why.
• Transfer it. Perhaps to a vendor or insurance provider.
• Avoid it. Reconsider whether the business need that exposes the risk is worth it.

Remediation is planned and tracked, and its progress is visible to the security office. Reading that progress, for a team, a unit or the whole organization, belongs to Federated Practice Monitoring.

FCR measures two things and keeps them apart: how far the practice has reached, and how much risk remains where it has. Each has a score.

They are kept apart because the risk an organization has not looked at can hurt it more than the risk it knows about. Excellent plans for a tenth of the organization are not a good position.

Resource Coverage Maturity (RCM)

RCM shows how far the practice has reached. It runs from 0 to 1, and higher is better.

RCM = 1 − e^{−k(R + C + A)}

• R is the number of resources documented.
• C is the number of controls documented across those resources.
• A is the number of risk management activities carried out.
• k is a scaling factor, set for the size and complexity of the organization or team.

The curve is deliberate. The first steps count for the most, and each further step adds a little less as the practice nears full maturity.

Human-Enabled Administrative Risk (HEAR)

HEAR shows how much of the identified risk remains. Lower is better. It is built from the bottom up, starting with each resource:

HEAR_resource = sum of mitigated risk scores ÷ sum of unmitigated risk scores

An unmitigated score is what a risk would be with no controls. A mitigated score is what is left once the resource's controls are counted. The organization's score averages its resources and then takes coverage into account:

HEAR_organization = (sum of resource HEAR ÷ number of resources) × (1 − RCM)

Reading the two together

Neither score means much alone. High coverage with high risk, and low coverage with low risk, call for opposite responses. How to read the combinations, and what to do about each, is part of Federated Practice Monitoring.

Both scores are kept for each team and for the organization. Teams differ in size and in what they manage, so a team is best judged against its own earlier results, not against another team.

The work itself is familiar. What changes is who does each part.

The first three make up a resource team. With the routine work in the teams' hands, the security office has time to build programs that help them with the fixes.

FCR asks people outside the security office to take on work they may believe belongs to someone else. It is adopted in stages, and each stage earns the next.

1. Find out where you stand

   Ask people across the organization how they understand their own part in cyber risk, what they think is unprotected, and how much they can see. The answers show how ownership is understood today.

2. Start with early adopters

   Begin with a few units that want to take part. Choose ones that matter to the organization, can start without disruption, and look enough like the rest that what they learn will carry over.

3. Share what they achieve

   Results and the adopters' own words do more to bring in the next units than a mandate does.

4. Expand in waves

   Bring in more units in groups small enough for the security office to support, and use what each wave teaches.

5. Build a community of practice

   Teams that have done the work are the best help for teams that are starting.

What the security office prepares

• Baselines. Prepare the frameworks and policies that plans will be measured against.
• Guided plans. Publish QuickPlans for the most common situations, so a team in an ordinary situation does not start from a blank framework.
• Help at the moment of need. Short guidance and recorded walk-throughs, and a one-hour session for a team that wants company on its first plan.

Choosing tools

FCR does not require a particular tool. Whatever is used should pass four tests:

• someone with no security training can use it
• each person sees only the resources they are responsible for
• its pricing does not make every new participant a new cost
• one inventory can be reported against many baselines

FCR is built on the five principles of participation. Each one shows up in how the work is done.

The principles themselves are shared by all three methodologies. Read “The Five Principles of Participation”

Once teams are planning for themselves, two refinements remove most of the duplication that remains.

Common control services

Many of the controls in a team's plan are delivered by a shared service, such as central identity, backup or a managed network. The provider of that service can document those controls once, and every team that uses the service inherits them by reference instead of describing them again.

What a provider says its service delivers is a claim. Before others build on it, the security office can review the controls and check the evidence behind them, raising the fidelity of every security plan that depends upon it.

Each verified service becomes a building block. Every plan that uses it gets more accurate, with no extra work from the team that owns the plan. Read “How Common Control Services Work in FCR”

Dependency tracking and drift

Inheriting by reference means every dependency is known. Plans, the services they inherit from, and the vendors behind those services form one graph of “inherits from” links.

• Judged once. A control is examined where it is owned, not again in every plan that relies on it.
• A gap stays where it belongs. A gap in a shared service is one item for its provider. It is visible to every team that inherits from the service and is not charged to each of them.
• Change is flagged. When a service changes, every plan that inherits from it is marked as drifted with a Cheese Flag, named for the old question of who moved the cheese.
• Checkups by layer. A Compliance Checkup routes each gap to the layer that owns it: the vendor, the shared service, or the team's own use of the resource.

Vendors enter the same graph through Federated Third-Party Risk. Read “D&D: Dependency Trees and Drift”

FCR rests on what all three methodologies have in common: who owns the risk, who takes part, the five principles of participation, and levels of care. They are described in Federated Cybersecurity.

Risk that comes from vendors is the subject of Federated Third-Party Risk. Seeing how all of this is running, at every level, is the subject of Federated Practice Monitoring.