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. joseat_private 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.
This archive was generated by hypermail 2b30 : Wed Oct 23 2002 - 11:33:24 PDT