Re: comments on handbook chapter
- From: "Travis H." <solinym@xxxxxxxxx>
- Date: Sat, 9 Sep 2006 22:29:02 -0500
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
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
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Warning: MFC of security event audit support RELENG_6 in the next 2-3 weeks
- Next by Date: Re: comments on handbook chapter
- Previous by thread: Re: comments on handbook chapter