SI-11 Error Handling

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Moderate, High	System	None

Related controls: AU-2, AU-3, SC-31, SI-2, SI-15

Control statement

• a. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and
• b. Reveal error messages only to [Assignment: organization-defined personnel or roles].

NIST discussion

Organizations consider the structure and content of error messages. The extent to which systems can handle error conditions is guided and informed by organizational policy and operational requirements. Exploitable information includes stack traces and implementation details; erroneous logon attempts with passwords mistakenly entered as the username; mission or business information that can be derived from, if not stated explicitly by, the information recorded; and personally identifiable information, such as account numbers, social security numbers, and credit card numbers. Error messages may also provide a covert channel for transmitting information.

Assessment objectives (SP 800-53A)

Objectives and methods for SI-11

Determine if:

• SI-11a. error messages that provide the information necessary for corrective actions are generated without revealing information that could be exploited;
• SI-11b. error messages are revealed only to [Assignment: organization-defined personnel or roles].

Examine: System and information integrity policy; system and information integrity procedures; procedures addressing system error handling; system design documentation; system configuration settings and associated documentation; documentation providing the structure and content of error messages; system audit records; system security plan; other relevant documents or records.

Interview: Organizational personnel responsible for information input validation; organizational personnel with information security responsibilities; system/network administrators; system developer.

Test: Organizational processes for error handling; automated mechanisms supporting and/or implementing error handling; automated mechanisms supporting and/or implementing the management of error messages.

Policy statement

• The System owner shall ensure the system generates error messages that provide the information needed for corrective action without revealing information that could be exploited. (SI-11a)
• The System owner shall ensure the system reveals detailed error messages only to Fill in: personnel or roles to whom error messages are to be revealed Typical: system administrators and developers with a need to know, through the system’s logs. (SI-11b)

From the System and Information Integrity Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SI-11 asks the system to give error messages that help correct the problem without revealing anything an attacker could use (a), and to show detailed error messages only to the people you name (b). NIST’s SI-11 discussion lists exploitable information: stack traces and implementation details; failed logon attempts where a password was typed as the username; mission or business information that can be derived from what is recorded; and personally identifiable information such as account numbers, social security numbers and credit card numbers. It also says error messages can be a covert channel. SI-11 is in the Moderate and High baselines, not Low.

Like SI-10, SI-11 is mostly built in during development and checked in testing (SA-11), with the detail going to the logs, where AU-9 protects it.

Common implementations. Users see a short, generic message and a reference number; the full detail, keyed to that number, goes to the application log. Production builds have debug output, verbose errors and framework error pages turned off. Login, registration and password reset pages give the same message whether or not the account exists. Logging libraries mask personally identifiable information and secrets before they are written. Web servers, load balancers and API gateways return standard error pages that do not name the product or version.

Organization-defined parameters. Typical value, from the System and Information Integrity policy, which your organization may set differently:

Parameter	Typical value
Who may see detailed error messages (b)	System administrators and developers with a need to know, through the system’s logs

Sending detail to the logs means log access is the control: the people who can read the application logs are the people who can see detailed errors, so keep that group to those named.

Evidence assessors ask for.

• The secure coding standard’s rules on error handling and logging of sensitive data
• The production configuration showing debug mode and detailed errors turned off
• Screenshots or the assessor’s own tests of error pages, failed logons and password resets
• A sample of application log entries, checked for passwords, personally identifiable information or secrets
• Who has access to the application logs, compared with the people named

Inheritance. Usually system-specific: each application owns its own messages. Web servers and gateways shared across systems can provide standard error pages as a common control. A software as a service product’s error handling is the provider’s.

Common findings.

• Stack traces, SQL errors or server versions shown to users, found by scans or penetration tests.
• Login or reset pages that say “user not found”, letting an attacker list valid accounts.
• Passwords typed into the username field, or full card or account numbers, written to logs.
• Detailed errors visible in logs that many people can read, such as a shared logging platform with broad access.

Enhancements in the Moderate baseline. None. SI-11 has no enhancements.

Artifacts

• System and Information Integrity Decision Worksheet
• System and Information Integrity Policy