I was interested in running Fedora Core 12 amd64 as dom0. Since the default kernel has no dom0 support, I wanted to use the myoung dom0 kernels. Unfortunately, they won't work with Xen 3.4.2 which is the latest included build in Fedora Core 12 and even Rawhide. I took the latest 3.4.3 build, rolled them into RPMs, and installed it. This works with the myoung kernels. Hopefully it will be of use to some of you. If there is interest, I'll stand up a yum repo for this. Chime in with a comment if you are in need of this. 

xen-3.4.3-2.fc12.x86_64.rpm

xen-devel-3.4.3-2.fc12.x86_64.rpm

xen-doc-3.4.3-2.fc12.x86_64.rpm

xen-hypervisor-3.4.3-2.fc12.x86_64.rpm

xen-libs-3.4.3-2.fc12.x86_64.rpm

xen-runtime-3.4.3-2.fc12.x86_64.rpm

I'm quite interested in the Eucalyptus Cloud platform. I wanted to run it on a Fedora Core 12 amd64 platform, yet they only make RPMs available for CentOS. I corrected a bunch of things in the spec files and rolled binary RPMs for Fedora. I hope they are useful. If there is demand I'll stand up a yum repo for them as well. Please chime in with comments if you are interested in this.

euca-axis2c-1.6.0-1.x86_64.rpm

eucalyptus-1.6.2-1.x86_64.rpm

eucalyptus-cc-1.6.2-1.x86_64.rpm

eucalyptus-cloud-1.6.2-1.x86_64.rpm

eucalyptus-common-java-1.6.2-1.x86_64.rpm

eucalyptus-gl-1.6.2-1.x86_64.rpm

eucalyptus-nc-1.6.2-1.x86_64.rpm

eucalyptus-sc-1.6.2-1.x86_64.rpm

eucalyptus-walrus-1.6.2-1.x86_64.rpm

euca-rampartc-1.3.0-1.x86_64.rpm

As I write this, there is a massive recall and public outcry against Toyota for a faulty accelerator that could cause unintended acceleration. This presents a risk of accident or death in a number of cases and has been taken very seriously by the government, public, and media. My first reaction was this: they should put their CIO/CISO in charge of the recall because they deal with ‘recalls’ multiple times a week in the form of vulnerable software.

Are software vulnerabilities any less risky than a faulty accelerator? Does software not control every major facet of our critical infrastructure, transportation, financial, and personal health and well being? Imagine the highway was filled with cars that have the same number of ‘severity 5’ defects that our software and applications have. How safe would you feel driving home? Would you be willing to take your car in monthly on “Recall Tuesday” to have it fixed?

If we have established that software defects and vulnerabilities (which could be misconfigurations, programming errors, and the like) are critical to our well being and economic viability, why do we continue to make choices to purchase new software and develop new applications that are not secured to the level of risk we wish to accept? It seems that we would want to consider security and reliability as one of the cornerstones of our decision-making process, yet we rarely do.

My personal conclusion to that question is because we have the economics wrong. The risk reduction incentives of safer software aren’t aligned with the business decisions when choices are being made. This includes choice of what vendor to work with, what software to purchase, how to develop your own application, how to configure your server, and all of the other factors that contribute to our technical vulnerabilities.

It doesn’t have to be this way. There are models that have been effective in realigning choice and incentives to achieve a goal. Let’s take one specific example as a case study in redefining the incentives to realize a desired outcome.

economic_incentives_and_security.pdf

I shared the following text with my organization recently for security awareness purposes. I thought it was worth posting as well.

There's a fairly new website called Foursquare. It is a free site that allows people to publish their physical location via twitter. The idea is you can tell the world you are at the movies and perhaps catch up with friends who are also in the area. Do you see where this is going yet?