U.S. Flag Official website of the Department of Homeland Security

Note: This page is part of the us-cert.gov archive.This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact info@us-cert.gov if you have any questions about the US-CERT website archive.


Design Configuration Subsystems Correctly and Distribute Safe Default Configurations

Published: June 20, 2013

Author(s): William L. Fithen Maturity Levels and Audience Indicators: L4  / D/P  SDLC Life Cycles: Implementation Copyright: Copyright © Carnegie Mellon University 2005-2012.


Poorly designed configuration subsystems and poor default configurations may produce system vulnerabilities.


The configuration of a system is the non-executable data delivered with a system that governs its dynamic behavior. The configuration is generally a set of variable values that supply information to the system in order to customize its behavior for a particular environment.

Default Configurations

This occurs when a system is shipped with a default configuration <define> <j2ee XML aspect oriented programming> that is insecure [Schneier 02: II. Default Configurations].

While this is not a programming vulnerability, it is an engineering vulnerability that is introduced in the product packaging phase of the software development life cycle.

Management or Debugging Interfaces Left Enabled

Administrative interfaces can lead to vulnerability. Sometimes the interface is left in by mistake. Sometimes it is intentional, but insecure.

In many cases, such administrative interfaces are configurable. In general, the solution to such interfaces is to configure them off. If, however, the product ships with such interfaces enabled by default, then one would reasonably classify this as a vulnerability in the product (if not in the software per se).

Administrative or management interfaces should always be restricted (via [authentication, authorization]) to proper administrators or managers.

Configuration Languages Too Complex

When the configuration "language" of a system is too complex, insufficiently expressive, contradictory, misleading, or ambiguous, it is reasonable to argue that this design will produce deployed systems that are vulnerable.

For example, avoid double or triple negatives, such as

no-read: false

When complex configuration languages are necessary,1 be sure to include in system adequate tooling for creating, managing, and checking such configuration files.


CitationBibliographic Entry

[Landwehr 93]

Landwehr, Carl; Bull, Alan; & McDermott, John. "A Taxonomy of Computer Program Security Flaws, with Examples." Technical report NRL/FR/5542--93/9591. United States Navy, Naval Research Laboratory, Nov. 1993.

[Schneier 02]

Schneier, Bruce. "Judging Microsoft." Crypto-Gram Newsletter. February 15, 2002. http://www.schneier.com/crypto-gram-0202.html


Vulnerability Note VU#247371: Borland/Inprise Interbase SQL database server contains backdoor superuser account with known password. cert.org, 2001. http://www.kb.cert.org/vuls/id/247371.


Vulnerability Note VU#602734: Cisco default install of IBM Director agent fails to authenticate users for remote administration. cert.org, 2004. http://www.kb.cert.org/vuls/id/602734.


Vulnerability Note VU#858726: MailPost discloses sensitive system information when operating in debug mode. cert.org, 2004. http://www.kb.cert.org/vuls/id/858726.


Back to Top