The purpose of this document is to help answer the Minimum Security Standards for a Managed Linux system. The answers provided below describe an environment which the "Managed Servers - Linux" team can fully support. Please consult your friendly neighborhood Linux Admin if any adjustments need to be made to accommodate your system. Depending on what changes are made, alterations may affect the ability for your system to be considered a "Managed Linux System" and the responsibility for the enforcement of these items may shift to you.

Green - ITS Linux and we are in compliance.

Orange - Shared responsibility.

Red - Not the responsibility of ITS Linux.

RedCell - ITS Linux and we are 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 Linux team offers managed support for IT systems classified as servers, which we ensure to be suitable for all levels of risk classification.

MSS Details	ITS Linux Implementation
1.1.1 Classify the IT System as high, moderate, or low risk based on data classification, availability requirements, and external obligations	The ITS Linux team works with the system owner to determine the risk classification, based on the importance and sensitivity of the data.
1.1.2 Determine your system type	The ITS Linux team is responsible for servers; that include Web servers, file servers, database servers and email servers.
1.1.3 Determine if your system is Internet Accessible	The ITS Linux 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 system	The ITS Linux 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 parties	The ITS Linux 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 requirements	The ITS Linux 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 system	The ITS Linux 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 met	It is the responsibility of the system over to ensure a valid policy exception request is filed.

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

The ITS Linux 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 Linux team aware of the constraints the system must run under.

MSS Details	ITS Linux Implementation
1.2.1 Ensure you can meet any obligations in the event of a security incident or data breach	The system owner is responsible for identifying external obligations; the ITS Linux team will implement appropriate controls based on those obligations.

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

The ITS Linux 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 Details	ITS Linux Implementation
1.3.1 Ensure the Data Addendum process is followed when storing data in a vendor's cloud	The 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 place	The 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 Linux team or their peers (The Network team, the Windows team, the Data Center Operations team, etc.) For those components managed by the Linux team, we attest that those systems adhere to the MSS.

MSS Details

ITS Linux Implementation

1.4.1 Maintain a tailored security plan that matches the security best practices for that specific system/technology

The ITS Linux 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
regular patching

1.4.2 Ensure the tailored security plan is periodically reviewed and advanced, at least on an every other year basis

The ITS Linux team participates in a yearly security audit by Price Waterhouse Cooper. We also amend our security plan as we learn of new best practices and as threats emerge.

1.4.3 Physically secure the Critical IT System in accordance with the Minimum Physical Security Standards for Critical IT Spaces

All systems managed by the ITS Linux 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 Linux 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 Details

ITS Linux Implementation

1.5.1 Determine the maximum amount of data that can be lost during a disruption before incurring significant impact to operations

The 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 Linux 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 Linux 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 Linux team will answer questions pertaining to the SPA, and this document lists what the ITS Linux team guarantees as part of our managed server offering.

YALE-MSS-2

YALE-MSS-2: System Inventory

Automation controls the configuration management of all Linux 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 Linux Planning

2.1.1: Identify and maintain a current inventory of all components and dependencies

The ITS Linux team enables system discovery for all managed servers. That data is stored in the ServiceNow CMDB. This includes information about installed packages, resources, networks, etc.

It is the responsibility of the system owner to maintain a high level inventory of all systems (servers, databases, load balancers, etc) that compose their individual service.

2.1.2: Document and maintain your inventory and dependencies

The ServiceNow CMDB is the canonical source of server inventory documentation.

It is the responsibility of the system owner to create and maintain their own high level inventory as relates to their individual service.

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 Linux team maintains that it is best practice to keep servers on private IP networks, and we encourage the use of those networks. 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 Linux 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 Guidelines	ITS Linux 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 Linux 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.
3.1.3: Identify procedures for recovering each component of the IT System	The ITS Linux team is responsible for the general procedures for any Linux Managed Server recovery. With Full Stack support, the ITS Linux 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.	The ITS Linux team provides recovery procedures for the VMware shared environment, often a prerequisite for server restore.
3.1.5: Keep the DR plan up to date	The ITS Linux team updates the DR plan as necessary.

YALE-MSS-3.2: Test the Disaster Recovery Plan

MSS Guidelines	ITS Linux Implementation
3.2.1: Test the Disaster Recovery (DR) plan once a year	A small test to recover VMs is scheduled every quarter. Larger data center tests are scheduled by the DR/BC team.
3.2.2: Validate that the contact information is accurate	Contact information for the ITS Linux 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 Linux team by the DR/BC 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 loss	This is a shared responsibility between the ITS Linux 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 loss	This is a shared responsibility between the ITS Linux team and the system owner.
3.2.6: Validate that any member of the team can access the DR Plan and the supporting documentation required	As part of employee onboarding, employees receive access to the DR/BC documentation. All members of the ITS LInux team have the ability to access this documentation.
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 expert	The ITS Linux team will update the DR documentation so that it can be executed by any member of the team.
3.2.8: Validate that the IT System can be restored to health within the availability requirements you established	The 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 Plan	The ITS Linux 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 Guidelines	ITS Linux Implementation
4.1.1: Implement the Minimum Physical Security Standards for Critical IT Spaces	All Managed Linux 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

MSS Guidelines	ITS Linux Implementation
4.2.1: Limit user access to the secure area to only those who need it	All Managed Linux 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.
4.2.2: Review and re-certify user access to the secure area annually	Auditing 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 log	Data 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 custody	This is not applicable for physical rack mounted servers.
4.2.5: Install privacy screen filters on computer screens that display ePHI	This is not applicable for physical rack mounted servers.

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

The Linux Managed Servers offering does not include printer management. Any servers configured to use PaperCut make 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

MSS Guidelines

ITS Linux Implementation

5.1.1: Document your approach to the chosen configuration standard

Linux systems are configured and maintained by automation software that runs, at minimum, once an hour to keep systems aligned with industry best practices.

The automation code serves as the documentation.

5.1.2: Utilize file integrity and configuration checking tools

Systems are scanned by Nessus security software once a month; adjustments to the base configuration are made accordingly. DEP and ASLR features have been built into the Linux kernel since v2.6 and should be included in all modern Linux kernels running on the systems Managed Servers Linux provides.

YALE-MSS-5.2: Utilize endpoint protection

MSS Guidelines	ITS Linux Implementation
5.2.1: Utilize a Next Generation Anti-Virus solution	ITS Linux doesn't install antivirus on managed servers.
5.2.2: Run Endpoint Detection Response (EDR) tool

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

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

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

MSS Guidelines	ITS Linux Implementation
5.5.1: All changes to the IT system are analyzed 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 whom

YALE-MSS-6

YALE-MSS-6: Patching

YALE-MSS-6.1: Apply security patches regularly

MSS Guidelines	ITS Linux Implementation
6.1.1: Apply all security patches to operating systems, software, and firmware based on risk
6.1.2: Identify maintenance windows for necessary upgrades/patches
6.1.3: Implement an emergency patch process

YALE-MSS-7

YALE-MSS-7: Data Protection

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

MSS Guidelines	ITS Linux Implementation
7.1.1: Run a scheduled automated network backup based on data and system recovery requirements
7.1.2: Document and test the restore process annually
7.1.3: Ensure backups are encrypted in transit and at rest

YALE-MSS-7.2: Encrypt all electronic storage devices

MSS Guidelines	ITS Linux Implementation
7.2.1: Utilize full disk encryption
7.2.2: Encrypt portable storage devices
7.2.3: Be able to provide evidence that an electronic storage device is encrypted

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

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

MSS Guidelines	ITS Linux Implementation
7.4.1: Securely dispose of devices using the Yale Environmental Health and safety process

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

MSS Guidelines	ITS Linux Implementation
7.5.1: Fully sanitize devices, by device type
7.5.2: Follow the University Chain of Custody process for devices being re-used or disposed of

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

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

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

YALE-MSS-7.9: Use inactivity locks

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

YALE-MSS-7.11: Use secure Bluetooth

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

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

YALE-MSS-8

YALE-MSS-8: Application Development Security

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

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

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)

YALE-MSS-9.3: Utilize secure passwords for authentication

MSS Guidelines	ITS Linux Implementation
9.3.1: Change all account usernames and passwords from defaults
9.3.2: Align (or surpass) password security to align with the current requirements for Net ID credentials
9.3.3: Lock mobile devices with a password, passcode or pin
9.3.4: Prohibit password, passcode, or pin reuse for a specified number of generations
9.3.5: Do not reuse passwords

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

MSS Guidelines	ITS Linux Implementation
YALE-MSS-9.4.1: Review all accounts with access to the system to ensure least privilege is applied
YALE-MSS-9.4.2: Maintain an inventory of all privileged and service accounts and assigned privileges

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

MSS Guidelines	ITS Linux 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
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 account
9.5.3: Identify dormant accounts and remove them on a regular basis

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

YALE-MSS-9.7: Use University approved authentication methods

MSS Guidelines	ITS Linux Implementation
9.7.1: Web applications are required to use Yale credentials to utilize the University's Approved Single Sign On methods
9.7.2: For non-web applications, use Yale’s central Active Directory services. LDAP is not approved.

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

MSS Guidelines	ITS Linux Implementation
9.8.1: Document secrets management decisions and operational practices

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

MSS Guidelines	ITS Linux Implementation
9.9.1: Use industry standard authentication protocols

YALE-MSS-9.10: Prevent brute force attacks

MSS Guidelines	ITS Linux Implementation
9.10.1: Implement rate limiting or failed authentication lockouts

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

MSS Guidelines	ITS Linux 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-party

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

MSS Guidelines	ITS Linux 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.
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.

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

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

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

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 Guidelines	ITS Linux Implementation
11.1.1: Ensure all staff are informed, understand their roles and responsibilities, and complete assigned security training requirements

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

MSS Guidelines	ITS Linux 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

YALE-MSS-12

YALE-MSS-12: Intrusion Detection

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

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

MSS Guidelines	ITS Linux Implementation
12.2.1: Control inbound and outbound traffic
12.2.2: Log and filter traffic to identify and protect against potential threats
12.2.3: Document your required firewall rules

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

YALE-MSS-13

YALE-MSS-13: Logging

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

MSS Guidelines	ITS Linux Implementation
13.1.1: Use multiple time servers
13.1.2: Ensure client IP addresses are not obscured by load balancers and reverse proxies
13.1.3: Ensure adequate space to log data. Logs should be kept for a minimum of 90 days.

YALE-MSS-13.2: Log all authentication events

MSS Guidelines	ITS Linux Implementation
13.2.1: Collect logs that include all authentication and privileged escalation events

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

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

MSS Guidelines	ITS Linux Implementation
13.4.1: Identify, track, and periodically audit source systems for compliance with all applicable laws, regulations, and University policies, standards, and procedures
13.4.2: Collect log data needed for Information System Activity Review

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

MSS Guidelines	ITS Linux 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

2023 MSS for a Managed Linux System

YALE-MSS-1: System Classification

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

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

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

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

YALE-MSS-1.5: Plan for data recovery requirements

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

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

YALE-MSS-2: System Inventory

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

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

YALE-MSS-3: Disaster Recovery (DR)

YALE-MSS-3.1: Create a Disaster Recovery Plan

YALE-MSS-3.2: Test the Disaster Recovery Plan

YALE-MSS-4: Physical Security

YALE-MSS-4.1: Physically secure Critical IT Spaces

YALE-MSS-4.2: Physically secure the IT System

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

YALE-MSS-5: Software Security

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

YALE-MSS-5.2: Utilize endpoint protection

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

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

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

YALE-MSS-6: Patching

YALE-MSS-6.1: Apply security patches regularly

YALE-MSS-7: Data Protection

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

YALE-MSS-7.2: Encrypt all electronic storage devices

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

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

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

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

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

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

YALE-MSS-7.9: Use inactivity locks

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

YALE-MSS-7.11: Use secure Bluetooth

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

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

YALE-MSS-8: Application Development Security

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

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

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)

YALE-MSS-9.3: Utilize secure passwords for authentication

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

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

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

YALE-MSS-9.7: Use University approved authentication methods

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

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

YALE-MSS-9.10: Prevent brute force attacks

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

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

YALE-MSS-10: Network Exposure

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

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

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

YALE-MSS-11: Security Training

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

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

YALE-MSS-12: Intrusion Detection

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

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

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

YALE-MSS-13: Logging

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

YALE-MSS-13.2: Log all authentication events

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

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

YALE-MSS-14: Security Incident Reporting

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

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

^{YALE-MSS-1: System Classification}