Re: comments on handbook chapter



On 9/8/06, Bigby Findrake <bigby@xxxxxxxxxxxxx> wrote:
That's how I interpret that passage from the handbook - that you should
detect *and* prevent. I'm not clear on how anyone is interpreting that
passage to suggest that unequal weight should be given to one side or the
other (detection vs. prevention). The above passage all but says, "don't
do X because that will interfere with Y." I just don't see that advice as
advocating imbalance.

Well, I think "one of the single most" is a somewhat strange turn of
the phrase anyway. Which is it, one of many, or single?
Anyway, he seems to be advocating /not/ hardening your system,
so that the opponent can get in using an attack vector you know
about, and which is easily detected. What if root runs a binary
before the change gets detected? What if they alter the integrity
database before the integrity check gets run? Ooops. There are
plenty of ways to detect things without deliberately leaving known
security holes hoping they'll be exploited by the first script-kiddie
or worm that rooted your box.

And if an access failure for a protection mechanism was
auditable then every prevention would be a detection gratis.

In those cases, where you're hit by attacks that you didn't know existed,
the importance of detection probably rises. In fact, in the case of
attacks (and possibly vectors) that you weren't aware of, I would argue
that detection can be a prerequisite of prevention.

Depends on what you mean by "didn't know existed".

There are ways to prevent some 0-days, such as anomaly detection.
There are some misuse-detection systems that can be given patterns
general enough to catch derivatives of known attacks (I have a pretty
good one that can catch most x86 stack overflows). And there
are honeypots, that you can use to analyze your opponent's techniques.
There are network forensic packages like sguil, that can provide
valuable information either proactively (monitor all network traffic)
or reactively (for analysis of how the attack got in).

But in the
cases where you cannot remove or mitigate the attack vector (eg. because
to do so would interfere with availability vs security), it seems to me
that prevention needs detection.

Yes, I can agree with this, but my strategy is:
Prevent if you can. An ounce of prevention is worth a pound of cure.
Detect if you can't. Monitoring is boring and takes lots of time that
could be used more productively. It's all sunk costs.
--
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • RE: Firewalls (was Re: IDS evaluations procedures) - AI
    ... information to label an event as attack. ... usability of Fusion theory or association rules to find correlations among ... >>This is not an attack against you or any other prevention vendor. ... >>detection or prevention requires accurate attack identification. ...
    (Focus-IDS)
  • Re: Firewalls (was Re: IDS evaluations procedures)
    ... I am agreed on the difficulty in defining an attack properly. ... AI/data mining/ machine learning techniques to get some more insight into ... >This is not an attack against you or any other prevention vendor. ... >detection or prevention requires accurate attack identification. ...
    (Focus-IDS)
  • Re: Firewalls (was Re: IDS evaluations procedures)
    ... > Systems that have integrated firewall. ... I can attack them. ... This is not an attack against you or any other prevention vendor. ... detection or prevention requires accurate attack identification. ...
    (Focus-IDS)
  • Re: Questions re WEP encryption
    ... to replay captured APR packets. ... most intrusion detection software never sees it happen. ... active attacks generate wireless traffic that can itself be detected ... and possibly alert the target of the attack. ...
    (alt.internet.wireless)
  • RE: IPSec and IDS
    ... it's the resulting change in host behavior AFTER the encrypted ... attack that must be detected. ... intrusion detection is a must. ... Server Sensor installation detected the IIS 5.0, ...
    (Focus-IDS)