I wrote:
> >Behavior blocking is a wonderful concept. I've seen the technique
> >succeed (it's the essence of type enforcement) and I've seen it fail
> >on workstations where the behavioral profile poorly matched the
> >application.
Niels responded:
> I don't think that is a fault inherent to the technique. There are, however,
> many ways to define the behavioural profile, and a number of
> economy/security trade-offs are as usual involved. On small networks it is
> quite cheap and manageable to define general rules combined with
> workstation-specific rules for software behaviour. We are in the side of
> intrusion detection concerned with detecting attacks on known weak spots.
Type Enforcement takes the opposite tack. Instead of saying "Restrict
behavior V because it is used by attack W," it says "Restrict behavior
V because program X doesn't need it." In other words, use the concept
of least privilege to prevent _and_ detect whole classes of attacks.
The other approach is reactive, and that leaves openings for future
attacks. Type Enforcement blocks attacks proactively and detects
behavior marked as abberant. So even if you didn't fully block the
attack, you at least get a real time warning.
Traditionally we've deployed Type Enforcement as a form of mandatory
access control, and I'm not entirely sure how good of a countermeasure
it is on a platform without a protected kernel (MSDOS, Mac). Perhaps
it's better than nothing. Clearly, checksum and virus signature based
countermeasures have similar vulnerabilities since they aren't
protected from integrity attacks either.
Rick.
smith @
sctc .
com secure computing corporation
|
|
