Cyber Resilience & Security

Security is important. Resilience is what happens when security fails.

No system is completely immune to attack.

Good security reduces the likelihood of something going wrong. Resilience asks what happens when prevention fails.

A resilient system is designed to limit the consequences of compromise or failure, protect what matters and allow the organisation to continue operating and recover without losing control of its systems or information.

Fern ICT helps organisations consider security and resilience as properties of the architecture rather than controls added around the outside.

What is the difference between cyber security and cyber resilience?

Cyber security is largely concerned with preventing, detecting and containing threats.

Cyber resilience goes further.

It asks what happens when an attacker gets through, a credential is compromised, a critical service becomes unavailable, a supplier is disrupted or important information is damaged or lost.

That changes the questions an organisation needs to ask.

For example:

• What happens if a critical system is compromised?
• Can the organisation continue operating?
• How quickly can important services be recovered?
• Can compromised systems be isolated without bringing everything else down?
• What happens if a key technology supplier becomes unavailable?
• How much of the organisation depends on a small number of systems, people or suppliers?
• Can recovery be trusted, or could the compromise simply be restored along with the data?

Security and resilience are closely related, but they are not the same thing.

A strong security posture reduces the probability and impact of an incident.

A resilient architecture limits the damage when an incident nevertheless occurs.

Look beyond the perimeter

Modern systems rarely have a single, clearly defined security boundary.

Applications, data and people may be distributed across cloud platforms, offices, suppliers, mobile devices and third-party services. Information moves between them continuously.

This changes where trust exists and where failure can propagate.

We can help examine:

• where important information resides and how it moves;
• which systems and services the organisation depends upon;
• where trust is placed within the architecture;
• what happens if an account, system or supplier is compromised;
• how much access people and services actually need;
• where a failure could propagate through the environment;
• which dependencies are genuinely critical; and
• how quickly the organisation could detect, contain and recover from an incident.

The objective is to understand the system as it actually operates, rather than relying on an assumed perimeter.

What happens when a critical system is compromised?

The important question is not simply whether a system can be compromised.

It is what the compromise allows an attacker to do next.

A resilient architecture considers the consequences of losing control of an individual component and attempts to prevent that failure from becoming an organisational failure.

This might involve:

• reducing unnecessary trust between systems;
• limiting access to critical information;
• separating important systems and services;
• containing the consequences of a compromised component;
• maintaining independent recovery mechanisms;
• protecting the integrity of important information;
• maintaining essential operations during disruption; and
• ensuring that recovery does not simply recreate the original vulnerability.

This is architectural thinking rather than a checklist of security products.

The objective is to make individual failures containable rather than allowing them to propagate unchecked.

What happens if infrastructure or a cloud provider fails?

Cloud infrastructure can be highly available without the organisation itself being resilient.

A system may depend on a particular provider, region, service, identity platform, network connection or managed service without that dependency being recognised as a significant operational risk.

We can examine questions such as:

• What happens if a critical cloud service becomes unavailable?
• What happens if connectivity to the provider is lost?
• Can essential operations continue without access to the cloud?
• How dependent is the organisation on a particular provider or region?
• Is recovery possible if the normal management plane is unavailable?
• What happens if a critical supplier suffers a serious incident?
• Would moving to another provider actually be practical?

The answer is not automatically “use multiple cloud providers”.

Multi-cloud can reduce some forms of dependency, but it can also introduce additional identity systems, operational processes, interfaces and technical complexity.

The appropriate architecture depends on the consequences of failure and the level of resilience the organisation actually requires.

How dependent are you on your suppliers?

Technology resilience extends beyond systems directly operated by the organisation.

Critical applications may depend on cloud providers, software vendors, managed service providers, telecommunications providers, payment platforms or specialist suppliers.

A supplier may therefore represent a significant architectural dependency even when its systems are outside the organisation’s direct control.

We can help identify:

• critical technology suppliers;
• dependencies between suppliers and internal systems;
• concentration of risk;
• contractual and operational assumptions;
• practical alternatives and recovery options; and
• the consequences of prolonged supplier disruption.

The question is not whether a supplier is trustworthy.

It is what happens if that supplier becomes unavailable, compromised or unable to provide the service you depend upon.

Design for what happens when things go wrong

Traditional security often concentrates on preventing undesirable events.

Prevention matters, but it is only part of the problem.

A resilient architecture assumes that some controls will eventually fail.

Depending on the environment, this might mean considering:

• compromise of privileged credentials;
• loss or corruption of important information;
• failure of critical infrastructure;
• compromise of an application or service;
• loss of connectivity;
• failure of a cloud provider or supplier;
• malicious or accidental deletion;
• inability to access normal management systems; and
• the ability to operate while recovery is taking place.

The aim is not to pretend that failure cannot happen.

It is to make sure that failure is survivable.

Security by design

Security and resilience decisions are often cheapest and most effective when made during architecture and design rather than after a system has been built.

We can work with technical and leadership teams to identify security and resilience requirements early, challenge assumptions and make proportionate improvements before they become expensive to retrofit.

Depending on the engagement, this can include:

• architecture review;
• threat and risk assessment;
• trust-boundary analysis;
• dependency analysis;
• consideration of failure and compromise scenarios;
• recovery and continuity assessment; and
• secure-by-design recommendations.

The emphasis is on understanding how the system behaves under adverse conditions, not simply whether individual security controls exist.

An independent perspective

Fern ICT does not sell security products or represent a particular security vendor.

That allows us to consider the whole environment and look at the relationship between architecture, security, resilience, people and dependencies.

Sometimes the answer will involve new technology.

Sometimes it will involve removing technology, reducing access, separating systems or simplifying an architecture.

The important thing is that the resulting system is easier to understand, harder to compromise and better able to recover when something inevitably goes wrong.

When does a cyber resilience review make sense?

An independent review can be particularly useful:

• when designing or changing a critical system;
• before moving important information into the cloud;
• when assessing the resilience of an existing architecture;
• after a significant cyber incident or near miss;
• when reviewing critical technology suppliers;
• when changing security or regulatory requirements;
• when an organisation has become heavily dependent on a particular provider;
• when business continuity depends upon assumptions about technology recovery; or
• when senior management needs an independent view of how the organisation would cope with a serious compromise.

You don’t need to know exactly what is wrong before starting a review.

Sometimes the most useful question is simply:

“What happens if our most important assumption fails?”

Further reading

The thinking behind this service is explored in:

• Why Technical Architecture Still Matters
• When Simplicity Is a Technical Strategy

Start with resilience

If you’re concerned about how well your organisation would cope with a serious cyber incident, infrastructure failure, cloud outage or supplier disruption, an independent review can help expose assumptions that are difficult to see from inside the organisation.

We can start with what matters most to your organisation, identify the dependencies that really matter and work through the consequences of failure.

The objective isn’t to promise that nothing will go wrong.

It is to make sure that when something does, the organisation can keep operating and recover.

Start a conversation →