Desired perceptions
D Deception objective (mislead, confusion) D
Specific goals
D Strategic goal
D
Requirements D
Figure 6.9: DREM::Goal layer structure
6 . 4 . TAC T I C M O D E L I N G
that can be modeled and analyzed. For example, the Honeyfile system, Decoy Document Distributor system, and Canary files are notable solutions for adding decoy files in a system. They could be used as-is or customized for a particular requirement. If no prompt solutions are found, a tactic is created from scratch. Tactics are linked to requirements by using the operationalize connector (DML).
Heuristic 12. Identify reusable tactics. Since off-the-shelf solutions tend to be tested and stable, we suggest to reuse such mechanisms whenever possible, instead of creating them from scratch.
Heuristic 13. Whenever possible, model multiple tactics for the same goal. Since a deception requirement may be satisfied by multiple tactics, consider to model all chosen alternatives since they may incur in different risks levels and conflicts.
The activityDefine tactic isolation levelassociates each tactic with its isolation level, namely permissive, shared, autonomous, or private. Tactic isolation level reflects directly on the composition models (insulation, extended, mixed in, and hybrid) of DACS, as presented in Section5.2.
Heuristic 14. Minimize system interference. Keep low coupling between deception tactics and system components. In other words, prioritize the tactic isolation level from private to permissive. To set the tactic isolation level, it is necessary to understand which system services the tactic will use, which system resources would be necessary, and how the tactic communicates to other tactics. Perhaps this information are not fully available in the first modeling iterations. Therefore, setting isolation level may be postponed until this information become more clear.
The activitySelect techniquesassigns techniques of simulation and dissimulation to a tactic. We described simulation and dissimulation techniques in Section2.4.1(Chapter 2) and provided applications on the reference architecture in Chapter5. If simulation is selected, we firstDefine artificial elementsthat will compose the system. Artificial ele-ments can be created using techniques of mimicking, inventing, or decoying. Choosing the proper simulation technique may be challenging, specially when distinguishing mim-icking from inventing. A classic example that can be misinterpreted is cited by Bell and Whaley [29]. In war time, the illusion created by rubber tanks is considered an invent-ing technique. However, one might clearly consider rubber tanks as imitation of real tanks. Thus, it is important to consider the underlie context when interpreting a partic-ular technique. For example, a single rubber tank might reflect an imitation of a real tank, but an army of dummy tanks can expose a new invented scenario. In the context of computational systems, we suggest three heuristic rules to apply simulation.
Heuristic 15. Applying mimicking. When applying mimicking, consider these two principles: (i)the target element (structural or behavioural) resembles the origin element in a given context, and(ii)the target element adapts according to the source element or its context.
Mimicking implies to make something looks like another one. Evaluating the plausi-bility of a replica might be a very abstract activity, specially considering computational elements, such as software and data. We suggest to evaluate the believability of replicas by employing consensual analysis among multiple engineers. This could mitigate individ-ual biases and increase the chances of creating effective replicas. We consider evolution a key factor for mimicking, since if the mimicked element is known to be changed, so the replica to maintain a coherent relation.
Heuristic 16. Applying inventing. Use inventing technique to create elements (struc-tural or behavioural) that are decoupled from any other element in a given context. Dif-ferent from the mimicking technique, inventing adds elements to a context that are false by themselves, i.e., they do not need a reference to exist.
Heuristic 17. Applying decoying. Use decoying to entice attackers to false default elements in a system. Systems use to provide several default elements that are sought by attackers. Examples include users labeled as sysadmin, default passwords, default cookie names in a web application, and default directory names. By using decoying techniques, these common elements are converted to fakes and their functions are activated in other elements. For example, an administrator user, regularly namedadminin many systems, is kept as a fake user account and the real administrator is activated as another regular account (e.g., jonsnow).
The next activity isDefine intentional vulnerabilities. This activity captures premed-itated vulnerabilities added in the system. Intentional vulnerabilities are applied to enchant attackers. There are two substeps to define intentional vulnerabilities: (i)Define the type of the vulnerability and(ii)Define the vulnerability management. The type of vulnerability varies according to the system. Examples include a weak password asso-ciated to a honey account, an intentional controlled bug in the code, and an unpatched plugin. The second step defines how to manage the consequences of exploiting the in-tentional vulnerability. After exploiting an inin-tentional vulnerability, the story may end or continue to a controlled space (e.g., a sandbox). An example of managed vulnerabil-ity is presented in Honey-Patches [21]. Honey-Patches explore the idea of simulating unpatched vulnerabilities redirecting exploits to a deceptive honeypot environment.
If the technique to apply is dissimulation, the activitySelect assets to cover is exe-cuted. Dissimulation can be done by masking, repackaging, or dazzling. We delineate the following heuristics to apply dissimulation.
Heuristic 18. Applying masking. Take the asset that will be hidden and select characteristics (structural or behavioral) that can be modified to make it imperceptible to attackers. This can be done by blending the element with its background, integrating itself with the surrounding, or make it invisible at all. An example of masking is the use of steganography [188], the practice of hiding a secret message inside of (or even on top of) something that is not secret. For example, embedding a secret piece of text inside a
6 . 4 . TAC T I C M O D E L I N G
picture or hiding a secret message or script inside of a Word or Excel document employs steganography.
Heuristic 19. Applying repackaging. Take the asset that will be hidden and deter-mine how this asset can be embedded in another element. Mimicking or inventing can be used to build the new appearance. Alternatively, you can use an existing system element to embed the asset. The resulting element should be aligned with deception goals, such as to seem dangerous, harmless, or simply irrelevant. An example of repackaging is to assign an unusual extension (e.g., tgg) to a document file (e.g., doc, docx) during a file transmission. The intention is to hide this type of file from sniffers that seek for docu-ments in a network. When using repackaging, consider that a simple internal inspection of the element covering the asset may reveal the ruse. Therefore, looking into the content of the file may easily reveal that the extension does not match its real constitution.
Heuristic 20. Applying dazzling. Take the asset that will be hidden and select characteristics that could be modified to create and mix new elements to the context. The blending should confuse the attacker to determine what is real and what is not. Use mimicking to create the new elements in such way that they look like the asset we want to hide. This technique is used by Honeywords, which associates only one correct password toN other fake passwords in a repository. The objective is to mitigate offline password cracking.
The next activity, Define references, aims at associating the selected technique to a reference asset. Consider the example illustrated in Fig. 6.11. This example shows the inventing technique applied to the Honeyfile tactic. The artificial element to be shown («show false») is Doc files. The reference («refs») to create these doc files is Word doc files.
It means that Word doc files will be used to create Doc files. The next activity isDefine
D Honeyfile
name: String content: Blob
Doc files
D Inventing
D
<<show false>>
<<technique>>
1..100
name: String content: Blob
Word doc files
<<refs>>
Figure 6.11: Example of reference link in DML
metrics. This activity involves determining the attributes to be measured, how to measure these attributes, and the necessary data to compute the metric.
Heuristic 21. Select quality attributes from goals. Inspect the DREM and search for goals that can represent quality attributes of the tactic. Consider the following deception goals extracted from a Deception Requirements Model (Fig. 6.12). Analyzing the graph,
Mislead attackers
D
Effective decoys
D
Enticing D Discriminated
D
Decoy files deployed
D and
...
Figure 6.12: Extracting goals to compute metrics
Effective decoys is a softgoal satisficed by Enticing and Discriminated. We define the attributes by asking “how to produce effective decoys”? Considering enticing and dis-crimination key attributes to answer this question, we formulate two more subquestions:
How to measure enticibility and how to measure discriminability? Measuring enticibility is very subjective and often requires collective sense or empirical studies to determine a scale of attractiveness (e.g., from very low to very high). Discriminability represents the capacity to differentiate a decoy from a legitimate file in a file system. This attribute could be computed by the number of legitimate users who touch the decoy in a certain time frame. Of course, the defender should provide means to ensure the legitimacy of the user, which may be challenging in certain circumstances (e.g., when using password based authentication).
The activityIdentify feedback channelscaptures the sources from which the tactic will collect data. Data necessary to calculate metrics defined in the previous step are identified during the definition of feedback channels. We also identify feedback channels to collect data about interactions between the attacker and elements of a deception tactic. A specific component prepared in the file system to deal with Honeyfiles is an example of feedback channel. Another example is the authentication component used by a system. If deception tactics are used to hide real passwords (e.g., using Honeywords, Honeyencryption), the authentication component will be used to collect data about attempts to authenticate
6 . 4 . TAC T I C M O D E L I N G
using a fake password.
Heuristic 22. Analyze the architecture model to determine feedback channels. If an architecture model exists, it can be used to determine the components that will con-tribute to form the feedback channels. Analyze how data flows between components.
Identify components that provide the necessary data for deception analysis and metric computation. If there is no component that could provide the necessary data, the archi-tecture should be extended with new ones.
After identifying the feedback channel, more techniques can be selected for the tactic under specification. Otherwise, another tactic can be defined. This process continues until no more deception tactics are specified in the current iteration.
6.4.2 Develop deception stories
Deception stories describe scenarios to capture behavioral aspects of one or more tactics.
Deception scenarios are modeled using UML interaction diagrams. Fig. 6.13shows the subactivites to develop deception stories. The activity Select deception tacticsidentifies
Identify scenario
Describe actors
Describe objects
Describe messages
Associate bias exploitation
[more scenarios]
Develop deception stories
[scenario exploits bias]
Select deception tactics
Figure 6.13: Develop deception stories: subactivities
the tactics that will interact in the story. Identify scenarioaims at listing the scenarios that will be modeled as sequences of messages.
Heuristic 23. Identify the engagement scenarios. First identify events that recog-nize the attacker has been engaged in the deception. Note that there may be more that one scenario representing an attacker engagement. For example, copying a decoy file to a folder represents an engagement scenario, so opening this file.
Heuristic 24. Identify management scenarios. Identify conditions that trigger man-agement functions of a tactic. In particular, model events that trigger a tactic to start, pause, and terminate. If the tactic is required to adapt over time, express the scenarios which the adaptation should trigger.
Heuristic 25. Describe functional scenarios. Model relevant scenarios that repre-sent functions performed by the tactics.
Heuristic 26. Refine tactics. If a scenario involves more than one tactic, consider creating an abstract tactic, aggregating the participant tactics and associate the scenario with the abstract tactic. Also, verify whether a tactic may be decomposed in more tactics.
The activitiesDescribe actorsandDescribe objectsidentify and describe the actors and objects participating in the scenario. Actors may be entities representing the defender or the attacker. Objects are entities that exchange messages and that will be used to describe the scenario. At this point, if necessary, an initial architectural design containing high-level components of the tactic could be created. The next activity isDescribe messages, aiming at identifying the messages exchanged between the actors. If the scenario intends to exploit some bias on the attacker, the activityAssociate bias exploitationis performed.
The process runs until no more scenarios are identified.
Heuristic 27. Associate bias to stories. Selecting biases is not a trivial process, since it is frequently based on assumptions that the defender makes about the attacker. To perform this activity, first identify which category of biases (personal, cultural, organiza-tional, or cognitive) the tactics intend to exploit. Personal, cultural, and organizational biases depend on specific parameters about the attacker or at least the origin of the attack to properly identify the biases that could be exploited. Cognitive biases crosscut human being capabilities of perceiving and thinking. If cognitive biases are chosen, use a catalog to assess the cognitive deviation to be exploited by the tactic. Wikipedia’s cognitive bias list is a good starting point for this activity [370].
6.4.3 Assess tactic risks
This activity aims at determining the risks of incorporating the deception tactic into a system. Risks are assessed in terms of likelihood of a certain event taking place and its consequences in terms of impact for the business. Fig. 6.14 shows the deception risk assessment process. The process is based on the ISO 31000:2018 guideline [335], which is suitable for our purpose due to its generality and to its capability in providing best practice structure and guidance to activities concerning risk management. The output of this activity is the DREM:Operational layer updated with risks associated to each tactic and optionally a Deception tactics threat model containing threats, attack vectors, and potential vulnerabilities, among other elements.
The activitySelect deception tacticschooses the tactics to which risks will be assessed.
Define risk assessment criteriaaims at establishing the rules to compute the risk and con-sider it acceptable or not. To compute the risk, stakeholders should agree on: (i) how impact and likelihood will be defined and measured,(ii)how the risk level will be com-puted,(iii)how combinations and sequences of multiple risks will be taken into account,
6 . 4 . TAC T I C M O D E L I N G
Assess tactic risks
Define risk assessment criteria
Identify risks Analyze risks Evaluate risks Treat risks
Select deception tactics
acceptable risks Communication and consultation
Monitoring and review
Figure 6.14: Assess tactic risks: subactivities
and(iv)how to determine whether a risk is acceptable. The purpose of the activity Iden-tify risksis to find and describe events and consequences that prevent the selected tactics from achieving their objectives. To identify risks, it should be considered:(i)events and their causes,(ii)potential vulnerabilities and capabilities of the tactic,(iii)threats that can jeopardize the effectiveness of the tactic (including changes on internal and external context of the system under protection),(iv)limitations of knowledge and reliability of information, and(v)biases, assumptions and beliefs of those involved.
Heuristic 28. Identify mistakenly legitimate use threat. Mistakenly legitimate use refers to a false positive scenario. It occurs when legitimate users mistakenly use de-ceptive elements. This is the case, for example, when genuine authorized users open a decoy file. The probability of false positive events happening should consider how fakes are protected from legitimate users. If the user is only one responsible for differentiate the real from the false (e.g., by distinguishing a decoy file by its name), the chances of erroneous use is greater than those applying any automation to discriminate it (e.g., using a particular user interface to manage the files).
Heuristic 29. Identify deception acknowledged by attackers threat. Deception acknowledged by attackers represents the recognition that a deception is ongoing. Con-sequences can be analyzed in two ways. First, stronger offensives can be perpetrated in retaliation. Second, defenders may incur in illegal situations, depending on how the deception has been designed (e.g., hacking back to cause some damage to the attacker’s system). Deceptions that are trivially recognized should be avoided, unless they are used as a bait for other traps.
Heuristic 30. Identify threats based on context changing. Identify those tactics that refers to some real element in the system (e.g., using mimicking or masking techniques).
Evaluate the possibility of the original element being modified over time (context chang-ing) and the risk associated to reducing plausibility and enticibility of the deception (if it is the case).
Heuristic 31. Identify security and privacy threats. Identify threats that can jeop-ardize the security of the system and user’s privacy. Deception tactics may incur in
vulnerabilities and threats that should be analyzed for adequate treatment. Therefore, threat analysis is required for each deception tactic proposed for the system. Threat anal-ysis can be done using different methodologies, such as Microsoft STRIDE [171], attack trees [314], and trike [307]. Similarly, privacy can be an issue since real data can be used as a reference to create false elements in a system. It is crucial to ensure that an attacker will not infer some real data based on a false element.
The activityAnalyze risksdetermines the likelihood of events and consequences and their impact on the effectiveness of a tactic. Factors that should be considered during risk analysis include the nature and magnitude of consequences, the complexity of a multi-deception system (if it is the case), and the effectiveness of existing controls to mitigate the risk.
Heuristic 32. Determining the likelihood and impact of deceiving. The risk anal-ysis may be influenced by any divergence of opinions, biases, perceptions of risk and judgements. Therefore, apply a process of judgment based on the expertise of security and deception engineers to determine consensual likelihood and impact of events when assessing the risks of deceiving; document and communicate all opinions that influence the judgment.
Evaluate risks aims at computing the risk level and comparing the to the criteria defined in the beginning of the process. DML uses a qualitative scale to indicate a threat likelihood and impact. To compute the risk level, first the qualitative scale is transformed into a quantitative scale (see these scales in the item Associated Risks in Section4.3.1, Chapter4). Then, the risk level is calculated by the formularisk-level = likelihood x impact.
If the risk level is acceptable, the process ends. Otherwise, the activityTreat riskstakes place. Risk treatment refers to means of mitigating or eliminating a risk. At this point, the following decisions can be made:
• Remove the tactic: which would eliminate or reduce the associated risk.
• Change the tactic: which implies modifying its functionality or elements associated to the tactic.
• Change the risk criteria: which leads to review the criteria to consider the tactic acceptable.
• Change the risk evaluation: which leads to review the values associated to the likelihood and impact of events and consequences.
• Postpone the evaluation: until more details about how the tactic will be integrated into the system emerge.
The process then returns to the activity Identify risks since the treatment can result additional risks that should be assessed.