CAF – Objective C

You are not able to apply Indicators of Compromise to systems monitoring your essential services to confidently detect the presence or absence of those IoCs (e.g. because your logging data is not sufficiently detailed).

You are not able to audit the activities of users in relation to your essential service.

You are not able to capture any traffic crossing your network boundary (e.g. even IP connections).

You are able to look for most IoCs you receive, but may need to adjust logging coverage or data quality to deal with some IoCs.

Some user monitoring is done, but not covering a comprehensive range of user activities that might affect them.

You are able to monitor traffic crossing your network boundary (including IP address connections as a minimum).

Your monitoring data provides sufficient detail to reliably detect security incidents that could affect your essential service.

You have timely access to the data you need to use with IoCs.

You are able to monitor user activity extensively in relation to essential services. You can detect policy violations and an agreed list of suspicious or undesirable behaviour.

As well as your network boundary, your monitoring coverage includes internal and host-based monitoring.

Your process for bringing new systems on line includes considerations for access to monitoring data sources.

There is no controlled list of who can view and query logging information.

There is no monitoring of the access to logging data.

There is no policy for accessing logging data.

Logging is not synchronised, using an accurate time source.

Privileged users can view logging information.

Some monitoring of access to logging data.

Some logging datasets are synchronised.

Logging data is segregated from the rest of the network, so disruption or corruption to network data does not affect the logging data.

Any alterations to logging data (e.g. re-normalising for SIEM analysis) is done on copies, not the master.

Logging datasets are synchronised, using a common time source, so separate datasets can be correlated in different ways.

Access to logging data is limited to those with business need and no others.

All actions involving all logging data (e.g. copying, deleting or modification, or even viewing) can be traced back to a unique user.

Legitimate reasons for accessing logging data are given in use policies and users are trained on this.

Your logging data is stove-piped, stored in different places and difficult to aggregate to investigate alerts.

You are not able to use log data to resolve alerts to a network asset or system.

You are not able to flag security alerts that relate to essential services.

Logs are not reviewed regularly.

Some logging datasets are stored centrally and can be used for some investigations.

You are able to use log data to resolve alerts to a network asset or system.

You are able to flag alerts that relate to your essential services.

Logs are reviewed at regular intervals.

You are able to aggregate separate datasets to investigate activity or alerts (e.g. by enriching logging data with other network data, or knowledge of the network more generally) and are able to make maximal use of a wide range of signatures and IoCs.

You are able to resolve alerts to network assets, using knowledge of the network and systems.

You are able to flag alerts that relate to essential services and use this information to support your incident management capability.

Logs are reviewed almost continuously, in real time.

You are able to test that alerts are generated reliably and that genuine security incidents are distinguishable from false alarms.

You do not apply intelligence updates (e.g. AV signature updates, other threat signatures or IoCs) in a timely way, after receiving them.

You do not receive signature updates for all protective technologies (such as AV and IDS) or other software in use.

You do not evaluate the usefulness of your threat intelligence or share feedback with providers or other users.

You apply some updates, signatures and IoCs in a timely way.

You receive signature updates for all your protective technologies (e.g. AV, IDS).

You are cognisant of how effective your threat intelligence is (e.g. by tracking how threat intelligence helps you identify security problems).

You are able to apply new signatures and IoCs within a reasonable (risk-based) time of receiving them.

You receive signature updates for all your protective technologies (e.g. AV, IDS).

You can track the effectiveness of your intelligence feeds and actively share feedback on the usefulness of IoCs and any other indicators with the threat community (e.g. sector partners, threat intelligence providers, government agencies).

Monitoring staff do not have the correct specialist skills.

Monitoring staff are not capable of reporting against governance requirements

Monitoring staff lack the skills to successfully perform any part of the defined workflow.

Monitoring tools are only able to make use of a fraction of logging data being collected.

Monitoring tools cannot be configured to make use of new logging streams, as they come online.

Monitoring staff are not aware of some essential services the organisation provides and what assets (and hence logging data and security events) relate to those services.

Monitoring staff can report to other parts of the organisation (e.g. security directors, resilience managers).

Monitoring staff are capable of following most of the required workflows.

Your monitoring tools can make use of logging that would capture most common attack types.

Your monitoring tools  can work with most logging data, with some configuration.

Monitoring staff are aware of some essential services and can manage alerts relating to them.

Monitoring staff have roles and skills that covers all parts of the monitoring/investigation workflow.

Monitoring staff have workflows that address all governance reporting requirements, internal and external.

Monitoring staff are empowered to look beyond fixed workflows to investigate and understand non-standard threats, by developing their own investigative techniques and making new use of data.

With some configuration, your monitoring tools are able to make use of all logging data collected.

Monitoring staff and tools are able to drive and shape new log data collection and can make wide use of it.

Monitoring staff are aware of essential services and related assets and can identify and prioritise alerts or investigations that relate to them.

You have no established understanding of what abnormalities to look for that might signify malicious activities.

You maintain descriptions of some system abnormalities that might signify malicious activity, informed by past attacks (on yours and others’ networks), threat intelligence and a general understanding of what an attack might look like.

Your choice of system abnormalities to search for takes into account the nature of attacks likely to impact on the networks and information systems supporting the delivery of essential services.

You regularly update the descriptions of the system abnormalities that you search for to reflect changes to your networks and information systems and current threat intelligence.

You have justified confidence in the effectiveness of your searches for system abnormalities.