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

"Yvan Boily" <[email protected]> Thu, 17 Jun 2004 14:04:03 -0500
Newsgroups gmane.comp.security.programming
Message-ID <[email protected]>
Mr. Therning was (from what I understand) looking for examples where two
effective solutions were combined and used properly, however the expected
outcome was a failure.  I don't agree with the example you provided to
illustrate this. In the case you provided there is one system with high
integrity (SystemA - Secret & Top Secret) and one system (SystemB -
Unclassified & Secret) with low integrity communicating.   Connecting high
integrity systems to low integrity systems is only an issue if you do not
provide access control mechanisms that prevent a low integrity operation
from affecting high integrity data; if SystemA treats all requests from
SystemB as high integrity operations this is more a case of poorly defined
trust relationships than incompatible security features.  

To use this example to properly illustrate the issue Mr. Therning was
looking for you would need to include a discussion of incompatible mandatory
access control mechanisms between SystemA and SystemB that would in theory
prevent breaches of integrity, but in practice does not.

A real world example of combined security features cancelling each other is
the case of an encrypted network in which IDS monitoring was required.  The
original network plan required that traffic between certain nodes on the
internal network be encrypted to ensure that users could not sniff data.
The same plan also required intrusion detection systems to be in place
(quite extensively).  Because of the issues with IDS and encrypting tunnels
it was determined that data would be encrypted to the point it entered the
IDS system and transmitted in the clear beyond that point.  Unfortunately
the systems in question all resided on the same switch and they were not
using static arp caches.

The result was that even though the intent was there to secure the systems
the combination of the two security measures resulted in an environment
where the ciphertext and plaintext of the same data were effectively
available to a sufficiently savvy attacker.

In terms of software I have seen similar behaviour.  A credit card payment
application which was designed to use encryption to transmit data on the
internal network improperly used encryption to ensure that the data was
protected.  The application used SSL to properly protect client server
communications between the web server and the browser, however it relied on
the Oracle Obfuscation Toolkit to encrypt data for transmission & storage.
Originally the application was designed in such a way that the database and
web server would reside on the same system for security reasons.  The web
server and database server were segregated during the development cycle to
prevent an attacker who compromises the web server from gaining access to
the database as well.  During these changes the developers failed to realize
that the selected method of encryption required that the data be transmitted
to the database in the clear so that the Oracle server could encrypt the
data, and then transmit back the ciphertext.  During a penetration test we
were able to compromise the network in such a way that we were able to
capture all traffic going between the web server and the database, including
the plaintext and ciphertext.  As a proof of this we performed a credit card
transaction and captured all the details required to use that credit card
elsewhere.

I believe this example is fairly close to what Mr. Therning was looking for
as it illustrates how distinct security measures must be properly analyzed
before being combined.  It is also an elegant example of how security is an
emergent property of complex systems and not just a simple matter of
layering security features until you have achieved "defence in depth".

Yvan Boily
Seccuris  

> -----Original Message-----
> From: Jeremy Epstein [mailto:[email protected]] 
> Sent: Wednesday, June 09, 2004 1:33 PM
> To: Magnus Therning; [email protected]
> Subject: RE: Examples of lost security when integrating (secure) SW
> 
> There are many examples.  The one that comes to mind is in 
> the multi-level
> security world.  Let's say I have two computers: one is 
> secure enough to
> handle information that's unclassified & secret, and the 
> other can handle
> information that's secret & top secret (in each case with an 
> acceptable
> level of risk of the information flowing to the less 
> classified level).
> When you hook them together, you've now got unclassified -> top secret
> connectivity, which increases the risk.  This is known as the "cascade
> problem".
> 
> Cheers,
> --Jeremy
> 
> > -----Original Message-----
> > From: Magnus Therning 
> [mailto:[email protected]]On Behalf Of
> > Magnus Therning
> > Sent: Tuesday, June 08, 2004 8:10 AM
> > To: [email protected]
> > Subject: Examples of lost security when integrating (secure) SW
> > 
> > 
> > I just had a discussion with my colleagues regarding problems with
> > security in larger systems that are composed by combining
> > modules/components that individually are secure. Both my gut 
> > and sources
> > I have consulted says this is the case. However, I haven't 
> > been able to
> > find any examples of when this has happened!
> > 
> > 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?
> > 
> > /M
> > 
> > -- 
> > --------------------------------------------------------------
> > ---------
> > Magnus Therning                 Philips Research Laboratories 
> > Eindhoven
> > Phone: +31 40 2745179           (OpenPGP: 0x4FBB2C40)
> > 
> > Some operating systems are called 'user friendly', Linux however is
> > 'expert friendly'.
> > 
> 
>