Re: Examples of lost security when integrating (secure) SW

On 2004-06-08, Magnus Therning <[email protected]> wrote:
> Bruce Schneier spends a few pages in Secrets & Lies on the subject,
> without offering any examples of what can happen. I seem to remember
> some talk on a conference (was it Usenix?) a few years ago__I never
> attended it but I read the abstract of the papers/talks--where a talk on
> security mentioned a case where the combination of two security features
> effectively cancelled each other.
> Can anyone offer any more concrete examples, ideally not only academic
> ones?

These may not be fully mutually nullifying, but that's an academic
distinction you seem unconcerned about :)  :

Network-level example:

A per-packet filtering IPS bridges traffic, dropping detected attacks
  with the hope retransmits will also be dropped, until timeout.
An RST-responsive IDS monitors the same traffic, flooding RST windows of
  tcp 5-tuples upon detection, for diverse coverage.
An attack is detected by the IDS, and it decides to act.  The IPS didn't
  recognize the attack, but recognizes an attempt to hijack a session.
  The RST's are filtered.  Well done, gentlemen.

Host-level example:

A file alteration monitor is configured to immediately mail security
  personnel upon modification of certain important files.  Inability to
  do so leads to a fail-close situation (no alterations allowed until
  the FAM is reset).
A personal firewall attempts to defend against trojan-borne spambot code
  by limiting outgoing SMTP sessions to foo / bar(sec).  It waits
  until a log message is written (in case of inaccurate filtering)
  before doing anything more complicated than blackholing.
An attacker rakes across a collection of important files.  The sudden
  burst of alert activity is classified as Viagra ads and prohibited.
  Tripwire locks the logfiles.  Sing the deadlock song.

Application-level example:

A developer reads two pages of Shannon too much, and decides he wants
  "real, statistically tested randomness".  Encryption libraries are
  told to block on /dev/random for that extra-secure flavor.
  Renegotiation of session keys is scaled up to occur regularly, and
  let's make them big keys for kicks.  The developer praises his own
  cleverness and talks about his "one-time pad" on sci.crypt.
/dev/random is restricted to apply obscenely stringent randomness tests,
  especially wrt data collected from externally-influenced network
  devices (the only highly active ones on the system).
The entropy pool is quickly exhausted, and blocking on it prohibits the
  network-driven app from doing much else to cause pool buildup.  The
  issue is blamed on a co-developer's choice of error, because debugging
  is hard.

Is that the kind of thing you're looking for?  It's an interesting issue.

-- 
nick black <[email protected]>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo