Key Performance Indicators Coaching For Process Safety Information

Some examples of indicators that typically used in security:

Number of attacks prevented / detected (FW, IPS, etc.).

Number of detected malware (antivirus, antispyware, etc.).

Number of security incidents reported and attended (incident response teams)

Number of security updates

Response time to address incidents

average time distribution of security patches

For reference, KPI library can find hundreds of additional indicators of various kinds.

Here are the queries which a key performance indicator coaching can answer:

Which of these technical indicators we really serve?

How can we generate indicators of information security, which are really key to the business based on certain technical indicators?

Technical Indicators

We must distinguish between technical indicators that are useful and those that are purely informational and do not provide specific data on the effectiveness of control.

The indicators measure things that are useful under our control and not dependent on the environment.

Examples of bad technical indicators:

Controls:

Number of detected viruses

Number of changes in configuration

Number of patches applied in the month

Number of detected attack attempt

Number of backup tapes generated in a month

Procedures:

Number of requests met

Hours spent on troubleshooting

Examples of good indicators:

Controls:

Percentage of virus detected and removed promptly

Percentage of attacks prevented

Percentage of critical patches applied in the same month of their release

Procedures:

Average time to restore a system from a

Average response time for resolving an incident

Average cost per incident resolution (+ man-hours material resources)

From the above examples, it is clear that good indicators are the result of a balance between actions implemented correctly and incorrect actions (wrong actions being the sum of false positives and negatives lacking). They are also good indicators of service level metrics (time) and cost related only to local variables.

Management of technical indicators

It is clear that generate hundreds of indicators at the technical level is not synonymous with a better or more precise control. We must use the minimum amount of technical indicators to build despempeño key indicators required by the business, but we also have other problems:

The measurement of prevented events - measuring actual events (incidents) with an impact to the business is relatively easy. Simply review the list of reports from the service desk, but there are a lot of controls that do not successfully prevented documented events (eg how many incidents prevented a laptop lock? Prevented many incidents off non-essential services on a server?

The joint control - When there are controls that work together (usually in different layers) is difficult to measure the effectiveness of each one of them. For example, the fact that a firewall by setting some traffic has prevented the spread of a new virus to pass into the internal network does not ensure that an antivirus or IPS behind the firewall could have acted effectively on this event.

If we can not measure with certainty false positives and negatives, we can not determine an indicator of effectiveness at the level of a particular control.