Selecting Strategic, Tactical, and Operational Solutions
Once organizations have a clear understanding of their information assets and the value they represent to the business, the various vulnerabilities that assets exhibit, and the threats they are facing, they will be better placed to begin development of an overall cyberattack prevention and response strategy which will form the basis of more detailed action plans.
This chapter will deal with these two principal areas:
Prevention—the proactive side of cybersecurity and business continuity, which aims to reduce the likelihood of a successful cyberattack by putting measures in place that either stop such an attack or at least reduce its impact.
Response—the reactive side of cybersecurity and business continuity, which aims to equip the organization for reacting quickly to a cyberattack that is not stopped by preventive measures, but again limits its impact.
The response strategy will also determine the approach that the organization takes to returning its operations to a normal or near-normal level.
Equally importantly, the response strategy will also deal with how the organization should communicate with its customers, stakeholders, the media, and where necessary, government or public sector authorities and regulators.
In Chapter 7, we will describe how organizations should implement these proactive and reactive measures and turn the response strategies into contingency plans to be used when required.
In Chapter 2, we looked very briefly at the strategic choices for how to deal with cybersecurity incidents, so let’s now take a more detailed look. The overall process of selection of the strategic options is shown in Figure 6.1.
Figure 6.1 The strategic risk management process
Firstly, we must decide whether or not we can avoid or terminate the risk. For example, if the organization was going through the process of transferring its confidential customer information to a cloud service provider and it had been identified that this action would locate the information in a jurisdiction that did not meet data protection legislation, the recommendation would be to cancel the transfer, which would constitute avoidance or termination of the risk.
However, it must be borne in mind that this might raise two secondary impacts. Firstly, there might already have been some expenditure for work already carried out, possibly also incurring contractual penalties; and secondly, the organization would still have to find a replacement cloud service supplier if it wished to continue to outsource the information, and again this would incur further cost.
If the risk cannot be avoided or terminated, the next option would be to share or transfer the risk. This normally requires the involvement of a third party that would take responsibility for managing the risk either in total or in part, and while this might appear to be a simple solution, it may not be possible to transfer or share the entire amount of the risk, or it may be prudent to share the risk among a number of third parties.
An example of risk sharing or transfer would be when an organization takes out insurance against the losses incurred if its information is lost or damaged. An insurance company might be willing to accept all or part of the risk, but the organization would have to balance the cost of premiums against the potential losses that might be incurred if the information was lost, stolen, or destroyed.
To ensure that the cost of such insurance premiums does not become excessive, the insurer might insist on guarantees such as the provision of disaster recovery systems, and might set an upper limit on the payout, in which case the organization would have to accept some residual risk.
Alternatively, an organization that placed its business-critical information with a cloud service provider would reasonably expect the provider to cover at least a large proportion if not the whole of the risk.
In both examples, it must be remembered that overall ownership of the risk must always be retained by the organization itself.
In cases where risk sharing or transfer is not a viable option, the next choice would be to investigate risk reduction or modification, which is sometimes referred to as risk treatment. When the organization considers the option to reduce or modify risk, it involves either reducing the impact or reducing the likelihood and occasionally a mixture of both, since there are many approaches that can be used in combination to reduce the level of risk down to a level below that of the organization’s risk appetite.
An example of risk reduction would be the reduction of the likelihood of unauthorized access by improving basic user ID and password checks with the addition of a second authentication factor using a security token. This would significantly strengthen the process reducing the likelihood of unauthorized access, but the organization would need to balance this against the costs of token deployment and support, together with the additional risks brought about by lost or stolen tokens.
A second example of risk reduction would be in reducing the impact of the loss or theft of a laptop by encrypting its entire hard disk drive. Although the capital value of the laptop could still be lost (although this might be recoverable through insurance), the information contained on the laptop would be totally secure as decryption without the master password at this level is considered to be virtually impossible. Naturally, the information itself would need to have been previously backed up.
As with the option to share or transfer, the organization might accept some residual risk, such as the replacement cost of the laptop, and there could also be additional expenditure for configuration and restoring software and data. Residual risk must be recorded and monitored on an ongoing basis.
When no other options are open, when a risk is too costly to treat by any other means, where following other forms of risk treatment the risk level has reached a point where no further treatment is possible, or if the level of risk is very low, then the organization must accept or tolerate the risk. However, it is important to understand that this does not mean that it can be ignored.
Risks that are accepted must always be documented as such, and must be reviewed periodically in order to ensure that the level of risk has not changed in either its impact or likelihood, which would require that the choice of avoid/terminate, share/transfer, or reduce/modify is taken again.
Tactical and Operational Options
Tactical Controls
Once the choice of strategic option has been made, there will be four possible tactical approaches to treating the risk. These are detective, preventative, directive, or corrective, and will depend to some extent upon the strategic choice already taken. Sometimes these will be used individually and sometimes in conjunction with one another as we shall see later. As with strategic controls, tactical controls themselves do not actually treat the risks, but lead us to a more specific course of action determined by the operational controls. The overall picture is illustrated in Figure 6.2.
Figure 6.2 Tactical and operational options
Let’s now look at each of these options in greater detail.
Detective controls are those that permit the organization to be aware that an incident is taking place, but they can achieve nothing else—they are unable to alter either the likelihood or the impact of a risk, and they are normally used in conjunction with other types of tactical control that are able to do so.
If the warning suggests that some form of response should be taken as a result of this alert, then a separate (probably corrective) control must be initiated either automatically by the system that has detected the incident or by security staff monitoring the application. Intrusion detection software is an example of a detective control.
Preventative controls are used to stop an incident from occurring, and the choice of which operational control or controls are used will determine the steps taken. Preventative controls will reduce or even remove the likelihood that an incident will occur, and as a consequence will either reduce or terminate the risk.
A simple example of a preventative control is that of passwords on user accounts; without knowing both the user identifier and the associated password, access to the user account is barred.
Directive controls are normally based on policies, processes, procedures, and work instructions, all of which dictate what actions must or must not be undertaken.
As with detective controls, directive controls on their own cannot change either the impact or the likelihood of an incident taking place, since they only reinforce the organization’s policies. It follows, therefore, that if staff adhere to policies, the controls will be successful, otherwise they will be ineffective. For this reason, directive controls are frequently coupled with other types such as preventative or corrective controls in order to ensure that the policies are followed.
An example of a directive control is a policy stating that users must not load unauthorized software onto their company computers. One or more detective controls might be used in conjunction with this kind of control in order to monitor compliance, and penalties may be applied for users who fail to adhere to the policy.
Corrective controls are those that will change either the impact or the likelihood of a risk, but in this case after the incident has occurred, their purpose being to fix the problem and ultimately to prevent it from recurring.
Operational Controls
There are just three types of operational control—procedural, physical, and technical.
As the name suggests, procedural controls simply set out actions that users and IT staff must or must not undertake in defined situations. Procedural controls alone cannot reduce or eliminate either the impact or the likelihood of a risk occurring, but are designed to do so when users adhere to them.
An example of a procedural control is the requirement for users to lock their screens when away from their computer, so that some form of user authentication must be undertaken before it can be used again. This is a directive/procedural control.
Physical controls are designed to address both physical and environmental threats, and are designed to reduce or eliminate either the impact or the likelihood aspect of the risk. They may be delivered through technical means, but the technology is normally not related to the information itself.
An example of a physical control would be an electronic entry management system that required an access card and PIN to gain entry to a computer room. This would be a preventative/physical control.
Technical controls normally refer to controls that are directly connected to the technology that supports the information infrastructure. They are implemented either in hardware, in software, and frequently in both. An example would be configuring a rule in a Firewall, and this could either be a corrective/technical control or a preventative/technical control.
Different aspects of the organization’s operations will require very differing approaches in identifying the most appropriate choices for dealing with cybersecurity issues. There are no hard-and-fast rules as to how these should be applied, but in general, once the tactical options—directive, preventative, detective, and corrective—have been selected, the operational choices should be fairly obvious, but it is important to remember that more than one tactical choice and more than one operational choice may be involved in providing the final solution.
Where to Begin
It is often said that it is difficult to see the wood for the trees, and this can be especially true when trying to decide where to begin in identifying firstly the areas that might require attention, and secondly what to do about them, remembering that. As you can see from Figure 6.2, not all forms of tactical control make use of all forms of operational controls.
Tables 6.1, 6.2, and 6.3 provide an excellent starting point for all kinds of organization in understanding where to begin with this.
Table 6.1 Critical Security Controls, version 5.0
| No | Control title |
| 1 | Inventory of authorized and unauthorized devices |
| 2 | Inventory of authorized and unauthorized software |
| 3 | Secure configurations for hardware and software on mobile devices, laptops, workstations, and servers |
| 4 | Continuous vulnerability assessment and remediation |
| 5 | Malware defenses |
| 6 | Application software security |
| 7 | Wireless access control |
| 8 | Data recovery capability |
| 9 | Security skills assessment and appropriate training to fill gaps |
| 10 | Secure configurations for network devices such as firewalls, routers, and switches |
| 11 | Limitation and control of network ports, protocols, and services |
| 12 | Controlled use of administrative privileges |
| 13 | Boundary defense |
| 14 | Maintenance, monitoring, and analysis of audit logs |
| 15 | Control access based on the need to know |
| 16 | Account monitoring and control |
| 17 | Data protection |
| 18 | Incident response and management |
| 19 | Secure network engineering |
| 20 | Penetration tests and red team exercises |
Table 6.2 ISO/IEC 27001/27002 controls
| Reference | Title (Number of controls) |
| A.5 | Information security policies (2) |
| A.6 | Organisation of information security (7) |
| A.7 | Human resource security (6) |
| A.8 | Asset management (10) |
| A.9 | Access control (14) |
| A.10 | Cryptography (2) |
| A.11 | Physical and environmental security (15) |
| A.12 | Operations security (14) |
| A.13 | Communications security (7) |
| A.14 | System acquisition, development, and maintenance (13) |
| A.15 | Supplier relationships (5) |
| A.16 | Information security incident management (7) |
| A.17 | Information security aspects of business continuity management (4) |
| A.18 | Compliance (8) |
Table 6.3 NIST special publication 800-53 revision 4 controls
| Identifier | Family (Number of controls) |
| AC | Access control (25) |
| AT | Awareness and Training (5) |
| AU | Audit and Accountability (16) |
| CA | Security Assessment and Authorization (9) |
| CM | Configuration Management (11) |
| CP | Contingency Planning (13) |
| IA | Identification and Authentication (11) |
| IR | Incident Response (10) |
| MA | Maintenance (6) |
| MP | Media Protection (8) |
| PE | Physical and Environmental Protection (20) |
| PL | Planning (9) |
| PS | Personnel Security (8) |
| RA | Risk Assessment (6) |
| SA | System and Services Acquisition (22) |
| SC | System and Communications Protection (44) |
| SI | System and Information Integrity (17) |
| PM | Program Management (16) |
Critical Security Controls, Version 5.0
Table 6.1, containing 20 areas for consideration, is taken from the Council on Cyber Security’s document Critical Security Controls, version 5.01 and is covered in greater detail in Appendix A—Information on controls. It contains a variety of detective, preventative, directive, and corrective control areas, and will guide organizations through the most important aspects requiring attention.
ISO/IEC 27001/27002
Table 6.2 comes from the international Information Security Standards ISO/IEC 27001.
It covers 14 areas of information security, totaling 114 separate operational controls, which are described in greater detail in Appendix A. A more detailed description of the controls can also be found in ISO/IEC 27002 in its sections 5 to 18.
Again, all four areas of tactical controls—detective, preventative, directive, and corrective are covered.
National Institute of Standards and Technology (NIST) SP 800-53 Revision 4
Table 6.3 comes from NIST Special Publication 800-53 Revision 4, and contains 256 separate operational level controls, grouped into 18 categories in its Appendix F, and also conveniently maps them against ISO/IEC 27001 controls in its Appendix H. Again, these control categories are expanded and described more fully in Appendix A.
As with the previous two examples, this list also covers detective, preventative, directive, and corrective control areas.
Incident Management Plans
The final part of this chapter deals with incident management plans. There are a number of different types of plan that can be used in the business continuity context, and these fall into one of four groups:
Incident management plans deal with the initial response to the disruptive incident, and will usually be completed well before the recovery time objective is reached.
Business continuity plans help the organization to begin its recovery process once the initial disruptive incident has been resolved, and may be extended, depending on the maximum tolerable period of disruption.
Disaster Recovery plans will normally be initiated soon after the incident management stage begins, as recovery of IT systems is normally a high priority.
Once business continuity plans are complete or almost complete, the plan to recover the organization’s operations back to a normal or near-normal level is commenced, and this is generally referred to as a business resumption plan. In some instances, business continuity and business resumption plans may be one and the same, especially in smaller organizations.
Depending upon the organization’s style, the development of plans may be centralized across the whole organization, or may be developed at a departmental level, and then brought together with others to form a coordinated approach.
An owner is required for each plan produced—preferably either someone who already has experience in writing plans of this type or someone with some level of responsibility for putting the plans into action.
The objectives and scope (both those things that are in scope and those that are out of scope) should be defined, and if necessary, aligned with other related or interdependent plans, which will involve coordination between a number of planning teams.
The responsibilities of the incident management team or teams must be clearly identified, so that everybody understands their role when the plan is put into practice.
Once assembled, the plan should be reviewed before being “signed off,” following which it should be tested—initially in isolation, and once proven, in conjunction with other departmental or interdependent plans.
Format of Plans
So far, we have avoided any discussion about the format of the plans, but now is the time to consider this. As with the generic or specific contents, there may be an organization or parent company standard that must be followed.
Paper-based documentation has the advantage that no specific technology (apart from possibly a pair of spectacles) is required in order to read it, and it can easily be annotated by those using it. A major disadvantage of course is that if it is significant in size, it becomes less easy to carry around, update, and store. If versions change rapidly, as they often do in the early stages of plan development, then the waste of paper and toner can be excessive. However, some people do have a problem reading from a screen, so for them, paper may be the only choice.
Electronic versions of plans have the advantage that they can be very quickly updated and distributed, and are easily transportable on a memory stick for example. However, the media on which plans are stored must be secured against unauthorized access, and the presentation of the information must be straightforward.
Many organizations use a variety of standard “office” software applications to produce the plans—word processing software being the most common, but when it is necessary to include detailed layout diagrams, other more complex software such as computer-aided design software may be required. This can present a problem for the users of the plans, in that they would require access to all of the software applications in order just to read them. However, this can be overcome by arranging for all the documentation to be output in Adobe’s Portable Document Format (pdf), which is easily readable on any hardware platform using a free-of-charge pdf reader.
Some organizations also now provide staff with briefing cards that provide them with basic information of what to do in the event of a disruptive incident.
Typically, these will include the following key components:
The briefing cards may come in one of two forms—Letter, A4- or A5-sized printed and laminated documents aimed more generally at staff involved in the actual incident response, or credit card–sized folded “aides memoire” with the basic instructions for all staff, which can easily be carried in a pocket or purse at all times.
Plans will naturally be very specific to the organization, but will usually include a number of key elements:
Most plans begin with a brief introduction, outlining why the plan has been produced, and will describe its purpose and scope in rather more detail.
The roles and responsibilities of team members may also be described, and should some of these have variations in their reporting lines, these should also be included. For example, a team member may have the expected reporting line into his or her team leader, but may also have a requirement to report to a manager in another area of the organization.
The alerting and invocation processes should be described in detail, including the thresholds and trigger points, and again, the plan should take into account those situations in which the incident grows from a minor problem to a major one and crosses one or more thresholds along the way.
The plan should continue by describing the main activities, actions, and tasks, but may leave out the finer detail, especially if this is also contained in an operational level plan, such as a disaster recovery plan.
Any relevant background information that makes the plan more understandable should be included, as should the recovery and resumption priorities, which should have previously been agreed with senior management as a result of the earlier business impact analysis and the continuity requirements analysis, which we shall cover in greater detail in Chapter 7.
The plan must always contain contact information for key stakeholders, which might include a number of different contact options, and in the case of key suppliers, may also include reference information for out-of-hours support calls.
Finally, the plan should contain details of plan ownership and its version history, so that everybody who uses it can be certain they are working from the same version of the plan.
Incident Management Plans
Incident management plans should include the following:
Business Continuity Plans
For business continuity plans, the information would also include the following:
Disaster Recovery Plans
In addition to the items in incident management plans, disaster recovery plans will include the following:
Business resumption plans will provide details of the following:
Contact Information
Contact information has been mentioned in each of the above-mentioned plan types, and the list in the following paragraph gives suggestions as to the main requirements that need to be pulled together and placed in the appropriate plans:
ICT Configuration Information
Information for ICT configurations should include the following:
Summary
In this chapter, we have examined the strategic, tactical, and operational options for dealing with the prevention of cybersecurity attacks, reducing their impact if they do occur, and the types of plan required when dealing with the aftermath of a disruptive incident.
The next chapter in this book will deal with the actual business continuity activities that will take place to bring all of the aforementioned into effect.
__________________