Unnecessary built-in application accounts must be disabled.

From Application Security and Development Security Technical Implementation Guide

Associated with: CCI-003109

SV-85023r1_rule Unnecessary built-in application accounts must be disabled.

Vulnerability discussion

Default passwords and properties of built-in accounts are often publicly available. Anyone with necessary knowledge, internal or external, can compromise an application using built-in accounts.Built-in accounts are those that are added as part of the installation of the application software. These accounts exist for many common Commercial Off-the-Shelf (COTS) or open source components of enterprise applications (e.g., OS, web browser or database software).

Check content

Review the application documentation and identify if the application creates or utilizes built-in accounts. Examine the account list for obvious examples (e.g., accounts with vendor names such as Oracle or Tivoli). Verify that these accounts have been removed or disabled. If enabled built-in accounts are present, ask the application representative the reason for their existence. If the account is required in order for the application to operate properly, verify the account password has been changed to a DoD acceptable value. If these accounts are not necessary to run the application, or if the accounts are required and the password has not been changed to meet DoD password requirements, this is a finding.

Fix text

Disable unnecessary built-in userids, use other strong authentication when possible and use strong passwords if accounts are necessary for application operation.

Pro Tips

Lavender hyperlinks in small type off to the right (of CSS class id, if you view the page source) point to globally unique URIs for each document and item. Copy the link location and paste anywhere you need to talk unambiguously about these things.

You can obtain data about documents and items in other formats. Simply provide an HTTP header Accept: text/turtle or Accept: application/rdf+xml.