Re: Detecting covert data channels?

["Joff Thyer" <jsthyer () gmail com>]

Jeremy,

You make some very good points.

Data leakage via a covert storage channel is probable assuming that
both ends of the channel are owned.    But, to own both ends, there
needs to be minimally one host compromised in the environment
containing the valuable data.

Therefore on the data leakage front, prevention is absolutely the key.
But I would focus the prevention effort on the end nodes/hosts.

As far as protocol normalization goes, I think there is still some
opportunity for data transmission especially in packet headers.  As
you say, "almost all" covert channels.... I dont think we can ever
completely remove the threat because the use of protocol header fields
is subject to interpretation in many RFC's and has changed over time.
 It comes down to close manual scruntiny in the end.

Covert storage channels can and do use header fields in protocols that
are part of the protocol itself.   My thinking is not just about the
known channels but also what is possible, and perhaps not yet
implemented by anyone.

-Joff




On 13 Jul 2007 17:21:49 -0000, jeremy () deities org <jeremy () deities org> wrote:
> The key question here is 'why?' If your goal is detection and forensics then collecting batches of data for statistical 
> analysis is likely to be both possible and the best approach. You'll want to analyze the data in multiple dimensions to look for 
> anomalies across volume, targets, protocol structure, sequencing, fragmentation, metadata, etc. (Remember you covert channel may not 
> be in the data at all it may be as subtle as the timing of when the packets arrive or the order)
>
> For this approach I'd tend to use tcpdump and various custom scripts doing the batch analysis.
>
>
> If your goal is to prevent data leakage or generally prevent unmonitored communications then I think that detection is 
> mostly moot. Instead you should focus on prevention. In this case, analyze what you can and what you care about and 
> normalize the rest. All covert channels I can think of rely on using parts of the data streams that are not used for 
> the core protocol goals. Therefore normalizing traffic rates, header fields, sequencing, fragmentation, etc will simply 
> remove the opportunity for almost all covert channels.
>
> You will, of course, still need the forensic approach above if you want to increase your confidence but as you find each 
> possible channel you'll probably only need to modify your normalization to remove it.
>
>
> -J
>
> ------------------------------------------------------------------------
> Test Your IDS
>
> Is your IDS deployed correctly?
> Find out quickly and easily by testing it
> with real-world attacks from CORE IMPACT.
> Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
> to learn more.
> ------------------------------------------------------------------------

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------