Versions Compared

Version Old Version 2 New Version Current
Changes made by

Nancy Braen

Nancy Braen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Table of Contents

...

Panel
titleColorwhite
titleBGColor#0F4D92
titleMSS 1

YALE-MSS-1: System Classification

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

Info
iconfalse

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 DetailsITS 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 AccessibleThe 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 systemThe 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 partiesThe 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 requirementsThe 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 metIt 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 

Info

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 DetailsITS Linux 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; 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

Info

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 DetailsITS Linux 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 

Info

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 DetailsITS 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 basisThe 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 

Info

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 DetailsITS 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 

Info

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.

...

Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-MSS-5

YALE-MSS-5: Software Security

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


MSS GuidelinesITS 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 twice per day to keep systems aligned with industry best practices.

The automation code serves as the documentation.

5.1.2: Utilize file integrity and configuration checking toolsSystems 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 

ITS Linux doesn't install antivirus on managed servers
MSS GuidelinesITS Linux Implementation
5.2.1: Utilize a Next Generation Anti-Virus solutionYale currently employs the Crowdstrike Falcon software. 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) tool

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

YALE-MSS-5.4: Ensure
Yale currently employs the Crowdstrike Falcon software. 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 Linux runs supported software and operating systems.

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

ITS Linux ensures 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 GuidelinesITS Linux Implementation
5.5.1: All changes to the IT system are analyzed to ensure the security posture is not weakened5.5.All changes to the IT system are vetted by the Change Advisory Board 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.



...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-MSS-6

YALE-MSS-6: Patching

YALE-MSS-6.1: Apply security patches regularly 



MSS GuidelinesITS Linux Implementation
6.1.1: Apply all security patches to operating systems, software, and firmware based on risk

ITS Linux applies operating system patches via automation twice monthly. Any software patches not included in that process are applied quarterly.

6.1.2: Identify maintenance windows for necessary upgrades/patches6.1.3: Maintenance windows are agreed to with the customer when a new system is built. If the system being built is a replacement system, the existing patch schedule is kept.
6.1.3: Implement an emergency patch processEmergency patches are installed as soon as possible in coordination with ISO and the customer.



...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-MSS-7

YALE-MSS-7: Data Protection

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


MSS Guidelines
MSS GuidelinesITS Linux Implementation
7.1.1: Run a scheduled automated network backup based on data and system recovery requirements7.1.2: Document and test the restore process annually

A managed Linux 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.

7.1.3: Ensure backups are encrypted in transit and at rest

YALE-MSS-7.2: Encrypt all electronic storage devices 

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 Linux 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 encrypted

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

The 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 Linux physical server where applicable.


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 GuidelinesITS Linux Implementation
7.4.1: Securely dispose of devices using the Yale Environmental Health and safety processDisposal of devices managed by the Managed Servers - Linux team is handled by the Data Center Facilities group upon request.

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

MSS GuidelinesITS Linux Implementation
7.5.1: Fully sanitize devices, by device type7.5.2: Follow the Any physical managed Linux system is fully wiped before reuse using the DOD disk wiping software where applicable. Linux 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 Linux:

  • 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

YALE-MSS-

Linux 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 Linux Servers.

YALE-MSS-7.9: Use inactivity locks 

Application owners should research and apply inactivity locks suitable for their application security level.

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

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

YALE-MSS-7.11: Use secure Bluetooth

YALE-

This is not applicable to Managed Linux Servers.

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

This is not applicable to Managed Linux Servers.

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

This is not applicable to Managed Linux Servers.


...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-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 Linux Servers.

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

Managed Linux 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.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 

Linux Administrators have user accounts across all systems. Work is done using these accounts, with access to escalate privileges if needed. Other groups/users are given access if applicable. Access is managed through automation and has a standardized level of access. Automation tool users and Jenkins users are created via automation software for use of configuration management and deployments of the application via the Jenkins software respectively. Other service accounts are created for specific use and restricted for that purpose.

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

The Linux Team does not share user accounts.

YALE-MSS-9.3: Utilize secure passwords for authentication


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-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 GuidelinesITS Linux Implementation
9.3.1: Change all account usernames and passwords from defaults9.3.2: Align (or surpass) password security to align with the current requirements for Net ID credentials9.3.3: Lock mobile devices with a password, passcode or pin9.3.4: Prohibit password, passcode, or pin reuse for a specified number of generations9.3.5: Do not reuse passwords
MSS GuidelinesITS Linux Implementation
YALE-MSS-9.4.1: Review all accounts with access to the system to ensure least privilege is appliedYALE-MSS-9.4.2: Maintain an inventory of all privileged and service accounts and assigned privileges
MSS GuidelinesITS Linux Implementation
9.3.1: Change all account usernames and passwords from defaults

The Linux Team changes all default passwords upon creation or installation of a service or device.

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

Access to Linux servers utilizes PKI (public/private keys).

Application teams are responsible for setting password complexity.

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

Access to Linux servers utilizes PKI (public/private keys).

Application teams are responsible for setting password reuse policy.

9.3.5: Do not reuse passwordsAccess to Linux servers utilizes PKI (public/private keys).

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


MSS GuidelinesITS Linux Implementation
YALE-MSS-9.4.1: Review all accounts with access to the system to ensure least privilege is appliedThe Linux 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 Linux 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 


MSS GuidelinesITS 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

If the user whose role is changing is a member of the Linux Team, a change request is submitted by the Manager of the Linux 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 Linux 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 Linux Team changes roles or is terminated, the Linux Team will roll the root password and the password to Keepass.
9.5.3: Identify dormant accounts and remove them on a regular basisThe Linux 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

ITS Linux uses SSH with public key authentication.

YALE-MSS-9.7: Use University approved authentication methods 

MSS GuidelinesITS Linux Implementation
9.
5
7.1:
Ensure accounts are deprovisioned or altered to reflect necessary access when an individual's role or responsibilities change or a user is terminated9.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 account9.5.3: Identify dormant accounts and remove them on a regular basis
Web applications are required to use Yale credentials to utilize the University's Approved Single Sign On methodsThe Linux 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 Linux Team is not responsible for authentication to applications.

YALE-MSS-9.

6: Require Multifactor Authentication (MFA) for access to authenticated systemsYALE-MSS-9.7: Use University approved authentication methods 

8: Secure and/or limit storage of authentication information 

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

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

MSS GuidelinesITS Linux Implementation
9.
7
8.1:
Web applications are required to use Yale credentials to utilize the University's Approved Single Sign On methods9.7.2: For non-web applications, use Yale’s central Active Directory services. LDAP is not approved
Document secrets management decisions and operational practices

Decisions are documented in Confluence and appropriate repositories.

Work is logged in ServiceNow.

YALE-MSS-9.

8: Secure and/or limit storage of authentication information 

9: Allow only encrypted network protocols for authentication 

MSS GuidelinesITS Linux Implementation
9.
8
9.1:
Document secrets management decisions and operational practices

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

MSS GuidelinesITS Linux Implementation
9.9.1: Use industry standard authentication protocolsUse industry standard authentication protocols

Managed Linux uses only the secured ports which is "https" (443) and we always recommend end-to-end encryption for applications. Protocols and ciphers are reviewed periodically and adjusted where needed. For Linux administrators, SSH private/public key infrastructure is used for access to all Linux systems.

YALE-MSS-9.10: Prevent brute force attacks 

MSS GuidelinesITS Linux Implementation
9.10.1: Implement rate limiting or failed authentication lockoutsThe Linux Team does not currently have any controls to prevent Brute Force attacks.

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

MSS GuidelinesITS 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-partyAny privilege account escalation is performed by the Managed Servers Linux team.  Access to escalate one's own privilege is not accessible to users.

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 Linux system. Linux administrators log in using their own ID and any account privilege escalation is logged via system logs.

MSS GuidelinesITS 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.Where applicable, Linux disables direct login to service & shared accounts in favor of user login with switch user privileges.
9.12.2: Do not allow direct logins to accounts with administrative privileges. Require users to log in with an individual account and log in with an individual account and escalate privileges.ITS Linux requires login with NetID and then escalate privileges.



...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-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 

Network Exposure

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

All the securities are behind the Yale 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.

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

On RHEL8, firewalld is enabled and only ssh and nrpe are allowed. Any additional ports that need to be opened must authorized by the team and the application owner and set through configuration management.

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

Network traffic is logged and ports are opened as needed by the Linux Managed servers team through configuration management once the ports have been approved by both teams.

Host based firewalls are applied when necessary. They are default on RHEL8.


...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-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 Linux Implementation
11.1.1: Ensure all staff are informed, understand their roles and responsibilities, and complete assigned security training requirements

The Linux Manged servers team is informed, trained, and understand their roles

and responsibilities, and complete assigned security training requirements

and responsibilities through constant peer and managerial review.

The Linux 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 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 YaleRequire 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 Linux Managed servers team defers to the procurement team to ensure that third parties are compliant.

It is not the responsibility of the Linux 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.



...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-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 possibleof access possible

All the systems are behind firewall.

MSS GuidelinesITS Linux Implementation
12.2
.1: Control inbound and outbound traffic
.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 on the linux servers that control 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. Access to the system directly is logged in /var/log/messages & /var/log/secure. Crowdstrike is installed to further identify threats.
12.2.3:
Document your required firewall rules
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.

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

The ISO team manages the Intrusion Protection System.


...


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

Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-MSS-13

YALE-MSS-13: Logging

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

MSS GuidelinesITS Linux Implementation
MSS GuidelinesITS Linux Implementation
13.1.1: Use multiple time serversThe Linux Manged servers team uses clock1.net.yale.edu, clock2. net.yale.edu and clock3.net.yale.edu as time sources.
13.1.1: Use multiple time servers13.1.2: Ensure client IP addresses are not obscured by load balancers and reverse proxies2: Ensure client IP addresses are not obscured by load balancers and reverse proxies

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

By default, all VIPs in the load balancer have X-Forwaded-For (XFF) enabled so that source ip addresses can be identified.

A project is ongoing to remediate all outstanding VIPs that do not have XFF enabled.

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.

Logs are only kept for 30 days in Graylog.

YALE-MSS-13.2: Log all authentication events 

Users logging to systems are tracked in audit.log file

MSS GuidelinesITS Linux Implementation
13.2.1: Collect logs that include all authentication and privileged escalation eventsevents

Users logging to systems are tracked in /var/log/secure file

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 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

The Linux Manged servers team does not currently have a process to audit all Linux servers.

Specific servers (i.e. Banner) are audited by a third party annually.

13.4.2: Collect log data needed for Information System Activity ReviewData is collected in /var/log/secure and in a central logging system. It includes all necessary information for a Security Activity Review and is available on-demand.



...


Panel
titleColorwhite
titleBGColor#0F4D92
titleYALE-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 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 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

It is not the responsibility of the Linux Manged 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.