caf_text is now complete although will need checking against 3.2 and that it all maps correctly.
Now on with the tests and the actual app!
This commit is contained in:
parent
b7aece3469
commit
94fa2f5767
@ -640,9 +640,437 @@ objectives:
|
||||
subprincipleitem:
|
||||
- You have business continuity and disaster recovery plans that have been tested for practicality, effectiveness and completeness. Appropriate use is made of different test methods (e.g. manual fail-over, table-top exercises, or red-teaming).
|
||||
- You use your security awareness and threat intelligence sources to identify new or heightened levels of risk, which result in immediate and potentially temporary security measures to enhance the security of your network and information systems (e.g. in response to a widespread outbreak of very damaging malware).
|
||||
#
|
||||
# - objective:
|
||||
# name: Objective C - Detecting cyber security events
|
||||
#
|
||||
# - objective:
|
||||
# name: Objective D - Minimising the impact of cyber security incidents
|
||||
- sub-principle:
|
||||
name: B5.b Design for Resilience
|
||||
description: You design the network and information systems supporting your essential function(s) to be resilient to cyber security incidents. Systems are appropriately segregated and resource limitations are mitigated.
|
||||
subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Network and information systems supporting the operation of your essential function(s) are not appropriately segregated.
|
||||
- Internet services, such as browsing and email, are accessible from network and information systems supporting the essential function(s).
|
||||
- You do not understand or lack plans to mitigate all resource limitations that could adversely affect your essential function(s).
|
||||
subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Network and information systems supporting the operation of your essential function(s) are logically separated from your business systems (e.g. they reside on the same network as the rest of the organisation but within a DMZ).
|
||||
- Internet services are not accessible from network and information systems supporting the essential function(s).
|
||||
- Resource limitations (e.g. network bandwidth, single network paths) have been identified but not fully mitigated.
|
||||
subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Network and information systems supporting the operation of your essential function(s) are segregated from other business and external systems by appropriate technical and physical means (e.g. separate network and system infrastructure with independent user administration). Internet services are not accessible from network and information systems supporting the essential function(s).
|
||||
- You have identified and mitigated all resource limitations (e.g. bandwidth limitations and single network paths).
|
||||
- You have identified and mitigated any geographical constraints or weaknesses. (e.g. systems that your essential function(s) depends upon are replicated in another location, important network connectivity has alternative physical paths and service providers).
|
||||
- You review and update assessments of dependencies, resource and geographical limitations and mitigations when necessary.
|
||||
- sub-principle:
|
||||
name: B5.c Backups
|
||||
description: You hold accessible and secured current backups of data and information needed to recover operation of your essential function(s).
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Backup coverage is incomplete and does not include all relevant data and information needed to restore the operation of your essential function(s).
|
||||
- Backups are not frequent enough for the operation of your essential function(s) to be restored effectively.
|
||||
- Your restoration process does not restore your essential function(s) in a suitable time frame.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You have appropriately secured backups (including data, configuration information, software, equipment, processes and knowledge). These backups will be accessible to recover from an extreme event.
|
||||
- You routinely test backups to ensure that the backup process function(s) correctly and the backups are usable.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Your comprehensive, automatic and tested technical and procedural backups are secured at centrally accessible or secondary sites to recover from an extreme event.
|
||||
- Backups of all important data and information needed to recover the essential function(s) are made, tested, documented and routinely reviewed.
|
||||
- principle:
|
||||
name: Principle B6 Staff Awareness and Training
|
||||
description: Staff have appropriate awareness, knowledge and skills to carry out their organisational roles effectively in relation to the security of network and information systems supporting the operation of essential functions.
|
||||
sub-principles:
|
||||
- sub-principle:
|
||||
name: B6.a Cyber Security Culture
|
||||
description: You develop and maintain a positive cyber security culture.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- People in your organisation don't understand what they contribute to the cyber security of the essential function(s).
|
||||
- People in your organisation don't know how to raise a concern about cyber security.
|
||||
- People believe that reporting issues may get them into trouble.
|
||||
- Your organisation's approach to cyber security is perceived by staff as hindering the business of the organisation.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Your executive management understand and widely communicate the importance of a positive cyber security culture. Positive attitudes, behaviours and expectations are described for your organisation.
|
||||
- All people in your organisation understand the contribution they make to the essential function(s) cyber security.
|
||||
- All individuals in your organisation know who to contact and where to access more information about cyber security. They know how to raise a cyber security issue.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Your executive management clearly and effectively communicates the organisation's cyber security priorities and objectives to all staff. Your organisation displays positive cyber security attitudes, behaviours and expectations.
|
||||
- People in your organisation raising potential cyber security incidents and issues are treated positively.
|
||||
- Individuals at all levels in your organisation routinely report concerns or issues about cyber security and are recognised for their contribution to keeping the organisation secure.
|
||||
- Your management is seen to be committed to and actively involved in cyber security.
|
||||
- Your organisation communicates openly about cyber security, with any concern being taken seriously.
|
||||
- People across your organisation participate in cyber security activities and improvements, building joint ownership and bringing knowledge of their area of expertise.
|
||||
- sub-principle:
|
||||
name: B6.b Cyber Security Training
|
||||
description: The people who support the operation of your essential function(s) are appropriately trained in cyber security. A range of approaches to cyber security training, awareness and communications are employed.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- There are teams who operate and support your essential function(s) that lack any cyber security training.
|
||||
- Cyber security training is restricted to specific roles in your organisation.
|
||||
- Cyber security training records for your organisation are lacking or incomplete.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You have defined appropriate cyber security training and awareness activities for all roles in your organisation, from executives to the most junior roles.
|
||||
- You use a range of teaching and communication techniques for cyber security training and awareness to reach the widest audience effectively.
|
||||
- Cyber security information is easily available.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- All people in your organisation, from the most senior to the most junior, follow appropriate cyber security training paths.
|
||||
- Each individuals cyber security training is tracked and refreshed at suitable intervals.
|
||||
- You routinely evaluate your cyber security training and awareness activities to ensure they reach the widest audience and are effective.
|
||||
- You make cyber security information and good practice guidance easily accessible, widely available and you know it is referenced and used within your organisation.
|
||||
|
||||
- objective:
|
||||
name: Objective C - Detecting cyber security events
|
||||
description: Capabilities exist to ensure security defences remain effective and to detect cyber security events affecting, or with the potential to affect, essential function(s).
|
||||
principles:
|
||||
- principle:
|
||||
name: Principle C1 Security Monitoring
|
||||
description: The organisation monitors the security status of the network and information systems supporting the operation of essential functions in order to detect potential security problems and to track the ongoing effectiveness of protective security measures.
|
||||
sub-principles:
|
||||
- sub-principle:
|
||||
name: C1.a Monitoring Coverage
|
||||
description: The data sources that you include in your monitoring allow for timely identification of security events which might affect the operation of your essential function(s).
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Data relating to the security and operation of your essential function(s) is not collected.
|
||||
- You do not confidently detect the presence or absence of Indicators of Compromise (IoCs) on your essential function(s), such as known malicious command and control signatures (e.g. because applying the indicator is difficult or your log data is not sufficiently detailed).
|
||||
- You are not able to audit the activities of users in relation to your essential function(s).
|
||||
- You do not capture any traffic crossing your network boundary including as a minimum IP connections.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Data relating to the security and operation of some areas of your essential function(s) is collected but coverage is not comprehensive.
|
||||
- You easily detect the presence or absence of IoCs on your essential function(s), such as known malicious command and control signatures.
|
||||
- Some user monitoring is done, but not covering a fully agreed list of suspicious or undesirable behaviour.
|
||||
- You monitor traffic crossing your network boundary (including IP address connections as a minimum).
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Monitoring is based on an understanding of your networks, common cyber attack methods and what you need awareness of in order to detect potential security incidents that could affect the operation of your essential function(s) (e.g. presence of malware, malicious emails, user policy violations).
|
||||
- Your monitoring data provides enough detail to reliably detect security incidents that could affect the operation of your essential function(s).
|
||||
- You easily detect the presence or absence of IoCs on your essential function(s), such as known malicious command and control signatures.
|
||||
- Extensive monitoring of user activity in relation to the operation of your essential function(s) enables you to detect policy violations and an agreed list of suspicious or undesirable behaviour.
|
||||
- You have extensive monitoring coverage that includes host-based monitoring and network gateways.
|
||||
- All new systems are considered as potential monitoring data sources to maintain a comprehensive monitoring capability.
|
||||
- sub-principle:
|
||||
name: C1.b Securing Logs
|
||||
description: You hold log data securely and grant appropriate access only to accounts with business a need. No system or user should ever need to modify or delete master copies of log data within an agreed retention period, after which it should be deleted.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- It is possible for log data to be easily edited or deleted by unauthorised users or malicious attackers.
|
||||
- There is no controlled list of the users and systems that can view and query log data.
|
||||
- There is no monitoring of the access to log data. There is no policy for accessing log data.
|
||||
- Log data is not synchronised, using an accurate common time source.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Only authorised staff can view log data for investigations.
|
||||
- Authorised users and systems can appropriately access log data.
|
||||
- There is some monitoring of access to log data (e.g. copying, deleting, modifying or viewing).
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- The integrity of log data is protected, or any modification is detected and attributed. The logging architecture has mechanisms, policies, processes and procedures to ensure that it can protect itself from threats comparable to those it is trying to identify. This includes protecting the essential function(s) itself, and the data within it.
|
||||
- Log data analysis and normalisation is only performed on copies of the data keeping the master copy unaltered.
|
||||
- Log data is synchronised, using an accurate common time source, so that separate datasets can be correlated in different ways.
|
||||
- Access to log data is limited to those with business need and no others.
|
||||
- All actions involving all log data (e.g. copying, deleting, modifying or viewing) can be traced back to a unique user.
|
||||
- Legitimate reasons for accessing log data are given in use policies.
|
||||
|
||||
- sub-principle:
|
||||
name: C1.c Generating Alerts
|
||||
description: Evidence of potential security incidents contained in your monitoring data is reliably identified and triggers alerts.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Alerts from third party security software are not investigated (e.g. Anti-Virus (AV) providers).
|
||||
- Logs are distributed across devices with no easy way to access them other than manual login or physical action.
|
||||
- The resolution of alerts to a network asset or system is not performed.
|
||||
- Security alerts relating to essential function(s) are not prioritised.
|
||||
- Logs are reviewed infrequently.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Alerts from third party security software are investigated, and action taken.
|
||||
- Some, but not all, log data can be easily queried with search tools to aid investigations.
|
||||
- The resolution of alerts to a network asset or system is performed regularly.
|
||||
- Security alerts relating to some essential function(s) are prioritised.
|
||||
- Logs are reviewed at regular intervals.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Log data is enriched with other network knowledge and data when investigating certain suspicious activity or alerts.
|
||||
- A wide range of signatures and indicators of compromise is used for investigations of suspicious activity and alerts.
|
||||
- Alerts can be easily resolved to network assets using knowledge of networks and systems. The resolution of these alerts is performed in almost real time.
|
||||
- Security alerts relating to all essential function(s) are prioritised and this information is used to support incident management.
|
||||
- Logs are reviewed almost continuously, in real time.
|
||||
- Alerts are tested to ensure that they are generated reliably and that it is possible to distinguish genuine security incidents from false alarms.
|
||||
- sub-principle:
|
||||
name: C1.d Identifying Security Incidents
|
||||
description: You contextualise alerts with knowledge of the threat and your systems, to identify those security incidents that require some form of response.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Your organisation has no sources of threat intelligence.
|
||||
- You do not apply updates in a timely way, after receiving them (e.g. AV signature updates, other threat signatures or Indicators of Compromise (IoCs)).
|
||||
- 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.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Your organisation uses some threat intelligence services, but you don't necessarily choose sources or providers specifically because of your business needs, or specific threats in your sector (e.g. sector-based infoshare, ICS software vendors, anti-virus providers, specialist threat intel firms, special interest groups).
|
||||
- You receive updates for all your signature based protective technologies (e.g. AV, IDS). You apply some updates, signatures and IoCs in a timely way.
|
||||
- You know how effective your threat intelligence is (e.g. by tracking how threat intelligence helps you identify security problems).
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You have selected threat intelligence sources or services using risk-based and threat- informed decisions based on your business needs and sector (e.g. vendor reporting and patching, strong anti-virus providers, sector and community-based infoshare, special interest groups).
|
||||
- You apply all 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 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).
|
||||
- sub-principle:
|
||||
name: C1.e Monitoring Tools and Skills
|
||||
description: Monitoring staff skills, tools and roles, including any that are outsourced, should reflect governance and reporting requirements, expected threats and the complexities of the network or system data they need to use. Monitoring staff have knowledge of the essential function(s) they need to protect.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- There are no staff who perform a monitoring function.
|
||||
- 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 some significant parts of the defined workflow.
|
||||
- Monitoring tools are only able to make use of a fraction of log data being collected.
|
||||
- Monitoring tools cannot be configured to make use of new logging streams, as they come online.
|
||||
- Monitoring staff have a lack of awareness of the essential function(s) the organisation provides, what assets relate to those functions and hence the importance of the log data and security events.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Monitoring staff have some investigative skills and a basic understanding of the data they need to work with.
|
||||
- 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 unsophisticated and untargeted attack types.
|
||||
- Your monitoring tools work with most log data, with some configuration.
|
||||
- Monitoring staff are aware of some essential function(s) and can manage alerts relating to them.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You have monitoring staff, who are responsible for the analysis, investigation and reporting of monitoring alerts covering both security and performance.
|
||||
- Monitoring staff have defined roles and skills that cover all parts of the monitoring and investigation process.
|
||||
- Monitoring staff follow policies, processes and procedures that address all governance reporting requirements, internal and external.
|
||||
- Monitoring staff are empowered to look beyond the fixed process to investigate and understand non-standard threats, by developing their own investigative techniques and making new use of data.
|
||||
- Your monitoring tools make use of all log data collected to pinpoint activity within an incident.
|
||||
- Monitoring staff and tools drive and shape new log data collection and can make wide use of it.
|
||||
- Monitoring staff are aware of the operation of essential function(s) and related assets and can identify and prioritise alerts or investigations that relate to them.
|
||||
- principle:
|
||||
name: Principle C2 Proactive Security Event Discovery
|
||||
description: The organisation detects, within network and information systems, malicious activity affecting, or with the potential to affect, the operation of essential functions even when the activity evades standard signature based security prevent/detect solutions (or when standard solutions are not deployable).
|
||||
sub-principles:
|
||||
- sub-principle:
|
||||
name: C2.a System Abnormalities for Attack Detection
|
||||
description: You define examples of abnormalities in system behaviour that provide practical ways of detecting malicious activity that is otherwise hard to identify.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Normal system behaviour is insufficiently understood to be able to use system abnormalities to detect malicious activity.
|
||||
- You have no established understanding of what abnormalities to look for that might signify malicious activities.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Normal system behaviour is fully understood to such an extent that searching for system abnormalities is a potentially effective way of detecting malicious activity (e.g. You fully understand which systems should and should not communicate and when).
|
||||
- System abnormality descriptions from past attacks and threat intelligence, on yours and other networks, are used to signify malicious activity.
|
||||
- The system abnormalities you search for consider the nature of attacks likely to impact on the network and information systems supporting the operation of your essential function(s).
|
||||
- The system abnormality descriptions you use are updated to reflect changes in your network and information systems and current threat intelligence.
|
||||
- sub-principle:
|
||||
name: C2.b Proactive Attack Discovery
|
||||
description: You use an informed understanding of more sophisticated attack methods and of normal system behaviour to monitor proactively for malicious activity.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- You do not routinely search for system abnormalities indicative of malicious activity.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You routinely search for system abnormalities indicative of malicious activity on the network and information systems supporting the operation of your essential function(s), generating alerts based on the results of such searches.
|
||||
- You have justified confidence in the effectiveness of your searches for system abnormalities indicative of malicious activity.
|
||||
|
||||
- objective:
|
||||
name: Objective D - Minimising the impact of cyber security incidents
|
||||
description: Capabilities exist to minimise the adverse impact of a cyber security incident on the operation of essential functions, including the restoration of those function(s) where necessary.
|
||||
principles:
|
||||
- principle:
|
||||
name: Principle D1 Response and Recovery Planning
|
||||
description: There are well-defined and tested incident management processes in place, that aim to ensure continuity of essential function(s) in the event of system or service failure. Mitigation activities designed to contain or limit the impact of compromise are also in place.
|
||||
sub-principles:
|
||||
- sub-principle:
|
||||
name: D1.a Response Plan
|
||||
description: You have an up-to-date incident response plan that is grounded in a thorough risk assessment that takes account of your essential function(s) and covers a range of incident scenarios.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Your incident response plan is not documented.
|
||||
- Your incident response plan does not include your organisations identified essential function(s).
|
||||
- Your incident response plan is not well understood by relevant staff.
|
||||
- subprincipleitemgroup:
|
||||
kind: Partially
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Your incident response plan covers your essential function(s).
|
||||
- Your incident response plan comprehensively covers scenarios that are focused on likely impacts of known and well understood attacks only.
|
||||
- Your incident response plan is understood by all staff who are involved with your organisation's response function.
|
||||
- Your incident response plan is documented and shared with all relevant stakeholders.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Your incident response plan is based on a clear understanding of the security risks to the network and information systems supporting your essential function(s).
|
||||
- Your incident response plan is comprehensive (i.e. covers the complete lifecycle of an incident, roles and responsibilities, and reporting) and covers likely impacts of both known attack patterns and of possible attacks, previously unseen.
|
||||
- Your incident response plan is documented and integrated with wider organisational business plans and supply chain response plans, as well as dependencies on supporting infrastructure (e.g. power, cooling etc).
|
||||
- Your incident response plan is communicated and understood by the business areas involved with the operation of your essential function(s).
|
||||
|
||||
|
||||
- sub-principle:
|
||||
name: D1.b Response and Recovery Capability
|
||||
description: You have the capability to enact your incident response plan, including effective limitation of impact on the operation of your essential function(s). During an incident, you have access to timely information on which to base your response decisions.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Inadequate arrangements have been made to make the right resources available to implement your response plan.
|
||||
- Your response team members are not equipped to make good response decisions and put them into effect.
|
||||
- Inadequate back-up mechanisms exist to allow the continued operation of your essential function(s) during an incident.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You understand the resources that will likely be needed to carry out any required response activities, and arrangements are in place to make these resources available.
|
||||
- You understand the types of information that will likely be needed to inform response decisions and arrangements are in place to make this information available.
|
||||
- Your response team members have the skills and knowledge required to decide on the response actions necessary to limit harm, and the authority to carry them out.
|
||||
- Key roles are duplicated, and operational delivery knowledge is shared with all individuals involved in the operations and recovery of the essential function(s).
|
||||
- Back-up mechanisms are available that can be readily activated to allow continued operation of your essential function(s), although possibly at a reduced level, if primary network and information systems fail or are unavailable.
|
||||
- Arrangements exist to augment your organisation’s incident response capabilities with external support if necessary (e.g. specialist cyber incident responders).
|
||||
|
||||
|
||||
- sub-principle:
|
||||
name: D1.c Testing and Exercising
|
||||
description: Your organisation carries out exercises to test response plans, using past incidents that affected your (and other) organisation, and scenarios that draw on threat intelligence and your risk assessment.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Exercises test only a discrete part of the process (e.g. that backups are working), but do not consider all areas.
|
||||
- Incident response exercises are not routinely carried out or are carried out in an ad-hoc way.
|
||||
- Outputs from exercises are not fed into the organisation's lessons learned process.
|
||||
- Exercises do not test all parts of the response cycle.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Exercise scenarios are based on incidents experienced by your and other organisations or are composed using experience or threat intelligence.
|
||||
- Exercise scenarios are documented, regularly reviewed, and validated.
|
||||
- Exercises are routinely run, with the findings documented and used to refine incident response plans and protective security, in line with the lessons learned.
|
||||
- Exercises test all parts of your response cycle relating to your essential function(s) (e.g. restoration of normal function(s) levels).
|
||||
|
||||
|
||||
|
||||
|
||||
- principle:
|
||||
name: Principle D2 Lessons Learned
|
||||
description: When an incident occurs, steps are taken to understand its root causes and to ensure appropriate remediating action is taken to protect against future incidents.
|
||||
sub-principles:
|
||||
- sub-principle:
|
||||
name: D2.a Incident Root Cause Analysis
|
||||
description: When an incident occurs, steps must be taken to understand its root causes and ensure appropriate remediating action is taken.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- You are not usually able to resolve incidents to a root cause.
|
||||
- You do not have a formal process for investigating causes.
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- Root cause analysis is conducted routinely as a key part of your lessons learned activities following an incident.
|
||||
- Your root cause analysis is comprehensive, covering organisational process issues, as well as vulnerabilities in your networks, systems or software.
|
||||
- All relevant incident data is made available to the analysis team to perform root cause analysis.
|
||||
|
||||
- sub-principle:
|
||||
name: D2.b Using Incidents to Drive Improvements
|
||||
description: Your organisation uses lessons learned from incidents to improve your security measures.
|
||||
subprincipleitemgroups:
|
||||
- subprincipleitemgroup:
|
||||
kind: Not
|
||||
condition: At least one
|
||||
subprincipleitem:
|
||||
- Following incidents, lessons learned are not captured or are limited in scope.
|
||||
- Improvements arising from lessons learned following an incident are not implemented or not given sufficient organisational priority
|
||||
- subprincipleitemgroup:
|
||||
kind: Achieved
|
||||
condition: All
|
||||
subprincipleitem:
|
||||
- You have a documented incident review process/policy which ensures that lessons learned from each incident are identified, captured, and acted upon.
|
||||
- Lessons learned cover issues with reporting, roles, governance, skills and organisational processes as well as technical aspects of network and information systems.
|
||||
- You use lessons learned to improve security measures, including updating and retesting response plans when necessary.
|
||||
- Security improvements identified as a result of lessons learned are prioritised, with the highest priority improvements completed quickly.
|
||||
- Analysis is fed to senior management and incorporated into risk management and continuous improvement.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user