Acceptable Use for HITS Managed Microsoft Windows Servers


Introduction

This article centers around what is considered acceptable use of an EHIS-HITS Managed Microsoft Windows Server by an authorized Application Team member, vendor support personnel and any other user with logon rights to an EHIS-HITS Managed Windows Server. If a statement made in this KB conflicts with any SPG, including those listed in the "Key external documents" section, the SPG will take precedence. To maintain the highest level of security, Windows Hosting Services has put together this KB article to assist with decision making as it relates to the documented topics in this KB article.

Key external documents:

Servers differ from workstations in that they primarily run background processes, responding to client requests or handling data manipulation tasks. On the servers, the installed software and processes typically run as a service, automated task or in a similar fashion. Exceptions exist, but these are the primary manners in which servers operate. If variations are required due to business or technical needs, the server requester should consult a Windows Hosting Services Team Member to determine if remediation steps can be taken to avoid this setup or otherwise request approval to proceed.

All EHIS-HITS Managed Microsoft Windows Server conform to the Information Security policies as set forth by Information Assurance (IA), as outlined in SPG 601.27.  As such, it is the responsibility of all authorized users of the server, which include the Application Teams, vendors and any other user with logon rights to the Windows Server, to ensure that this same level of security is maintained throughout the entire lifecycle of the server.  By using these provided resources, the authorized user has agreed to abide by these high security and server use standards, and are required to comply with all University policies, state and federal law concerning appropriate use of information technology.

Instructions

Software Installation on Servers:

Software installation on servers should be kept at a minimum to reduce the attack surface of the server.  The Application Team is responsible for all vulnerabilities (KB0013060) and compromises introduced for any non-Infrastructure (non-EI) software.  Proactive steps, such as subscribing to vendor security email notifications, reviewing the release notes for updated versions of the software and reviewing vendor website content for security news should be performed by the Application Team.  The security/vulnerability information obtained via these multiple data sources should then be used by the Application Team to ensure that any security vulnerabilities in the vendor software are addressed, on Michigan Medicine servers, in a timely fashion; this review should be performed minimally on a monthly basis and remediation of any vulnerabilities should occur as soon as possible after the vulnerabilities have been identified.  In the case of strictly vendor supported servers/appliances, the Application Team is responsible to ensure their vendors are addressing all vulnerabilities in a timely manner and are therefore meeting the terms and conditions of this KB.

Do:

  • Only Assure Investments/Software (Approved Software) from approved vendors should be installed.
  • Only install software that is mandatory and required for the functionality of that applicable server type.  Application Teams are required to verify all the software they, their vendors or any non-EI user with logon rights to the server installed is properly licensed, as per the terms of the software licensing agreement.
  • Network capture software should ONLY be installed on a server for troubleshooting purposes and as soon as the troubleshooting is complete, the software MUST be removed immediately. 

Don't:

  • No additional web browsers should be installed, such as Chrome or Firefox.  Microsoft Edge is the preferred web browser.  The security patches for Microsoft Edge and Internet Explorer (IE) are maintained by Windows Hosting Services.
  • Web browsing to the general Internet is discouraged.  Use a workstation for web browsing.
  • Software installed by the Application Team, the Vendor or a user with logon rights to the server should NEVER be installed on the C drive without prior Windows Hosting Services approval; if it is found to be installed without prior approval, you will be asked to move it to another drive.
  • Cloud file syncing software such as Dropbox, Box, Google Drive, OneDrive, etc., is not allowed as these types of software packages compromise the integrity of the daily backups of the system.
  • Freeware software should not be installed on the server unless it has already been vetted and approved by IA.
  • Unless otherwise stated by a Windows Hosting Services team member, adding and removal of Windows Roles and Features, or other core Windows server components, must be handled by Windows Hosting Services; this includes but is not limited to IIS and .Net. Submit a ServiceNow request to the Windows Hosting Services team if you need to add or remove such components.
  • Remote Desktop Client is the standard remote-control software.  The installation of 3rd party Remote Control software, such as but not limited to TeamViewer, LogMeIn, GoToMyPC, BeyondTrust, Radmin and more require an approved RDR from IA.

User Profiles:

Storing files in a user profile should be kept at a minimum, since low C: drive space conditions can cause system instability and potential data loss or corruption. As a user of a server, it's crucial to understand that upon logging into the server, a user profile is created on the C drive (core Windows behavior).  This user profile contains not only user preferences but also files that are placed on the desktop, in the download and documents folders, etc. To avoid system instability and potential data loss due to limited free space on the C drive, it is mandatory for users of the server to store or move all non-essential files to a non-C: drive or NAS share. Practice mindful storage for smooth operations. The C drive is reserved for Windows Hosting Services Team use.

Web Browsers on Servers:

  • Use of a web browser on a server should not be used or used on a very limited basis, such as when application testing/troubleshooting needs to be performed via a browser on the server itself.  Web browsing to the general Internet is discouraged.  Use a workstation for web browsing.
  • Only the web browser provided with the server should be used.  Windows 2016 and Windows 2019 come with Internet Explorer, while Windows 2022 comes with Microsoft Edge.  Only these browsers should be used.  Upon request, it is acceptable to request Windows Hosting Services to install Microsoft Edge on a Windows 2016 or Windows 2019 server, but this should always be handled by Windows Hosting Services. No additional web browsers should be installed, such as but not limited to Chrome and Firefox. 
  • If a vendor requires another browser and if it must be installed on the server, submit a ServiceNow ticket, containing the business case, to Windows Hosting Services for approval. If approval is given, the Application Team, vendor or the user with logon rights to the server will be responsible for the installation of the browser, they MUST handle any upgrades, and they are responsible for all vulnerabilities and any compromises that are caused by the existence of the software on the server.

Server Access:

This includes the ability to log into a Windows Server or access the data on the server.

  • Remote Desktop Server Access requests (Administrators, Power Users, Remote Desktop Users, etc.) can ONLY be processed by Windows Hosting Services.
  • Only System Admin (*name*-SA) Groups, not individual accounts, can be used to grant access to log into a Windows Server; it is irrelevant whether that access is going to be evaluated (administrators) or non-elevated (remote desktop users).  The group MUST end with -SA.
  • With the exception of vendor and service accounts, the use of Privileged Accounts (accounts in the form of umhs-uniqname) are required in order to log onto Michigan Medicine Windows Servers; this includes console, RDP or remote access methods, such as but not limited to WINRM.  Passwords for these Privileged Accounts are obtained via the processes and procedures outlined in the "Duo Two-Factor Authentication (KB0014512)" KB.
  • Service Accounts
    • Can be granted access to a server.
    • Must be in an SA Group, not individually added.
    • Unless it is absolutely required, the service account should not be used like a shared account where administrative or non-administrative activity is performed on the server with it.  For example, logging into the server as a service account to install software, troubleshoot issues, etc. should NOT be performed, unless it is a vendor requirement.
    • If a Vendor App requires a user to be always logged in to run an App (non-standard and these Apps should be avoided), then a Service Account should be used and not a User's individual SA account.  Windows Hosting Services should be made aware of these situations before they are implemented.
  • Shared Accounts are prohibited and cannot be granted access to servers.
  • When file shares are present (strongly discouraged), groups should be used.  Groups can be non-SA groups.  The App Team is responsible for all management of CIFS shares on Windows Servers.  NAS shares should be used in place of CIFS shares on Windows Servers, unless it is impossible to do so.
  • When databases are present, please defer to the EI Database Teams for details on their standards. The Database teams provide certain security standards that meet the University of Michigan SPG 601.27 Security Standards, such as database backup and recovery, encryption, auditing, password standards, etc.

 

Additional Information:

  • The Application Team, vendor or a user with logon rights to the server should not alter the Server drive configuration, including but not limited to changing the drive letters.  If a drive letter change is mandatory, approval should be received from Windows Hosting Services so the change can be made by Windows Hosting Services and tracked.
  • Any alteration to any set policy, such as but not limited to changes to the STIG, can only be made after an approved RDR is received from IA. The Application Team, vendor or a user with logon rights to the server may make the change once the approved RDR is received.  These changes must be reported to Windows Hosting Services upon implementation so the changes can be tracked.
  • The configuration of any policy currently in a state of "non-configured" (not enabled or disabled) must be approved and made by Windows Hosting Services.
  • Alteration of the Windows Hosting Services image is strictly prohibited, this includes alternations to all EHIS branding, drive standards, policy changes and more.  If a setting, system policy or otherwise, is found to be enforced/set it is a violation to alter it without the appropriate approval.
  • All users with any elevated rights, including but not limited to Administrative rights, must follow SPG 601 and other Key external documents noted at the top of the document.
  • If in doubt, open a ticket with Windows Hosting Services to inquire if any action will violate acceptable use.

Types of Servers:

Foreground Process Servers: This type of server is not common but is required in the environment and is considered acceptable.  This grouping of servers would include Management Servers, Jump Servers, and Terminal Server or Citrix Servers.  A Management Server is used as an access point to manage other server, such as running scripts either manually or via a scheduled task for varying purposes, such as server/data health checks, data collection, etc. A jump server is used as a jumping point to get to another server, such as one behind a firewall. A Terminal Server or Citrix Server is used to host applications, such as MiChart; this server type might also have background processes, thereby making it a Hybrid.

Background Process Servers: This type of server is the majority of all servers, where all the vendor software runs in the background, generally as a service, but sometimes certain tasks are run as scheduled tasks.  Examples of services would be IIS, Apache, SQL Services and more, where examples of scheduled tasks might be the running of PowerShell or other scripts, or the execution of a vendor executable that performs a task at specific times of the day or every x minutes.  These servers are the true definition of a server as a user is not logged into the system and interacting directly with a piece of software on the system itself.  This server should NOT have any foreground processes running on it, otherwise it would be considered a hybrid server.

Non-standard Servers: This is any server that doesn't fall into the two previous server types.  If this type of server is required, the Windows Server requestor should communicate with a Windows Hosting Services Team Member to discuss these non-standard server requirements.  All non-standard servers must be approved.  These types of servers should be avoided, but if approved would be considered 'acceptable use servers' under this policy.  An example of this type of server is one where the vendor application will only run if a user is logged into the user, and therefore the application runs within that active or disconnected user session.  This type of server is strongly discouraged, but if approved is allowed under the acceptable use policy.

Appliance Server (Windows-based): This is a subset and very specific non-standard server, where the server is provided by the vendor and can be either a physical server or a virtual server.  This server would not contain the EHIS image, but instead one provided by the vendor, or it would be built under strict vendor guidelines.  Examples would be using an OVA/OVF file for a VM or building the server from the Microsoft ISO.  These are vendor supported devices where Windows Hosting Services will only assist in getting the servers deployed, when appropriate, after which time Windows Hosting Services will ONLY provide a hosting environment, no other support, including OS level support.  The Application Team, vendor or a user with logon rights to the server is responsible for all patching, vulnerabilities and compromises due to the existence of this server in the environment.  Windows Hosting Services must be provided with an administrative level local account and when domain joined, the Windows Hosting Services SA Group must be granted administrative level access; this applies to all appliances.  Note: Windows Hosting Services will assist in the deployment of Windows-based appliances while Linux Hosting Services will assist in the deployment of Linux-based appliances.