The Office of the Secretary of Defense CIO releases policy guidance promoting the use of Open Source Software throughout the DoD.
This is wonderful news, its great to see the DoD taking a leadership position with Open Source. It also puts in place guidance that encourages the evaluation of open source products as well as how they should be managed within the DoD. I believe that other agencies across the Federal Government should be pro-actively creating polices like this within their organizations.
Wednesday Oct 28, 2009
Sunday Oct 25, 2009
Secretary Janet Napolitano delivered a special Cybersecurity webcast this past Tuesday that I thought would be a good opportunity to share some advancements in using complementary layers of protection for Internet services. 
The Internet services environments are just as important for Cybersecurity as your personal computing environment, and I often talk about how information assurance may be improved by following some of our recommendations to limit your exposure to attacks by deploying strong countermeasures. When describing our Cybersecurity capabilities, I like when we demonstrate how effective protection can be constructed with a little ingenuity and assembled with readily available components. You may have heard me talking about the use of Mandatory Access Control (MAC) when describing systems that are deployed within the U.S. Federal Government, but I need to explain more frequently that MAC has additional benefits for commercial use in the enterprise for Internet services. Our contributions to The National Cybersecurity Awareness Month emphasize the mandates that everyone, including those who deploy Internet services, must follow - all of the time - for operating safely online.
Recently, I challenged two of our senior researchers to demonstrate how they enforce MAC with virtualization to confine Internet services with simple security configurations using Solaris. The following information comes from John Weeks and John Totah showing MAC enforcement that they configured for some interesting security restrictions they have been testing for commercial use. They also layered the MAC protection with what you would ordinarily expect from using all of the other Solaris security features combined with virtualization, eg. zones, and Internet community sponsored configuration guidelines such as the Center for Internet Security (CIS) benchmarks.
Introduction
Thanks Bill! - We think the use of MAC is a good way to prevent certain kinds of attacks and is also effective for isolating the remote administration for out-of-band management. Traditional implementations for the “zones of trust” concept often relied on the use of network firewall configurations for isolating
Internet services from other network resources in an enterprise. We realized a long time ago that network firewall architectures by themselves are insufficient for securing Internet infrastructure for services and applications. We understand that we must also apply many of the critical security controls that are now defined in the Consensus Audit Guidelines (CAG) to include operating system confinement techniques. We must also enforce more protection so that the communication endpoints for applications also restrict an attacker from gaining administrative access to other parts of the enterprise. The security failures that we must prevent include improper access control, and the failure to prevent an attacker from manipulating configuration files and manipulating other parts of the environment. The idea of attack resistant architectures is not new, but we want to show a few interesting ways to use Solaris with Trusted Extensions (labeling) enabled as a security container for Internet services.
Too often, we define MAC in terms of labeling to enforce a Multi-Level Security (MLS) policy and sometimes we unfortunately overlook the value that MAC can bring to a virtualized environment. In addition to filesystem MAC security, Solaris provides trusted networking to enforce MAC policy for labeled network communications. The trusted networking can be used to restrict network connections to one-way inbound connections and also isolate administrative network access to manage the Internet services such as configuring an application server. The use of MAC for labeled network restrictions is slightly different than only using host-based firewalls, due to the simple association of a label to communication endpoints that are compared for equality by the kernel and only if the label comparison is successful then the firewall rules are applied.
The basic MAC concept to start with is that labels are associated with all IP addresses that the Solaris host is authorized to communicate with. Obviously, this includes the IP addresses that are configured for the Solaris physical NIC adapters, and also the virtual NICs that are plumbed up within the Solaris host, as well as any virtualized guest operating systems virtual NICs. In addition to the labels associated to all the IP addresses, Solaris may be configured to start labeled Solaris zones when trusted extensions is enabled. The labeled zones may start processes, including Internet services for applications that are also associated with the same label of the labeled zone. It is important to understand that if a process inside a labeled zone attempts to initiate a network connection to an IP address of a different label, the connection will not be permitted based on MAC enforcement by the kernel. However, the interesting MAC enforcement that we
have been using with Solaris is based on the configuration of an address for a NIC that uses a different label than the application process that starts in a labeled zone by listening for connections using a construct called a Multi-Level Port (MLP).
The first example is a Sun Glassfish security container using two labeled zones which must be defined with different labels for Solaris to start. The first labeled zone is where we are running a reverse proxy server to control incoming connections destined for the second labeled zone where we have the Glassfish instance running. We restrict remote administration from another network that is specifically designated for out-of-band management. In each of the zones, we use MAC to enforce incoming connections only and we therefore have robust control over the processes that execute in the confined labeled zones.
The second example replaces the Sun Glassfish security container with a Microsoft Internet Information Services (IIS) security container using Sun VirtualBox that is running Windows Server 2008 using the "Core" installation option. The notable differences between the two examples are that Glassfish security container is using a Java Virtual Machine (VM) to execute in the restricted labeled zone and the Microsoft IIS security container is using Sun VirtualBox to execute in a restricted labeled zone.
The Experiment
To test the use of MAC to restrict connection initiation from Internet hosted services to an enterprise network computing environment, we built an example configuration in our lab to demonstrate what could be accomplished using off-the-web components without modification to their source code. We decided to try a simple configuration that would easily show the basic concepts described above. We were pleasantly surprised to find out how easy it was to construct the prototype to show Bill some of the unique value of MAC to benefit customers that are outside our typical U.S. Federal Government deployments. We start with a simplified system configuration with one NIC connected to the Internet, and another NIC for remote administration allowing connections from an out-of-band management network. 
Our first test example uses the MAC capabilities of Solaris, the Sun GlassFish Application Server, and the Sun Java System Web Proxy Server running on an Ultra 27 Workstation. We configured a virtual DMZ security container in a dedicated labeled zone where the Sun Server Java Proxy instance is running to control incoming connections destined for web services in other zones. 
What's unique about the MAC configuration of the virtual DMZ zone is that the label of the Internet NIC is
different from the label of the virtual DMZ labeled zone itself. This means that the MAC policy will also allow the Proxy to accept incoming connections, but will not allow the Proxy, or any other process that may run in the virtual DMZ labeled zone, to initiate any outbound connections to applications with listeners using the
NIC IP address or through the NIC to any network endpoints.
We also use Solaris IP Filter with traditional host-based firewall rules for the physical NICs as a typical defense-in-depth measure.
Virtual DMZ/Proxy Security Benefits:
* Contained within a labeled zone
* Configuration prevents any outbound Internet connections
* Remote administration is isolated to strictly allow incoming connections from the out-of-band management network
We then configured a virtual WEBAPP security container in the second labeled zone where the Glassfish instance is running and accepting connections from the reverse proxy server running in the virtual DMZ security container. The next step was to configure a dedicated NIC for the WEBAPP zone that allows access to the GlassFish Application Server Administrative port 4848 from the out-of-band management network.
The resulting configuration allows Internet web browser access through the virtual DMZ labeled zone to the WEBAPP labeled zone, and GlassFish Administrative access from the out-of-band management network. You will notice that the administration of the GlassFish running instance is not accessible from the same network that GlassFish is listening on for the application service, nor is the Glassfish administration accessible from within the WEBAPP labeled zone where GlassFish is running. After having success with the DMZ and WEBAPP configuration, we decided to apply the same concepts and methods to Microsoft IIS. We created a new IIS labeled zone and used VirtualBox to run a Windows image as a guest operating system.
1. Used VBox NAT to redirect listener ports (8090 8091)
2. Prevented Windows/IIS from initiating any connections to network endpoints outside of the
WEBAPP labeled zone
3. Remotely administer Windows via VRDP port
4. Remotely administer IIS using IIS Manager via 8172 from the admin network
As you can see, we utilize MAC network isolation within the system, but all external network interfaces are configured as single-level. This means that you could drop such a configuration into an existing enterprise without the need to support labeled networking using Commercial Internet Protocol Security Option
(CIPSO) anywhere in an enterprise.
Other Common Methods to Secure the System
* Follow the National Institute of Standards and Technology (NIST) guidelines to continually manage risks to the enterprise.
* Follow basic concepts that are described in the Immutable Service Containers project.
* Reducing the effective privileges on web components using Solaris Role Based Access Control (RBAC).
* Use Process Rights Management with roles to manage all web services as a role that can't assume the root role.
* Loopback mounting critical system configuration files (e.g., etc/sshd_config) from the labeled zone back to the global zone making them immutable from with the labeled zones.
* Instrument host based introspection using Solaris Dynamic Tracing (DTrace) and analyzing security events with Solaris Auditing.
* Instrument network deep packet inspection using Packet CAPture (PCAP) library interfaces and high performance techniques.
Conclusions
It's nice to see how MAC can be used for protecting Internet services and we look forward to any questions about how much we can effectively improve information assurance using readily available security components. We will be happy to post more of the internal details as a follow up for those who would like to have a better understanding of how MAC protection can help you.
The additional MAC functionality of the OpenSolaris.org Flexible Mandatory Access Control (FMAC) is extremely effective to impose even tighter (fine-grained) security controls and we also welcome your inquires to see how future FMAC concepts can also be beneficial for commercial use.
For the purpose of our initial tests, we omitted a database and the technical controls that we would apply there. However, if anyone is interested, it may be interesting for us to demonstrate the methods and techniques for improving database security. In addition, we can show how e-mail server environments, naming services and other collaboration systems can be protected with MAC to prevent other types of
attacks that may be launched to target the Internet services environment.
We are also looking forward to seeing Homeland Security Secretary Janet Napolitano this week to learn more about our real world challenges and urgency for significant improvements.
Thanks again Bill for giving us the challenge and posting our findings that should help to protect Internet services using MAC for commercial use.
Wednesday Jun 17, 2009
Some people may wonder when I am going to run out of reasons to move to Open Source. I feel like I have the opposite problem. I find it difficult to limit the number of reasons I highlight to move to open source.
I remember back in the 80’s and 90’s everything software-related was focused on “best of breed”. Best of breed was a term that made companies and organization feel special. It made them feel like a solution was tailored to fit their specific problem. Best of breed appealed to egos but mostly it was a term created by a marketer trying to sell product.
Soon, best of breed went the way of other boom technology terms such as robust. However, perhaps in times like today when retro is in, best of breed may make a comeback as the #6 reason to move to open source is the ability engage with a community to get specific requirements into a product.
Governments do not need to settle for the packaged solutions that a vendor is selling them. They can take existing open source solutions, join the community process, and add the features that are right for them, not what a vendor “thinks” is right for them. This is happening all over the government in the Intelligence agencies with examples like FMAC and SE Linux in places like NASA with the World Wind Java 3D project DISA's Government Forge.mil project and many, many, more.
Open source code creates a vehicle for a community of developers (including government organizations and the SIs) to contribute creating applications that meet the government’s requirements. Much like the community development process undertaken by the Nationwide Health Information Network (NHIN), open source put thousands of developers available to develop a truly customized solution made by the masses. NHIN The Office of the National Coordinator developed a pilot 'Reference Implementation' solution based on Sun's open source middleware software that enables multiple federal agencies and private sector organizations to securely link their existing systems to NHIN-CONNECT, allowing for the beginnings of a true interoperable electronic health care record information exchange. The pilot was developed with no need for long procurement cycles or massive costs since the entire software backbone is 100% open source.
I am toying with the idea of posting two more blogs on reason 7 and 8 to move to open source...stay tuned 
Thursday May 28, 2009
Generally speaking, you receive better quality with commercial open source software because of the larger number of reviews the code needs to go through on its way to a production product, and the larger number of people reviewing the code. In most cases, you will see that commercial open source products don't have as many patches or patch cycles as proprietary products. It's important to understand that public scrutiny tends to improve the overall quality of software, just like public scrutiny improves the security of software.
Public scrutiny improves many things, for example, if a movie star is going to have a beach scene in his next film, where he takes off his shirt, he is going to
work out for six months before that scene, right? Because he is going to get publicly scrutinized. That is why movie stars always look in such good shape in the movies 
If you are a proprietary software developer, and your boss walks into your office and says "Fix this before you go home," you will just do whatever you need to get something working so you can head home. It's not as important to you how many memory allocation errors or security flaws you have, because your changes will be included in the next build, and odds are, that as long as it meets the functionality requirements (and does not crash), no one else will even look at your code.
But if you are an open source developer under the same pressure, once you complete that code, you have to submit it to the community for inspection. That community is an average age of 30, and has an average coding experience of 11 years, these are not amateurs. If fact, if you look at places like Slashdot where some of the design discussions take place, they can be ruthless. If they don't like how your code is written, they will criticize it like crazy (along with your intelligence and the intelligence of your family ), much more aggressively than any product manager would with a proprietary vendor.
As a matter of fact, it takes Sun an average of three to four years to take a proprietary product and move its code over into an open source community. A huge amount of that time is spent "cleaning up" the code, so that developers will not be embarrassed in public (among their peers) when the code is released. There are many cases where I have asked product teams to release some products for Government review, before we open the product up, and they often "beg" for more time to clean it up before anyone else gets a chance to look at it. That community peer exposure tends to greatly improve the quality of the code both before it's released, and then after as the community engages in the review process.
After you get through the community review, then you have to go through an architecture review to get included in the product. Next, if the vendor is going to provide support for the product, you have to go through an IP infringement review. Now you will have to show that you can indemnify every line of code that you have and prove that you wrote every line of code that is included in your contribution. If you can't, they won't include it, because they can't indemnify it and guarantee the IP. If you think it's bad to have Techies review it, with open source you have to also have the lawyers review the IP issues with the code, and you know how lawyers can be (I can say that since I am married to a Techie lawyer )
After you are done with those types of inspections, you then have to go through the same kind of inspections that any proprietary vendor would do. Backward compatibilities, security view, QA tests and so on. So open source does receive a lot more inspection and generally leaves with better code. It's not a silver bullet...but it's pretty close.
As you can see from this slide, all major open source products have a community version, and a supported enterprise/commercial version. The peer/community review is done in the open source community environment and once those reviews are done, the code is "harvested or packaged" from the community version to create the enterprise version. Both are open source, but the enterprise version is usually a subset of the community version has gone through the same reviews and QA as any proprietary product. On average, commercial open source products go through about 3x more formal reviews than proprietary products do, and have about 100x more people validating the code and the product.
Wednesday May 20, 2009
Generally speaking you get 90% of the functionality for 10% of the cost. However, in many cases you get more functionality for a lower cost. For example, many of the open source products "grew up" in the Web 2.0 world, so they were made from day one with security and MASSIVE scale as part of their design requirements.
Very few proprietary products were build out of the box to support deployments the size of Google, Yahoo, Facebook, and eBay. All of these deployments are built on open source for many of the reasons I have been talking about in my blog, because open source provides better security, huge scale, all at a much lower deployment cost. If enterprise and web scale is what you need, open source is the way to go. 
Alternately, it is very important to understand the licenses and support agreements and how you are going to use them. There are some examples where the open source licensing and support can be more than a proprietary equivalent. I have found these examples to be rare, but they do exist (for example if you look at the GSA schedule, RedHat on the same server will actually cost you more than Windows). It's important to know the cost of acquisition is zero, but open source is not free in a production environment, because CIOs running mission critical environments need support and indemnification.
Open source enterprise products are ready to support your mission critical applications, in the operating system area there's Solaris, Linux, in the middleware area there's Glassfish, JBoss, in the database area there's MySQL, PostgreSQL and even in the desktop area...which has been lagging behind in open source, but is starting to gain some ground with over 220 Million OpenOffice users. Government organizations can realize significant savings in support costs by moving to open source products.
Bottom line, you are saving money on the licensing cost, support cost, deployment cost, and manpower to deploy it. It's just all goodness from a cost perspective. Lately I have seen numerous government reports estimating many, many billions of dollars that could be saved by moving to open source.
Saturday May 16, 2009
First of all, for any software or hardware platforms, you want to make sure the product you select implements open standards interfaces, so that you are not locked into using only one product. This gives you the flexibility to move from one product to another if you run into security, scaling, support, or cost issues.
However, if the product is open source, because you can see how the interfaces are implemented, it makes reverse engineering them a much more simple process. Being able to see the source code also aids with interoperability, because it removes any ambiguity on how the interfaces are implemented.
The other big advantage to selecting open source is that you can get support from multiple vendors. For example, with Solaris you can get support from HP, IBM, DELL, Sun, INTEL, Fujitsu and AMD (also true for Linux). So anyone can provide support because all of the Solaris code is in the public domain. This also gives you, what I like to call "investment protection." If a company provides you with an open source product, and then goes out of business tomorrow, the code is still in the public domain, so you can easily get another company to pick up your support requirements.
This also saves money because there is competition in providing the support. For a proprietary product, only the company that owns the code can support it. With open source, since you are not locked in, you can compete the support from multiple vendors.
That's a HUGE deal, because in the government sometimes the cycles are so long that a selected vendor could go out of business or completely change its product direction during the life cycle of your project, and that could force a very expensive change and/or extended time line. Also, vendors can often only provide support for one version of their product for about 10 years, and many government projects live longer than that, so by selecting open source products, it gives the government many other support options, for example a Systems Integrator could pick up support for an open source product version that has been EOLed by a vendor.
The selection of an open source product keeps you from being locked into a vendor and provides "investment protection" throughout the entire life of your project and beyond the life of the vendor and that's really, really important in this wild unruly world of mergers and acquisitions, changing economies and those kinds of crazy things
Wednesday May 13, 2009
It's that time of year again where the DoDIIS community comes together for their annual event called DoDIIS Worldwide Conference. This year it'll be held in Orlando, FL at the Orlando World Center Marriott from May 17-21. With this year's theme of "Empowering Decision Advantage," Sun Microsystems Federal and 2 key booth partners, Paragon Systems and GTSI, are providing a venue for the IC to experience new solutions to capitalize on more secure, lower cost, more efficient ways to do more with less - a message that resonates with all government agencies.
What does that really mean....empowering decision advantage? I can tell you what it means to Sun Federal. More effective secure collaboration using visual web services and identity management, faster and more secure feature deployments using open source software products, cross domain solutions to centralize user access; and thin clients to add mobility, reduce costs, and improve security.
So what are we showcasing in the Sun booth (booth #425)? Sun is showcasing MLS thin, thick and soft client solutions; GTSI is showcasing Amber Road - the hottest open storage solution that you don't want to miss; and Paragon Systems is showcasing their Transportable Datacenter solution. Also in our booth will be nationally renowned magician, Scott Tokar, who will literally amaze you with his extraordinary talent of magic and illusion.
As for me, yes, I'll be attending the DoDIIS show too. I'll be a speaker in one of the break-out sessions on Monday afternoon from 2:00-2:45 in Ballrooms F, E, D. Guess what my topic is? (If you've followed my past blogs then it'll be clear.) If you guessed open source then you're right. Sun has a phenomenal story to share and with multiple compelling reasons to choose open source solutions - such as more secure, lower cost and more efficient - I'd love for you to be part of the session if you're attending the show. Stop by the Sun booth (#425) and tell our team "Bill's Blog sent me to your booth."
Monday Apr 27, 2009
Reduced procurement time is the number two reason to move to open source. Why? You don't have to wait for the vendor to pilot and you don't need to go through long evaluations. If you take a look at Health and Human Services (HHS), their Nationwide Health Information Network (NHIN) referenced implementation is being created as an enterprise service to allow a single patient view across 26 agencies that manage your health information in the government.
HHS went to each of the agencies and looked at what they were using for their middleware. Almost all of them were using proprietary middleware. So HHS picked one vendor and went out and received an estimate to deploy it across all 26 agencies. There are 307.2 million people in the country and that vendor came back with a price of approximately $800 million to obtain a license. But we all know in government land, anything over a $100 million has to go through a multi-year, full, open procurement process. So in the meantime, veterans are not getting their prosthetic limbs, seniors are not getting their medications and everything comes to a screeching halt.
There is a HUGE problem with the information system, when we can't share information. So when HHS realized the current procurement process was going to result in a three-year delay, they looked to Sun's open source, enterprise class, middleware...recommended by their Gartner analyst because of its ability to scale and features. All they needed to do was download it. So they downloaded it in about a week, and in less than a month they had it up and running. In the following month they had a pilot, and in the third month they were well on their way to a referenced implementation that is not only being used in the U.S. (first production deployment is Social Security Adminstration), but is now being considered globally to address electronic health information exchange. Now that it is deployed, they are talking about getting a support contract in place. So the choice is simple...three months or three years?
There are numerous great examples like this one all over the federal government, mostly in defense and intelligence, where agencies have moved to open source not only because it is the most secure, but also because it can be deployed much faster...weeks verses years. It can also scale very quickly, so if it needs to be deployed to 7,000 new sites, it can be done quickly and then followed up later with a support contract. No one is held back by "the process."
Check back soon for the No. 3 reason to move to open source.
Thursday Apr 16, 2009
If you are like me, and you have been involved in cryptography and Cyber Security for a long time, it's obvious to you that commercial open source code is more secure. As a matter of fact, in the late 90s, many of the Intelligence agencies mission systems and the DoD tactical systems moved to open source ONLY to improve security. Today, the majority of the critical systems in the Intelligence agencies (the people that care most about Cyber Security) run on open source operating systems like Solaris and Linux. The same is true of places like the FAA, IRS, and a whole lot of other organizations that care about security.
We have a saying in the world of Cyber Security: Security through obscurity, isn't. However, to many, it may not be so obvious, so let me walk you through some of the reasons that commercial open source software tends to be more secure, then I will give you some data at the end to back it up.
First of all, you need to look at the supply chain issues. The reality is today, that ALL software is written globally. You need to deal with the fact that Microsoft, Oracle and IBM software is written in India, China, and Russia. In fact, the majority of all software, open or not, is written all over the world. By making the code open source, nothing can be hidden in the code. 
If the Trojan Horse was made of glass, would the Trojans have rolled it into their city? NO. Open governments are more secure for their citizens, and open source software is more secure for anyone running it. Public scrutiny is a beautiful thing. Just look at free press in this country and open government. We want and need security, peace and tranquility for our citizens. The founders of this country based our government on openness. Open Source enables security. It's pretty obvious when you think about it.
I'm not the only one saying that, of course. One recent examination is in the light of large scale computer intrusions detected coming from a PRC based hacker group. This week the New York Times and CNET ran a story by John Markoff titled "Vast
Spy System Loots Computers in 103 Countries" which details these
attacks. In a related technical report issued by the University of
Cambridge "The snooping dragon: social-malwar surveillance of the
Tibetan movement" on these widespread series of attacks, researchers point out many ways these threats could have been mitigated, including strong endorsement of open source SE Linux and Trusted Open Solaris.
Let me give you another analogy...
I usually like to use car analogies, but lately I've been using this suitcase analogy to make my point about open source and security. Imagine you enter the security line at the airport and there is a proprietary vendor in front of you with his locked suitcase telling the TSA official not to worry, and to trust him, stating he has checked everything in his suitcase and it is safe. How would this make you feel? Pretty vulnerable...right? Wouldn't it be better if the person in front of you is a true open source advocate and welcomes the TSA official to check anything he wants...because he has nothing to hide?
Who are you going to feel safe about getting on the plane with? It's a no-brainer...so why would you trust a vendor to put stuff on your server with life critical or mission critical systems, where no one can see what is on the server except for that one company, or that one group of people. I have sometimes heard some proprietary vendors say about open source code "but everyone can see how the security works." They are making the point for me! That is why open source code has to be made stronger on open source than on proprietary software products.
Proprietary (closed source software) developers say “trust us.” Commercial open source software developers say “see our security...everything we do to build security in: our documentation, models, architecture, review processes, programming language selection, coding standards, source code, verification analysis methods, instrumentation, tools, techniques, automation, certification, ongoing deployment risk management results, remediation, ...” You get the picture. For commercial open source software the security advantages are more than just the ability to view the source code, it's the entire open technology development life cycle that begins with security fundamentals and security goals very early in the process.
The newly announced Building Security In Maturity Model is a great way to openly see how experts can analyze the effectiveness of a software security group and it should be apparent that having commercial open source software developers allow their data collected and security initiatives assessed in public view will increase their resulting security if properly vetted. Think about it, all physical security is open source. You can go to any lock and see how it works at the patent office or on line, but that exposure only makes it more secure.
I often hear from the proprietary vendors that they have "the right" people reviewing their code. That proprietary vendor guy in my suitcase analogy probably had "the right" people back at the office check his suitcase (in China), so the TSA official should just allow the suitcase to go through security without checking it...right? Wrong. With Open Source EVERYONE is looking at and in the suitcase...Even the intelligence agencies.
The Intelligence agencies are part of the Open community that look at code. Keep in mind there are millions and millions of lines of code out there. In Microsoft it's like 30 million lines of code, Oracle I would guesstimate at 15 million lines of code. Solaris has 20 million lines of code. (See page 19). Then you add Linux in at around 12 million lines of code and MYSQL... it compounds quickly. There is no way that a few hundred experts can really review all of the code out there. It truly takes a village.
To make the point even more, when Sun open sourced Solaris - Solaris previously had the highest rating in security that the government offers in enterprise operating systems and still does today. Plus it is certified by the federal government, reviewed by all the best experts in Sun (there are a lot of smart of people at Sun) the intelligence agencies and lot of other smart people out there in the community. When we released the code, within one month we had 28 new vulnerabilities identified by the 160,000 people that are in the Solaris community, and we were able to fix them before some one used them to do something bad.
Same thing happened when we opened sourced Java. Java has had almost no security issues in its entire history. There were three or four issues that came up that we were able to fix before someone could use them for wrong doing. As soon as you move to Open Source there is a lot more that the community will pick up, and you are going to fix it before it can be used for an infiltration rather than after.
So that's why the national security agencies and others made this big initiative to move to open source, because, the public scrutiny increases the quality of the code just like it does with physical security. You know when you use the RSA algorithm, which you use every time you buy something online. The algorithm was done in the public, it was done in Open Source, it was criticized, it was changed, it was criticized again, and it was changed before it was put into production because we have got lots of people looking at it, lots of people criticizing it for security.
Then there was the clipper chip. So the clipper chip was done by the Clinton administration, you may or may not remember it, and the whole idea of the clipper chip was, we won't tell you how it works but you should trust it is secure.
The clipper chip was compromised within 48 hours of its release. Why, because it had a secret in its code inside the lock, the inside was made of paper (they used a 16-bit checksum). It was not open sourced, so it was immediately compromised. Had it been open source, everyone would have seen the weak checksum, and it would have been corrected before it was deployed. The RSA algorithm to my knowledge has never been compromised today other than (brute force).
Remember, security through obscurity, isn't. How many times do we have to see that truth repeated? If you look at common criteria certifications, the two enterprise operating systems with the strongest protection profile and the strongest certification are both Open Source. Open Source drives more security.
Eventually, the trend toward higher assurance levels will hopefully benefit from new open source projects such as Open Proofs and related open source tools such as Why with the associated formal methods open source software components. Again, Open Source drives more security.
If you take a look at the National Vulnerability Database, you can see almost every open source product has had less vulnerabilities exposed and less vulnerabilities exploited against it than the equivalent proprietary products. The NVD is a product of the NIST Computer Security Division, Information Technology Laboratory and is sponsored by the Department of Homeland Security’s National Cyber Security Division.
Here is some risk data provided by the Airius Risk Report® developed from Homeland Security's NVD. 
Here you can see that all the proprietary software products have a MUCH higher security risk than their open source equivalents.
Here they are side by side, and you can see in each case, the open source product is statistically more secure. So the Data does back up the logic. And it's not like the open source products are not widely deployed either...There are over 6 billion Java deployments, 14 million Open Solaris, 120 million Open Office, and 115 million MySQL deployments.
Clearly security is the number one reason to move to open source...Check back soon for the number 2 reason to move to open source.
Airius Risk Report:12/31/07, Copyright Airius Internet Solutions, LLC 2009
Tuesday Mar 17, 2009
I know I said I would create six specific blogs focused on the six reasons to move to Open Source...but while I finish writing my blog on Reason No. 1 - improved security and privacy over proprietary software...I wanted to share a recent on-demand webcast I did with World Wide Technology that answers the question: Why move to Open Source? It details the benefits of Open Source and showcases Open Source products like MySQL, Apache, OpenOffice, Open Solaris and more. Let me know what you think...And Happy St. Patrick's Day.
.
