Windows Server Administration and Security Standards

Institutional Computing Standards

Standards and Guidance for Windows Server Administrations and Security

Created by IT @ JH

FINAL Version July 2015 1 of 25 Windows Server Administration and Security Standards

I. Table of Contents

I. Table of Contents ...... 2 II. Introduction ...... 4 A. Background ...... 4 B. Policy ...... 4 C. Audience ...... 6 D. Scope ...... 6 E. Enforcement ...... 6 III. Configuration Checklist ...... 6 IV. Physical Security ...... 7 V. Hardware ...... 7 VI. Virtualization ...... 8 VII. System Installation and Configuration ...... 8 A. Preparation ...... 8 VIII. Security ...... 9 A. Endpoint Protection ...... 9 B. Auditing ...... 9 C. OS and Application Updates ...... 11 D. Hardware Related Updates ...... 12 E. Microsoft Baseline Security Analyzer ...... 12 F. Vulnerability Scanning ...... 13 G. Securing Files and Directories ...... 13 H. Local User Accounts ...... 13 I. Enterprise Authentication ...... 14 J. Additional Security Policy Settings...... 15 K. Services ...... 15 L. Pass the Hash Mitigation ...... 15 M. Encryption ...... 16 IX. Networking ...... 17 A. DNS / IP Configuration ...... 17 B. TCP & UDP Ports ...... 17 C. Network Security ...... 18 X. Administrative & Performance Settings ...... 18 A. Recovery Console ...... 18 B. Windows Remote Desktop for Administration ...... 18 XI. Monitoring ...... 19 A. Tools ...... 19 B. System Monitoring ...... 19 C. Server Asset Inventory ...... 19 D. Performance Monitor Tool ...... 20 E. Task Manager ...... 20 F. Event Viewer ...... 20

FINAL Version July 2015 2 of 25 Windows Server Administration and Security Standards

G. System Management ...... 20 H. Security Event Log Retention ...... 21 XII. Administration and Operations ...... 21 A. Storage ...... 21 B. Backup ...... 22 C. SSL/TLS PKI ...... 22 D. System Documentation ...... 22 E. Multi-Factor Authentication ...... 23 F. Server Retirement ...... 23 XIII. References ...... 24 A. Books/Training ...... 24 B. Web Sites ...... 24 XIV. Appendix...... 24 A. Securing Service Accounts ...... 24 B. Logon Banner ...... 25 C. Sample Group Policy Template ...... 25

FINAL Version July 2015 3 of 25 Windows Server Administration and Security Standards

II. Introduction This document is written to support the operation of Windows-based servers at Johns Hopkins institutions. The objective of the document is to provide for effective and consistent management of Windows servers. The goal of each standard is to enhance security of servers that generally share the Hopkins backbone network resources. All systems must be administered securely as to not adversely affect other systems. This document is not meant to be a substitute for formal training of the Windows administrator. Windows server is a complex system and should be administered by skilled personnel.

A. Background This standard incorporates input from previous Windows Server standards and IT @ Johns Hopkins standards related to Windows server and workstation administration.

B. Policy This standard applies to Windows servers and is required for systems that store, process or transmit Restricted information or serve or support another critical business purpose. Restricted Systems are addressed in JH IT Policies:

11. SECURITY ADMINISTRATION OF RESTRICTED SYSTEMS

Systems or applications that store, process or transmit Restricted information require more intensive security at technical and managerial levels. Preserving the confidentiality, integrity and availability of sensitive information and business-critical systems requires managerial leadership, conscientious users and sound technical practice.

As the purpose and functions of systems vary, administrators (including, without limitation, those for networks, hosts, applications, devices, databases and interfaces) should refer to specific JH Standards for guidance and industry best practices. This policy outlines high level guidance: a. Systems Documentation – Restricted systems should have documentation regarding asset management, configuration, maintenance, security, disaster recovery and compliance. An inventory of equipment storing Restricted information must be maintained. Inventory procedures should include provision for equipment disposal or movement of equipment off-site and between JH campuses, including responsible parties and major repairs or configuration changes. b. Risk Assessment – Administrators of Restricted systems should conduct or solicit periodic (at least every three years) risk assessments regarding administrative, physical and technical vulnerabilities. Risk assessments should include inventories of interfaces, connectivity, vendor documentation and testing where appropriate. Risk assessments should be conducted in consultation with (internal or external) experts on security risk and in cooperation with technical and operational management. Documentation should include enumeration of security gaps and updated remediation plans. In addition, administrators should work with operational management to determine whether use of private Restricted information is the minimum necessary to accomplish business objectives. Please see current JH Risk Assessment Guidance for instructions.

FINAL Version July 2015 4 of 25 Windows Server Administration and Security Standards

c. Disabling Unnecessary Services – Restricted systems must have services disabled that are not required to achieve the business purpose of the system (e.g. FTP, Telnet, SMTP, etc). d. Virus Protection – Restricted systems must maintain automated virus detection update mechanisms. Updates should be automatic and transparent where practical, otherwise automatic reminders are required. It is also recommended that controls be implemented to protect against other malicious code as threats evolve (e.g. spyware). e. Patch Management – Restricted systems must have controls in place to provide timely notification regarding relevant patches. Administrators have the responsibility to determine whether and/or when to deploy patches. In cases where IT@JH recommends deployment of a patch, administrators must deploy patches in a timely fashion or otherwise implement and document compensating controls. f. Intrusion Detection and Monitoring – Johns Hopkins has deployed network intrusion detection (NIDS). NIDS is generally more effective when combined with host-based or application-level intrusion detection or monitoring. It is therefore recommended that administrators deploy these tools to supplement perimeter controls. Such may include, for example, automated access logging, integrity checking, or signature-based intrusion detection. g. Administration -- administration of Restricted systems may only be performed by authorized, trained personnel. Remote administration of Restricted systems requires strong authentication, stringent authorization, transmission encryption, and regular review of administrator and user access logs. h. Data Security -- Restricted information should be physically separated from application or system services (e.g. application middleware, Web and e-mail servers, etc). i. Vulnerability Scanning – there should be routine monitoring and remediation of equipment for vulnerabilities, specifically regarding components connected to the JH Network. j. Web servers -- Web-sites and Web applications should be documented and reviewed routinely for Web-based vulnerabilities and the possibility of unauthorized access to Restricted information on the Web-site or on the server. k. Automatic Log-off -- systems, applications and/or devices used routinely to access Restricted information must terminate/lock/suspend electronic sessions after a reasonable period of inactivity. Appropriate idle time depends upon the use, location and type of system and information. l. Equipment Placement -- Equipment should be positioned and configured so as to minimize the likelihood of unauthorized individuals intentionally or inadvertently viewing or otherwise accessing Restricted information. Appropriate risk assessments document opportunities for “shoulder surfing” regarding devices in public areas, including, without limitation, walkways, waiting areas, libraries and examination rooms.

FINAL Version July 2015 5 of 25 Windows Server Administration and Security Standards

m. Training and Awareness – technical and operational management should coordinate electronic system access with training that includes security awareness. Technical staff should include security as part of on-going skills development.

Source: http://it.jhu.edu/policies/itpolicies.html

C. Audience The target audience for this document is anyone who is responsible for deploying, building, and/or administering Windows servers on the Johns Hopkins Network. This document is intended for administrators who have some Windows administration experience.

D. Scope This standard applies to all servers running Windows 2008 or later versions including Windows 2008, 2008 R2, 2012, 2012 R2.

Note: While the ICSC intends to keep this document updated frequently, issues related to server administration change rapidly with technology. It is therefore strongly recommended that administrators keep current with Microsoft documentation and updates. Discrepancies between these standards and Microsoft documentation should be directed to [email protected].

Microsoft online resources provide comprehensive up-to-date technical guidance on all aspects of Windows server administration. This document provides high-level guidance for administrators supporting one or more Windows servers and links to Hopkins and Microsoft services.

E. Enforcement Enforcement of IT Policies is intended to safeguard shared resources. It may be necessary to enforce specific standards in this document to ensure availability, performance or security of JH IT Resources.

III. Configuration Checklist

We recommend that you supplement this checklist with additional steps related to your environment.

 Verify that all disks are formatted with NTFS.  Disable unnecessary services. Or conversely, enable necessary services. It is the responsibility of the system administrator to determine what services should be disabled.  Local Account Management. Disable or delete any unnecessary user accounts. All passwords should be changed from vendor supplied defaults.  Remove all unnecessary file shares. Verify permissions on all shares that are necessary.  Rename and disable the guest account.

FINAL Version July 2015 6 of 25 Windows Server Administration and Security Standards

 Rename Administrator account and configure administrator password policies (15 characters minimum, both alpha and numeric characters)  Configure Audit Policy  Configure event log settings  Configure a logon message for user interfaces.  Apply all security updates. If patches cannot be applied due to software incompatibilities or other conflicts, it is the responsibility of the system administrator to understand the vulnerability and implement appropriate measures to mitigate the vulnerability.  Apply all hardware management, driver and firmware updates.  Update Local Security Policy for “Pass the Hash” Mitigation  Install Endpoint Protection software. Configure it to automatically update definitions. Apply an appropriate configuration for cleaning/quarantine/deletion of infected files, and configure notification of infections.  Configure Remote Desktop Security Settings  Review Additional Local Security Settings  Review a Tenable or MBSA scan of host for any potential OS or service (e.g. Web server) vulnerabilities.  Ensure system is properly inventoried, monitored, critical data is backed up, and has proper Security Event Log Retention  Configure Multi-Factor Authentication  Complete Systems Documentation

IV. Physical Security Server security begins with a secure location and appropriate physical security controls. The ICSC has approved standards for physical security of servers (Data Center Security Standards and Guidance, http://it.jhu.edu/standsandguidelines/). We differentiate physical requirements based on several risk criteria, including type and amount of information stored, downtime requirements, use patterns, and redundancy.

Servers should be in a secure location with limited access or locked area. Unrestricted physical access opens machines to compromise from boot floppy, CD, or USB device. In addition, machine theft and environmental hazards should be considered by administrators when locating and monitoring server assets. Servers should be left in the logged off or locked state when not in use.

V. Hardware Hardware requirements vary based on use and scope. At JH, we work with vendors and developers to ensure that hardware meet application profiles and requirements. For minimum hardware standards for Windows servers:

FINAL Version July 2015 7 of 25 Windows Server Administration and Security Standards

http://www.microsoft.com/technet/windowsserver/evaluate/system- requirements.mspx

We recommend that administrators consider the following for high availability hardware configurations:

1. Storage RAID 2. Redundant power supplies 3. Teamed NICS 4. SAN 5. Remote access card

VI. Virtualization Server virtualization is a recommended best practice at Johns Hopkins and is encouraged as a means to reduce power and cooling requirements in the datacenter. Server virtualization is a common practice at Johns Hopkins and has been in place since 2008. Current production environment is limited to VMware vSphere, but Microsoft Hyper-V is quickly becoming available as an alternate virtualization hypervisor. Administrators should consult virtualization vendor documentation (e.g. VMWare, Microsoft) and consider application and system requirements to ensure it meets vendor requirements.

Links

VMWare: http://www.vmware.com Microsoft Hyper-V : Microsoft Hyper-V Server 2012 R2 and Hyper-V Server 2012

Contact virtualization resources: [email protected]

VII. System Installation and Configuration

A. Preparation Required: Before beginning an installation, the administrator should have a chosen server name and a renamed administrator account, in accordance with a reasonable naming standard. Installation should proceed as though as the server is installed on the network it will be under attack. It is therefore critical that the installation package include all recent updates. In cases, where an older version must be installed, installation should take place off-line.

Microsoft security updates http://windowsupdate.microsoft.com/

FINAL Version July 2015 8 of 25 Windows Server Administration and Security Standards

VIII. Security

A. Endpoint Protection Required: All Windows Servers on the Johns Hopkins network are required to run Endpoint Protection software. The current standard is System Center Endpoint Protection 2012. A comprehensive guide may be found here.

Links Download: http://it.jhu.edu/antivirus/

Recommended: It is recommended that server Admins review and create endpoint protection exclusion policies on their Windows servers to ensure proper performance of their Windows servers.

Microsoft Anti-Virus Exclusion List: http://social.technet.microsoft.com/wiki/contents/articles/953.microsoft-anti-virus- exclusion-list.aspx

B. Auditing Having the proper Windows Server auditing settings configured is critical to ensure proper monitoring and investigation when a system is compromised or has a critical issue.

Required: The “basic” Windows audit policy should be used if you have Windows 2003 servers or have a significant amount of space set aside for your Security Event Log and archiving solution. If you do not have Windows 2003 servers in your environment, please see the Advanced Auditing section.

These include baseline recommendations below.

Audit Policy Security Setting

Success Failure Audit account logon √ √ events Audit account √ √ management Audit logon events √ √ Audit object access √ Audit policy change √ Audit privilege use √ Audit process tracking √ Audit system events √

Recommended: Folder File Auditing

FINAL Version July 2015 9 of 25 Windows Server Administration and Security Standards

In order to be aware of changes to critical files, auditing can be enabled on critical files or folders in Windows Server. It is recommended to only selectively audit critical/sensitive/Restricted file access, as these events can create excessive events. Here is example of auditing recommended for any critical files or folders.

Access Successful Failed Traverse Folder / Execute File √ Read Attributes √ Read Extended Attributes √ Write Attributes √ √ Write Extended Attributes √ Delete Subfolders and Files √ √ Delete √ √ Read Permissions √ Change Permissions √ √ Take Ownership √ √

Advanced Auditing Introduced with Windows 2008, Advanced Auditing provides a more granular ability to audit specific event types, rather than all event for a single category. This helps reduce the number of audited events. If you do not have Windows 2003 OS servers to manage, it is recommended to only use the Advanced Auditing for your Windows Servers. If you have Advanced Auditing enabled, Windows will ignore any “basic” auditing settings defined.

Advanced Auditing Recommendations for all domain member servers Audit Category Policy Setting Account Logon Audit Credential Validation Success Audit Other Account Success, Failure Logon Events Account Management Audit Application Group Success, Failure Management Audit Computer Account Success, Failure Management Audit Security Group Success, Failure Management Audit Other Account Success, Failure Management Events Audit Security Group Success, Failure Management Audit User Account Success, Failure Management Detailed Tracking Audit Process Creation Success, Failure

FINAL Version July 2015 10 of 25 Windows Server Administration and Security Standards

Audit Process Termination Success, Failure Logon/Logoff Audit Account Lockout Success, Failure Audit Logoff Success, Failure Audit Logon Success, Failure Audit Other Logon/Logoff Success, Failure Events Audit Special Logon Success, Failure Policy Change Audit Audit Policy Change Success, Failure Audit Authentication Success, Failure Policy Change Privilege Use Audit Non Sensitive Failure Privilege Use Audit Other Sensitive Failure Privilege Use Audit Sensitive Privilege Failure Use System Audit Security State Success, Failure Change Audit System Integrity Success, Failure

Command Line Auditing Introduced with a February 2015 Security Update, MS15-011, Command Line Auditing is available in Windows Server 2008 R2 and higher. This feature provides additional logging to help monitor and investigate activity when running cmd.exe or cscript.exe. To use this feature, Advanced Auditing (specifically Detailed Tracking- Process Creation) must be enabled. This can be set within Group Policy located at:

Computer Configuration\Policies\Administrative Templates\System\Audit Process Creation\Include command line in process creation events – Set this value to Enabled.

C. OS and Application Updates Required: All Windows servers must run a Microsoft-supported OS version. (link) Windows Servers should receive all Security Updates (MSXX-XX updates) in a timely manner. A timely manner is defined as systems having all Security Updates (MSXX-XX updates) applied within 30 days of release.

Recommended: It is recommended Windows Software Updates can be automatically applied via the local ‘Windows Software Update’ or through the enterprise (WSUS) Windows Server Update Services. Administrators should have documented procedures for testing,

FINAL Version July 2015 11 of 25 Windows Server Administration and Security Standards

evaluating and deploying updates rapidly, preferably within the first two weeks for most updates. For out-of-band and critical updates, it may be necessary to expedite the update process. It is generally acceptable to leverage testing and update deployment schedules established by IT @ JH and follow its lead. There may be exceptions, where the server in question runs a vulnerable system or service.

In addition, Adobe and other common third party application vendors frequently issue updates that may be updated on servers. Just as with Microsoft updates, IT groups should test and evaluate each update. IT administrators should assess risk and consider following ICSC recommendations regarding individual 0-day updates or patches.

Download Critical Updates: http://windowsupdate.microsoft.com/ Enterprise Update Server: http://nts.jhmi.edu/sus/

Contact WUS resources: [email protected]

D. Hardware Related Updates Required: Software that is required for server hardware will occasionally have vulnerabilities. Vulnerabilities that are exploitable via remote methods must be addressed in a timely manner. Some typical vulnerabilities that need to be addressed in a timely manner are: Remote Access Card (ilo, DRAC) software and web management consoles like Dell OMSA or HP Systems Management Homepage. This management software is often a target for 0-day exploits.

Recommended: Installing software drivers and firmware is critical for security and performance of hardware based servers. Updates can be downloaded and installed using the links listed below. Alternatively, hardware updates can be delivered through vendor management application such as HP SIM or Dell OpenManage or via enterprise software distribution programs such as Microsoft SCCM.

Links Dell: http://support.dell.com/support/downloads/index.aspx?c=us&cs=28&l=en&s=dfb HP: http://welcome.hp.com/country/us/en/support.html IBM: http://www.ibm.com/support/us/

E. Microsoft Baseline Security Analyzer Recommended: The Microsoft Baseline Security Analyzer (MBSA) is a tool to scan Windows, SQL Server, IIS, and Office security settings. This includes missing security updates and a vulnerability assessment of registry and application configurations. For example it can find blank/insecure SQL SA passwords. MBSA can be run locally on a server or remotely from a workstation where the user has Administrative rights. This tool can also be used to scan a large number of systems remotely.

Download MBSA http://www.microsoft.com/en-us/download/details.aspx?id=7558

FINAL Version July 2015 12 of 25 Windows Server Administration and Security Standards

F. Vulnerability Scanning Required: For Restricted or otherwise mission critical servers, administrators should not rely on MBSA or other native tools to identify vulnerabilities. Restricted systems must have regular vulnerability scanning/testing using a tool like Tenable’s NESSUS Johns Hopkins has an enterprise license for Tenable’s Security Center tool that maintains and administers NESSUS scans. The tool is fully configurable to schedule scans and reports, and it has documented descriptions of scan purposes and levels of intrusiveness. It uses standard CVE formats to describe vulnerabilities.

Recommended: Even the most secure server will likely have vulnerabilities. It is recommended that all critical vulnerabilities be remediated, that all high vulnerabilities be addressed and that other lower-rated ones be reviewed. These vulnerabilities can be identified via tools such as MBSA, SCCM, or Tenable (NESSUS). Vulnerabilities may also be identified on systems through software inventory tools such as SCCM or PowerShell scripts.

Links NESSUS (Network Security Scanner): http://www.nessus.org/ Establish Tenable account: [email protected]

G. Securing Files and Directories Required: With respect to file systems, NTFS or ReFS should be used on all Windows Servers, rather than FAT or FAT32. NTFS and ReFS preserve and enforce ACL’s, providing the ability to secure drives, files and folders on Windows systems. With Windows 2008 and above, it is generally recommended to stay with the default permissions on the SYSTEM drive. For additional data volumes, NTFS File System permissions should be reviewed for removal of any accounts other than Administrator, Service or System accounts.

The ReFS file system was introduced with Windows Server 2012 and preserves and enforces ACL’s like NTFS. ReFS also removes the need for chkdsk, as it is able to recover from corruption rapidly, and is more resilient.

Recommended: For data disks that are larger than 2 TB, disks need to be initialized using NTFS GUID Partition Table (GPT) formatting, rather than Master Boot Record (MBR) with NTFS. For bootable system volumes, it is recommended to avoid use of GPT formatted volumes for NTFS. To become bootable, GPT formatted volumes must meet the following requirements: System Firmware must be UEFI and it must be x64 versions of Windows.

H. Local User Accounts

Required: Rename Administrator account: Rename built-in Administrator (do not delete) account and choose a strong administrator password (a minimum of 15 characters). In Windows 2008 and above passwords can be up to 127 characters long. They should include UPPER and lower case letters, as well as non-alphanumeric

FINAL Version July 2015 13 of 25 Windows Server Administration and Security Standards

characters. Administrator passwords should be changed regularly, securely, and be randomized across groups of systems.

Rename and Disable the Guest account

Recommended: Add and remove domain accounts: Remove any unneeded Domain accounts from Users and Administrators Groups, i.e. Domain Users and Domain Admins. Add appropriate Domain Security Groups to their respective local group.

Disable or remove any local accounts: Accounts that may be created by vendors, applications or other third-parties should be discouraged and should be strongly considered to be disabled or deleted. Domain Service Accounts are recommended to meet these needs.

Deny Access to this computer from the network (Administrator Account): Once defined, this setting will prevent any network access to any account added to this setting. By defining the renamed Local Administrator account in this setting, it prevents the Local Administrator account from passing its credentials to other systems. It is recommended to never add Domain Users to this setting. By default, Local Security Policy has the built-in guest account defined. Of note, Domain Controllers should never define this setting, unless it is for a known compromised account. This can be set within Group Policy located at:

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Deny access to this computer from the network.

I. Enterprise Authentication The Enterprise Directory is being utilized for authentication and access control and allows the creation and management of a single identity for Hopkins’ faculty, staff and students.

Required: For Restricted servers hosting web-based applications requiring JHED user account authentication, the application will integrate with one of the WebSSO supported technologies. The purpose of our WebSSO implementation is to provide a centralized web access platform for user identification, authentication, and authorization.

Web SSO information: http://tinyurl.com/enterprise-auth

Contact the Enterprise Authentication team: [email protected]

Recommended: The Enterprise Active Directory (WIN domain) provides the means to access and manage network resources on the Johns Hopkins’ network. Windows servers should reside in a managed Organizational Unit (OU) within the WIN domain.

Active Directory Services information: http://www.it.johnshopkins.edu/services/directoryservices/ad/

FINAL Version July 2015 14 of 25 Windows Server Administration and Security Standards

Contact enterprise directory resources: [email protected]

J. Additional Security Policy Settings Recommended: SMB Signing: Ensuring that SMB-signed is enabled is an important security configuration for preventing “man in the middle” attacks. Enabling signing via Group Policy determines whether SMB signing must be negotiated before further communication with an SMB client. This can be set within Group Policy located at:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server\Microsoft network server: Digitally sign communications (always) Set to Enabled

Securing Access to Server: Remove ‘Everyone’ group from ‘Access this computer from the network’ and Remove ‘Guest’ and ‘Users’, if possible, from ‘Log on locally’. These can be set within Group Policy located at:

Computer Configuration\Policies\Administrative Tools\Local Security Policy\Security Settings\Local Policies\User Rights Assignment.

Additional Rights to Server: Add ‘Administrators’ only to ‘Manage auditing and Security Log’, ‘Take ownership of files and objects’ and ‘Shut down the System’. This can be set within Group Policy located at:

Computer Configuration\Policies\Administrative Tools\Local Security Policy\Security Settings\Local Policies\User Rights Assignment.

K. Services Recommended: Disable unnecessary services – in particular IIS components, file and print sharing and remote access should be disabled. These may waste system resources and create vulnerabilities. Other services that should be reviewed include:

 Help and Support Services (if Help is never used on server)  Inter-site messaging  Remote Access Connection Manager (if no VPN or Remote Access Service RAS are needed)  Computer Browser  Shell Hardware Detection  Wireless Configuration  Task Scheduler

NOTE – Do not disable the DHCP client service, as it is vital for Active Directory.

L. Pass the Hash Mitigation There is a vulnerability in Windows that is known as “Pass the Hash”. This vulnerability allows an attacker to use credentials of accounts that have logged in to a Windows system and pass the credentials on to another Windows system. Details

FINAL Version July 2015 15 of 25 Windows Server Administration and Security Standards

of this vulnerability are addressed in the SANS reading room article “Pass the hash attacks: Tools and Mitigation” and on various pass the hash toolkit sites.

Required:

Disable Cached Logons: This setting is used to define the number of previous logons to cache in the event that a Domain Controller is unavailable. While this setting is valuable for laptops and other devices that leave the Johns Hopkins network, for servers it is recommended to reduce this value to zero. By default, Windows 2008 cached 25 logons and Windows 2003 caches 10. This can be set within Group Policy located at:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Number of previous logons to cache Set to 0

Avoid LM and NTLM challenge response: These are older protocols used by Windows OSs prior to Windows Server 2003 and were primarily used for authentication in workgroups. LM and NTLM challenge-response are considered weak protocols and should no longer be used unless there is a significant requirement. It is recommended to move to Send NTLMv2 response only and also set the setting to not store LAN Manager hash values. This can be set within Group Policy located at:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Network Security: Do not store LAN Manager hash value… & Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\ Network Security: LAN Manager Authentication level Set to Send NTLMv2 response only

Recommended: Remove Admins from Debug Privilege: By default, Administrators have rights to Debug Programs. Malware writers can exploit this default setting to implement “pass the hash” exploits. Removing Administrators from this right can greatly reduce these exploits. This can be set via Local Security Policy or via Group Policy. It is recommended to use Local Security Policy in this case, as some installations, such as Microsoft SQL Server, require this right to install the software or perform Service Pack installations. This can be set within Local Security Policy (or Group Policy) located at:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Debug programs.

M. Encryption Required: Encryption is an important security control in many respects, but navigating encryption requirements and protocols can be complex (see Hopkins Encryption Standards). For server administrators, there are several fundamental principles:

Encryption of Data in Transit – Restricted information transmitted across public

FINAL Version July 2015 16 of 25 Windows Server Administration and Security Standards

networks must be encrypted. It is critical that server administrators ensure that ciphers and encryption protocols are current and sufficient to effectively protect data. For example, SSL 3.0 and 64 bit ciphers are inadequate to protect transmission security.

Encryption of data in storage in Hopkins data centers– Server administrators are encouraged to encrypt data in storage where practical. The decision of whether to use whole disk or database server encryption is dependent on a number of factors, such as the existence of multiple applications, system administration, performance, cost, and backup requirements. Where performance is an issue, database column- based encryption should be assessed for the most critical data elements.

Encryption of data in storage in cloud-based servers – Servers storing Restricted information in a cloud service (e.g. Amazon Web Services, Microsoft Azure) must encrypt data in storage using keys that are maintained by Hopkins rather than by the cloud provider. For example, Amazon S3 encryption uses keys managed by Amazon and would thus not meet this standard. It is, however, acceptable to contract key management to a third party such as a software-as-a-service provider so long as the third party has been contractually obligated to manage Hopkins Restricted information securely.

Encryption of data in storage outside Hopkins data centers – Hopkins requires that Restricted information be stored in compliant data centers. In exceptional cases where such servers are managed in another facility, Restricted information must be encrypted in storage through full-disc encryption.

IX. Networking

A. DNS / IP Configuration Recommended: The DNS request process for all JHU, JHMI, Johns Hopkins, and most organizationally owned domains has been consolidated into a centrally managed system. IT Administrators should ensure their servers are registered in DNS.

IP addresses should be provided via JHARS/Infoblox. You should consider whether it is best to Run DHCP or Static IP of your Windows Server.

DNS Requests: Web: http://www.it.johnshopkins.edu/services/network/requests/dns.html

IP Configuration Info: http://www.it.johnshopkins.edu/services/network/jhars/JHARS%20Step-By-Step.pdf

Contacts: Email: [email protected] or [email protected]

B. TCP & UDP Ports Check the TCP and UDP ports to ensure that no service or application is running that might compromise the server. Consider these ports when configuring or updating firewall policy and security monitoring. Current active TCP and UDP ports can be

FINAL Version July 2015 17 of 25 Windows Server Administration and Security Standards

fiewed by starting a command prompt and running netstat –a command -- or from TCPView, a utility from Microsoft sysinternals. Active ports from PowerShell can be viewed by running the following command: Get-NetTCPConnection | ? State -eq Established | FT -Autosize

TCPView download: https://technet.microsoft.com/en-us/library/bb897437.aspx

C. Network Security Network security provides the community with information and tools to help provide additional security.

Links

More information: http://it.jhmi.edu/infosec Johns Hopkins System Block List: http://it.jhmi.edu/restricted/infosec/blocklist.html General questions: [email protected] Incidents: [email protected]

X. Administrative & Performance Settings

A. Recovery Console Recommended: Recovery Console as a startup option (called Recovery Environment in Server 2008) The Recovery Console allows administrators to use a command prompt during the boot-up process. The console is a command-line interface that provides a limited set of tools to repair a computer. You can use the Recovery Console to start and stop services, read and write data, and format drives. If the Recovery Console/Recovery Environment is not installed with Windows Server, tools such as Microsoft DaRT (Diagnostics and Recovery Toolkit) should be available to the server team to be used as bootable media in the event of an OS problem.

B. Windows Remote Desktop for Administration Typically, IT Administrators use Remote Desktop for Administration (formerly known as Terminal Services in Remote Administration mode) provides remote access to a remote session for Windows 2003 and above. This allows IT Administrators to manage servers from virtually any computer on the JH Network. For detailed information about using Remote Desktop for Administration for remote server administration, see Using Remote Desktop for Administration for remote server administration in server help. Remote Desktop for Administration is not enabled by default and it is recommended to leave it disabled if it is not needed.

Required: If Remote Desktop for Administration is enabled, it is important to protect and monitor Windows Server systems from Man in the Middle or User Dictionary Attacks.

Monitor for Remote Desktop Failures: In Windows 2008 R2 and above, there is a dedicated log file for Remote Desktop Session connections that is enabled by default. It is important to review and monitor this log file. These events are in addition to the Security Event Log Event ID 4624 Logon Type 10 (when the recommended auditing is enabled). The log file is located in the following location:

FINAL Version July 2015 18 of 25 Windows Server Administration and Security Standards

Event Viewer-Windows Logs-Applications and Services Logs-Microsoft-Windows- TerminalServicesLocalSessionManager in the Operational Log

Network Level Authentication: This setting forces all Remote Desktop connections to use the Credential Security Support Provider (CredSSP) Protocol. This uses stronger authentication through TLS/SSL or Kerberos and protect against “Man in the Middle” attacks. This can be set within Group Policy located at:

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host/Security\Require user authentication for remote connections by using Network Level Authentication Set to Enabled

XI. Monitoring

A. Tools It is recommended that multiple tools or applications be used to monitor servers especially server clusters and multi-server configurations. These tools can be used to baseline server performance and health. In addition, host security monitoring is required for servers with Restricted Information, and security logging should be part of a documented monitoring strategy. IT @ JH Utilizes SCCM, SCOM, and What’s UP for System Management and Monitoring.

B. System Monitoring Recommended: Monitoring software should provide comprehensive event and performance management, proactive monitoring and alerting, reporting and trend analysis, and system and application specific knowledge and tasks to improve manageability of server hardware, operating systems, applications, security, and network connectivity. It is important for the health and security of a Windows system to ensure it is monitoring properly.

Windows Server monitoring is provided as an enterprise service at Johns Hopkins.

Links Microsoft: http://www.microsoft.com/SCOM/default.mspx HP: http://h20229.www2.hp.com Contact systems monitoring resources: [email protected]

C. Server Asset Inventory Required: It is important to maintain an inventory for all Johns Hopkins Windows server assets. This inventory should include both static information (location, server administrator), along with dynamic information. For Windows servers, there are a number of key attributes that must be inventoried to collect information of WMI, Registry, or file attributes on all Windows servers. This is valuable when trying to identify specific

FINAL Version July 2015 19 of 25 Windows Server Administration and Security Standards

software version, file version or hardware vulnerabilities quickly and through dynamically generated reports.

All systems that require direct access from the external network must be registered in the IT @ Johns Hopkins Configuration Management Database (CMDB).

Recommended: IT @ Johns Hopkins provides a dynamic server inventory agent, using SCCM, and static inventory through the CMDB. IT @ Johns Hopkins uses this data together to pair this data into useful reports, available via SCCM or the CMDB. Static and Dynamic Inventory Windows Server monitoring is provided as an enterprise service at Johns Hopkins using the CMDB and SCCM.

Items that should be dynamically inventoried include: Members of Local Administrators group, Security Update compliance, Windows Services, Installed Software, and file level inventory.

Contact systems monitoring resources: [email protected]

D. Performance Monitor Tool Recommended: System administrators can use the Performance Monitor tool to send alerts over the network, record events to the event viewer application log, launch a program or batch file when high and low thresholds are reached. This utility can be extremely useful to administrators who need to be notified remotely when a resource has reached a threshold and action is required.

E. Task Manager Recommended: An integrated tool for monitoring applications and tasks. Task Manager reports key performance metrics of Windows based systems. Task Manager provides detailed information on each application and process running on the workstation in addition to memory and CPU usage. Task Manager allows termination of applications and processes that are not responding.

F. Event Viewer Required: Event Viewer is the principal monitoring tool for discrete events in performance and security. Typically a Window Server stores application, security, and system logs. The Event Viewer provides a dashboard and classification structure for such events. It could also contain other logs, depending on the computer's role and the applications installed. Microsoft continues to refine this tool, and it is especially useful for administrators managing a small number of servers. The primary Event Logs, Application, Security and Systems should be set to a minimum of 50MB and should be set to ‘Overwrite events as needed’, to ensure that the logging does not fill up and need to be cleared. Systems with a high turnover of the Security Event log are highly encouraged to implement a larger Security Log size.

G. System Management Recommended:

FINAL Version July 2015 20 of 25 Windows Server Administration and Security Standards

Inventory, operating systems deployment (imaging), remote access, and software distribution should be managed by a secure central application. System management software is designed to simplify the entire server lifecycle, Server Management Suite provides deployment, management, asset inventory and security functions from a centralized console—automating operations , improving system availability, and reducing overall infrastructure costs. Moreover, it is essential to have the ability to provide up-to-date and detailed server hardware, software, service, and asset reports.

Links Microsoft: http://www.microsoft.com/systemcenter/configurationmanager

Contact systems management resources: [email protected]

H. Security Event Log Retention Required: The Security Event log should be of reasonable size to handle the recommended auditing configurations. An Administrator should be able to review events for at least 7 days in the local servers Security Event log, unless the security events are going to a Security Event Log archiving system.

Recommended: It is recommended for IT groups to utilize tools to monitor, aggregate, and report on security log information. Intelligent log collectors/readers can harvest event log data throughout the network in a readable format. The most prevalent technology used at Johns Hopkins is based on the Microsoft System Center Operations Manager framework, under a technology called Audit Collection Service (ACS). ACS will use an agent-based architecture and will collect logs into a SQL Server database. EventMeister is a lower cost solution for smaller numbers of systems.

ICSC Logging Standard: http://www.it.johnshopkins.edu/restricted/standards/StandardLogManAPPROVED061 2.pdf Microsoft ACS: https://technet.microsoft.com/en-us/library/hh212908.aspx EventMeister: http://www.soft3k.com/EventMeister-p7285.htm

Contact audit collection resources: [email protected]

XII. Administration and Operations

A. Storage Recommended: Alternatives to locally attached storage are SAN and NAS storage. A storage area network (SAN) is a dedicated network that provides access to block level data storage. The storage attaches to the server and appears to be a locally attached drive. Network-attached storage (NAS) is file-level data storage that is connected to the network. Servers can attach to this storage by mapping a network drive.

FINAL Version July 2015 21 of 25 Windows Server Administration and Security Standards

More details can be found on the IT website at http://www.it.johnshopkins.edu/services/sla/storage/.

Contact storage resources: [email protected]

B. Backup Required: Regular backups are required for systems that store Restricted information or serve/support another critical business purpose – i.e. configuration settings. Ensure that all backup to removable media solutions are encrypted.

Recommended: Regular backups protect data from hardware failures and accidental deletions as well as from risk of data loss from malware and other malicious behavior. Backup privileges should be limited to administrators and backup operators — people who are trusted read and write access on all files.

More details about a centrally managed backup solution can be found on the IT website at http://www.it.johnshopkins.edu/services/sla/data/backup.html

Contact backup resources: [email protected]

C. SSL/TLS PKI Required: All Web-based applications and systems/applications authenticating JHED users against AD/LDAP must be secured with an SSL Certification. Trusted certification can be SSL/TLS certificates requested through the Johns Hopkins’ Comodo SSL/TLS certificate request site. SSL/TLS certificates requested through this site must meet the requirements of the InCommon Certificate Service agreement between Johns Hopkins and InCommon. The certificates must be for a domain that is registered to Johns Hopkins under its non-profit charter. Certificates for dot.com domains may not be issued under this agreement. The domains must be pre-registered with Comodo before a certificate request will be accepted by Comodo.

Certificates offered through the Johns Hopkins Enterprise PKI provides the ease of installing and renewing SSL/TLS certificates for servers participating in the Enterprise Active Directory. Certificates use for smartcards and other forms of certificate-based authentication and the need for other intended purposes for digital certificates are recommended for this certificate service.

Johns Hopkins SSL/TLS Certificate Services information: http://www.it.johnshopkins.edu/services/directoryservices/sslcertificates

Contact PKI resources: [email protected]

D. System Documentation Create and maintain an electronic record of the server system. At a minimum, the following should be documented:

 System or department contact information.

FINAL Version July 2015 22 of 25 Windows Server Administration and Security Standards

 System configuration and other settings including network, arrays, drives, system services enabled or disabled, utilities loaded, etc.  Additional Microsoft software loaded (e.g., IIS, SQL Server)  Description of all third party vendor or JHMCIS software on system including installation location, and any configuration parameters for the software. Identify location of original media.  Description of any client software used to access server. Identify location of original media.  Identify each vendor contact and whether or not the vendor has remote access to the server.  Service, administrative, or local user accounts created to run applications or services on the server.  List of all scripts, their functions, locations, and when and how they are used.  Scheduled tasks or jobs (including database flat file dumps to disk, imports or exports to/from other systems, event log parsers and archiving, etc.).  Archive for Event logs – where are the application, system, security and other event logs archived?  Disaster Recovery Plan /Business Continuity Plan

There is a template that is available for use by IT staff to document servers/applications available on the IT Policy Standards and Guidelines site. The template, Project Application System Planning Template, covers the majority of information critical to supporting a server.

E. Multi-Factor Authentication Required: Security challenges are a constant battle for system administrators. It is widely known that passwords are not enough to protect systems or users from malicious individuals. It is critical that IT Administrators and other staff with administrative rights use Multi-Factor Authentication (MFA). Therefore Restricted systems must include MFA for all admin access or at least a plan for deploying such MFA by 2016.

Since 2012, administrative MFA has required a token-based solution, in large part due to Windows authentication technical requirements. The technology in this area is evolving rapidly, and thus it is likely that alternate forms may become technically feasible in the future, however, due to the current limitations of Windows authentication and resource mapping, it is currently necessary to use a token-based solution for Windows server MFA, as one-time passwords are not yet feasible for use to protect these resources.

If you do not have a token or need more information on how to setup your smartcard, please visit http://tinyurl.com/enterprise-auth or contact [email protected].

F. Server Retirement Required: As with any equipment, plans should be made to retire the Windows Server. Retirement procedures should include proper disposal of backup media and hard disks; along with removal from Active Directory, Configuration Management and

FINAL Version July 2015 23 of 25 Windows Server Administration and Security Standards

Monitoring systems. All systems must comply with the Data Removal Standard, which covers all the details for proper removal of a system at Johns Hopkins.

Data Removal Standard: http://www.it.johnshopkins.edu/restricted/standards/StandardDataRemovalRevisions 030112.pdf

XIII. References

A. Books/Training  Mastering Windows Server 2012 R2 http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118289420.html  Microsoft Virtual Academy – Free Online Training from Microsoft http://www.microsoftvirtualacademy.com/  eBooks – Microsoft Virtual Academy – Free Electronic Books from Microsoft http://www.microsoftvirtualacademy.com/ebooks

B. Web Sites  Windows Server - TechNet https://technet.microsoft.com/en-us/library/bb625087.aspx  Windows Server Security https://technet.microsoft.com/en-us/library/windows-server-security.aspx  Microsoft Services and Ports http://support.microsoft.com/kb/832017  SANS “Pass the Hash Attacks: Tools and Mitigations” http://www.sans.org/reading_room/whitepapers/testing/pass-the-hash- attacks-tools-mitigation_33283

XIV. Appendix

A. Securing Service Accounts Windows services typically run under the Local System account, but they can also run under a domain user or local account. A service runs under the security context of its service account, so if an attacker compromises a service on a member server, the service account can potentially be used to attack a domain controller. When determining which domain account to use as a service account, ensure that the assigned privileges are limited to what is required for the successful operation of the service and use the settings described below.

 The logon name could be an acronym but it is recommended to avoid making the logon name obvious or easy to guess in relationship to the service.  For domain service account, the option “User cannot change password” should be set since this is a service account and there should be no need for

FINAL Version July 2015 24 of 25 Windows Server Administration and Security Standards

the password to be updated interactively by a user logged in with the service account. Such a password change on the service account may affect service operations. Having this setting enabled also reduces the possibility of this account being used by an attacker.  Consider limiting what workstations the user can log on to though the user properties. This prevents compromised accounts from accessing other systems in the domain.  The “Allow logon to terminal server” is checked by default upon the creation of an account. Disabling this feature helps rule out the possibility of unauthorized access via terminal services.  Consider removing the Domain Users group from the Service Account.

B. Logon Banner Recommended: A Logon Banner is recommended to be used on all Windows Server systems. A typical exception to having a logon banner is a Windows Server running a Citrix or RDS Seamless application.

BANNER Title: Johns Hopkins IT Use Statement

BANNER Message: Use of this system is restricted to authorized personnel for clinical or other business purposes of Johns Hopkins in accordance with applicable law and Hopkins policies. Users are expected to exercise due care in protecting confidential information. Use of and activity on this system is monitored and logged. Use of this system constitutes consent to such monitoring.

This can be set within Group Policy located at:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Interactive Logon\Interactive logon: Message title for users attempting to log on & Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Interactive Logon\ Interactive logon: Message text for users attempting to log on

C. Sample Group Policy Template For Windows Server systems that reside in the Enterprise Active Directory, a sample Group Policy Object (GPO) has been created that has applicable required and recommended settings for the Windows Server Standard defined. This GPO may be copied and linked to Organizational Units (OU) where JH IT group’s servers reside, typically the Systems OU. This GPO contains all of the recommended Group Policy Settings except for Removing Administrators from the Debug Privilege.

This GPO is called Sample GPO for Windows Server Standard 2015.

IMPORTANT NOTE – Do not link directly to this GPO, always make a copy before using.

FINAL Version July 2015 25 of 25