Before you choose a security solution, define the problem

Four questions to help organisations make better security investments — and keep those investments effective over time.

By John Helge Gantz, Solutions Architect, NetNordic

Security investments often begin with a discussion about technology. Which products should we consider? What capabilities do they offer? How much do they cost?

These are reasonable questions. But I believe there is a more important one to answer first.

What problem are we actually trying to solve?

Before choosing a solution, we need to understand what matters to the organisation, which risks we need to address and what the investment must enable us to do.

A security policy can establish that a control is required. An architecture diagram can show where it belongs. A licence report can confirm that the technology has been purchased.

None of these, on their own, demonstrates that the organisation is better protected or better prepared to handle an incident.

Security architecture needs to work in practice

I have seen similar reference architectures produce very different outcomes across organisations.

In one case, the design was technically sound and the technology was appropriate, but the organisation lacked the resources to operate it effectively. Over time, alerts went unreviewed, exceptions accumulated and configurations received less attention than they required.

The protection weakened gradually, without an obvious failure drawing attention to it.

In another case, the implementation met the requirements of a recognised standard within the scope being assessed, yet an important attack path remained outside that scope. The organisation could demonstrate compliance, but that did not mean its relevant risks had been adequately addressed.

Neither situation reflected a lack of commitment to security.

Both illustrate why security architecture must account for more than technical requirements. It must reflect the organisation’s actual exposure, its operating model and the resources available to maintain the necessary controls.

What does this mean in practice?

Consider a fictional transport and logistics operator with several terminals.

If systems at one terminal are compromised, the organisation may need to isolate them while maintaining operations at the other terminals.

That may sound like a purely technical requirement. But making it possible requires an understanding of how the terminals communicate, which shared systems they depend on, what can be isolated safely and who has the authority to make that decision.

The answers influence network segmentation, access controls, monitoring and incident response procedures. They may also reveal that isolation would have greater operational consequences than initially expected.

A product comparison can help identify suitable technology. Understanding how the organisation should handle an incident also requires input from the people who know its day-to-day operations.

Good security starts with understanding the organisation’s operations, critical functions and the dependencies between them. The illustration shows a fictional logistics terminal.

Four questions before the shortlist

Before comparing technologies or suppliers, I would begin with four questions.

They do not replace a formal risk assessment or architecture review. Their purpose is to establish whether we understand the problem well enough to make an informed decision. We do not need every answer at the outset, but we should know what still needs to be investigated.

1. What are we protecting?

Start with the functions the organisation depends on, rather than simply listing systems and applications.

An asset inventory tells us what exists. Understanding how those assets support the organisation tells us why they matter.

For our logistics operator, this could mean freight scheduling, terminal operations and communication with drivers.

Which functions must remain available? How long can they tolerate disruption? Which systems, people and external suppliers do they depend on?

The answers help identify critical dependencies and establish where stronger protection or greater resilience is needed. Different systems can have very different levels of business importance. Security architecture should reflect that distinction.

2. Which threats and attack paths matter here?

Once we understand what matters, we need to consider how it could be compromised.

Threat modelling helps identify relevant attack scenarios and understand how an attacker could exploit weaknesses and dependencies. It should reflect the organisation’s technology, working practices and connections to external parties.

Could an attacker reach a critical system through a compromised user account? Could a supplier connection provide an unintended route into the network? Do users or systems have more access than they need?

The aim is to understand which scenarios are credible, how existing controls address them and where significant gaps remain.

Another security product may be the right response. In other cases, better configuration, clearer segmentation, fewer privileges or more effective use of existing capabilities may deliver greater value.

3. What could the consequences be?

To prioritise a technical weakness, we need to understand what it could mean for the organisation.

For our logistics operator, an incident might delay deliveries, interrupt terminal operations, expose customer information or put people’s safety at risk. It could also cause financial losses, breaches of contract and obligations to notify authorities or affected parties.

Some consequences can be quantified. Others need to be assessed with the people responsible for operations, finance and business leadership.

An important part of security advisory work is making technical risk understandable and relevant to those allocating resources. This allows security needs to be considered alongside the organisation’s other business risks.

We therefore need to establish both what could go wrong and why preventing or limiting the consequences deserves investment.

4. What must the organisation be able to do during an incident?

Security architecture must also enable action when an incident occurs.

Who needs to detect and assess the situation? What information do they need to make a decision? Who has the authority to act? Can the necessary actions be carried out outside normal working hours?

For our logistics operator, isolating a compromised terminal requires more than network segmentation. Those responsible must be able to identify affected systems, understand the consequences of isolation and determine which actions will contain the incident without creating greater problems.

They also need to know how critical functions will be restored and how to verify that it is safe to resume normal operations.

This requires visibility, clear responsibilities and agreed procedures. Cooperation between security personnel and those responsible for daily operations needs to be established before an incident occurs.

Who will operate the solution in twelve months?

The four questions help establish what the solution needs to achieve. But the outcome also depends on the organisation’s ability to maintain it over time.

Systems change, new services are introduced, configurations drift and integrations can fail. Alerts need reviewing, exceptions need managing and security controls need testing.

That work requires time, expertise and clear ownership.

Some organisations have the capacity to manage these responsibilities internally. Others rely on an external provider or combine internal and external resources. The appropriate model depends on the organisation’s needs and circumstances.

A solution with more features may also demand more specialist knowledge, greater operational effort and investment in supporting systems. These costs need to be considered before procurement.

A suitable security solution must meet the need and be sustainable to operate over time.

Turn the answers into a clear brief

Before approaching suppliers, we should be able to describe the need without naming a particular product.

A short statement can bring the essential requirements together:

We need to protect [critical function] against [relevant threat or attack path], because an incident could cause [business consequence]. During an incident, [responsible role] must be able to [required action] within [necessary timeframe].

This does not replace a formal requirements specification, but it gives the people involved a common starting point.

Two further considerations belong alongside it:

• Operations and accountability: Who will maintain the solution after implementation, what expertise and capacity will it require, and how will responsibilities be allocated?
• Evidence of effectiveness: How will we establish that the controls work as intended and that the organisation can handle an incident?

The assessment will depend on the control. It may involve testing whether relevant events are detected, reviewing configurations, validating technical capabilities or exercising incident response procedures.

Agreeing on this before implementation also makes it easier to identify when protection weakens or requirements change.

With a clear brief, suppliers can be evaluated against how well they address the organisation’s problem and what it will take to maintain that effectiveness over time.

Start with one critical function

You do not need to review your entire security architecture to begin.

Choose one function the organisation depends on. Examine what it needs to operate, which risks could affect it and how you would handle a disruption. Involve the people who understand daily operations, alongside those responsible for technology and security.

You may find that existing controls are sufficient. You may also discover gaps in visibility, unclear responsibilities or dependencies that need closer attention. Either outcome provides a better basis for prioritisation.

A good security decision does not always lead to a new purchase. Sometimes the greatest improvement comes from making better use of what is already in place.

The goal is to give the organisation the protection and response capabilities it actually needs.

In the next article, I will explore visibility in security operations: what an organisation can actually see, where blind spots emerge and why collecting more data does not necessarily lead to a better understanding of what is happening.

A conversation worth having?

Are you considering a security investment, or questioning whether your existing solutions meet your needs? I am always happy to discuss which questions are worth answering before you move forward.

The transport and logistics operator used in this series is fictional, included to make the examples concrete without describing a real organisation.

Author