*5.2. Prevention*

An important aspect to consider to fully asses the security of network/computing infrastructures concerns how to completely prevent the possibility of setting up a network covert channel. As hinted, protocols known to be prone to steganographic attacks should be completely blocked [1,8,55]. Unfortunately, this is unfeasible in many scenarios and use cases. Since covert channels are the prime consequence of imperfect isolation, prevention mechanisms should aim at restoring the protocol data units to their basic form, in order to reduce the chance of leaking states or embedding additional information. In this vein, reverting fields to default values or inserting padding (or trimming messages) are the methodologies at the basis of many countermeasures [9].

However, the increasing sophistication of exfiltration attempts as well as the complexity of modern network architectures require to consider covert channels from the early stage of the design phase. Thus, prevention should be considered an "offline" process and handled in a *security-by-design* manner. To this extent, standardization surely plays a major role and security considerations on potential covert channels should be always present. Enforcing a flow to adhere to its standard implementation can be also exploited at runtime to sanitize the behavior of the protocol and disrupt secret messages, if present. Covert channels can be also impeded by selectively blocking some protocol features while pursuing functional tradeoffs acceptable for the specific scenario or application.

#### **6. Trends and Challenges**

The growing adoption of covert channels as a paradigm to empower stegomalware and support data exfiltration is expected to persist in the future [1]: new attacks will be more sophisticated, cross-layer and able to leverage the complex interplay of hardware and software components [52]. This will magnify the gap between the attacker and the defender, especially in terms of uncertainty of what to inspect and where to place wardens within the overall network architecture. Reviewed countermeasures as well as tools deployed in the wild seem only partially trying to mitigate such an aspect. Thus, the main trends in the development of countermeasures observed and the challenges to be faced are:


approach concerns the development of more abstract metrics, which can be used to spot the steganographic attack despite the used carrier. Literature demonstrated that process correlation [61] or anomalous energy consumption and drains [62,63] are excellent candidates to make the detection more threat-independent. To pursue such a vision, the detection could need to be shifted towards the border of the network or close to users. This poses several challenges, for instance in terms of avoiding performance degradation of devices of end users and additional security requirements;


#### **7. Conclusions**

In this paper, we have presented a thorough review on countermeasures against network covert channels. We have addressed the different steps needed to enforce security when in the presence of hidden communications. In more detail, we have considered works dealing with the detection, limitation and elimination of network covert channels. We have also addressed methodologies to prevent hidden communications. Even if comprehensive, the investigation revealed some imperfections. For instance, the complex continuum of computing and networking platforms leads to a problem space not well delimited. Thus, it has been difficult tracing a clear line between network covert channels and other types of threats. For instance, covert channels targeting cloud scenarios could be quickly become relevant for the network case (and vice versa).

As shown, the majority of frameworks and ideas handles security issues caused by stegomalware and network covert channels in an almost unique threat-dependent flavor, mainly due to the strict dependency of the behavior of the channel on the used carrier or injection mechanism. This magnifies the asymmetry between the attacker and the defender. To partially recover to this, future research should focus on the development of more general indicators and frameworks, as well as methodologies to inspect multiple carriers

at once. Such a trend is partially observable in the literature (see, e.g., energetic indicators to abstract the underlying threat) but, to be effective, should be consolidated. Another interesting path to pursue, which requires long term research efforts, concerns increasing the awareness of developers and engineers of risks caused by network covert channels. In this case, different research areas (e.g., networking and software engineering) could find a common "playground" and do not duplicate efforts or develop overlapped solutions. Moreover, awareness should lead to adopt methodologies for preventing the exploitation of ambiguities already in early design phases both of protocols, services and architectures.

**Funding:** This research was funded by EU Project SIMARGL—Secure Intelligent Methods for Advanced Recognition of Malware and Stegomalware (Grant Agreement No 833042) and the EU Project ASTRID—AddreSsing ThReats for virtualIzeD services (Grant Agreement No 786922).

**Conflicts of Interest:** The authors declare no conflict of interest.
