NEWS AT SEI
This article was originally published in News at SEI on: December 1, 1998
The previous issue of this column covered today’s strategic reliance on
technology and the fundamental business need of all organizations for
security and privacy. We contrasted this reliance with the lack of security
offered in the infrastructure and supporting services upon which the
technology is based. The message I hope you were left with was your need to
use security as a discriminating factor in system and software procurement.
But just purchasing a product with security features is not the end of the story;
just as important is how you deploy that product for use. I’m joined in this
release by Shawn Hernan of the CERTÒ Operations group. We’ll write about
how your interactions with a vendor can affect a vendor’s decisions on the
security of configurations for better or for worse!
Why on earth would a vendor do that?
One aspect of the work that we carry out at the CERTÒ Coordination Center is
vulnerability handling: reviewing reports of security flaws, working with vendors and
domain experts to identify patches and workarounds, and issuing advisories to the
community at large when appropriate. As a result, we constantly receive reports of
apparent security weaknesses in protocols, in software, and in product configurations.
The cause of the flaws identified can vary widely. Some are the result of common or
naive programming errors, while others point to far more subtle issues. On some
occasions, the cause of a security weakness is immediately obvious. On other
occasions, we’re left scratching our heads and saying, “Why on earth did the vendor
do that?” (On closer inspection, the answer is often surprising, but not always
immediately obvious.) On more than one occasion, the answer has been “That’s what
the customer asked for.” It is hard to imagine that a customer would request a security
weakness; but as we’ll show, it happens more often than you might think.
Increasing awareness and customer demand
As a result of increased awareness either from security organizations or their own
adverse experiences, organizations have begun to seek improved security. But simply
requesting security features does not result in the delivery of a product that will be
secure out of the box. Systems are shipped with insecure defaults and with network
services enabled by default (regardless of what percentage of the services a site wants
or plans to use). This contrasts with the model espoused by many security
experts¾deploy systems with secure defaults and disabled network services, then
only enable the functionality that is needed.
Too many sites don’t take the time to address security issues once products are
deployed, even if security was requested in the procurement stage. After delivery, the
pressure is on to get the product installed and interoperating with the existing
technologies. Remembering to turn off unnecessary services that pose a security risk
or enabling security features are often items that don’t make it to the top of a system
administrator’s to-do list. As a result, deployed products interoperate but pose a
security risk (even though they may have security features, these features are not
Primarily, organizations are using technology as a result of a business need. They
want security but they don’t want it to affect their ability to conduct business
effectively and efficiently. So in
addition to requesting security, they continue to demand high-performance products
that will operate in their heterogeneous environments. The resulting message sent to
the vendors is
Provide up-to-date technology with increasedfunctionality and good performance, security features, and default interoperability.
On the surface that sounds like a reasonable enough message to send.
The vendor dilemma
Consider the software marketplace from a vendor’s perspective. Vendors have a
whole range of factors that they must consider when developing a software product.
The biggest driver for most organizations is new software sales, but other major
- keeping pace with technology changes
- keeping pace with competitors’ functionality
- providing interoperability among a range of products
- broadening the range of supported platforms
- providing new functionality to meet changing business needs
Clearly vendors have quite a dilemma when choosing where to apply their available
Security in its own right is notably absent from the list of major factors for the
majority of vendors. Rather, it is considered as a facet in one of the factors listed.
Only customer pressure for increased security features can make this change.
Unfortunately, as far as security is concerned, the vendors continue to receive what
they would perceive as contradictory messages from customers: Provide products
with default security features. Provide products with default interoperability or make
this product secure—turn off the default security to make this product easier to use.
As a result, the vendors provide products with security features, but to address the
interoperability demand, the features are rarely enabled by default. Just recently one
vendor’s experiences of trying to implement improved security was brought to our
attention. This vendor’s story reinforces the general vendors’ dilemma.
One vendor’s experience
One email product vendor has been among the market leaders in implementing
security features in its products. The vendor ships both email servers and email
clients, and was among the first to add a particular kind of secure authentication to
either client or server. Because it was among the first vendors to add the secure
authentication scheme to its products, there was a concern about interoperability:
Would its email client be able to work with other vendors’ email servers, and viceversa?
Would the secure authentication scheme prevent interoperation with other
Complicating matters was the fact that the email protocol did not provide for explicit
failure messages when an authentication attempt failed. That is, the client was unable
to tell if the authentication attempt failed because the password was incorrect or
because the server did not support the same authentication scheme. Possible options if
the client received a failure message:
- Ask the user for the password again, assuming it was incorrect the first time.
- Try a less secure but more widely implemented authentication scheme, namely plaintext passwords.
In other words, the vendor was faced with a tradeoff between interoperability and
security by default.
The vendor chose security by default and started to ship the client so that the default
behavior was to stick with the secure authentication scheme but give the end user a
way to configure the client to use a less secure authentication scheme. The effect of
this security-conscious choice was that the client would work only with a server from
the same vendor, until other vendors implemented the same authentication scheme.
The vendor provided documentation with the product to allow an end user to
configure the product to work with other vendors’ servers. So the issues of security
and interoperability were addressed, but security was primary.
Although the end user could configure the product to work with other vendors’
servers, the vendor received more than 280 trouble reports from sites that thought the
client was broken or that simply didn’t want to reconfigure the client. The customers
wanted interoperability by default. This market pressure forced the vendor to choose
a different set of defaults—the product will now try less secure authentication
schemes if the more secure scheme fails. Thus, if a user makes an error in typing a
password, the client will try the same incorrect password using all of the
authentication schemes, including plain text. This means that if the user makes a typo
in entering a password, the slightly incorrect password is sent on the network in plain
text. More importantly, if an intruder is able to convince a user to establish a
connection to a mail server of the intruder’s choice, the intruder can recover the
user’s password. Thus a consequence of the customers’ demands for default
interoperability was that they obtained a less secure product.
Having changed the default configuration of the product, we would expect that the
vendor would have received trouble reports from other customers complaining about
the less secure configuration. But they received only one such report. The message
sent to this vendor was loud and clear: Default interoperability is more important than
A failed standard?
The need for more secure out-of-the-box defaults is well recognized, so much so that
in 1996 The Open Group (recognized in standards setting for open systems) produced
the X/OpenÒ Baseline Security Services (XBSS) standard
(http://www.opengroup.org/prods/xs.htm). The standard includes a base set of
security-related functionality and a standard “safe” configuration on delivery. The
standard looks promising because it is consistent with other security standards, yet its
focus is more specific and business oriented than other standards such as the Orange
Book, which characterizes criteria for Department of Defense systems for secure
computing architectures across a broad scope from security policy, accountability,
and assurance to documentation. It includes sensible secure defaults such as
- passwords on all accounts by default and changed during installation
- auditing on by default
- access control lists for users and groups
- owner-only access to objects by default
However, we do not know of any out-of-the-box products that conform to XBSS. If
the need for such a standard is recognized and vendors have the capability to
implement the standard in their products, then why isn’t it being adopted? We suspect that the answer is a lack of market demand for security in relation to the demand for
Message received and understood?
When asked, most people will claim that they want security features in their products.
But when confronted with the choice between security and other features, security
often comes up short. How can vendors provide security when customers complain
about secure defaults at the same time that they are demanding security? This is a bit
like specifying that your new house must have a security system with motion
detectors inside and detectors on all windows and doors; but you never turn it on, or
you never change the code on the keypad from the vendor-supplied default of 1234!
When commenting on his company’s experiences, one person from the
vendor organization in our story said, “The bottom line with security is
that people want it, they just don't want to have to know about it.”
Probably most people would agree—that is exactly what they want,
although invisible security may bring its own drawbacks. But in today’s
market, with so many vendors competing on so many fronts, it is not
possible to provide invisible but effective security without a considerable
investment. As the old adage goes, you get what you pay for. Unless the
community is willing to pay for security, vendors won’t invest in
In the meantime, be careful what message you send to your vendors, as you may get
what you ask for, and it may not be what you expected. We only hope that the next
time we’re analyzing a security vulnerability and are left scratching our heads and
saying, “Why on earth did the vendor do that?” it won’t be because the customer
asked for it.
About the authors
Moira J. West-Brown is a senior member of the technical staff within the CERTÒ
Coordination Center, based at the SEI, where she leads a group responsible for
facilitating and assisting the formation of new computer security incident response
teams (CSIRTs) around the globe.
Before coming to the CERTÒ/CC in 1991, West-Brown had extensive experience in
system administration, software development and user support/liaison, gained at a
variety of companies ranging from academic institutions and industrial software
consultancies to government-funded research programs. She is an active figure in the
international CSIRT community and has developed a variety of tutorial and workshop
materials focusing mainly on operational and collaborative CSIRT issues. She was
elected to the Forum of Incident Response and Security Teams Steering Committee in
1995 and is currently the Steering Committee Chair. She holds a first-class bachelor's
degree in computational science from the University of Hull, UK.
Shawn Hernan is a member of the technical staff at the CERT Coordination Center
where he leads the vulnerability handling group. Prior to joining CERT, Shawn
worked for the Systems and Networks division of the University of Pittsburgh for
seven years where he developed databases and network applications, and shared in
the system administration of the centralized computing facilities and the large campus