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'. > > > >