/
2024 MSS for a Managed Windows System

2024 MSS for a Managed Windows System

 

The purpose of this document is to help answer the Minimum Security Standards for a Managed Windows server. The answers provided below describe an environment which the "Managed Servers - Windows" team can fully support. 

Green - ITS Windows in compliance.

Orange - Shared responsibility.

Red - Not the responsibility of ITS Windows.

RedCell - ITS Windows NOT in compliance.


Prerequisites

The Minimum Security Standard can be found here: https://cybersecurity.yale.edu/mss/list

MSS 1

YALE-MSS-1: System Classification

YALE-MSS-1.1: Classify the IT System and Meet the Minimum Security Standards

The ITS Windows team offers managed support for IT systems classified as servers, which we ensure to be suitable for all levels of risk classification.

MSS DetailsITS Windows Implementation
1.1.1 Classify the IT System as high, moderate, or low risk based on data classification, availability requirements, and external obligationsThe Windows Team works with the server and application owners to determine the risk classification based on the risk level of the data and the outcome of the risk calculator.

1.1.2 Determine your system type

The System type will be Server in 99% of cases involving the Windows Services Team.  
1.1.3 Determine if your system is Internet AccessibleThe Windows Team works with the system owner to determine if the server is internet accessible.
1.1.4 Define roles and responsibilities for meeting and maintaining the Minimum Security Standards and any external security requirements throughout the lifespan of the systemThe ITS Windows Team  works with the system owner to determine the roles and responsibilities.
1.1.5 Ensure roles and responsibilities for meeting and maintaining all security requirements throughout the life cycle of the system are accepted by all partiesThe ITS Windows team works with the system owner to ensure that roles and responsibilities are accepted by all parties.
1.1.6 Provide appropriate level of staffing to manage your systems in accordance with their security requirementsThe ITS Windows Manager will ensure that there is appropriate level of staffing.
1.1.7 Budget for maintaining the ongoing support and maintenance of the system to meet its security requirements throughout the lifespan of the systemThe ITS Windows team works with the system owner to provide the overall cost of maintaining the server.

It is the responsibility of the system owner to budget for these costs.
1.1.8 Ensure a valid policy exception request is filed when a Minimum Security Standard cannot be metIt is the responsibility of the system owner to ensure a valid policy exception is filed.  

YALE-MSS-1.2: Apply any additional security requirements required by external obligations 

The ITS Windows team supports managed servers that are required to comply with external requirements. External obligations (such as FERPA, HIPAA, and the like) inform decisions at build time, such as network placement, access limitations, system architecture, etc, and during run time, such as response SLAs, patching cadences, etc.

It is the system owner's responsibility to understand their external obligations and make the ITS Windows team aware of the constraints the system must run under.

MSS DetailsITS Windows Implementation
1.2.1 Ensure you can meet any obligations in the event of a security incident or data breachThe system owner is responsible for identifying external obligations.  Windows Services will implement appropriate controls based on those obligations where applicable.

YALE-MSS-1.3: Ensure appropriate contracts for all third-party relationships are in place

The ITS Windows team is not responsible for entering into contract negotiations with vendors, nor for maintaining those contracts. It is the responsibility of the system owner to ensure appropriate contracts are in place for their system and application software.

MSS DetailsITS Windows Implementation
1.3.1 Ensure the Data Addendum process is followed when storing data in a vendor's cloudThe system owner is responsible for ensuring cloud vendors sign appropriate contracts. The ITS Cloud team is responsible for broad data agreements with Amazon, Azure, and other cloud vendors with whom we contract.
1.3.2 A Business Associate Agreement (BAA) is in placeThe system owner is responsible for all BAAs with vendors.

YALE-MSS-1.4: Designate and protect Critical IT Infrastructure 

Most or all Critical IT Infrastructure is managed by the ITS Windows team or their peers (The Network team, the Linux team, the Data Center Operations team, etc.) For those components managed by the Windows team, we attest that those systems adhere to the MSS.

MSS DetailsITS Windows Implementation
1.4.1 Maintain a tailored security plan that matches the security best practices for that specific system/technologyThe ITS Windows team applies best security practices on all managed servers. This includes but is not limited to:

limiting access
only running necessary services
properly configuring running services
Monthly patching Securing servers with Group Policy
1.4.2 Ensure the tailored security plan is periodically reviewed and advanced, at least on an every other year basisThe ITS Windows team usies the Microsoft RAP (Risk Assessment Program).
1.4.3 Physically secure the Critical IT System in accordance with the Minimum Physical Security Standards for Critical IT SpacesAll systems managed by the ITS Windows team are located in one of the following:

  • a physically secured Yale data center
  • a locked rack in a colocated facility (CyrusOne; Equinix)
  • a cloud vendor's secure site (AWS; Azure)

YALE-MSS-1.5: Plan for data recovery requirements 

Recovery of data is ensured by the ITS Windows team for all managed servers. By default, our systems are recoverable as full system images; file level backups can be implemented if required by the system owner at (potentially) additional cost. The default backup schedule (which determines how much data could be lost) should be understood by the system owner.

MSS DetailsITS Windows Implementation
1.5.1 Determine the maximum amount of data that can be lost during a disruption before incurring significant impact to operationsThe system owner is responsible for understanding the maximum acceptable data loss on the platform - often described as the Recovery Point Objective (RPO.)

The RPO for the VMware environment is guaranteed by the ITS Storage Team. VM image snapshots are taken nightly, and volumes are replicated off-site.
The RPO of Cloud platforms (AWS; Azure) is guaranteed by the ITS Cloud Team.

YALE-MSS-1.6: Plan for meeting and maintaining the security requirements for the IT System 

The ITS Windows team, for all managed servers, understand our responsibility to the security of the systems we manage. We work closely with system owners to ensure appropriate, timely response and attention for all managed servers. Despite that, the system owner cannot cede all security responsibilities to the Windows team. As noted below, there are a number of security requirements that are the sole responsibility of the system owner.

YALE-MSS-1.7: Complete a Security Planning Assessment (SPA) 

The system owner is responsible for completing the SPA. The ITS Windows team will answer questions pertaining to the SPA, and this document lists what the ITS Windows team guarantees as part of our managed server offering.




YALE-MSS-2

YALE-MSS-2: System Inventory

Automation controls the configuration management of all Windows systems. Additional measures can be performed if necessary, as per requirements provided by Information Security Team.

YALE-MSS-2.1: Establish the scope of the IT System 


MSS Guidelines
ITS Windows Planning
2.1.1: Identify and maintain a current inventory of all components and dependenciesIn the process of implementing the CMDB for inventory of components.  
2.1.2: Document and maintain your inventory and dependenciesThe Windows Team is responsible for the security of the OS.  VMware for the Infrastructure, application owner for the security of the application.

YALE-MSS-2.2: Use a private IP address if direct internet access is not required 

All servers are placed on appropriate networks in coordination with the system owner. The ITS Windows team maintains that it is best practice to keep servers on private IP networks, and we encourage the use of those networks. All servers are assigned private IPs. VIPs and public IPs are assigned as needed for public access.  If the system owner determines that their server(s) cannot live on private networks, we require them to seek an exception from Information Security.   




YALE-MSS-3

YALE-MSS-3: Disaster Recovery (DR)

YALE-MSS-3.1: Create a Disaster Recovery Plan


ITS Windows has a documentation for VMware Disaster Recovery Test Plan.

Please follow the below link to visit the plan of recovery.

/wiki/spaces/SLO/pages/993592360


MSS GuidelinesITS Windows Implementation

3.1.1: Identify roles and responsibilities for your DR Plan 

The system owner is responsible for identifying roles and responsibilities for DR.

3.1.2: Identify components, dependencies, and their relationships using architectural diagrams

The ITS Windows team, in collaboration with other IT teams and the system owner, will help identify all of the components of the system, and help draft/audit architectural diagrams. The ITS Windows team works with application owners to provide architectural diagrams for all new servers.

3.1.3: Identify procedures for recovering each component of the IT System

The ITS Windows team is responsible for the general procedures for any Windows Managed Server recovery. With Full Stack support, the ITS Windows team works with the service owners and other IT teams to create the specific procedures required to restore the application to service.

3.1.4: Ensure the up-to-date DR Plan is available to any staff that could be required to execute it in the event of a disaster.


3.1.5: Keep the DR plan up to date

YALE-MSS-3.2: Test the Disaster Recovery Plan 

Central IT is creating a formalized DR plan.  


MSS GuidelinesITS Windows Implementation
3.2.1: Test the Disaster Recovery (DR) plan once a yearCentral IT is creating a formalized DR plan.  
3.2.2: Validate that the contact information is accurateContact information for the ITS Windows team is updated and distributed as required.

Contact information for the system is the responsibility of the system owner.

This should be part of a yearly audit managed outside of the ITS Windows Team  
3.2.3: Validate that all steps are identified and in the right order for the restoration of a component or as a result of a facility lossThis is a shared responsibility between the ITS Windows team and the system owner.
3.2.4: Validate that any component or technology, including versions are identified that are required for this IT System to be healthy.All components and technologies are monitored in Dynatrace. Once a system is recovered, components will be validated with Dynatrace monitors.
3.2.5: Validate that recovery steps and order are correct for any component loss or facility lossThis is a shared responsibility between the ITS Windows team and the system owner.
3.2.6: Validate that any member of the team can access the DR Plan and the supporting documentation requiredCentral IT is creating a formalized DR plan.  
3.2.7: Validate that any member of the team can execute this DR Plan in its entirety without the assistance of the subject matter expertCentral IT is creating a formalized DR plan.  
3.2.8: Validate that the IT System can be restored to health within the availability requirements you establishedThe requirements come from the system owner. The ITS teams responsible for implementation will advise on how to achieve those goals. Without proper implementation we cannot assure RTO and RPO.
3.2.9: Identify and record any gaps found during the testing of this DR PlanThe ITS Windows team will document gaps in our procedures.




YALE-MSS-4

YALE-MSS-4: Physical Security

YALE-MSS-4.1: Physically secure Critical IT Spaces

N/A

MSS GuidelinesITS Windows Implementation
4.1.1: Implement the Minimum Physical Security Standards for Critical IT SpacesAll Managed Windows systems are sited in either a Yale controlled data center, or a cloud provider's data center. Those data centers are controlled for physical access. For more information, contact either Data Center Support or the ITS Cloud team.

YALE-MSS-4.2: Physically secure the IT System

The systems live in the Datacenter or in the cloud.  Server that are hosted in VMWare are in the Datacenter.  Physical servers are in the datacenter
MSS GuidelinesITS Windows Implementation
4.2.1: Limit user access to the secure area to only those who need itAll Managed Windows systems are sited in either a Yale controlled data center, or a cloud provider's data center. Those data centers are controlled for physical access. 
4.2.2: Review and re-certify user access to the secure area annuallyAuditing physical access to the data centers is the responsibility of Data Center Support. Cloud data centers are outside of scope.
4.2.3: Access to the secure space produces a physical or electronic audit logData Center Support is responsible for maintaining logs - physical or electronic - of Yale controlled data center access.
4.2.4: A locking cable or equivalent physical protection for all devices when not in the user's physical custodyThis is not applicable for physical rack mounted servers.
4.2.5: Install privacy screen filters on computer screens that display ePHI

N/A

YALE-MSS-4.3: Ensure print jobs are physically secure 

The Windows Managed Servers offering does not include printer management. Any servers configured to use PaperCut makes use of private printing, but not all systems that require printing take advantage of this.




YALE-MSS-5

YALE-MSS-5: Software Security

YALE-MSS-5.1: Utilize an industry-standard secure configuration method 

CIS Benchmark is used for all server configured since July 2018.  Older systems are being brought into this configuration as Operating Systems are being upgraded\migrated.  
MSS GuidelinesITS Windows Implementation
5.1.1: Document your approach to the chosen configuration standardCIS Benchmark is achieved by applying the recommended settings in Group Policy. 
5.1.2: Utilize file integrity and configuration checking tools90 Min Group Policy Refresh. CrowdStrike.

YALE-MSS-5.2: Utilize endpoint protection 

MSS GuidelinesITS Windows Implementation
5.2.1: Utilize a Next Generation Anti-Virus solutionYale currently employs the Crowdstrike Falcon Complete. Crowdstrike Falcon is an Endpoint Detection Response (EDR) tool that provides the capabilities of a Next-Generation Antivirus (AV) solution.
5.2.2: Run Endpoint Detection Response (EDR) toolYale currently employs the Crowdstrike Falcon Complete. Crowdstrike Falcon is an Endpoint Detection Response (EDR) tool that provides the capabilities of a Next-Generation Antivirus (AV) solution.


YALE-MSS-5.3: Run supported software and operating systems 

ITS Windows team runs supported software and operating systems. It is the responsibility of application owners to keep their software on current versions.  

YALE-MSS-5.4: Ensure all software is actively supported by a vendor or open-source project

All Operating systems and software owned by Windows Services are kept on currently supported versions. Application owners are responsible for their applications. 

YALE-MSS-5.5: Manage all changes to the system through a change control process

ITIL and Service Now change control is used by all of ITS. Windows services for their changes and application owners for theirs.  
MSS GuidelinesITS Windows Implementation
5.5.1: All changes to the IT system are analyzed to ensure the security posture is not weakenedAll changes to the IT system are vetted by (various ITS groups) to ensure the security posture is not weakened.
5.5.2: An audit trail for changes to the IT system is maintained to account for when changes were made and by whomAll changes to the IT system are made via the Change Request Process in ServiceNow and auditable by system logs.


YALE-MSS-6

YALE-MSS-6: Patching

YALE-MSS-6.1: Apply security patches regularly 

The ITS Windows team patches servers within 30 days of release by Microsoft.  


MSS GuidelinesITS Windows Implementation
6.1.1: Apply all security patches to operating systems, software, and firmware based on riskAll systems patched within 30-days of Microsoft patch releases.  Express patching is already covered by our condensed patching schedule which is 2 weeks.  
6.1.2: Identify maintenance windows for necessary upgrades/patchesMaintenance windows are weekly and are 3 hours.  
6.1.3: Implement an emergency patch processEmergency patches are installed as soon as possible in coordination with ISO and the customer.




YALE-MSS-7

YALE-MSS-7: Data Protection

YALE-MSS-7.1: Back up user-level and system-level data


MSS GuidelinesITS Windows Implementation
7.1.1: Run a scheduled automated network backup based on data and system recovery requirementsA managed Windows system is backed up nightly. For virtual machines, this done via VMware NetApp plugin. For physical servers, this is achieved with the Veritas NetBackup Client.  
7.1.2: Document and test the restore process annually

Restore a VM from a NetApp backup and verify the data.

A ServiceNow ticket is created quarterly with instructions.
Need a cadence for back and restore testing.  

7.1.3: Ensure backups are encrypted in transit and at rest

Storage traffic encryption occurs only if data leaves the datacenter or our network. That is only done once a day when all volumes are vaulted off to S3/IA. Data is encrypted then before leaving the AltaVault replication appliance.

YALE-MSS-7.2: Encrypt all electronic storage devices 


MSS GuidelinesITS Windows Implementation
7.2.1: Utilize full disk encryptionVMware disk is encrypted. Physical server disk encryption is utilized where necessary.
7.2.2: Encrypt portable storage devicesThis is not applicable.
7.2.3: Be able to provide evidence that an electronic storage device is encryptedThe FTS-Storage team will be able to provide information on the encryption of VMware disk.
Evidence of storage device encryption may be provided for a Managed Windows physical server where applicable.

YALE-MSS-7.3: Encrypt data in transit and at rest

TLS is used for data in transit.  Disks are encrypted for data at rest.  

YALE-MSS-7.4: Recycle IT Systems using Yale's Environmental Health and Safety (EHS) Process

MSS GuidelinesITS Windows Implementation
7.4.1: Securely dispose of devices using the Yale Environmental Health and safety processDisposal of devices managed by the Managed Servers - Windows team is handled by the Data Center Facilities group upon request.

YALE-MSS-7.5: Sanitize systems before re-use 

MSS GuidelinesITS Windows Implementation
7.5.1: Fully sanitize devices, by device typeAny physical managed Windows system is fully wiped before reuse using the DOD disk wiping software where applicable. Windows team does not recommend reusing physical systems for high risk data involvement.
7.5.2: Follow the University Chain of Custody process for devices being re-used or disposed ofIf any physical system is to be repurposed for use of HIPAA data, the University Chain of Custody process for devices will be followed.

YALE-MSS-7.6: All network traffic must use a strong, industry-standard encryption method

Where possible, ITS Windows:

  • uses https for web traffic
  • uses client side VPNs
  • encrypts data before transmission

YALE-MSS-7.7: Purge data once it is no longer required

Windows has 30 day retention policy when decommission a system. After 30 days, the system data and any application is erased.

Exports of application data are honored by request.

YALE-MSS-7.8: Utilize host Data Loss Prevention (DLP) 

This is not applicable to Managed Windows Servers.

YALE-MSS-7.9: Use inactivity locks 

All server desktops lock after 10 minutes.

YALE-MSS-7.10: Store Yale Data within the United States 

Virtual machine data and managed physical Windows server data is stored within the United States.

YALE-MSS-7.11: Use secure Bluetooth

This is not applicable to Managed Windows Servers.

YALE-MSS-7.12: Enroll in a remote wipe capability 

This is not applicable to Managed Windows Servers.

YALE-MSS-7.13: No circumvention of device security ("Jailbreaking") 

This is not applicable to Managed Windows Servers.




YALE-MSS-8

YALE-MSS-8: Application Development Security

YALE-MSS-8.1: Follow an appropriate secure development methodology when writing software 

This is not applicable to Managed Windows Servers.

YALE-MSS-8.2: Test for security vulnerabilities when any changes are made to the system

Managed Windows servers are scanned daily via Nessus.  ISO provides access to Nessus reports to identify security vulnerabilities.

Application owners may have items listed in the daily report mentioned above that should be addressed.




YALE-MSS-9

YALE-MSS-9: Authentication and Authorization


YALE-MSS-9.1: Ensure all account types are uniquely authenticated 

...

YALE-MSS-9.2: Do not share account credentials (username/password) 

The Windows Team does not share user accounts.

YALE-MSS-9.3: Utilize secure passwords for authentication


MSS GuidelinesITS Windows Implementation
9.3.1: Change all account usernames and passwords from defaults

The Windows Team changes all default passwords upon creation or installation of a service or device.  GMSA accounts are used wherever possible and do not have passwords.

The Application Team is responsible for changing default passwords on applications.

9.3.2: Align (or surpass) password security to align with the current requirements for Net ID credentials

The Password Group Policy exceeds the password complexity.

Application teams are responsible for setting password complexity.

9.3.3: Lock mobile devices with a password, passcode or pinThe Windows Team is not responsible for mobile devices.
9.3.4: Prohibit password, passcode, or pin reuse for a specified number of generations

The Password Group Policy exceeds the password complexity and reuse.

Application teams are responsible for setting password reuse policy.

9.3.5: Do not reuse passwordsThe Password Group Policy exceeds the password complexity.

YALE-MSS-9.4: Grant privileges to IT Systems and data according to the principle of least privilege 


MSS GuidelinesITS Windows Implementation
YALE-MSS-9.4.1: Review all accounts with access to the system to ensure least privilege is appliedThe Windows Team reviews accounts to ensure least privilege is applied upon account creation but does not currently have a process in place to review the accounts periodically.
YALE-MSS-9.4.2: Maintain an inventory of all privileged and service accounts and assigned privileges

The Windows Team does not currently have a process to review and remove service accounts and assigned privileges.

YALE-MSS-9.5: Deprovision accounts and access when roles & responsibilities change 

Deprovisioned at the IAM level.  Gap when switching roles.
MSS GuidelinesITS Windows Implementation
9.5.1: Ensure accounts are deprovisioned or altered to reflect necessary access when an individual's role or responsibilities change or a user is terminated

If the user whose role is changing is a member of the Windows Team, a change request is submitted by the Manager of the Windows Team which creates appropriate tasks to remove the user from all required systems.

If the user whose role is changing is not a member of the Windows Team, it is the user's manager's responsibility to create this request.

9.5.2: Shared service account passwords should be renewed on a routine basis or when an individual who knew the credentials no longer needs access to the accountWhen a member of the Windows Team changes roles or is terminated, the Windows Team will roll the root password and the password to Keepass.  
LAPS is used for rotating unique password for admin access to servers. GMSA is used for many service accounts. Other service accounts are provided to application owners who are responsible for maintaining the password.

9.5.3: Identify dormant accounts and remove them on a regular basisThe Windows Team does not currently have a process to review and remove dormant and unused accounts.

YALE-MSS-9.6: Require Multifactor Authentication (MFA) for access to authenticated systems

MFA DOU is used with netid.  

YALE-MSS-9.7: Use University approved authentication methods 

MSS GuidelinesITS Windows Implementation
9.7.1: Web applications are required to use Yale credentials to utilize the University's Approved Single Sign On methodsThe Windows Team is not responsible for web application authentication.
9.7.2: For non-web applications, use Yale’s central Active Directory services. LDAP is not approved.The Windows Team is not responsible for authentication to applications.

YALE-MSS-9.8: Secure and/or limit storage of authentication information 

Passwords are not stored in source code repositories for Windows. Keypass is used to store secrets for the Windows team. Importing secrets into Jenkins and Ansible is documented.

Application owners will need to assess secret management within their own teams.

MSS GuidelinesITS Windows Implementation
9.8.1: Document secrets management decisions and operational practices

Decisions are documented in Confluence and appropriate repositories.

Work is logged in ServiceNow.

YALE-MSS-9.9: Allow only encrypted network protocols for authentication 

TLS 1.2 and above are used.  Lower levels are disabled.  
MSS GuidelinesITS Windows Implementation
9.9.1: Use industry standard authentication protocols

Managed Windows uses NTLM and Kerberos.

YALE-MSS-9.10: Prevent brute force attacks 

MSS GuidelinesITS Windows Implementation
9.10.1: Implement rate limiting or failed authentication lockoutsActive Directory account lockout policy.  

YALE-MSS-9.11: Use administrative and service accounts for their IT function only 

MSS GuidelinesITS Windows Implementation
9.11.1: Adjustment of privileged account permissions should be performed by the provider of the account and never the user of the account or a third-partyThis is controlled by the "Local Access"  Group Policy.

YALE-MSS-9.12: Ensure authentication events are associated with an individual and not just an administrative or service account 

Authentications are tracked by individual Net IDs.

The "root" user cannot be logged into directly on any Windows system. Windows administrators log in using their own ID and any account privilege escalation is logged via system logs.

MSS GuidelinesITS Windows Implementation
9.12.1: Disable direct login with generic, shared account names ("root", "administrator", "dba", "sa"). The login accounts must meet the account requirements outlined in Yale-MSS-9.3.The administrator account has been renamed and the Password is unique, rotating and is controlled by LAPS.
9.12.2: Do not allow direct logins to accounts with administrative privileges. Require users to log in with an individual account and escalate privileges.We use Secret Server for all administrative access.  In a future state all application owners should use secret server.  




YALE-MSS-10: MANAGE ACCESS TO THE SYSTEM

YALE-MSS-10: Network Exposure

YALE-MSS-10.1: Enable ports, protocols, and services on an as needed basis 

All the servers are behind the Datacenter firewall and ports are opened only as needed with all appropriate approvals.

Specific ports are allowed based on the VLAN the system has an IP address in. These are determined by the ISO team; additional rules are requested during initial setup of the system/application. This is not done on a cadence, however firewall requests for additional port access is done on an as needed basis.

Application owners need to provide a list of ports needed to run their application.

YALE-MSS-10.2: Configure host firewalls to deny all unsolicited inbound traffic by default 


Windows firewall is configured to use only the ports required to run the server and the application on it. The traffic is not logged by default.

YALE-MSS-10.3: Utilize host firewalls to control and log all inbound and outbound traffic 

Windows firewall is configured to use only the ports required to run the server and the application on it.  This is for inbound traffic.  Outbound is only configured in certain cases.  




YALE-MSS-11

YALE-MSS-11: Security Training


YALE-MSS-11.1: Require security training for all users of Yale Data and Yale IT Systems 

MSS GuidelinesITS Windows Implementation
11.1.1: Ensure all staff are informed, understand their roles and responsibilities, and complete assigned security training requirements

The Windows Managed servers team is informed, trained, and understand their roles and responsibilities through constant peer and managerial review.

The Windows Managed servers team completes all required training in Yale's Training Management System.

YALE-MSS-11.2: Ensure all third parties complete required training 


MSS GuidelinesITS Windows Implementation
YALE-MSS-11.2.1: Require vendor(s) to ensure that anyone who performs work under their agreement receives annual instruction and/or training to comply with the provisions of their contract(s) with Yale

The Windows Managed servers team defers to the procurement team to ensure that third parties are compliant.

It is not the responsibility of the Windows Managed servers team to ensure third parties are compliant, however, we will liaise with the procurement team and the third party to ensure the requirements are met.



YALE-MSS-12

YALE-MSS-12: Intrusion Detection

YALE-MSS-12.1: Capture inbound and outbound network flow data 

Inbound/Outbound traffic flow is captured by appliances managed by the security team.

YALE-MSS-12.2: Utilize a network firewall to allow the least amount of access possible

All the systems are behind firewall.

MSS GuidelinesITS Windows Implementation
12.2.1: Control inbound and outbound traffic

Inbound traffic is controlled first by firewalls managed by the network team, then VPN, then user accounts and local firewall.

VMs are also assigned their subnet VLAN according to the access required by applications and users.

There are no specific rules configured on most Windows servers that controls outbound access. Outbound access is logged on the network team controlled firewall and inspected for threats.

12.2.2: Log and filter traffic to identify and protect against potential threatsTraffic is logged at the firewalls managed by the network team. Crowdstrike is installed to further identify threats.
12.2.3: Document your required firewall rulesAll firewall rules are requested via ServiceNow, which serves as documentation. Additionally, the network team is responsible for backing up firewall rules.  They are also documented in the Hosted Application Inventory.  

YALE-MSS-12.3: Implement an Intrusion Detection and Prevention System 

The ISO team manages the Intrusion Protection System.




YALE-MSS-13

YALE-MSS-13: Logging

YALE-MSS-13.1: Ensure logging contains information required for incident response 

Security incidents will be reported to the Information Security Team via a ServiceNow incident with all available information. 

The logs are maintained on Windows servers and ISO uses Winlogbeats and Filebeats to pull and store those logs on a daily basis.
MSS GuidelinesITS Windows Implementation
13.1.1: Use multiple time serversYale Time servers are used.  
13.1.2: Ensure client IP addresses are not obscured by load balancers and reverse proxies

Direct access to Windows systems will be recorded with the source address.

We need to check that all VIPs in the load balancer have X-Forwaded-For (XFF) enabled so that source ip addresses can be identified. 

13.1.3: Ensure adequate space to log data. Logs should be kept for a minimum of 90 days.

Logging space is monitored and additional space is added when necessary before space is exhausted.

IIS Logs are only kept for 30-days.  

YALE-MSS-13.2: Log all authentication events 

Authentication is recorded in the Windows Security log.

MSS GuidelinesITS Windows Implementation
13.2.1: Collect logs that include all authentication and privileged escalation events

The logs are held by ISO.

YALE-MSS-13.3: Ensure logs are forwarded to a log server in addition to the in-scope system 

All the logs are forwarded to Graylog. Adequate permissions are set for users through Grouper in order to access the logs where they can access the required information.

YALE-MSS-13.4: Collect and review all source system activity logs 

Users logging to systems are tracked in audit.log file

MSS GuidelinesITS Windows Implementation
13.4.1: Identify, track, and periodically audit source systems for compliance with all applicable laws, regulations, and University policies, standards, and procedures

The Windows Managed servers team does not currently have a process to audit all Windows servers.


13.4.2: Collect log data needed for Information System Activity ReviewThe logs are held by ISO.




YALE-MSS-14

YALE-MSS-14: Security Incident Reporting


YALE-MSS-14.1: Report any suspected security incidents to the Information Security Team in a timely manner 

Security incidents will be reported to the Information Security Team via a ServiceNow incident with all available information.

Depending on the severity of the security incident, the team may reach out directly to the security team via phone, Teams, etc.


MSS GuidelinesITS Windows Implementation

14.1.1: Require vendors (third-party service providers) to notify Yale of a security incident within a 72 hours of a discovery of a confirmed incident

It is not the responsibility of the Windows Managed servers team to ensure that vendors notify Yale of a security incident within 72 hours.


YALE-MSS-14.2: YALE-MSS-14.2: Identify the system's primary security contact 

Based on the tagging information available on the respective node in VMWare, we will be contacting the client accordingly. 

Information for physical systems is identified in the CMDB.