Comments on: Complexity, virtualization, security, and an old approach http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/ Privacy, Security and Information Assurance issues Fri, 16 May 2008 06:56:02 +0000 http://wordpress.org/?v=2.5.1 By: Spaf http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-90815 Spaf Tue, 17 Jul 2007 20:23:40 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-90815 Pascal, There is effort involved in creating any system. The use of existing systems simply "hides" the effort that has been involved in development over the years. The Poly^2 nodes are small, so the effort is less. Furthermore, because they are small, they will undergo far few patches and upgrades than current systems do, so the lifetime cost is less. The "big picture" view here is where the value occurs. Pascal,
There is effort involved in creating any system. The use of existing systems simply “hides” the effort that has been involved in development over the years.

The Poly^2 nodes are small, so the effort is less. Furthermore, because they are small, they will undergo far few patches and upgrades than current systems do, so the lifetime cost is less.

The “big picture” view here is where the value occurs.

]]> By: Pascal Meunier http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-90707 Pascal Meunier Tue, 17 Jul 2007 13:16:19 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-90707 Is it really better to have a multitude of simple items that are possibly proven correct according to their design, but designed separately and interacting together, leading to emergent behavior problems, or a few well-studied complex ones? Isn't there a point where a high cardinality of simpler but interacting items isn't really less complex? What if the "simple" items are really difficult to get right? In your POLY(2) project, you try to assemble a system from "simple" parts with minimalistic functions. However, getting each part minimalized and simplified is quite difficult and time-consuming, requiring highly-skilled labor; I hear you even need to make kernel patches. Many mistakes and bugs can be created while doing so. Therefore, I submit to you that your approach is paradoxical: it is quite difficult and complex to create the simple parts in your system, so the reduction in complexity may not be so advantageous as it would seem. How can complexity be assessed and compared? How can someone know if (and I'm not saying you do, I'm just considering it as an abstract case) they are spending a lot of energy just trading and moving complexity around instead of reducing it? Is it really better to have a multitude of simple items that are possibly proven correct according to their design, but designed separately and interacting together, leading to emergent behavior problems, or a few well-studied complex ones? Isn’t there a point where a high cardinality of simpler but interacting items isn’t really less complex?

What if the “simple” items are really difficult to get right? In your POLY(2) project, you try to assemble a system from “simple” parts with minimalistic functions. However, getting each part minimalized and simplified is quite difficult and time-consuming, requiring highly-skilled labor; I hear you even need to make kernel patches. Many mistakes and bugs can be created while doing so. Therefore, I submit to you that your approach is paradoxical: it is quite difficult and complex to create the simple parts in your system, so the reduction in complexity may not be so advantageous as it would seem.

How can complexity be assessed and compared? How can someone know if (and I’m not saying you do, I’m just considering it as an abstract case) they are spending a lot of energy just trading and moving complexity around instead of reducing it?

]]> By: Spaf http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-86967 Spaf Mon, 09 Jul 2007 16:01:32 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-86967 I'm assuming that you are proposing a revision to the protocols so that IP addresses can't be faked, because they certainly can (and are) faked now in many different kinds of attack. Assuming we could get everyone to switch to using that protocol -- which is extremely unlikely in even a near term -- there are still problems with people using "victim" sites as relays and bots. There is also the problem of using intermediary sites where logs are not kept, and/or controlling interests (national or commercial) refuse to provide log details to investigators. Knowing a source IP address might help some, but it is not a complete solution. I’m assuming that you are proposing a revision to the protocols so that IP addresses can’t be faked, because they certainly can (and are) faked now in many different kinds of attack.

Assuming we could get everyone to switch to using that protocol — which is extremely unlikely in even a near term — there are still problems with people using “victim” sites as relays and bots. There is also the problem of using intermediary sites where logs are not kept, and/or controlling interests (national or commercial) refuse to provide log details to investigators.

Knowing a source IP address might help some, but it is not a complete solution.

]]> By: Daniel Chien http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-86375 Daniel Chien Sun, 08 Jul 2007 03:57:25 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-86375 I have a very simple way to enhance Internet security. On the Internet, everyone has IP address which can not be faked due to the Internet Routing. You can hide but can not fake. Based on the IP address, lots thing can be done. For example, phishing website has it own IP address, and can not use the same IP address as legitimate financial institutions. So when visiting a website, we can check its IP address and know for sure if it is a phishing site. This is just one of the many security enhancements we can do based on IP address. It is very simple. I have a very simple way to enhance Internet security. On the Internet, everyone has IP address which can not be faked due to the Internet Routing. You can hide but can not fake. Based on the IP address, lots thing can be done. For example, phishing website has it own IP address, and can not use the same IP address as legitimate financial institutions. So when visiting a website, we can check its IP address and know for sure if it is a phishing site. This is just one of the many security enhancements we can do based on IP address. It is very simple.

]]> By: Pascal Meunier http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-82074 Pascal Meunier Thu, 28 Jun 2007 13:32:35 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-82074 The Intel Core 2 Duo bugs show that complexity in the hardware is bad too... I think I'd rather have virtualization done the VMWare way, in software, because it can be patched. Even though we say patching doesn't work (well), it's still better than being stuck with a useless piece of hardware. It's not the first time either: see the previous Intel processor Pentium instruction that could crash the CPU: see Sun Security Bulletin #00161 (1997). RISC processors may be better for security too. The Intel Core 2 Duo bugs show that complexity in the hardware is bad too… I think I’d rather have virtualization done the VMWare way, in software, because it can be patched. Even though we say patching doesn’t work (well), it’s still better than being stuck with a useless piece of hardware. It’s not the first time either: see the previous Intel processor Pentium instruction that could crash the CPU: see Sun Security Bulletin #00161 (1997). RISC processors may be better for security too.

]]> By: Liudvikas Bukys http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81718 Liudvikas Bukys Wed, 27 Jun 2007 14:28:23 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81718 The IBM Blue Gene supercomputer adopts the "processor per process" strategy, not for security but for raw speed. (At the high end, speed, packaging and architectural simplicity all intersect.) The IBM Blue Gene supercomputer adopts the “processor per process” strategy, not for security but for raw speed. (At the high end, speed, packaging and architectural simplicity all intersect.)

]]> By: Spaf http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81521 Spaf Wed, 27 Jun 2007 04:32:09 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81521 Thanks for the feedback, Pascal. Even if the hardware has some support for the virtualization, there is still added complexity that needs to be managed to set up registers, map memory, and fire up processes. The whole process of virtualization is complex, and putting some of it in hardware makes it safer, but not safe! And yes, WWW browsers and Web X.0 (for x > 1) are indeed fine examples of both the complexity creep I described, and the security/maintenace complications that result. Thanks for the feedback, Pascal.

Even if the hardware has some support for the virtualization, there is still added complexity that needs to be managed to set up registers, map memory, and fire up processes. The whole process of virtualization is complex, and putting some of it in hardware makes it safer, but not safe!

And yes, WWW browsers and Web X.0 (for x > 1) are indeed fine examples of both the complexity creep I described, and the security/maintenace complications that result.

]]> By: Pascal Meunier http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81296 Pascal Meunier Tue, 26 Jun 2007 17:44:26 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81296 Thinking some more about it, I'd like to point out that you consider a single software security principle in isolation. Virtualization offers both compartmentalization and defense in depth. In addition, it enables simplicity and the usage of community resources through the use of virtual appliances. That's 4 software security principles out of 10 with a single technology -- not bad! I am surprised that your discussion of complexity doesn't mention web browsers. I believe that it is an important battle -- there seems to be no upper bound to the growth of their complexity and fragility. Web 2.0 apps resemble in my mind a juggler's act, likely to come crashing down at the slightest tremor. Google apps are like spinning tops, twirling adamantly but unsteady. To answer your question about minimalism, I'd love to see browsers support a "restricted", "safe" or "simple" JavaScript that wouldn't be able to invoke ActiveX, for example, but would be able to support basic events and functions, such as changing the class of HTML tags. Such a simple JavaScript would enable people to use most websites that require JavaScript, but without exposing dangerous APIs and plugins, and restricting JavaScript functionality to just that needed to make the sites work. Also, current web browsers would greatly benefit from an internal organization (architecture) that would compartmentalize plugins, pages, tabs, cookies, etc... -- but I've already discussed that in one of my posts. Thinking some more about it, I’d like to point out that you consider a single software security principle in isolation. Virtualization offers both compartmentalization and defense in depth. In addition, it enables simplicity and the usage of community resources through the use of virtual appliances. That’s 4 software security principles out of 10 with a single technology — not bad!

I am surprised that your discussion of complexity doesn’t mention web browsers. I believe that it is an important battle — there seems to be no upper bound to the growth of their complexity and fragility. Web 2.0 apps resemble in my mind a juggler’s act, likely to come crashing down at the slightest tremor. Google apps are like spinning tops, twirling adamantly but unsteady. To answer your question about minimalism, I’d love to see browsers support a “restricted”, “safe” or “simple” JavaScript that wouldn’t be able to invoke ActiveX, for example, but would be able to support basic events and functions, such as changing the class of HTML tags. Such a simple JavaScript would enable people to use most websites that require JavaScript, but without exposing dangerous APIs and plugins, and restricting JavaScript functionality to just that needed to make the sites work. Also, current web browsers would greatly benefit from an internal organization (architecture) that would compartmentalize plugins, pages, tabs, cookies, etc… — but I’ve already discussed that in one of my posts.

]]> By: Pascal Meunier http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81287 Pascal Meunier Tue, 26 Jun 2007 17:05:39 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-81287 I think that virtualization, and instruction sets in the hardware to support it, have the potential to "transfer complexity" (as in "transfer risk"). It replaces some and isolates other complexities instead of simply making things worse, by contrast to pure "featuritis". I don't know anyone who would argue that protected memory and pre-emptive multitasking decrease security due to their complexity (if you disagree, go back to using MacOS 9 :-P). I believe that virtualization can provide additional or better security guarantees, and I think that it's a plus. Virtualization resembles more security in depth instead of just adding more attack surface, although it currently does a mix of both. It's a tool -- just don't poke your eye out with it, and don't think it will solve everything. I think that virtualization, and instruction sets in the hardware to support it, have the potential to “transfer complexity” (as in “transfer risk”). It replaces some and isolates other complexities instead of simply making things worse, by contrast to pure “featuritis”. I don’t know anyone who would argue that protected memory and pre-emptive multitasking decrease security due to their complexity (if you disagree, go back to using MacOS 9 :-P). I believe that virtualization can provide additional or better security guarantees, and I think that it’s a plus. Virtualization resembles more security in depth instead of just adding more attack surface, although it currently does a mix of both. It’s a tool — just don’t poke your eye out with it, and don’t think it will solve everything.

]]> By: George Jones http://www.cerias.purdue.edu/weblogs/spaf/general/post-108/complexity-virtualization-security-and-an-old-approach/#comment-80805 George Jones Mon, 25 Jun 2007 18:41:02 +0000 http://www.cerias.purdue.edu/weblogs/spaf/kudos-opinions-rants/post-108/complexity-virtualization-security-and-an-old-approach/#comment-80805 > So, I challenge my (few) readers to think about > minimalism. If we reduce the complexity of our > systems what might we accomplish? What might we > achieve if we threw out the current designs and > started over from a new beginning and with our > current knowledge and capabilities? > > > Copyright © 2007 by E. H. Spafford > > [posted with ecto] So, do you think you could give up your fancy, complex Mac/blogging software and do blog posts with telnet ? :-) BTW, I am in full agreement with your basic premise. complexity == insecurity. I just doubt we'll ever get people to choose security over functionality. ---George Jones > So, I challenge my (few) readers to think about > minimalism. If we reduce the complexity of our
> systems what might we accomplish? What might we
> achieve if we threw out the current designs and
> started over from a new beginning and with our
> current knowledge and capabilities?
>
>
> Copyright © 2007 by E. H. Spafford
>
> [posted with ecto]

So, do you think you could give up your
fancy, complex Mac/blogging software
and do blog posts with telnet ? :-)

BTW, I am in full agreement with your
basic premise. complexity == insecurity.
I just doubt we’ll ever get people to choose
security over functionality.

—George Jones

]]>