RE: Covert Channels

["Brooke, O'neil (EXP)" <o'neil.brooke () lmco com>]

On 22 Oct 2002, Frank Knobbe wrote:

> does anyone think that attempting to solve the covert channel issue is
> gonna be the next market boon in security?

for the reasons clearly stated by several bright individuals on this topic
previously, any product which claims to detect and defeat covert channels
on a network (or even a multiuser system) is snake oil.
___________________________
jose nazario, ph.d.                     jose () monkey org

I don't think that the detection of covert channels would be very difficult
in a secure environment. One commonality for all these covert channels is
that they all have a large amount of overhead traffic. By analysing traffic
patterns on the network it should be possible to identify new (to the
security people anyways) business functions / services or covert
communication channels.

Pinging a host should not cause alarm, but sending enough ICMP traffic to
transmit even a moderately sized word document should raise red flags.
Having a couple of HTTP POST commands go through the proxy may be normal,
but a couple of megs going out this way from any one host should again cause
concern.

I've seen product demo's for anomaly detection applications, their
demonstration was a bomb because they spent most of their time discussing
set theory rather than identifying the tangible benefits of their product.
This would be a perfect application of anomaly detection technologies
though. At the time it seemed that the product would generate way too much
operator intervention, but now that I see a need for knowing about strange
and uncategorized network traffic, I can see the business justification for
the investment. Essentially what you need to do as an operator of this
product is look at the traffic on your production network. The traffic gets
classified in a series of sets (which host talks to which other host, what
protocols are used, etc, etc). The operator needs to look at each set and
identify the sets that are appropriate for the environment. Once tuned, the
system will spit out a report for any set that falls outside known
parameters, this includes changes to existing applications / business logic,
new applications / business logic and covert channels. 

Countering covert channels in this way means that the perpetrator is able to
get some information out of the network prior to setting off the anomaly
detection alarms. Depending on how well you know your production environment
and how secure your known services are (i.e. is the covert channel piggy
backing on a known communications channel because a known service has been
compromised?) you could probably lock this down pretty tight so that very
little information is leaked before an investigation is started.