See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/290027416

Identifying tools and technologies for professional offensive cyber operations

Article · January 2013

CITATIONS READS

4 1,139

2 authors, including:

Tim Grant
Ministry of Defense, Netherlands
72 PUBLICATIONS   364 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mission Execution Crew Assistant (MECA) View project

Information sharing in Command & Control View project

All content following this page was uploaded by Tim Grant on 19 December 2016.

The user has requested enhancement of the downloaded file.

Grant, T.J. & Prins, R. (2013). Identifying Tools and Technologies for Professional Offensive Cyber
th
Operations. In Hart, D. (ed), Proceedings, 8 International Conference on Information Warfare &
Security (ICIW 2013), Regis University, Denver, CO, USA, 25-26 March 2013, (book:) ISBN 978-1-
909507-09-8 / ISSN 2048-9870, pp.80-89.

Identifying Tools and Technologies for Professional Offensive Cyber Operations

1 2
Tim Grant , Ronald Prins
1
R-BAR, Benschop, The Netherlands
2
Fox-IT, Delft, The Netherlands
tim.grant.work@gmail.com
prins@fox-it.com

Abstract: Since 2008, several countries have published new national cyber security strategies that
allow for the possibility of offensive cyber operations. Typically, national strategies call for the
establishment of a cyber operations unit capable of computer network defence, exploitation, and, in
some nations, attack. The cyber operations unit will be manned by professionals and operate under
government authority compliant with national and international law. Our research focuses on offensive
cyber operations (i.e. computer network exploitation and attack). The cyber unit must be provided with
the right resources, in the form of accommodation, computing and networking infrastructure, tools and
technologies, doctrine, and training. The open literature gives an unbalanced view of what tools and
technologies a professional group needs because it emphasizes malware and, to a lesser extent, the
delivery media used by cyber criminals. Hence, the purpose of this paper is to identify systematically
the tools and technologies needed for professional, offensive cyber operations. A canonical model of
the cyber attack process was enhanced by adding control inputs and mechanisms, and tools and
technologies were extracted from these mechanisms. Both the enhanced model and the set of tools
and technologies have been checked by a subject matter expert.

Keywords: Offensive cyber operations; attack; canonical process model; tools; technologies; SADT.

1. Introduction

1.1 Background
Since 2008, several countries have published new national cyber security strategies that allow for the
possibility of defensive and offensive cyber operations. For example, the Netherlands’ Defence Cyber
Strategy (MinDef, 2012) lists defence, offence, and intelligence as spearpoints and calls for the
establishment of a Defence Cyber Command (DCC). The DCC will be manned by professionals and
operate under government authority compliant with national and international law. The centre will
need to be provided with resources, in the form of personnel, accommodation, computing and
networking infrastructure, tools and technologies, doctrine, and training. The Netherlands is one of ten
to twelve nations developing offensive cyber capabilities (Lewis & Timlin, 2011). The research
reported in this paper focuses on the tools and technologies needed for offensive cyber operations,
i.e. the combination of Computer Network Exploitation (intelligence) and Computer Network Attack.

A quick look at the information available on the Internet shows that there are many lists of tools used
by cyber criminals and, to a lesser extent, by ethical hackers. The emphasis is on malware. For
example, the SANS institute – a well-known cooperative research and education organization for
security professionals – identifies worms, rootkits, exploits, Trojans, and backdoors (SANS, 2012).
The MalwareInfo site (MalwareInfo, 2012) – provided by a consortium of anti-malware tool suppliers to
inform Dutch home computer users – lists virus, worm, spyware and adware, keylogger, tracking
cookie, browser hijacker, Trojan, dropper, dialler, rootkit, backdoor, and rogueware tools.

There are at least three reasons why such lists give an unbalanced view of the tools and technologies
that a professional team operating under government authority would need. Firstly, cyber criminals
and ethical hackers often operate as individuals, and not as a professional group. Rivalry among
criminals hinders cooperation. It is not unusual for one criminal to take over the target or botnet of
another. While criminals may be part of a loose group, this is more to exchange knowledge on specific
vulnerabilities, targets, or attack technologies than to attack a target together as a team. Ethical
hackers tend to concentrate on penetration testing and on reporting what target information is at risk,
rather than on the whole attack process. Secondly, the lists are unlikely to emphasize the mundane
tools supporting the attack process “logistics”. For example, intercepts show that cyber criminals use

1
chat for communicating with one another (Honeynet, 2008), but this technology does not appear in
the lists. Thirdly, cyber professionals from nations with an operational offensive capability are loath to
reveal their capabilities (McAfee, 2011).

Hence, another way must be found to identify tools and technologies. Ways in which this could be
done include:

Case study. Researchers could observe a set of cyber attacks and note the tools and
technologies that the attackers used.

Software engineering. The attack process could be modelled using software engineering
techniques and the tools and technologies extracted from the analysis.

Literature survey. A canonical list of tools and technologies could be constructed by
comparing the multiple lists, taxonomies, and ontologies to be found in the open literature.
There are three sources of literature: experienced hackers, the vendors of cyber security
software products (e.g. anti-virus (AV) packages, firewalls (FW), and intrusion detection
systems (IDS)) and services, and scientific publications.

Besides the questionable ethicality of the case study approach, it is doubtful if this would be
representative of offensive cyber operations performed by a professional group. A literature survey is
likely to over-emphasize malware. Hence, this paper takes the software engineering approach. In the
research reported here, the canonical process model from Grant, Burke & van Heerden (2012) was
enhanced by adding control inputs and mechanisms. A set of tools and technologies was extracted
from the mechanisms. Both the enhanced model and the set of tools and technologies were checked
by a subject matter expert.

1.2 Purpose, scope, and paper structure

The purpose of this paper is to identify the tools and technologies needed for professional offensive
cyber operations, based on software engineering analysis. The scope of our research is restricted to
operations:

Performed by a professional group of specialists operating under governmental authority;

Compliant with national and international law and with the prevailing doctrine and RoEs;

In response to an incoming attack or the impending threat of an incoming attack;

Where the response requires a penetrative counter-attack on a new target; and

Where the infrastructure (including Command & Control) for offensive cyber operations is
already in place.
Legal issues are outside the scope of our research.

This paper consists of five sections. After an introductory section, section 2 outlines the research
methodology. Section 3 describes the enhancement of the canonical attack process model. Tools and
technologies are extracted from the enhanced model in section 4. Section 5 draws conclusions, states
the contributions and limitations of the research, and outlines further research needed.

1.3 Operational context

We assume that the Dutch national and defence cyber strategy documents (MinJus, 2011) (MinDef,
2012) accurately define a professional group capable of offensive cyber operations. The national
strategy depends on collaboration between public and private organizations, between ministries, and
with other nations. At the governmental level, cyber security activities are led by the Ministry of
Security & Justice in partnership with the Ministries of Economic Affairs, Agriculture & Innovation,
Defence, and Internal Affairs. Offensive operations are the responsibility of the Ministry of Defence,
with the support of military intelligence (Schnitger & Folmer, 2011).

An offensive cyber operation can take three possible forms:

Counter-attack when the nation has already suffered an attack;

Pro-active defence when an impending attack threatens the nation;

An attack on opposing forces with and without associated conventional military action.

Although our research focuses on the first two, the organization and attack process should be
compliant with the existing arrangements for conventional military action to make the third form
possible when necessary. This implies that the professional group would include the following
specialist sub-groups (see Figure 1):

Strategists would determine whether an incoming attack or threat of an impending attack is
grave enough to require a military response and, when authorized, would determine the goals
and the rules of engagement (RoEs) for the counter-attack.

Intelligence analysts would select and gather information about the target organizations and
their computer-based systems, both before (e.g. attribution and reconnaissance) and after
(e.g. battle damage assessment) the counter-attack.

Planners would plan the counter-attack in detail, obtain and prepare the resources needed,
and test the plan in a simulated environment.

Weaponeers would prepare cyber weapons to the planners’ specifications by integrating
payloads (e.g. exploits) into delivery platforms (e.g. USB stick, virus).

Cyber operatives would rehearse and execute the testing plan using prepared resources,
aiming to achieve the attack goals defined by the strategists.

Figure 1. Operation in context.

The professional group has access to a variety of resources. These include overt and covert sources
of information, an archive of data and documents (e.g. from previous operations), a repository of tools
and technologies, a computing and communications infrastructure, and a set of facilities (i.e. buildings
or other accommodation). The operation would be monitored and controlled by a military commander.
Separate from the professional group, governmental authorities would provide governance at the
political and national level, approving each phase in the operation if justified by the information
obtained up to that point. C2 and governance processes are outside the scope of our research.

2. Methodology
The research reported in this paper uses rational reconstruction and the Structured Analysis & Design
Technique (SADT). In philosophy, rational reconstruction (RR) is defined as “a philosophical and
linguistic method that systematically translates intuitive knowledge of rules into a logical form”
(Habermas, 1976). The canonical process model for an attack was obtained by analysis, i.e. breaking
down the various process models found in the literature into its component steps. Then the “best-of-
breed” steps were synthesized into the canonical model. SADT notation was used to represent the
text describing how the output produced by one step was consumed as an input into one or more
subsequent steps. Using a formalisation like SADT enforces systematic analysis, and the graphical
notation provides Habermas’ (1976) “logical form”.

SADT (Marca & McGowen, 1988) is a software engineering technique that is highly suited to
specifying the behaviour of systems in terms of functional processes. The graphical notation
represents the system as a network of boxes (known as “nodes” and representing processes)
interconnected by arrows (known as “ICOMs”, i.e. inputs, controls, outputs, and mechanisms). Arrows
entering a box from the left represent data input, and arrows exiting a box from the right represent
data output. Arrows entering a box from above represent control inputs, constraining or guiding the
process. Arrows entering a box from below represent the mechanisms or resources needed to
perform the process. Details of the SADT methodology and validation rules may be found in (NIST,
1993). The analysis reported in this paper was supported by the IDEF shareware tool, which
facilitates creating SADT diagrams and validating them according to the NIST rules.

3. Enhancing the Canonical Process Model

In earlier work, Grant, Burke and van Heerden (2012) developed a canonical model of the attack
process by rationally reconstructing a set of seven process models found in the literature. Each model
was analysed using SADT without tool support. The canonical model was then constructed by linking
inputs to outputs, but controls and mechanisms were not identified. Since then, we have enhanced
the earlier model by systematically adding controls and mechanisms. Compliance with the NIST
(1993) methodology was aided by using the IDEF tool. Figure 2 shows the resulting process
breakdown for an offensive cyber counter-attack or pro-active defensive operation. Each process has
been numbered following the NIST conventions.

Figure 2. Canonical model - process breakdown.

Analysis started with a context diagram (not shown). Key inputs to Operation are the actual or
threatened effects of the attack on the victim systems. The victim systems themselves are included as
a mechanism because access to these systems is needed to establish how the attack was carried out
and who was responsible. Likewise, access is needed to the target system(s), i.e. the ones at which
the counter-attack will be directed, and their environment. Other mechanisms include the professional
group and their resources. Control inputs include “Authorisation”, showing that the operation can only
be executed with approval from the authorities at the political / national level, and “Law” representing
not only national and international law but also the prevailing doctrine for offensive cyber operations.

There are several outputs from Operation. There are requests to the governmental or political
authorities to proceed with the next phase in the attack. A wide variety of reports are generated during
the course of the attack. The cyber weapons used are themselves an output, together with two flags
to indicate what level of success has been reached in executing the attack. The “embedded” flag
indicates that the cyber weapons have been embedded into the target system. The “C2 open” flag
indicates that the target system has linked up to the professional group’s C2 servers and is ready to
receive commands. The “Commands (incoming)” input and the “Commands (outgoing)” output apply
when the counter-attack is aimed at converting the target system into a bot to be included in a botnet
under the professional group’s control. The “effects” output represents the actual effects of attacking
the target system, which may differ from the attack goals. Effects may be unintended and even
undesirable, e.g. collateral damage to other systems in the target’s environment.

Figure 3 shows how Operation is decomposed. Splitting the operation into five phases makes it
consistent both with the NATO standard approach to operations planning and with the assumed
specialisations within the professional group. As can be seen, the Professional Group mechanism is
split into Strategists, Analysts, Weaponeers, Planners, and Operatives.

Figure 3. Operation (node A0) as five phases.

Determine Goals (Phase 1) splits into four processes (not shown). In Monitor Threats, the Analysts
continually monitor selected parts of cyberspace for signs of an impending incoming attack. They use
sniffers, packet diversion tools, data extraction tools, and Advanced Persistent Threats (APTs) if these
have been previously inserted into the potential attackers’ systems. The outcome is a threat report. In
Assess Effects, the Analysts react to an incoming attack, using forensic tools and reverse engineering
techniques to establish what happened and who was responsible. They need access to the victim
system(s). They report the impact of the attack to the Strategists. In Obtain Authority, the Strategists
receive the threat and/or impact reports, and establish the severity of the threat and/or incoming
attack. If this breaches legal criteria, then the Strategists request authorisation from the authorities at
political and national level to initiate a (pre-emptive) counter-attack. They need secure
communications with the authorities, perhaps separate (e.g. at a higher security level) from the
communications linking the professional group. If the Strategists receive authorisation, then the
Define Goals & RoE process starts. Based on the threat and/or impact reports, the Strategists define
the counter-attack goals and the RoEs. They need access to Office Automation (OA) tools, such as
word-processing, spreadsheet, database, email, and presentation software. Finally, all the processes
generate an event-log that will eventually be used in evaluating the operation.

Select Targets (Phase 2) splits into four processes (not shown). In Footprint Organizations, the
Analysts gather information about the organization(s) to be attacked when given authorization by the
political / national authorities. The aim is to identify and localize the organization(s)’ computer-based
systems and key persons who could be useful as the targets of social engineering techniques. The
Analysts use open-source information sources, such as the organization(s)’ public websites, any
reports that may have been published by or about the organization, and other information that can be
obtained by searching the web, including social networking sites. Where necessary, this information
could be supplemented by information obtained from covert sources. The resulting footprint is a
database of relevant information about the organization(s), their computer systems, and key persons.
In Recce System(s), the focus of the Analysts’ attention is on these computer systems. They fill a
database describing the topologies of these systems and possible paths to access them, e.g. to
deliver a cyber weapon. The Analysts need access to the (potential) target system(s) and their
environment. Moreover, the Analysts need tools to scan and map the target system(s) and to detect
the presence of FW and AV software, IDS, sniffers, and honeypots. Scanning includes enumerating
the make, type, and update status of the hardware and software in the target system(s). To hide their
reconnaissance activities, the Analysts need DNS zone transfer tools. Since reconnaissance may
involve manipulating key persons in the target organization(s) and their suppliers, the Analysts also
need social engineering skills. In Target List, the Analysts use the information gained from footprinting
and reconnaissance to draw up a list of the target system(s) to be attacked in order to achieve the
attack goals. In Identify Vulnerabilities, the Analysts identify what vulnerabilities are known to exist in
the target system(s)’ hardware and software. This may require access to the target system(s), but
most information is available on the web in vulnerability databases, on the websites of the hardware
and software suppliers, on Computer Emergency Response Team (CERT) websites, and from hacker
fora. If the professional group has access to or can generate information on zero-day vulnerabilities,
this covert information would be added to the vulnerabilities database.

Plan (Phase 3) splits into three processes (not shown). In Plan Attack, the Planners use the target list
and the information on the target system(s)’ topologies, access paths, and vulnerabilities to draw up
an attack plan designed to achieve the counter-attack goals. The Planners need a planning tool, a
plan template, and databases listing the payloads and delivery platforms available to the group.
Associated with the resulting attack plan will be a set of cyber weapon specifications. In Prepare
Weapons, the Weaponeers prepare the cyber weapons according to the Planners’ specifications.
They need access to the repository of payloads and platforms. Integration would be performed using
a software development environment (SDE). To avoid detection, the weapons would be encrypted
and tested against the AV, FWs, and IDSs detected in the target system(s). In Test Plan, the Planners
test the prepared cyber weapons in a simulation of the target system(s). When tested successfully,
the tested plan is output.

Figure 4. Phase 4: counter-attack (node A4).

Counter-attack (Phase 4) splits into four processes (Figure 4). In Distribute Plan, the tested plan is
distributed using secure communications to the Operatives who will execute it and they are briefed on
the counter-attack goals and RoEs. To preserve operational security, this is done “just in time” when
authorized by the Authorities. In Rehearse, the Operatives practise executing the tested plan using
the prepared cyber weapons in a simulator. When they are ready, the Operatives execute the plan in
the Penetrate & Control process, using the prepared cyber weapons, a set of penetration and control
(P&C) tools, and access to the target system(s). During the course of this process, the Operatives will
emit the “embedded” flag when they succeed in embedding the weapons into the target system(s).
The “C2 open” flag will be emitted if the target system(s) successfully join the professional group’s
botnet. The Penetrate & Control process is decomposed further in Figure 5.

In Violate System(s), the Operatives attempt to achieve the counter-attack goals. This may call for
one or more of the security principles to be violated. Data may be extracted from the target system(s)
to violate their confidentiality. Their integrity may be violated by modifying or deleting information
stored within or passing through the target system(s). The availability of the target system(s) may be
violated by disconnecting the users, by denying them access to some or all of the services and
information the system(s) provide, and/or by delaying the provision of information to users.

Penetrate & Control has been decomposed further into four sub-processes (Figure 5). In the
Penetrate sub-process, the Operatives exploit a vulnerability to gain access within the target
system(s)’ firewalls. This may be done using a firewall tunnelling tool or social engineering
techniques. Log editors/wipers are needed to erase the Operatives’ actions. When the target
system(s) are penetrated, then the Take Control sub-process can begin. The Operatives use a variety
of tools and techniques (e.g. a rootkit, password crackers, and/or social engineering) to raise their
access privileges to root or superuser. If necessary, the Operatives may install their own command
interpreter on the target system(s). In Embed Weapon(s), the Operatives exploit their control over the
target system(s) to embed backdoors, enabling direct access to the system(s) in the future, network
mappers to expand their view on the targets’ environment, and email/chat servers to facilitate data
extraction and communication with the target system(s). In Connect to C2, the Operatives connect the
target system(s) to the professional group’s botnet via the C2 channel, so that the target system(s)
can receive incoming commands and send outgoing commands to other bots.

Figure 5. Decomposition of Penetrate & Control (node A43).

Lessons learned (Phase 5) splits into four processes (not shown). In Assess Damage, the Analysts
may access the target system(s) again when authorized, to establish what lasting damage has
actually been achieved by the counter-attack. The tools needed are largely the same as used in
reconnaissance. In Unintended Effects, the Analysts explore the target system(s)’ environment and
seek information from the public media, the Internet, and collateral systems to establish what
unintended effects, if any, the counter-attack has caused. In Evaluate Operation, the whole
professional group reviews the logged events, the actual damage achieved, and the unintended
effects against the goals and RoE for the operation, perhaps replaying some of the events in the
simulator. They prepare an evaluation report using the report template, specifically identifying any
new lessons learned (LLs) that are not already in the LL database. In Disseminate LL, the group
disseminates the new lessons learned to those who need to know them (e.g. the authorities, other
Ministries, and/or other professional groups) by means of secure communications.

4. Extracting Tools and Technologies

The tools and technologies were extracted from the SADT diagrams by enumerating all the
Resources used per phase at the lowest level of decomposition. These resources were then grouped
into the categories given in the operational context diagram, as shown in the following table:

Resource Malware? Phase 1 Phase 2 Phase 3 Phase 4 Phase 5

Information sources:
Internet A52
Public media A52
Target organization’s website A21
Target organization’s reports A21
Web search tools A21
Open-source information A21
Covert information sources A21
Suppliers’ websites A24
CERT website A24
Hacker fora A24
Victim system A12
Target system(s) A22, A24 A43, A44 A51
Target’s environment A22 A52
Archive:
Vulnerability database (DB) A24
Payload database A31
Platform database A31
Plan template A31
Report template A53
Lessons learned database A53
Repository:
Sniffers A11 A44 A51
Packet diversion tools A11 A44 A51
Extraction tools Yes A11 A44 A51
Encryption tools A32 A44
Forensic tools A12
Reverse engineering tools A12
Data editor A44
Software development A32
environments (SDEs)
Payloads (exploits) Yes A32
Delivery platforms (incl distribution Yes A32
points & malware droppers)
Anti-virus (AV) products A32
Firewalls A32
Intrusion Detection Systems A32
Vulnerability scanners A22
Port scanners Maybe A22
Network mapping tools A22 A433
Sniffer detectors Maybe A22
IDS detectors Yes A22
Honeypot detectors Yes A22
Zone transfer tools Maybe A22
Planning tool A31
Firewall tunnel Yes A431
Log editors/wipers Yes A431
Rootkit Yes A432
Command interpreter A432
Password cracker Yes A432
Privilege tools Yes A432
Backdoors Yes A433
Email server A433
Chat server A433
C2 server Yes A434
C2 (subliminal) channels & Yes A434
backconnects/tunnelling
Botnet Yes A434
Advanced Persistent Threat Yes A11
Techniques:
Social engineering Yes A11 A21, A22 A431, A51
A432, A44
Infrastructure:
Operations centre & ops area (All) (All) (All) (All) (All)
Software development area (All) (All) (All) (All) (All)
Laboratory area (All) (All) (All) (All) (All)
Secure communications (All) (All) (All) (All) (All)
Office automation products (All) (All) (All) (All) (All)
Content / database management (All) (All) (All) (All) (All)
systems
Self-defence measures (All) (All) (All) (All) (All)
Simulator (a.k.a. test range) A33 A42 A53

Two types of resource – communications and OA tools – were identified explicitly in a handful of
processes, but found to be implied in many other processes. For example, for the Analysts to send
the threat and impact reports to the Strategists (in Phase 1) there would have to be communications
system connecting them. Moreover, the Analysts would need OA tools to prepare the reports.
Therefore, we considered such resources to be ubiquitous, and assigned them to the category
Infrastructure. While not identified explicitly, we considered it obvious that the cyber operations centre
would need to have strong self-defence measures (FW, AV, IDS, honeypot, etc), because it would be
an attractive target for a pre-emptive or a counter-counter-attack.

6. Conclusions and Further Work

Several countries, including The Netherlands, are in the process of establishing a Defence Cyber
Command (DCC) capable of offensive cyber operations. Combining Computer Network Exploitation
and Computer Network Attack, offensive cyber operations would be performed by a professional
group of specialists under government authority in compliance with national and international law. The
purpose of this paper is to identify the tools and technologies that a DCC would need. The research
reported here builds on earlier work in creating a canonical process model for offensive cyber
operations (Grant et al, 2012). We enhanced the earlier model by adding SADT control inputs and
mechanisms following the NIST (1993) methodology, aided by the IDEF0 shareware tool. Tools and
technologies were extracted from the mechanisms. A subject matter expert checked the canonical
process model and the extracted set of tools and technologies. Independently, the canonical process
model has been checked by using it to “walk through” a real cyber incident.

The resulting set of tools and technologies includes ten information sources, six databases, a
repository of some thirty software tools, and social engineering techniques. The DCC would need
access to the system attacked or threatened by the incoming attack, to the intended target system(s)
to be counter-attacked, and the systems in the targets’ environment. Finally, the DCC would need an
infrastructure consisting of working areas, secure communications, office automation and
content/database management software, strong self-defence measures, and a simulation
environment. It is noteworthy that malware represents a small fraction of the software tools identified.

The key contribution of this paper has been to identify a set of tools and technologies for professional
offensive cyber operations. This should be a help for those authorities responsible for establishing
DCCs. Nevertheless, the research has several limitations. Most importantly, the canonical process
model on which this research is based lacks any representation of temporal or other quantitative
aspects. Timing is very important in cyber operations. By contrast with conventional military
operations, they can be over in seconds or minutes, rather than weeks, months or even years.
Consequently, many of the processes shown in the canonical process model will have to be
automated. This brings challenges, especially in the first two phases of determining the goals and
planning the counter-attack. Another major challenge will be an organizational one. The various
specialities making up the professional group will have to work extremely closely together. Given that
 there is traditionally a “Chinese wall” between the intelligence services (Analysts) and the military
services (the other specialisations), some way must be found to break down or tunnel through this
wall. Various possibilities would be to ensure each group includes at least one representative of each
specialism, to co-locate the group, to cross-train each member of the group in another specialisation,
and to train the group together using exercises and past incidents. A similar challenge exists in the
interplay between the professional group and the authorities. The authorities must understand
offensive cyber operations, without succumbing to “regulatory capture” by the professional group.

There are many directions in which further work could go. For example, the canonical process model
clearly needs to be subjected to a “reality check” by using it in simulated operations, exercises, and
eventually live operations. Moreover, additional research is needed into whether the process model
also applies to the third form of operations, namely an attack on opposing forces with and without
associated kinetic military action. Furthermore, what activities the DCC should perform in the periods
between operations – the “interbellum” – needs to be studied. Clearly, such activities would include
training, monitoring possible opposing forces, gathering intelligence about their computer-based
systems, contingency planning, and developing assets, such as finding zero-day vulnerabilities.

References
Denning, P.J. & Denning, D.E. (2010) “Discussing Cyber Attack”. Communications of the ACM, Vol 53, no 9, pp
29-31.

Grant, T.J., Burke, I., & van Heerden, R.P. (2012) “Comparing Models of Offensive Cyber Operations”,
Proceedings, 7th International Conference on Information Warfare & Security (ICIW 2012), Seattle, WA, USA,
March.

Habermas, J. (1976) Communication and the evolution of society. Beacon Press, Toronto.

Honeynet. (2008) Know your Enemy: Tracking Botnets, Appendix C: Chatlog – watching attackers at their work.
The Honeynet Project. Accessed from http://www.honeynet.org/papers/bots, 29 December 2011.

Lewis, J.A. & Timlin, K. (2011) Cybersecurity and Cyberwarfare: Preliminary assessment of national doctrine and
organization. Center for Strategic and International Studies, Washington DC, USA.

Lin, H. (2009) “Lifting the Veil on Cyber Offense”. IEEE Security & Privacy, Vol 7, No 4, pp 15-21.

MalwareInfo. (2012) Soorten Malware. Malware Information and Prevention. (In Dutch: Types of malware.)
Accessed from http://malwareinfo.nl/malware-2/soorten-malware/, 11 October 2012.

Marca, D. & McGowen, C.L. (1988) SADT: Structured Analysis and Design Technique. McGraw-Hill, NY.

McAfee. (2011) 2012 Threats Predictions. McAfee Labs, Santa Clara, CA, USA.

MinDef. (2012) Brochure Defensie Cyber Strategie. Ministry of Defence, The Hague, The Netherlands, published
27 June 2012. (In Dutch: Defence Cyber Strategy brochure.) Accessed from
http://www.rijksoverheid.nl/documenten-en-publicaties/brochures/2012/06/27/brochure-defensie-cyber-
strategie.html, 11 October 2012.

MinJus. (2011) Dutch National Cyber Security Strategy. Ministry of Security & Justice, The Hague, The
Netherlands, published 23 February 2011. (In English.) Downloadable from http://www.govcert.nl/english/service-
provision/knowledge-and-publications/factsheets/national-cyber-security-strategy-launched.html, accessed 11
October 2012.

NIST. (1993) Integration Definition for Function Modeling (IDEF0). Federal Information Processing Standard
Publication 183, 21 December 1993.

SANS. (2012) Malware FAQ. SANS Institute. Accessed from http://www.sans.org/security-

resources/malwarefaq/, 11 October 2012.

Schnitger, S. & Folmer, H. (2011) “Cyber Ontwikkelingen bij Defensie”. Intercom, 2011-4, pp.17-20. (In Dutch:
Cyber Developments in the Ministry of Defence.)

View publication stats