Security Policy Exceptions

There are times in which an organization (or a department within an organization) may realize that an information security policy requirement may not be reasonable or even possible for them to implement. In these cases an information security policy requirement exception should be developed. The benefit to creating a policy exception is that the information security requirement is directly addressed and a documented rationale is provided explaining why the exception is requested or taken.

An information security policy exception is a gap between the information security requirements and the adopted information security policy. In most cases information security policy will reflect information security requirements, but occasionally an organization may find it appropriate to document an exception to a requirement. Exceptions are generally noted with a modification to the requirement, with compensating controls, or with a risk-based rationale. Each of these information security policy exception types are explained below:

• Exception with Requirement Modification – This type of policy exception acknowledges the security requirement but provides a modification to the strength, frequency, or application of the requirement. For example, the policy statement below is modified to perform a review of selected audit events every six months instead of every year.

Audit Reviews and Updates – The department shall review and update the selected audited events annually every six months, or as required.

• Exception with Compensating Controls – This type of policy exception acknowledges the security requirement, states the requirement cannot (or will not) be met by the system, system component, or the department, and provides compensating controls to address residual risks of not implementing this control. For example, the policy statement below states that the identification and authentication requirement cannot be met by a system component and offers a list of compensating controls to offset the residual risk.

Identification and Authentication of Organizational Users - The Department shall ensure the organization’s information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users.

Exception: Thin client workstations require a logon to provide access to applications. Group identifiers are used for thin clients.

Compensating Controls

Thin client desktop has not access to sensitive data.

Data may not be stored on thin client desktops.

Each application requires a unique user identifier and authentication credential to login.

·????? Exception with Risk-Based Rationale - This type of policy exception acknowledges the security requirement, states the requirement cannot (or will not) be met by the system, system component, or the department, and provides a risk-based rationale to address residual risks of not implementing this control. For example, the policy statement below states that the authentication feedback requirement cannot be met by a web-based application in the system and offers rationale of why the risk is considered low for this component.

Authenticator Feedback - The Department shall ensure the state information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

Exception: Web-based application has an option to “show password” while providing authentication information. Users are instructed to guard their screen and to only use this option when providing authentication information after a failed attempt. The risk of exposure is considered low based on limited use of the web application to a protected environment and user training provided for protection from shoulder surfing.

Passage from the Security Policies, Procedures, and Standards. Order your copy: https://www.amazon.com/Information-Security-Policies-Procedures-Standards/dp/036766996X