Interdependencies between essential and important entities
ENISA Interdependencies Indicators Tool
| ISO IEC 27002 control name | EXAMPLE OF IMPLEMENTATION |
|---|---|
Management of technical vulnerabilities
Information about technical vulnerabilities of information systems being used should be obtained in a timely fashion, the organisation’s exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. |
Review information security incident reports focusing on the root cause of the incident. Count the number of vulnerabilities that caused an incident and were not identified during the management of technical vulnerabilities. |
Administrator and operator logs
System administrator and system operator activities should be logged and the logs protected and regularly reviewed. |
Review the information security incidents and the collected evidence related administrator and operator logs. Count the number of times per system that an indicative log entry is missing. |
Event logging
Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed. |
Review the information security incidents and the relevant event logs. Count the number of times per system that an indicative log entry is missing. |
Clock synchronisation
The clocks of all relevant information processing systems within an organisation or security domain should be synchronised to a single reference time source. |
Compare the time stamp of all critical components to a reliable and reputable time source. Count the number of diviations. |
Technical review of applications after operating platform changes
When operating platforms are changed, business critical applications should be reviewed and tested to ensure there is no adverse impact on organisational operations or security. |
Review the test reports of applications after operating plarform changes. Measure the mean amount of time needed to perfom the test and fix possible subsequent problems per system. |
System change control procedures
Changes to systems within the development lifecycle should be controlled by the use of formal change control procedures. |
Review the change requests and relevant documentation and measure the mean amount of time needed for a change to be performed in a system, per system. |
Restrictions on changes to software packages
Modifications to software packages should be discouraged, limited to necessary changes and all changes should be strictly controlled. |
Review existing software components and compare their version to the latests available. Count the number of system currently not up-to-date. |
Monitoring and review of supplier services
Organisations should regularly monitor, review and audit supplier service delivery. |
Review the monitoring and evaluation reports of suppliers focusing on the incident reports. Measure the mean amount of time for the conclusion of the incident. |
Managing changes to supplier services
Changes to the provision of services by suppliers, including maintaining and improving existing information security policies, procedures and controls, should be managed, taking account of the criticality of business information, systems and processes involved and re-assessment of risks. |
Measure the mean amount of time needed by the supplier to implement an emergency change. |
Learning from information security incidents
Knowledge gained from analysing and resolving information security incidents should be used to reduce the likelihood or impact of future incidents. |
Review the types, volumes and costs of information security incidents. Identify the number of controls implemented that changes some aspect of similar future incidents. |
Collection of evidence
The organisation should define and apply procedures for the identification, collection, acquisition and preservation of information, which can serve as evidence. |
Measure the mean amount of time for the collection of evidence. |
Assessment of and decision on information secuirty events
Information security events should be assessed and it should be decided if they are to be classified as information security incidents. |
Review information security incident reports and measure the mean amount of time needed to reach a decision per system / service. |
Response to information security incidents
Information security incidents should be responded to in accordance with the documented procedures. |
Review information security incident reports and measure the mean amount of time needed for the responce to security incidents per system and service. |
Reporting information security events
Information security events should be reported through appropriate management channels as quickly as possible. |
Review the information security events and measure the mean time needed for the resolution of an incident per system / service. |
Reporting information security weaknesses
Employees and contractors using the organisation’s information systems and services should be required to note and report any observed or suspected information security weaknesses in systems or services. |
Measure the mean amount of time between the reporting of a critical weakness and its resolution. |
Implementing information security continuity
The organisation should establish, document, implement and maintain processes, procedures and controls to ensure the required level of continuity for information security during an adverse situation. |
Count the number of time dependent services/sysetms/components, per service. |