Information security design, existence and operation

What does "detention" mean?

Design the question whether the measure is appropriately designed.

Example:

The organisation wants to prevent unauthorised persons from accessing critical systems.

The design may then consist of:

• individual accounts;
• multi-factor authentication;
• limited management rights;
• periodic access review;
• exit procedure.

The audit question is:

Would this facility, if properly implemented, adequately manage the risk?

What does existence mean?

Existence means that the proposed measure has actually been implemented.

In the same example, you look at:

• MFA technically activated;
• management accounts exist;
• rights are set up;
• review process started;
• offboarding procedure is used.

A policy document with MFA not yet.

You need to see how this is actually implemented.

What does working mean?

Operation Going one step further.

The measure exists, but does it also function structurally?

Examples include:

• MFA remained active during the period under investigation;
• have added new accounts correctly;
• are subject to exceptions;
• have been effectively conducted quarterly reviews;
• have been found to resolve anomalies;
• have left employees closed in time.

This shifts the demand from presence to reliability.

Why is this distinction so useful?

Because many security issues arise between these three layers.

Good design, no existence

The procedure has been described in an excellent way, but it has not yet been technically implemented.

Existence, limited effect

The vulnerability scanner is running, but no one is following the findings in time.

Operation without clear purpose

An experienced administrator does sensible checks, but everything is in his head and no one knows what happens when he leaves.

The three concepts make such differences visible.

Example: Backup and Recovery

Design

It is stated:

• which systems are backed up;
• which frequency is applicable;
• the period of storage required;
• how backups are protected;
• which repair times are appropriate to the business operation.

Existence

You can see that:

• back-up tasks are organised;
• storage exists;
• rights are limited;
• reports are generated.

Operation

You can show that:

• structuralally successful rotation of tasks;
• errors are monitored;
• restore tests are performed;
• recovery is completed within the required timeframe.

For management/direction, the last step is particularly relevant.

A green backup status says less than demonstrably recovers.

Example: supplier management

Design

It is determined which suppliers are critical and which requirements apply.

Existence

Contracts, SLAs and assessment processes are set up.

Operation

Suppliers are effectively assessed periodically, assurance is read, abnormalities are monitored and risks are updated.

That's the difference between "we've got supplier management" and "we" it can be demonstrated that it is at supplier risk.

Example: incident response

Design

There's an incident response plan with roles and escalation.

Existence

Contact lists, roadmaps and facilities are available.

Operation

The organisation exercises, updates contact information, processes lessons and really knows who decides during an incident.

What does this mean for the board and executive management?

For management/direction, the distinction between management information is much more acute.

Take the verdict:

“Our critical controls are in order.”

I'd like to know:

• We mean they've been described;
• have been technically introduced;
• or detectable over time?

That's three different levels of security.

A useful board-level question

“What important security measures do we know about? only that they exist, and of which we have demonstrable operation?”

That often gives us a more interesting conversation than a dashboard score.

What does this mean for the IT manager?

For the IT manager, it helps to obtain evidence from normal management processes.

Remember:

• account reviews;
• patch reports;
• vulnerability tickets;
• SIEM alert top-up;
• Restore tests;
• change logs;
• endpoint status;
• supplier tickets.

Then evidence will automatically emerge during work.

That's much more efficient than collecting just before an audit screenshots.

How do you test how to work without bureaucracy?

You don't have to check every detail all the time.

Start risk-oriented.

Step 1

Select the controls most relevant to critical risks.

Step 2

Decide which evidence makes sense.

Step 3.

Capture who's in control.

Step 4.

Determine an appropriate frequency.

Step 5.

Register anomalies and follow-up.

That can be for one control monthly and for another annual.

Where does it go wrong in practice often?

The procedure is considered evidence

A procedure is particularly proof the intent.

A screenshot is considered structural

A screenshot shows one moment.

Control does not have an owner

Then it is unclear who should follow the anomalies.

There's evidence, but no one's judging it.

Reporting without follow-up is not yet effective control.

Everything gets the same frequency of control

Risk determines how often you want to test.

Design, existence and operation of an audit

In an audit, I use these concepts to structure evidence.

Examples include:

This makes an audit report more understandable for management.

The relationship with internal control

Internal control is ultimately about trust in the operation of measures.

That is why these concepts are so well suited to information security.

You can prevent conversations from sticking in:

• policy;
• tools;
• certificates;
• plans.

The key question is:

What risks do we manage, what measures do we take, and how do we know that these measures work?

That is the essence of demonstrable information security for me.

You want to set this up wider in the organisation? Then check out the Kynexis service Internal control information security.