DCO and Me: A Commander’s Aide-de-Memoire
Cyber defensive and offensive operations are now a recognized component of the defence and warfighting landscape, with some countries choosing to elevate cyber to be an operational environment on par with Land, Sea, and Air. As investment into this new domain continues, organization will focus efforts on advanced technical capabilities and training an expert work force, as they are fundamental to successful operations. The next tactical bound for a fully mature cyber capability is to achieve deliberate synchronization of cyber operations across the many supported and supporting functions. At the centre of any synchronization efforts are commanders and senior decision makers (hereafter referred to generically as commanders) that understand their role and act to force the necessary synchronization.
The logical question from any commander wanting to be this forcing function is “Where do I start?” This article will discuss key points for planning that will help enable today’s commanders and command staff to be effective, as well as some pitfalls to avoid. This discussion will be limited to Defensive Cyber Operations (DCO), or enabling mission success by countering the adversary use of cyber tools, and highlight what can be done to enable it. (Specific recommendations to commanders have been italicized.)
As the DCO community matures and evolves, commanders and their operational staff must also invest in evolving their processes and perspectives to account for cyber threats, integrate cyber into operational planning and execution activities as a core element, and generally prepare to make effective decisions in relation to their mission or area of responsibility. The fundamental responsibility to ensure that DCO capabilities and operations are aligned within a given mission rests with the individual responsible for that mission–the commander–who will need to provide guidance and direction supported by specialist advice.
IT security and cyber defence communities do not usually succeed in setting up commanders for success in providing guidance and direction, for multiple reasons. Technical people tend to focus on technical issues rather than the mission or operational objectives that the system itself supports. The IT security community tends to lean toward compliance and policy enforcement as a mechanism to manage highly complex systems in repeatable ways. Inexperienced intelligence analysts tend to see ghosts everywhere and confuse the possible with the likely. Standard cyber lexicon is anything but standard. Risk and decision-making models are network and technology centric and were developed largely without understanding how commanders make decisions. If a commander was confused or hesitant to give direction relating to cyber, it is clearly understandable.
The good news is that commanders do not need to be cyber ninjas in order to provide the direction needed for the integration of cyber into operations to succeed; they need to be able to contextualize their own experience, knowledge, and skills and make it relevant. In fact, as will be discussed further, being able to look at cyber threats and risks without the bias of IT security or cyber operations is very beneficial for making sure planning, preparation, and respond actions are measured and operationally meaningful.
Key points for planning
Commanders need to understand the context around cyber events, rather than the technical details of the issue. When presented with a cyber threat or event, a commander needs to find a way to discover this context. For example, a cyber incident could be reported as ‘a set of malicious emails that was sent to two members of the finance section that ended up sending 8 GB of data to an internet server.’ The incident would have been dealt with by technical staff and closed once the infection was removed and the user restored. A commander may not care about what seems to be a routine incident that the technical community is happy to run with. If this is changed to ‘a group of two people broke into the headquarters building, sought out two desks in the finance section, and stole three specific files and left,’ the commander would not likely be okay with closing the file once the cabinet and door was fixed. They would ask about the intruders, what they stole, and what could be done to find them.
Don’t conflate the means by which an event occurs with the context of the impact. An event may have occurred through cyber, but that does not mean that the effects and their ability to counter those effect are limited to cyber means. In the example above, cyber entities could gather all of the relevant data on the event, but that is only part of the complete picture. To determine the who and why, a commander needs to treat the event like any other sort of theft or espionage and task appropriate investigative and intelligence teams.
The absence of a holistic and synchronized approach to cyber can impact a commander’s mission specifically: the cost of cyber efforts increases unnecessarily; cyber efforts are unfocused and take cycles away from operational planning and execution (Ops) personnel; a mission may not be prepared for predictable and preventable cyber threats; or, a mission is uncapable of countering deliberate and integrated adversary effects delivered through or enabled by cyber means. Practical planning activities should answer fundamental questions, such as: who are the adversaries I care about and what will they aim to achieve; what are the realistic ways that their aims can be achieved or assisted through cyber means; what can be done to form the technical terrain (the state of mission networks) to provide a defensive advantage; what potential actions need to be prepared; and what plans, tools, and training are required to prepare for likely threat scenarios. Use the same thought process for cyber as any other threat and ensure planning is integrated into broader Ops and Int processes.
Objectives of an adversary do not change when using cyber tools. Criminal groups want to make money, hacktivists push an agenda, foreign intelligence services conduct espionage, foreign states seek to project influence and power, and militaries want to cause specific effects at the time and place of their choosing. Cyber is one tool of many that adversaries can leverage. This fact should prompt the consideration of the following: priority for planning and preparation should be given to cyber threats that could support adversary objectives; any contingency plans for dealing with real-world objectives should include a cyber component within them; any planning activities that aim to counter adversary objectives should consider what possible actions the adversary could take using cyber tools. Be confident that your experience and knowledge in the military domain is highly relevant to making effective decisions relating to cyber within that same domain. If a commander cannot see how a particular cyber threat could help an adversary support their objective, then it is likely not a valid threat to the mission.
Assets or information that are critical to the mission may not be of interest and value to an adversary. In most cases, the two sets can be represented in overlapping Venn diagrams that should inform IT security and cyber defensive activities. IT security is a tool to project assets that are critical to the mission, where cyber defence is a tool to counter adversary outcomes. Both activities should be well coordinated with each other as they are highly interdependent. Ensure that asset and service criticality is used to drive IT security, that adversary interest is used to drive any additional specific defences or response actions, and that both mutually support each other.
The effectiveness of DCO is determined before the engagement occurs, through planning and preparation of the environment. If an adversary chooses to use cyber against an operation, they will be forced to interact with the networking and security environment that the defender has established. In this respect, the defender has the advantage unless they have chosen to cede it deliberately or through inaction. Should a commander not wish to cede the advantage, they have the option to cause the planning to occur that will design and deploy the equipment and processes required to establish it. Any related activities need to occur before a network is put to use supporting a mission, as trying to retake the advantage within a system that has already been built, shipped, and turned on is akin to trying to design and install reactive armour on a tank while it is in combat. Seize the advantage in the cyber environment before a system is deployed, and direct accordingly.
Succeeding in cyber is a team sport. Commanders are uniquely positioned to obtain significant support from national cyber elements if they choose to ask for assistance. To obtain effective support, commanders need to ensure that systems have the technical ‘plumbing’ required for leveraging national or centralized capabilities. The need for this may be counterintuitive as commanders do not usually need to make sure that third line support and logistics systems have been set up to be compatible with the mission. Further requirements can be identified to allow for local and operational support elements to have access to cyber tools. To enable this support, national elements will ask for context about the mission, events, configuration, etc., which they need to customize their support. Ensure that the conditions are set to obtain support from cyber capabilities external to the mission. This requires asking for assistance and working to ensure that anyone providing support has what they require. Commanders should not mistake the existence of centralized cyber authorities as a removal of their responsibility to risk manage their mission.
Making sense of the cyber environment and making effective decisions at a senior level is often made more complicated than it needs to be. These complications often originate in how IT security, IT systems, and cyber were grown over time. Commanders need to be aware of major pitfalls in decision-making and how they can be overcome.
A key risk is to allocate a disproportionate amount of focus on ‘cyber-meteors’, which are high impact scenarios that are technically possible but highly unlikely. Something that is possible is not always likely. Expending resources on dealing with ‘cyber-meteors’, which are very low risk due to a lack of likelihood, is a drain on resources that could otherwise be put to more effective use. Stuxnet, a virus that spread around the world while attempting to locate and disable Iranian uranium centrifuges at the Natanz nuclear facility, is a prime example of a meteor. Looking at the technical elements of Stuxnet, it is easy to draw the conclusion that all networks and weapons platforms are vulnerable to Stuxnet-like attacks. Consider the sheer scope and scale of the long running intelligence efforts required for Stuxnet to be successful, as well as the planning and execution of real-world operations to get the malware close to its target. From start to finish, the Stuxnet attack likely took many months, if not years, to gather intelligence, plan, and target this single specific system. It is only useful to compare Stuxnet to a threat to another system if it has the same strategic value as Natanz to a capable adversary. Don’t worry about cyber-meteors. To verify if a risk is a meteor ask: “When has this risk been seen in a real situation with relevant context to this mission?”, “Under which conditions would this risk be the attack mechanism selected by a known adversary?”, and “Why would the use of this tactic be of optimal value to a known adversary?”
There are many IT risk-based methodologies that are used to support IT/cyber decision-making, most of which are ineffective for a variety of reasons. IT and cyber communities are replete with various risk-based methodologies, many of which are deeply flawed or inappropriate to support a military commander’s decision-making. When being presented with a risk assessment, a commander or their staff should challenge conclusions if they observe any of the following circumstances:
- There is a vulnerability assessment that is masquerading as risk assessment. IT security professionals have a tendency to generalize operational impacts and threat likelihoods, which can cause cases where non-compliance to a standard or the mere presence of a vulnerability is called a risk. Risks only occur where there is also a threat (likelihood) or a verified potential impact. Don’t get caught protecting a CF-18 from a meteor.
- Be wary of risk assessments that use general threat levels to describe the threat to a system. Requesting a cyber threat level for an entire system, geographic region, or operation is as useful as asking what the temperature is on the planet. Drive your intelligence staff to get useful threat assessments.
- When considering directed threats from state-level adversaries, be wary of risk assessments that do not account for non-technical aspects of how attacks would be planned and executed within a larger non-cyber effort, as this creates cyber-meteors. Relevant factors inhibiting cyber tactically include: duration of effect, development cost, complexity, opportunity, the ability to synchronize effects, and the scale of targets. Drive your staff to get useful risk assessments, accounting for how cyber is a single component of the larger picture.
- Avoid using any risk assessments that are oriented toward a specific standard rather than toward the realities of the mission.
Commanders should recognize that having DCO capabilities can enable them to actively defend a system and avoid relying upon risk avoidance as a primary strategy. Making quality risk decisions means challenging models and information that do not make sense.
Lexicon is the enemy of effective decision-making. Placing ‘cyber’ or ‘IT’ in a phrase confuses its meaning and creates the impression that it is somehow distinct form the word it is placed with. For example, cyber espionage is espionage leveraging cyber. Cyber mission assurance should be a sub component of mission assurance. IT security should be an integrated component of security. Cyber intelligence, surveillance, and reconnaissance (ISR) should be a subcomponent of ISR. Eliminate the disjointedness between functions that have been segregated by lexicon and the cyber prefix by simply flipping them around and directing the function that cyber was modifying to ensure that cyber is integrated. For example, those responsible for ISR should be tasked with ensuring that cyber ISR is integrated into ISR.
To succeed in cyber, commanders should ensure that they understand how to frame the cyber problem to their mission, cause integrated planning to occur, drive intelligence producers to provide relevant information, ensure that technical cyber specialist look beyond the technical, and avoid pitfalls in decision-making.
About the Author
For the past decade, Nicholas Scheurkogel has led key cyber intelligence capabilities at the Department of National Defence (DND) including strategic cyber assessment, tactical support to cyber defence teams, and intelligence operations. Since 2006, he was the go-to cyber threat expert at DND and beyond. He is currently Director, Cyber Intelligence at Cytelligence.