NEWS AT SEI
This library item is related to the following area(s) of work:Security and Survivability
This article was originally published in News at SEI on: December 1, 1998
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.
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 enabled).
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.
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 factors include
Clearly vendors have quite a dilemma when choosing where to apply their available resources.
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 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 vendors’ products?
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:
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 default security.
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
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 default interoperability.
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 providing it.
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.
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 network.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.