IT Resources Configuration Management

Purpose

The purpose of this policy is to establish information security standards for the configuration management processes relevant to University of Maryland Global Campus ("UMGC" or "University") Information Technology Resources.

Scope and Applicability

This policy applies to all University Information Systems and Information Technology Resources. Information System Stewards and Technical System Leads are responsible for adhering to this policy.

Definitions

Capitalized terms shall have the meaning ascribed to them herein and shall have the same meaning when used in the singular or plural form or any appropriate tense.

1. Authorized User: A User who has been granted authorization to access electronic Information Resources and is current in their privileges.

2. Baseline Configuration: A documented set of specifications for an information system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.

3. Configuration Settings: A set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices, network components (e.g., firewalls, voice and data switches, routers, wireless access point, network appliances, sensors), operating systems, middleware, and applications.

4. Blacklist: A list of discrete entities, such as hosts or applications that have been previously determined to be associated with malicious activity.

5. Contractor: A person or a company that undertakes a contract to provide materials or labor to perform a service.

6. Employee: University staff and faculty, including nonexempt, exempt, and overseas staff and collegiate faculty.

7. Information System: Inter-related components of Information Technology Resources working together for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

8. Information System Steward: A UMGC staff member or other individual providing services to the University who is responsible for the development, procurement, compliance, and/or final disposition of an Information System.

9. Information Technology Resource: Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by UMGC directly or by a third party under a contract with UMGC which requires the use of such equipment. The term includes computers, mobile devices, software, firmware, services (including support services), and UMGC's network via a physical or wireless connection, regardless of the ownership of the Information Technology Resource connected to the network.

10. Least Functionality: The principle of least functionality provides that information systems are configured to provide only essential capabilities and to prohibit or restrict the use of non-essential functions, such as ports, protocols, and/or services that are not integral to the operation of that information system.

11. Security Parameters: Parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include, but are not limited to, registry settings, account, file, directory permission settings, and settings for functions, ports, protocols, and remote connections.

12. Technical System Lead: An Employee or individual providing services to the University who works to ensure that the Information System meets the business expectations around functionality and deliverable as well as the integration, modification, security, operation and maintenance of an Information System.

13. User: A University community member, including but not limited to, staff, faculty, students, alumni, and individuals working on behalf of the University, including third party vendors, Contractors, consultants, volunteers, and other individuals who may have a need to access, use or control University Data.

14. User-Installed Software: User-installed application software refers to software applications that are installed on a computer by an end user, instead of by the corporate IT department. Software applications provisioned by IT are typically tested to ensure compatibility and stability, but a user installed application can cause problems for other applications or for the entire operating system. In a traditional environment, this is less of a problem because it will only affect one user. With the advent of desktop virtualization, however, user-installed applications can be a threat to an entire environment.

15. Whitelist: A process used to identify software programs that are authorized to execute on a system or authorized Universal Resource Locators (URL)/websites.

Configuration Management

Information System Stewards or Technical System Leads should adhere to the University's Configuration Management Policy when configuring and managing University Information Technology Resources to prevent unauthorized changes from being made.

1. Baseline Configurations should be established, documented, and maintained and inventories of University Information Systems throughout the respective system development life cycles.

2. Information System Stewards must employ the principle of Least Functionality by configuring University Information Systems to provide only essential capabilities.

3. User-installed software must be controlled and monitored. The Information System Steward must ensure that all software end user licensing agreements (EULA) are reviewed and approved by the UMGC Procurement team prior to deployment on a University device.

4. Security Configuration Settings for information technology Resources employed in University Information Systems must be established and enforced. Information System Stewards should document the Security-related configuration settings and apply them to all systems once tested and approved.

5. Changes to University Information Systems must be tracked, reviewed, approved or disapproved, and logged. Configuration change control for Information Systems should involve the systematic proposal, justification, implementation, testing, review, and disposition of changes to the systems, including system upgrades and modifications.

6. The security impact of changes should be analyzed prior to implementation and a plan established to ensure the ability to reverse a deployment or implementation.

7. Physical and logical access restrictions associated with changes to University Information Systems should be defined, documented, approved, and enforced. Control of configuration management activities may involve:

   1. Logical access control which prevents unauthorized users from logging onto an Information System to make configuration changes (e.g., requiring specific credentials for modifying configuration settings, patching software, or updating software libraries),

   2. Workflow automation in which configuration management workflow rules define human tasks and data or files are routed between people authorized to do configuration management based on pre-defined business rules (e.g., passing an electronic form to a manager requesting approval of configuration change made by an authorized employee),

   3. An abstraction layer for configuration management that requires changes be made from an external system through constrained interface (e.g., software updates can only be made from a patch management system with a specific IP address), and

   4. Utilization of a configuration management change window (e.g., software updates are only allowed between 8:00 AM and 10:00 AM or between 6:00 PM and 8:00 PM).

8. Nonessential programs, functions, ports, protocols, and services should be restricted, disabled, or prevented.

   1. All unnecessary programs and accounts are removed from all endpoints and servers.

   2. The University makes a policy decision to control the execution of programs through either whitelisting or blacklisting. Whitelisting means a program can only run if the software has been vetted in some way, and the executable name has been entered onto a list of allowed software. Blacklisting means any software can execute as long it is not on a list of known malicious software. Whitelisting provides far more security than blacklisting, but the University's policy can direct the implementation of either approach. Control of execution applies to both servers and endpoints.

   3. The University restricts the use of all unnecessary ports, protocols, and system services in order to limit entry points that attackers can use. For example, the use of the FTP service is eliminated from all computers, and the associated ports are blocked unless a required service utilizes those ports. The elimination of nonessential functionality on the network and systems provides a smaller attack surface for an attacker to gain access and take control of your network or systems.

9. A Deny-by-exception (Blacklisting) policy should be applied to prevent the use of unauthorized software or a deny all, permit-by-exception (Whitelisting) policy should be applied to allow the execution of authorized software.

Exceptions

Exceptions to this policy should be submitted to the VP of Information Security for review and approval. If an exception is requested a compensating control or safeguard should be documented and approved.

Enforcement

1. Any Employee, Contractor, or third-party performing duties on behalf of the University with knowledge of an alleged violation of this Policy shall notify the VP of Information Security as soon as practicable.

2. Any Employee, Contractor, or other third-party performing duties on behalf of the University who violates this Policy may be denied access to Information Resources and may be subject to disciplinary action, up to and including termination of employment or contract or pursuit of legal action.

Related Policies

1. Acceptable Use

2. Account Management

3. Information Security

4. Information Security Audit and Accountability

5. Information Security Incident Management

6. Maintenance

7. Media Protection

8. System and Communication Protection

9. System and Information Integrity

Effective Date: This policy is effective as of the Effective Date set forth above.