DGS_Configuration_Management_Policy_Compliance.pdf

GOVERNMENT OF THE DISTRICT OF COLUMBIA

DEPARTMENT OF GENERAL SERVICES

ttachment Q

Department of General Services onfiguration Management Policy

Government of the District of Columbia Department of General Services

Configuration Management Policy

Policy Number:

IT-CM-001.0

Approval Date:

6/4/2026

Effective Date:

7/7/2026

Approved by:

Ian Williams

Reviewed by General Counsel: Reviewed by Agency Director:

1. Purpose

This policy establishes mandatory baseline configuration and system hardening requirements for all Department of General Services vendor provided networking and infrastructure devices prior to their connection to the District of Columbia Government (District) network or information systems. The purpose is to ensure that all devices entering the District environment are securely configured, aligned with approved baselines, and protected against vulnerabilities that may compromise the confidentiality, integrity, or availability of District information assets.

This policy supports the District’s overall IT security posture by preventing insecure or noncompliant devices from being introduced into District networks.

2. Authority

DC Official Code § 1-1401 et seq.,

3. Applicability

This policy applies to:

• All vendor supplied or contractor managed network and infrastructure devices, including but not limited to servers, access points, and security appliances.

• Any device intended for connection to District networks, data centers, cloud environments, or operational technology (OT) systems.

• All personnel involved in procurement, deployment, configuration, or management of such devices.

4. Policy

4.1 Baseline Configuration Requirements

1. All vendor-provided devices must be delivered with a secure, documented baseline configuration approved by OCTO prior to deployment.

2. Baselines must align with recognized industry standards, including CIS Benchmarks or vendor-specific secure configuration guides.

3. Baseline configurations must be documented, version-controlled, and maintained throughout the device lifecycle.

4. Devices may not be deployed using vendor default configurations or “quick-start” templates unless explicitly approved by OCTO.

4.2 System Hardening Requirements

1. All devices must be hardened prior to connection to any District network. Hardening must include:

o Disabling unnecessary services, ports, and protocols.

o Enforcing strong authentication and role-based access control.

o Securing management interfaces (e.g., SSH, HTTPS, out-of-band management).

o Removing or changing all default credentials.

o Enabling logging, auditing, and time synchronization.

2. Hardening must follow CIS Level 1 security benchmarks, at a minimum for secure configuration and boundary protection.

3. Devices must support configuration integrity monitoring to detect unauthorized changes.

4.3 Vendor Compliance Requirements

1. Vendors must provide documentation demonstrating compliance with District baseline and hardening requirements, including:

o Full configuration export of the device as delivered.

o List of applied hardening controls.

o Evidence of compliance with the District’s approved baseline.

o Firmware and OS version information.

2. Vendors must certify that no known critical vulnerabilities exist in the delivered configuration.

Step To Do CIS

Preparation and Installation

If machine is a new install, protect it from hostile network traffic, until the operating system is installed and hardened.

Service Packs and Hotfixes

2 Install the latest service packs and hotfixes from Microsoft.

3 Enable automatic notification of patch availability.

User Account Policies

4 Set minimum password length. 1.1.4

5 Enable password complexity requirements. 1.1.5

6 Do not store passwords using reversible encryption.

(Default) 1.1.7

7 Configure account lockout policy. 1.2

User Rights Assignment

8 Restrict the ability to access this computer from the network to Administrators and Authenticated Users. 2.2.3

9 Do not grant any users the 'act as part of the operating system' right. (Default) 2.2.4

10 Restrict local logon access to Administrators. 2.2.8

11 Deny guest accounts the ability to logon as a service, a batch job, locally, or via RDP. 2.2.18-21

Security Settings

12 Disallow users from creating and logging in with Microsoft accounts. 2.3.1.2

14 Disable the guest account. (Default) 2.3.1.3

15 Require Ctrl+Alt+Del for interactive logins. (Default) 2.3.7.2

16 Configure machine inactivity limit to protect idle interactive sessions. 2.3.7.3

17 Configure Microsoft Network Client to always digitally sign communications. 2.3.8.1

18 Configure Microsoft Network Client to digitally sign communications if server agrees. (Default) 2.3.8.2

19 Disable the sending of unencrypted passwords to third party SMB servers. 2.3.8.3

20 Configure Microsoft Network Server to always digitally sign communications. 2.3.9.2

21 Configure Microsoft Network Server to digitally sign communications if client agrees. 2.3.9.3

Network Access Controls

22 Disable anonymous SID/Name translation. (Default) 2.3.10.1

23 Do not allow anonymous enumeration of SAM accounts. (Default) 2.3.10.2

24 Do not allow anonymous enumeration of SAM accounts and shares. 2.3.10.3

25 Do not allow everyone permissions to apply to anonymous users. (Default) 2.3.10.5

26 Do not allow any named pipes to be accessed anonymously. 2.3.10.7

27 Restrict anonymous access to named pipes and shares.

(Default) 2.3.10.9

28 Do not allow any shares to be accessed anonymously. 2.3.10.11

29 Require the "Classic" sharing and security model for local accounts. (Default) 2.3.10.12

Network Security Settings

30 Allow Local System to use computer identity for

NTLM. 2.3.11.1

31 Disable Local System NULL session fallback. 2.3.11.2

32 Configure allowable encryption types for Kerberos. 2.3.11.4

33 Do not store LAN Manager hash values. 2.3.11.5

34 Set LAN Manager authentication level to only allow NTLMv2 and refuse LM and NTLM. 2.3.11.7

35 Enable the Windows Firewall in all profiles (domain, private, public). (Default)

36 Configure the Windows Firewall in all profiles to block inbound traffic by default. (Default)

Configure Windows Firewall to restrict remote access services (VNC, RDP, etc.) to authorized campus-only networks .

38 Configure Windows Firewall to restrict remote access services (VNC, RDP, etc.) to the campus VPN.

Active Directory Domain Member Security Settings

39 Digitally encrypt or sign secure channel data (always).

(Default) 2.3.6.1

40 Digitally encrypt secure channel data (when possible).

(Default) 2.3.6.2

41 Digitally sign secure channel data (when possible).

(Default) 2.3.6.3

42 Require strong (Windows 2000 or later) session keys. 2.3.6.6

43 Configure the number of previous logons to cache. 2.3.7.6

Audit Policy Settings

44 Configure Account Logon audit policy.

45 Configure Account Management audit policy. 17.2.6

46 Configure Logon/Logoff audit policy. 17.5.3-4

47 Configure Policy Change audit policy. 17.7

48 Configure Privilege Use audit policy. 17.8

Event Log Settings

49 Configure Event Log retention method and size. 18.3.12; 18.9.26

50 Configure log shipping (e.g. to Splunk).

Linux Subsystem

Configure all Linux elements according to the Linux Hardening Guide, keeping in mind that some elements will require Windows tools (like Windows Firewall vs.

iptables)

Additional Security Protection

52 Disable or uninstall unused services.

53 Disable or delete unused users.

54 Configure user rights to be as secure as possible:

Follow the Principle of Least Privilege

55 Ensure all volumes are using the NTFS file system.

56 Configure file system permissions.

57 Configure registry permissions.

58 Disallow remote registry access if not required. 2.3.10.7-8

Additional Steps

59 Set the system date/time and configure it to synchronize against campus time servers.

60 Install and enable anti-virus software.

61 Install and enable anti-spyware software.

62 Configure anti-virus software to update daily.

63 Configure anti-spyware software to update daily.

Provide secure storage for Confidential (category-I) Data as required. Security can be provided by means such as, but not limited to, encryption, access controls, filesystem audits, physically securing the storage media, or any combination thereof as deemed appropriate.

65 Install software to check the integrity of critical system files.

66 If RDP is utilized, set RDP connection encryption level to high.

Physical Security

67 Set a BIOS/firmware password to prevent alterations in system start up settings.

68 Do not allow the system to be shut down without having to log on. (Default) 2.3.13.1

69 Configure the device boot order to prevent unauthorized booting from alternate media.

70 Configure a screen-saver to lock the console's screen automatically if the host is left unattended.

4.4 Patch and Vulnerability Management

1. Devices must be fully patched prior to deployment.

2. Vendors must provide a documented patching schedule and vulnerability remediation process.

3. Emergency security updates must be supported and applied in accordance with the District’s

System Patch Management Policy.

4. Devices with unmitigated critical vulnerabilities may not be connected to District networks.

4.5 Change Control and Configuration Monitoring

1. Any configuration changes after deployment must follow the District’s Information System

Change Control Policy.

2. Devices must support automated compliance checks and configuration integrity monitoring.

3. Agencies must ensure continuous monitoring to prevent drift from the approved baseline.

4.6 Network Connection Requirements

1. No device may connect to the District network until OCTO verifies compliance with this policy.

2. Devices failing compliance checks will be denied network access under the Network Access Policy.

3. OCTO reserves the right to disconnect any device that deviates from approved baselines or introduces security risk.

5. Roles and Responsibilities

OCTO

• Establish and maintain District approved baseline configurations.

• Review vendor documentation and validate compliance.

• Enforce configuration, hardening, and monitoring requirements.

• Conduct periodic audits of device configurations.

DGS

• Ensure vendor provided devices meet District requirements before procurement acceptance.

• Maintain configuration documentation and support OCTO audits.

• Report configuration deviations or security issues to OCTO.

Vendors and Contractors

• Deliver devices preconfigured to District approved baselines.

• Provide required documentation and evidence of compliance.

• Support OCTO in remediation of configuration or security issues.

6. Enforcement

Non-compliance with this policy may result in:

• Denial of network access for non-compliant devices.

• Suspension of procurement or deployment activities.

• Reporting to agency leadership for corrective action.

• Additional enforcement actions as authorized under DC Official Code § 1-1401 et seq.

7. References

• DC Official Code § 1-1401 et seq. (Authority of OCTO)

• NIST SP 800-53 Rev. 5 (CM and SC control families)

• CIS Microsoft Windows Server Benchmarks

• DISA Security Technical Implementation Guides (STIGs)

• NSA Network Infrastructure Security Guidance

8. Definitions

The definition of the terms used in this document can be found in the Policy Definitions website.

https://octo.dc.gov/node/856482

GS Chief Information Officer

June 29, 2026 Date

D