What is being investigated in an IT security audit?

First, the scope: What do we want to know?

“Just perform a security audit” is not yet a useful research question.

Before I do, I want to know:

• which processes are critical;
• which systems are included;
• which data are important;
• which suppliers play a major role;
• which is now uncertain about governance, management or IT;
• what decision should be taken after the audit.

An audit for an organisation that has outsourced almost all IT is automatically given a lot of attention to suppliers, access, contracts and assurance.

In an organisation with its own infrastructure, the technical equipment can weigh more heavily.

The scope follows from the organisation, not from a standard list.

Governance: who controls and who decides?

Cybersecurity is never just a technical subject.

I am therefore also looking at the board-level establishment.

Examples include:

• who owns digital risks;
• the role of management/direction;
• which responsibilities lie with IT;
• who may accept risks;
• how severe abnormalities are escalated;
• how information security is discussed;
• which information is directed towards management or oversight.

For the board and executive management is particularly relevant or risks Controllable are.

A technical problem will only become manageable when it is clear:

• the impact;
• who owns the property;
• what action is needed;
• the time limit for which it is realistic;
• which residual risk is left after that.

Identity and access rights

Access is almost always an important audit subject.

I'm looking at, for example,

• how accounts are created;
• how rights change when changing jobs;
• how quickly accounts are terminated;
• multi-factor authentication;
• management accounts;
• increased duties;
• service accounts;
• access by suppliers;
• periodic access reviews.

I do not want to see a procedure alone.

If the policy says that staff leaving is being closed immediately, I would also like to see that this has actually happened in the past period.

That difference between appointment and operation is important in audits.

Systems, endpoints and technical equipment

Then, of course, the technique will also be discussed.

Depending on the scope, I can look at:

• laptops and endpoints;
• servers;
• cloud environments;
• network segmentation;
• firewalls;
• management interfaces;
• security settings;
• patch management;
• encryption;
• external access;
• remote management.

The central question is always:

Is the establishment appropriate for the risk and can the organisation demonstrate that the establishment is being managed structurally?

A good security product helps, but does not solve much when it is misset or only covers part of the environment.

Patch and Vulnerabilities Management

Almost every organisation has vulnerabilities.

That is not special in itself.

I want to know how the organisation handles it.

Questions I ask are:

• which systems are scanned;
• how often;
• who evaluates critical findings;
• the time limits for the dilution;
• how exceptions are laid down;
• what happens if a supplier cannot patch in time;
• which vulnerabilities have been open for a long time.

For an IT manager this is often known territory.

For management or management, I prefer to translate it into:

Do we have an understanding of vulnerabilities that could affect our critical service, and are they being monitored in a demonstrably timely manner?

Logging, monitoring and detection

Prevention can never prevent any incident.

That is why I am looking at the question of whether an organisation sees any abnormal behaviour at all.

Examples include:

• which systems provide logging;
• which events are monitored;
• who assesses reports;
• what happens outside office hours;
• how long logs remain available;
• which reports lead to escalation;
• whether incidents can be investigated subsequently.

A dashboard with a lot of notifications doesn't give any certainty yet.

I want to know what reports matter and if anyone's actually doing anything with them.

Backup, recovery and continuity

Backup is almost always looking beyond . . backup runs .

The more interesting question is:

Can you go back?

I'm looking at, for example,

• which data and systems are backed up;
• how often;
• where backups are stored;
• who can modify or delete them;
• how ransomware is resistant to the device;
• where a restore has been last performed;
• how long recovery really takes;
• which suppliers are needed to get a critical process going again.

For the board and executive management, the link with continuity is particularly important.

A green backup status is nice. demonstrable recovery power gives much more certainty.

Incident response: what happens if things go wrong?

Good security has incidents, too.

That's why I'm investigating if the organisation knows what to do.

Remember:

• incident response plan;
• roles and responsibilities;
• accessibility;
• escalation;
• involvement of management/direction;
• communication;
• legal and privacy aspects;
• forensic research;
• recovery;
• contact with suppliers;
• exercises performed.

A plan that has never been practiced remains an assumption.

I therefore find a simple scenario exercise more valuable than an additional page in the incident manual.

Suppliers and chain dependencies

Many organisations have largely outsourced their IT.

That changes the work. The dependency remains.

I look at, for example:

• which suppliers are critical;
• which systems they manage;
• the data they process;
• the access they have;
• the security arrangements made;
• which assurance is available;
• how incidents are reported;
• the recovery arrangements;
• which subcontractors are used;
• which happens in the event of prolonged failure.

A supplier can have technically arranged a lot of good.

The audit question is also whether the organisation self sufficient visibility and direction .

Employees and daily implementation

Security is also in ordinary work processes.

That's why I'm looking at, for example:

• onboarding;
• exit;
• handling sensitive information;
• awareness;
• Phishing reports;
• change management;
• function separation;
• escalation of abnormalities;
• Incident reports.

I am less interested in the question of whether anyone has ever followed an e-learning.

More interesting is whether employees know what is expected of them and whether the organisation recognizes and succeeds deviations.

What evidence do you use during an audit?

An audit is a key part of being demonstrable.

Depending on the scope, I use:

• policy documents;
• configurations;
• user reviews;
• account reviews;
• logging;
• patch reports;
• vulnerabilities reports;
• back-up and restore reports;
• incident records;
• suppliers' contracts;
• Insurance reporting;
• tickets;
• management reports;
• minutes;
• checks carried out.

I would like to use three simple concepts:

Design

Is the measure designed to be logical and appropriate?

Existence

Has the measure actually been implemented?

Operation

Does the measure work in practice as intended?

Take multi-factor authentication.

On paper, it may be that MFA is mandatory. Then I want to see:

• for which accounts MFA applies;
• how this has been technically enforced;
• the exceptions that exist;
• who approved those exceptions.

That gives much more certainty than just a policy rule.

How do you translate technical findings into board-level risks?

An audit report should be useful for different readers.

The IT manager needs technical details.

A board member wants to know:

• what is the risk;
• which process can be affected;
• the impact of the project;
• the risk is now well controlled;
• which measure is a priority;
• who owns it;
• What decision is needed.

I think that translation is essential.

A critical vulnerability in a test server may be less important than a medium finding in a system that depends on the entire service.

The context determines the priority.

What does a good audit get?

I find an audit successful when the organisation can decide better afterwards.

The outcome should therefore at least make clear:

• where the organisation is shown to be strong;
• which risks are not adequately controlled;
• where evidence is lacking;
• which improvements can be made quickly;
• the structural measures needed;
• who should become owner;
• which points of management or management should decide themselves.

At Kynexis I translate this into a coherent and prioritized image, so that IT and management can continue with it.

When is an audit not the right form?

Not every question requires a broad audit.

If you want to know where your global position is, then a baseline assessment can be Make sense.

If you want to look at one technical environment in depth, then an assessment often fits better.

If you want to know specifically if an attacker can penetrate a system, you'll get to a penetration test sooner.

We have separate choice-helps for that.

Also read: cybersecurity audit, pen test or vulnerability scan: What's in your question?

My starting point for an IT security audit

After an audit, I do not want to produce a comprehensive report that the organisation itself should then give meaning to.

The outcome must be clear:

What works, what is not yet known, what risk is behind it and what deserves first attention?

That is the difference between checking and giving real insight.

Prep yourself?

Use the Cybersecurity audit checklist: What parts are you checking?

Do you want to have independent research into how technical and organisational security measures work in practice? Then look at the Cyber Security Audit of Kynexis.