2 Capability Requirements 2.1 General Considerations
2.4 Other Design Considerations
2.4.1 Modularity
As mentioned earlier, deception planning and design is an iterative process that involves continuously “checking the logic and consistency of the internal elements of the deception. This allows the deception planner to identify desired perceptions, observables, and executions that may need refinement, and to add supporting observables as needed to strengthen certain elements of the deception story or diminish the impact of troublesome competing observables. Each element of the deception story should have associated deception means that can credibly portray the data, plus identified conduits that transfer this information into the enemy’s information processing system” [4]. In order to comply with those requirements, especially in the case of complex expanded missions’ deception scenarios, it is necessary to provide a modular deception framework to enable deception designers to perform deception plot synthesis with facilities to operate and manipulate various deception elements to resolve conflicts, provide agility and build a holistic deception solution for a given mission. One approach that Intelligent Automation Inc. (IAI) is developing is to use deception controls as building blocks for a deception solution. However, there exists the challenge of combining various deception controls to work synergistically for depth and consistency in deception, and to detect and resolve possible conflicts between different deception controls that may arise during deception story presentation. A key part of this approach is to perform verification and validation during the deception design when a deception plot is being synthesized. We are currently experimenting with different ways of combining deception controls using a combination of merging and pipelining.
2.4.2 Resiliency, Agility and MTD in Deception
Deception and MTD capabilities are two integral parts of holistic agile cyber-defense posture. MTD is a cyber-cyber-defense strategy in which a set of system configurations is dynamically changing at network and/or host level to increase uncertainty and complexity for adversaries seeking to discover and exploit vulner-abilities in a target network or host environment. In IAI deception implementation, by combining MTD and deception concepts, we create a perception of a transient network environment, perform randomization and pollution of the network attack surface, and increase the work factor for an attacker to determine the direction, volume and importance of network traffic. We also introduce non-concurrency in network parameter modification schemes for unpredictable network parameter transitions and for minimization in interruption of network connectivity.
The deception design process should be integrated with planning and deployment of MTD technologies, in order to create a coherent and consistent presentation of the network and host environment to potential attackers, to reduce the cost of
deployment and maintenance, and to minimize impact on user/mission operation.
In our approach, we are aiming at an integrated planning, design and common configuration environment, in order to achieve mutual compatibility and effective-ness. Moreover, we believe that an integrated MTD and deception software base for network- and host-based components respectively, is the most practical and effective way to a fast and successful transition of a R&D solution into the user environment.
Deception should be an integral part of any agile software system [10] since it aligns with the main goals for achieving cyber resiliency: increasing cost to the attacker, increasing chance of detection, minimizing effect of the attacker and increasing the uncertainty that the attack was successful. While the first three stated objectives are factored largely through the trade-off analysis, the last objective should be implemented as a part of the deception story, especially in case of deception for confusion and intelligence.
2.4.3 C2 Interface
It is stated in [2] that “C2 functions are performed: : : by a commander in planning, directing, coordinating, and controlling forces and operations in the accomplishment of the mission”. Our deception design paradigm supports all three main C2 Interface modes. Figure2shows notional interfaces for these modes of operations.
For the Man-in-the-Loop mode, a mission commander creates deception scenar-ios, followed by a deception plot generation and deployment. Upon receiving orders, the mission commander updates the original deception scenarios, re-generates and deploys a new deception plot based on the Situational Awareness (SA) data and feedback from the deception system in the Mission Domain.
Fig. 2 C2 interface modes
For the Autonomous mode, the mission commander creates deception scenarios and context rules that are included in the generated deception plot being deployed.
The built-in context rules will govern the triggering of different deception scenarios based on the occurrence of network events within the mission domain. In this case, the mission commander does not act based on the feedback channel information. In practice, these two modes should be combined to provide more effective deception management.
For the Man-on-the-Loop mode, the mission commander has an option of creating and deploying deception scenarios and context rules independent from each other. This allows for changing the deception story without generation and re-deployment of the deception plot. Instead, upon receiving the new SA information and the feedback from the deception system in the mission domain, the mission commander modifies a deception story by simply updating and deploying the SA context rules that govern execution of the deception plot.
2.4.4 C2 Coordinated Response and Deployment
Attack scenarios might be fairly complex and include multiple steps. Accordingly, deception scenarios should reflect this fact. For example, consider an attack scenario where an attacker establishes a foothold on one of the compromised hosts and attempts to obtain a password, and discovers and gets access to an important C2 server. The deception scenario and generated deception plot might include host-based deception controls for the entrapment (marked/trackable security credentials left for the attacker to pick-up), network authentication protocol monitoring proxy to control and intercept an attempt to use the marked password hash, and to redirect to an installed decoy and the decoy control itself. In addition, an impediment deception control may also be used to simulate a bad network connection, in order to further increase the attackers’ work factor. In order to deploy a scenario of such complexity, a multi-layered and multi-staged deception plot must be created with various deception controls deployed on several hosts and deception units, which must be activated synchronously. In order to coordinate the deployment, activation and monitoring of various deception control and feedback sensors, the Deception Management Network Protocol must be created to facilitate dynamic configuration dissemination, deception coordination, and deployment of deception controls.
2.4.5 Interoperability with Mainstream Defensive Controls
Deception can be an effective tool for defending computer systems as a third line of defense when access controls and intrusion-prevention systems fail. The deception solution can benefit from already available network and host-based monitoring and alert generating capabilities of deployed intrusion detection system/intrusion prevention system (IDS/IPS) and security information and event management (SIEM) systems. Since it is not feasible to develop an interface to each mainstream
IDS/IPS/SIEM system, it seems more practical to develop open interfaces (south-bound or north(south-bound) to allow receiving of alerts, to process network events, and to analyze network flow generated by third party products.
Another significant topic is interoperability with access control systems. Efforts should be made to ensure that internal firewalls do not block communication between various deception units deployed throughout the network, or avoid discard-ing configuration dissemination updates between the centrally located deception management entity and peripheral deception units. Moreover, deception channels, used to relay deception information back to an attacker, may be impeded by the firewall that is configured to block egress Internet control message protocol (ICMP) traffic or to block all network packets with enabled IP option. Since some third party access control systems might also be subjects of an attack, they should also be part of the deception story. For example, an attacker may conduct a firewalking attack—an active reconnaissance network security analysis to determine access control list (ACL) filters and internal mappings behind a firewall. If firewalking is a part of the deception attack scenario, a deception unit should be installed in front of the firewall to provide deception coverage. Alternatively, wherever possible, the deception module should be integrated with a firewall that would defer to the deception module for all ingress and egress packets the firewall is configured to block.