Posts tagged monocultures

Page Content


[tags]diversity, complexity, monocultures[/tags]
In my last post, I wrote about the problems brought about by complexity.  Clearly, one should not take the mantra of “simplification” too far, and end up with a situation where everything is uniform, simple, and (perhaps) inefficient.  In particular, simplification shouldn’t be taken to the point where diversity is sacrificed for simple uniformity.

Nature penalizes monocultures in biological systems.  Monocultures are devastated by disease and predators because they have insufficient diversity to resist.  The irish potato famine, the emerald ash borer, and the decimation of the Aztecs by smallpox are all examples of what happens when diversity is not present. Nature naturally promotes diversity to ensure a robust population.

We all practice diversity in our everyday lives.  Diversity of motor vehicles, for instance supports fitness for purpose—a Camero, is not useful for hauling dozens of large boxes of materials.  For that, we use a truck.  However, for one person to get from point A to point B in an economical fashion, a truck is not the best choice.  It might be cheaper and require less training to use the same vehicle for everything, but there are advantages to diversity.  Or tableware—we have (perhaps) too many forks and spoon types in a formal placesetting, but try eating soup with a fork and you discover that some differentiation is useful!

In computing, competition has resulted in advances in hardware and software design.  Choice among products has kept different approaches moving forward.  Competition for research awards from DARPA and NSF has encouraged deeper thought and more focused proposals (and resultant development).  Diversity in operating systems and programming languages brought many advancements in the era 1950-2000.  However, expenses and attempts to cut staff have led to widespread homogenization of OS, applications, and languages over approximately the last decade.

Despite the many clear benefits of promoting diversity, too many organizations have adopted practices that prevent diversity of software and computing platforms.  For example, the OMB/DoD Common Desktop initiative is one example where the government is steering personnel towards a monoculture that is more maintainable day-to-day, but which is probably more vulnerable to zero-day attacks and malware.

Disadvantages of homogeneity:

  • greater susceptibility to zero-day vulnerabilities and attacks
  • “box canyon” effect of being locked into a vendor for future releases
  • reduced competition to improve quality
  • reduced competition to reduce price and/or improve services
  • reduced number of algorithms and approaches that may be explored
  • reduced fitness for particular tasks
  • simpler for adversaries to map and understand networks and computer use
  • increased likelihood that users will install unauthorized software/hardware from outside sources

Advantages of homogeneity:

  • larger volume for purchases
  • only one form of tool, training, etc needed for support
  • better chance of compatible upgrade path
  • interchangeability of users and admins
  • more opportunities for reuse of systems

Disadvantages of heterogeneity:

  • more complexity so possibly more vulnerabilities
  • may not be as interoperable
  • may require more training to administer
  • may not be reusable to the same extent as homogeneous systems

Advantages of heterogeneity:

  • when at a sufficient level greater resistance to malware
  • highly unlikely that all systems will be vulnerable to a single new attack
  • increased competition among vendors to improve price, quality and performance
  • greater choice of algorithms and tools for particular tasks
  • more emphasis on standards for interoperability
  • greater likelihood of customization and optimization for particular tasking
  • greater capability for replacement systems if a vendor discontinues a product or support

Reviewing the above lists makes clear that entities concerned with self-continuation and operation will promote diversity, despite some extra expense and effort.  The potential disadvantages of diversity are all things that can be countered with planning or budget.  The downsides of monocultures, however, cannot be so easily addressed.

Dan Geer wrote an interesting article for Queue Magazine about diversity, recently.  It is worth a read.

The simplified conclusion: diversity is good to have.

On standard configurations

[tags]monocultures, compliance, standard configurations, desktops, OMB[/tags]

Another set of news items, and another set of “nyah nyah” emails to me.  This time, the press has been covering a memo out of the OMB directing all Federal agencies to adopt a mandatory baseline configuration for Windows machines.  My correspondents have misinterpreted the import of this announcement to mean that the government is mandating a standard implementation of Windows on all Federal machines.  To the contrary, it is mandating a baseline security configuration for only those machines that are running Windows.  Other systems can still be used (and should be).

What’s the difference? Quite a bit. The OMB memo is about ensuring that a standard, secure baseline is the norm on any machine running Windows.  This is because there are so many possible configuration options that can be set (and set poorly for secure operation), and because there are so many security add-ons, it has not been uncommon for attacks to occur because of weak configurations.  As noted in the memo, the Air Force pioneered some work in decreeing security baseline configurations.  By requiring that certain minimum security configuration settings were in place on every Windows machines, there was a reduction in incidents.

From this, and other studies, including some great work at NIST to articulate useful policies, we get the OMB memo.

This is actually an excellent idea.  Unfortunately, the minimum is perhaps a bit too “minimum.”  For instance, replacing IE 6 under XP with Firefox would probably be a step up in security.  However, to support common applications and uses, the mandated configuration can only go so far without requiring lots of extra (costly) work or simply breaking things.  And if too many things get broken, people will find ways around the secure configuration—after all, they need to get their work done!  (This is often overlooked by novice managers focused on “fixing” security.)

Considering the historical problems with Linux and some other systems, and the complexity of their configuration, minimum configurations for those platforms might not be a bad idea, either.  However, they are not yet used in large enough numbers to prompt such a policy.  Any mechanism or configuration where the complexity is beyond the ken of the average user should have a set, minimum, safe configuration. 

Note my use of the term “minimum” repeatedly.  If the people in charge of enforcing this new policy prevent clueful people from setting stronger configurations, then that is a huge problem.  Furthermore, if there are no provisions for understanding when the minimum configuration might lead to weakness or problems and needs to be changed, that would also be awful.  As with any policy, implementation can be good or be terrible.

Of course, mandating the use of Windows (2000, XP, Vista or otherwise) on all desktops would not be a good idea for anyone other than Microsoft and those who know no other system.  In fact, mandating the use of ANY OS would be a bad idea.  Promoting diversity and heterogeneity is valuable for many reasons, not least of which are:

  1. limit the damage possible from attacks targeting a new or unpatched vulnerability
  2. limit the damage possible from a planted vulnerability
  3. limit the spread of automated attacks (malware)
  4. increase likelihood of detection of attacks of all kinds
  5. provide incentive in the marketplace for competition and innovation among vendors & solutions
  6. enhance capability to quickly switch to another platform in the event a vendor takes a turn harmful to local interests
  7. encourages innovation and competition in design and structure of 3rd-party solutions
  8. support agility—allow testing and use of new tools and technologies that may be developed for other platforms

These advantages are not offset by savings in training or bulk purchasing, as some people would claim.  They are 2nd order effects and difficult to measure directly, but their absence is noted….usually too late.

But what about interoperability?  That is where standards and market pressure come to bear.  If we have a heterogeneous environment, then the market should help ensure that standards are developed and adhered to so as to support different solutions.  That supports competition, which is good for the consumer and the marketplace.

And security with innovation and choice should really be the minimum configuration we all seek.

[posted with ecto]