Information Security Controls Standard

Overview

Information security controls comprise administrative, technical, and physical safeguards designed to ensure the confidentiality, integrity, and availability of UA’s information systems and the data stored, processed, or transmitted by them.  These controls are often required by statutory, regulatory, or contractual language by UA’s partners and governmental agencies.  In other cases, these are standards that UA has adopted or aligned with or are accepted as industry best practice.  In general, these controls are non-disruptive and pursuant to published UA policies, regulations, and standards, should apply as stipulated.  In certain circumstances, these standards may represent a significant burden that conflicts with required capabilities for a specific device, user, business unit, or project.  In such cases, an exception process must exist to allow for the evaluation, avoidance, or substitution of certain information security controls that prove incompatible with business needs.

The purpose of this standard is to communicate expectations and requirements related to requesting an exception to an information security control in place at UA, including roles and responsibilities, procedures for requesting, adjudicating, and managing exceptions, and penalties for non-compliance, etc.

Scope

Information Security and Assurance (ISA) Standards are mandatory and apply to the UA System and all users of UA computing resources.  This standard supplements and supports Board of Regents Policy & Regulation R02.07. These standards are reviewed and approved by the CIO Management Team (CMT), a system-wide governance group consisting of each èßäÉçÇø¹ÙÍø CIO, the System CITO, and the System CISO.  Business units maintaining their own security standards should utilize this standard as a baseline and may add additional requirements or detail as appropriate for their business needs, however, may not weaken any individual element of this standard without an approved Information Security Controls Exception.

It is not the intent of this standard to provide an exhaustive list of relevant information security controls for which an exception may be sought.  Rather, any published policy, regulation, or standard which indicates a requirement to obtain or maintain access to information resources (including but not limited to systems, services, data, or networks) should allow for an exceptions process to take place.  Where a control has its own published exceptions process, that process will take precedence over this one.  In all other cases, the following shall be the default exception handling process.

This standard is periodically reviewed and updated to respond to emerging threats, changes in legal and regulatory requirements, and technological advances.

Definitions

  • Security Control
    A security control is a measure or mechanism implemented to protect information systems, data, and resources from unauthorized access, disruptions, or destruction, and helps to ensure the confidentiality, integrity, and availability of information.

Standard

Procedure

Any user (or UA sponsor, in the case of a non-UA request) requesting deviation from an approved security control must first make the request to their supervisor, documenting the control, the reason for the exception, the duration of the exception, what impact not approving the exception will have on the requestee, and any compensating controls that will be implemented to mitigate risks associated with granting the exception.  Those requesting an exception are encouraged to speak with their central IT organization or the system-wide ISA team for assistance in identifying appropriate compensating controls.  If approved by the supervisor, requests shall be forwarded to the èßäÉçÇø¹ÙÍø CIO, CITO or CISO for review and approval.

 

 

Review and Approval/Denial

If the CIO, CITO, or CISO determines the request is unlikely to have any impact on the other MAUs, they shall review and approve, deny, or request additional details regarding the request within 15 business days of receipt (3 business days for critical or time-sensitive requests).

 

 

Appeal

If the CIO, CITO, or CISO denies or fails to respond to the request in the prescribed time frame, the requestor, with approval of their supervisor and next level supervisor (required only for denial), may submit the request to the CMT for reconsideration.  The CMT shall respond within 2 business weeks of receipt (1 business week for critical or time-sensitive requests).

Required Documentation

If approved by the CIO, CITO, or CISO, the request will be documented by the approver for review and audit purposes by the CMT.  This documentation must include:

  1. the requestor’s name
  2. department/program/business unit
  3. contact information
  4. supervisor information
  5. the control being excepted
  6. start and end dates for the exception
  7. the justification (e.g. implementing an equivalent or superior alternative, planned retirement of a system/service, inability to comply [explain], etc.)
  8. approver’s name
  9. any other relevant information

The approver will ensure the exception request is submitted to the appropriate system/service owner so that the exception is in place by the requested start date.  The system/service owner will communicate any relevant status information to the requestor (and/or CMT or the approver if necessary).  The system/service owner may be required to create or update a System Security Plan (SSP) or Plan of Action and Milestones (POAM).

Requests approved by an individual CMT member shall be shared with the full CMT at the next regularly scheduled CMT meeting to ensure awareness.

Maximum Duration of Exception

Exception requests approved by a CIO, CITO, or CISO must be temporary in nature and not to exceed 14 days.  Exceptions that are intended to persist for more than 14 days (including permanent exceptions) must be presented to and approved by the CMT.  Permanent exceptions are subject to an annual positive confirmation process – should the requestor fail to respond within 14 days to the positive confirmation request, the exception will be deemed no longer required and will be terminated.

 

Periodic Review

All active exceptions will be reviewed at least once annually by the approver and/or CMT to ensure there is still a business need for the exception.  System owners shall review their systems at least once annually to ensure all exceptions are in an approved, active state and will be provided the current approved exceptions list as needed.

The CMT will provide a digest of all approved and denied requests received on a quarterly basis to the Business Council for review and comment.  If desired, a relative risk ranking can be provided for any approved exception request by the CISO.

 

Violations and Exceptions

Per Board of Regents Policy & Regulation R02.07.060  violations of this Standard: 

  • may result in a reduction or loss of access privileges, or the imposition of other restrictions or conditions on access privileges;
  • may subject employees to disciplinary action, up to and including termination; 
  • may subject students to disciplinary action including expulsion according to the Student Code of Conduct procedures; and 
  • may also subject violators to criminal prosecution. 
Requesting an Exception

The process for requesting exceptions to this or other IT Security Standard are outlined in the Information Security Controls Standard.

 

Implementation

OIT Information Security and Assurance is responsible for the implementation, maintenance and interpretation of this IT Standard.

Related Standards

IT Security Standards

References

University of èßäÉçÇø¹ÙÍø Board of Regents Policy & Regulation 02.07 Information Resources

Lifecycle and Contacts

Standard Owner: OIT Information Security and Assurance

Standard Contact: Chief Information Security Officer

Phone: 907-474-5347

Email: ua-ciso@alaska.edu

Approved: September 2024

Effective: September 2024

Next Review: September 2026