Policy for System Asset Administration

By default, all computers and related assets owned and operated by the College are managed by Engineering Technology Services. The ETS service portal includes the ETS Service Catalog as well as related documentation and links to request help and services.

To effectively and efficiently manage the large number of College assets, ETS has a suite of standard offerings. These offerings are consistent with the policies, standards, and practices of the College and University. Specifically, they are designed to meet the Information Security Policy (ISP) and its affiliated standards and controls. ETS also manages to the requirements of 3^rd party contracts, statutes, and regulations that may be attached to specific research projects.

Assets that are managed by ETS are referred to as “ETS-managed”.

There are two situations where an asset may be managed by the asset’s custodian (or their designee).

1. If ETS management tools inhibit a specific business need of the researcher.
2. If the asset itself has an attribute outside the scope of the suite of ETS service offerings.

Example 1: A researcher is performing kernel-level development on a Linux system. The management system utilized by ETS is incompatible with that level of system modification. Therefore, ETS management would prevent the research from being conducted.

Example 2: A researcher has a software application that requires an unsupported operating system such as Windows 7. The application cannot be updated and there is no suitable alternative. Since Windows 7 is end-of-life and no longer supported by Microsoft, it is not possible for ETS to manage the device in a way that is compliant with University policy.

Assets that are not managed by ETS are referred to as “self-managed”.

Self-managed assets are still subject to all security controls mandated by the College, University, and all applicable 3^rd party contacts, statues, and regulations.

NOTE: Assets that are subject to a Technology Control Plan (TCP) by Export Control are not candidates for self-management.

Regardless the management state of an asset, it must be maintained in a state of compliance. ETS is fully responsible for ETS-managed assets. ETS and the asset custodian share responsibility for self-managed assets as follows.

Compliance requirements are based on the University’s Information Security Policy and related documents.

By default, all system assets are managed by ETS. ETS is a limited resource and thus has a defined service offering.

Account Management Services: ETS provides directory services for ETS-managed endpoints via an active directory called “COEIT”. Connected to the central OSU Identity Management Service, accounts for all COE affiliated are automatically provisioned in COEIT and are added to groups based upon their affiliation, allowing users to access many resources based solely upon the unit(s) they represent. ETS is responsible for the full account life cycle on ETS-managed assets.

ETS also manages administrative accounts and their lifecycle. In some cases, a user may require admin privileges to an asset. ETS and OSU follow the principals of least privileges (POLP) and the separation of elevated privileges from normal accounts. POLP is required by ISCR DAT 2.2. In ETS it is applied by requiring all login sessions to run from a standard (non-privileged) account and only those specific process that require administrative privileges to run in an elevated state (Windows “run as” or Linux “sudo”). This limits the scope of access a compromised process may acquire.

Admin accounts may be requested on the ETS service portal.

Asset Management including Procurement: ETS manages the full lifecycle of ETS-managed assets. From procurement through decommissioning, the University requires specific controls on its inventory. There are compatibility requirements for all ETS services (such as having up to date TPM modules, “keep your hard drive” agreements, and active updates from vendors). All asset acquisitions must start with a service request submitted through the ETS service portal. Likewise, any time an asset is moved or decommissioned, a service request must be submitted prior to the action.

Client Services: ETS offers direct support for its customers via dedicated staff in its Client Services group. Client Services can be engaged online, on the phone, or in person. Contact details are provided on the ETS service portal.

Endpoint Management: ETS provides full management of the endpoint’s operating system including updates and patching. Patching is performed monthly during the ETS maintenance window. All assets are patched and may be rebooted at this time. If rebooting an asset would interrupt a long-running process, an exception from the patching cycle may be requested through the ETS service portal. A second request may be made if the process continues to run into a second maintenance window, but no asset can be left without patches for more than 90 days so a 3^rd exception cannot be granted.

Note: ETS only supports a single operating system per asset. Dual-boot operating systems, or guest operating systems supported by virtualization software, cannot be managed in a fashion that guarantees compliance with University and College requirements. For this reason, multi-OS systems are unsupported.

Network Services: ETS provides wired network connectivity to all offices and labs in ETS-managed buildings (note that ETS does not manage the Pelotonia Research Center). Each connection in a room can be connected to one of several networks such as: trusted, untrusted, restricted, and printers. It can be connected to only one such network at a time.

Network services also provides a firewall for network access control to OSUNET and beyond, and a VPN for in-bound connectivity from those networks to ETS-managed assets.

Remote Access: Where required by a business purpose, ETS provides remote access. A VPN is provided as the entry for all such connections. The specifics of the VPN are detailed in an external document linked in the Supporting Documents and Additional Information section of this document. In addition to the VPN, connection tools are limited to an approved set. For access to a Windows asset, this is Remote Desktop Protocol, and for Linux-based assets, SSH. For remote windowing systems, OSU provides FastX for Linux assets. Note that TeamViewer and similar 3^rd party tools that are well documented as having active security vulnerabilities, violate the University and College standards and practices and are not allowed.

Risk and Compliance Services: ETS is responsible for all risk and compliance issues on ETS-managed endpoints. In part, this includes:

• Data Loss Prevention
• Enhanced Endpoint Protection
• Intrusion Detection
• Intrusion Prevention
• Local Firewall
• Remote System Logging
• Vulnerability Management

Risk and Compliance coordinates all security incident responses, vulnerability management, endpoint protection operations, and compliance with the Colleges IT responses to the ISCR.a and Audit.

Server Hosting: ETS provides racked server hosting in several locations. Some locations include physical access for users who may need to touch their asset. Note that all servers with TCPs are located at the SOCC and only ETS staff have access to that facility. Further note that OSU Internal Audit determined in a past audit that all servers, as defined by the ISCR (by function rather than form factor), require secure housing. The College provides this housing in the ETS-managed data centers. There are several requirements for the physical attributes of an asset to be placed in an ETS-managed data center. These requirements are detailed in a separate document that is linked in the Supporting Documents and Additional Information section of this document.

Server Management: ETS and OTDI provide services that, if run on a College asset, might trigger the ISCR to reclassify an endpoint as a server. These include:

• License Servers
• Message (Email, Teams)
• Storage (OneDrive, ETS provided storage)
• Web Services of several varieties

The management burden on ISCR defined servers is greater than ISCR endpoints. Therefore, ETS does not support services on ETS-managed assets that are redundant to those provided elsewhere. Any person considering a “server” purchase, must consult with ETS to discuss existing offerings that may already address the business need.

Some ETS service offerings are restricted to ETS-managed assets including storage and directory services.

Note that the ISCR define a “server” based on the services that run upon the asset. Thus, a laptop that is serving files across the network would be considered a server for compliance purposes. An asset with a physical server format (rack mounted, etcetera) that is effectively used as a remote-access workstation without providing networked services, might be considered an endpoint.

Software Services: Third party software is supported to the point of installation and confirmation that the software “runs”. ETS does not provide support in the use of the software. Software license servers are also maintained for the College. New software requests can be made through the ETS service portal. For Windows systems, many packages are available through the native “Software Center” tool.

All software purchases and installations must start with a service request through the ETS service portal. In addition to ETS support, this engages the reviews of all contracts, terms and conditions, and related materials as required by OSU Business and Finance. It also engages an accessibility assessment as required by the OSU ADA Coordinator’s Office and for cloud subscription services, a security assessment.

By default, all system assets are managed by ETS. If an asset triggers an exception state as defined previously, ETS still provides a subset of services for that asset.

Asset Management including Procurement: ETS does not manage the full lifecycle of self-managed assets but it is responsible for coordinating inventory and related functions. Additionally, there are certain hardware requirements for self-managed machines (such as having up to date TPM modules, “keep your hard drive” agreements, and active updates from vendors). All asset acquisitions including those intended to be self-managed must start with a service request submitted through the ETS service portal. Likewise, any time an asset is moved or decommissioned, a service request must be submitted prior to the action.

Client Services: ETS offers limited support for self-managed assets via dedicated staff in its Client Services group. Client Services can be engaged online, on the phone, or in person. Contact details are provided on the ETS service portal.

Network Services: ETS provides wired network connectivity to all offices and labs in ETS-managed buildings (note that ETS does not manage the Pelotonia Research Center). Each connection in a room can be connected to one of several networks such as: trusted, untrusted, restricted, and printers. It can be connected to only one such network at a time.

Self-managed assets are placed on untrusted networks. There are two such networks. The first contains assets that do not require access from the outside world. The second contains assets that do require access from the outside world. An example of such an asset would be a research asset that runs a web service that is required for a business need and cannot be met with an existing ETS or University offering. External access to self-managed assets is restricted at the College’s border firewall. Only those ports that are required to support a specific business need are opened.

Note: Any asset found to be non-compliant may be removed from the network. Reasonable attempts will be made to contact the custodian or their designated admin, but some risk and compliance related issues require prompt responses. The mechanism for removing non-compliant assets from the network is to turn down the network port(s) to which it is connected. If the port is shared with other devices, this may remove those devices from the network at the same time. Service will be restored as soon as is reasonable after the risk and compliance related issue is addressed.

Remote Access: ETS provides remote access to those assets which require it for the business purpose. A VPN is provided as the entry for all such connections. The specifics of the VPN are detailed in an external document that is linked in the Supporting Documents and Additional Information section of this document. In addition to the VPN, connection tools are limited to an approved set. For access to a Windows system, this is Remote Desktop Protocol, and for Linux-based systems, SSH. For remote windowing systems, OSU provides FastX for Linux systems. Note that TeamViewer and similar 3^rd party tools that are well documented as having active security vulnerabilities, violate the ISCR and are not allowed, even on self-managed assets. Self-managed assets must still be ISCR compliant.

Risk and Compliance Services: ETS is responsible for all reporting on risk and compliance issues on self-managed endpoints. ETS also acts as the interface between DST (Digital Security and Trust… the IT “security” segment of OTDI) and the asset custodian. Certain tools must be installed and/or configured on self-managed assets. In part, these include:

• Data Loss Prevention
• Enhanced Endpoint Protection
• Intrusion Detection
• Intrusion Prevention
• Remote System Logging
• Vulnerability Management

The specifics of the required tools are detailed in an external document linked in the Supporting Documents and Additional Information section of this document.

Risk and Compliance coordinates all security incident responses, vulnerability management operations, and compiles the Colleges IT responses to the ISCR.a and Audit.

Server Hosting: ETS provides racked server hosting in several locations. Some locations include physical access for users who may need to touch their asset. Note that all servers with a TCP are located at the SOCC and only ETS staff have access to that facility. Further note that OSU Internal Audit determined in a past audit that all servers, as defined by the ISCR (by function rather than form factor), require secure housing. The College provides this housing in the ETS-managed data centers. There are several requirements for the physical attributes of an asset to be placed in an ETS-managed data center. These requirements are detailed in a separate document that is linked in the Supporting Documents and Additional Information section of this document.

Self-managed servers are eligible for the server hosting service.

Server Functions: ETS and OTDI provide services that, if run on a self-managed asset, might trigger the ISCR to reclassify an endpoint as a server. These include:

• License Servers
• Message (Email, Teams)
• Storage (OneDrive, ETS provided storage)
• Web Services of several varieties

The management burden on ISCR defined servers is greater than ISCR endpoints and some of these services are restricted to designated service providers at the University. For example, no one may offer email services. Any person considering purchasing or configuring a “server,” must consult with ETS to discuss existing offerings that may already address the business need.

Note that the ISCR defines a “server” based on the services that run upon the asset. Thus, a laptop that is serving files across the network would be considered a server for compliance purposes. An asset with a physical server format (rack mounted, etcetera) that is effectively used as a remote-access workstation without providing networked services, might be considered an endpoint.

Software Services: ETS does not provide direct software support on self-managed assets, however software license servers are also maintained for the College. New software requests can be made through the ETS service portal.

All software purchases must start with a service request. In addition to ETS support, this engages the review of all contracts, terms and conditions, and related materials as required by OSU Business and Finance. It also engages an accessibility assessment as required by the OSU ADA Coordinator’s Office.

ETS does not offer these services to self-managed assets:

• Account Management
• Endpoint Management

When an asset is designated as self-managed, the asset custodian, usually the faculty member or researcher who designated the funds used by the University to purchase the device, assumes responsibility for all the following:

• All policies, standards, and practices of The Ohio State University
• All policies, standards, and practices of The College of Engineering
• All external control requirements, including but possibly not limited to:
  • Government statues and regulations
  • Contractual requirements

The assumed responsibility includes having a full understanding of all such requirements and implementing them as practiced at the University and the College; working with ETS to establish a compensating control; or working with ETS to request an exception.

Links are provided in the Supporting Documents and Additional Information section of this document for some of the more common policies and documents.

For all self-managed assets, the custodian shall do the following:

Assertion of Compliance: Every year, the College is required to submit the ISCR.a, an assessment of compliance with the ISCR. ETS submits the ISCR.a on behalf of the College and answers for all ETS-managed assets. The custodian of each self-managed asset must answer for each of their individual assets. Designated administrators may not substitute for custodians on this assertion. ETS will solicit these assertions through email to the asset custodian’s OSU email address. It will provide that year’s assessment criteria and a required submission date that the data may be included in the College’s ISCR.a response. ETS will remove any self-managed system from the network if an ISCR.a assertion has not been submitted by the required date.

In addition to the annual assertion of compliance, an “Initial Assertion of Compliance” is required for all self-managed devices. This document is linked in the Supporting Documents and Additional Information section of this document.

Designated Admin: The custodian is ultimately responsible for the asset but may designate an administrator for the asset. The designated admin does not replace the custodian as the responsible party but can perform the following duties. If there is no designated admin, then the duties remain the responsibility of the asset custodian.

• ETS Liaison – ETS staff will need someone to contact regarding the asset. Email and phone numbers must be provided. The designated admin is expected to respond to all ETS communications no later than the next business day. Often these contacts relate to risk and compliance issues and a timely response is necessary. If the issue constitutes a threat to other assets, it will be isolated from the network until the issue is resolved.
• Ensure compliance – The designated admin is responsible for compliance including, but not limited to, the ISCR.
• Receive and respond to vulnerability reports, performing corrective actions as directed – ETS and DST have several automated scanning systems and related detection systems. These systems generate vulnerability reports which are provided to ETS staff. When ETS staff identify an issue with a self-managed asset, this vulnerability will be shared with the designated admin. Most issues have a 30-day remediation window. Issues not resolved within their remediation window may trigger additional actions by ETS including the possibility of having the asset isolated from the network.

If the designated admin changes, the asset custodian is responsible for informing ETS of the change.

Access to the self-managed asset: ETS and OSU have a set of risk and compliance tools that are run on or against all endpoints at the University. Assets that are self-managed may still need to provide access for these tools. Some examples of the tools used are EEP (Enhanced Endpoint Protection, what would have formerly been referred to as anti-virus or anti-malware), DLP (Data Loss Prevention), IDP (Intrusion Detection/Prevention), Vulnerability Management, and SIEM (Security Information and Event Management). The specifics on the tools and how they are integrated into self-managed assets is detailed in a document linked in the Supporting Documents and Additional Information section of this document.

A self-managed asset must be compliant with the policies, standards, practices, statutes, and regulations applicable as listed above plus any that may not be listed. This is the responsibility of the asset’s custodian. The following is a set of clarifications on a subset of these compliance requirements.

COMPLIANCE

ISCR: All University assets, including those that are self-managed, must be compliant with all ISCR IT controls. Some details that may assist with compliance:

• ISCR is a living document – The ISCR is updated frequently. It is the responsibility of the asset custodian or their designated admin to keep current with all updates and adapt their compliance as required by the current set of controls.

• ISCR controls change based upon the S-level (security level) and C-level (criticality level) of the information and system assets. Knowing these levels is required to know which controls are applicable to a given asset. The IRMF Glossary is a useful job aid for evaluating these factors.

• Endpoint vs Server – The ISCR define any device that provides data or services to another asset as a server. Some examples include traditional file servers, print servers and directory servers. Note: an asset that might otherwise be classified as an endpoint would be classified as a server through the simple act of sharing local files or attached printers to another device across the network. The ISCR section that applies to servers is generally more stringent than that which applies to an endpoint. A server is defined by its networked services rather than its physical form factor.

• Account Management including Administrative Rights and Password Standards and Rotations: All assets require access control. Per the ISCR this is generally accomplished with passwords. All accounts must have a unique password that meets the standards of the ISCR including length, complexity, and maximum life span. This is a manual process on self-managed assets. The mechanism selected must be documented and followed. Note: accounts and passwords are not shareable assets. There are specific instances where a “shared account” may seem necessary. Before implementing a shared account, the asset custodian or their designated admin must contact ETS to discuss the circumstances to see if there is another mechanism that accomplishes the business task. If it is determined that a shared account is required, it must be documented.
  • In some cases, a user may require admin privileges to an asset. Engineering and OSU follow the principals of least privileges (POLP) and the separation of elevated privileges from normal accounts. POLP is required by ISCR DAT 2.2. At OSU it is applied by requiring all login sessions to run from a standard (non-privileged) account and only those specific process that require administrative privileges to run in an elevated state (Windows “run as” or Linux “sudo”). This limits the scope of access a compromised process may acquire.

• Supported Assets and Configurations – The ISCR has an entire section on requirements for client systems and another for server systems. Highlighted details:
  • Assets must be configured to provide only the essential capabilities necessary to support the business purpose of the asset.
  • Assets must have current, vendor-supported operating systems, software, and firmware. All security related patches must be applied, and other patches generally should be applied.
  • Once updates are no longer available, there may be compensating controls possible to allow an asset to remain in service if there is a business need that cannot be met otherwise. The asset custodian must engage ETS to discuss and design appropriate controls and register all required exceptions with the University. Otherwise, the asset must be retired.
  • Assets must log specific actions as detailed in the ISCR. These logs must be forwarded to the centralized logging system.

• Host-based Firewall – The ISCR requires defense in depth. A border firewall is complemented by a required local, host-based firewall. This firewall must be configured default-deny and only those services as are specifically required by the asset allowed access to the network.

• Remote Access – The ISCR has specific requirements for remote access to assets. Remote connections must be encrypted using a VPN and use specific software. ETS provides a VPN service which must be used for all remote connections. Allowed protocols include SSH and RDP. For Linux-based windowed environments, the university provides FastX. Most other remote connectivity software is not allowed. This specifically includes TeamViewer which has been repeatedly shown to be an active security risk. Should RDP and FastX not meet a business need, the asset custodian or designated admin must engage ETS to discuss the need and how it might be met in a compliant manner before an alternate connection mechanism is utilized.

• Vulnerability Management – The ISCR requires that vulnerabilities be identified and managed. Some management tools are maintained by ETS and DST and can be applied to self-managed assets. Some of these are specifically required and are detailed in a document linked into the Supporting Documents and Additional Information section of this document.

Note: the ISCR apply to all equipment regardless of network connection. If an asset is attached to an ETS-managed network, an OTDI-managed network, EDUROAM, OSUWireless, or no network at all, the ISCR still apply. Changing network connections may be part of a compensating control or exception, but all such deviations from the control requirements must be documented and registered.

Incident Response: ETS has a Self-managed Asset Incident Response Plan that must be followed by all asset custodians, designated admins, and users.

Multi-OS Systems (Virtual and Dual-boot): Multi-OS systems are prohibited on COE system assets regardless of management state. These systems pose significant risks to data integrity, system stability, and cybersecurity. Such configurations increase the attack surface, making system assets more vulnerable to malware, data breaches, and unauthorized access. ETS has a support model for Docker-based containerization and OSU offers a container-based service offering. A service request can be submitted to the ETS service portal to initiate a discussion on how these service can alleviate the perceived need for a multi-OS system.

Software Licensing and Digital Accessibility: Even on self-managed assets, all software purchases and installations must start with a service request through the ETS service portal. In addition to ETS license server support, this engages the reviews of all contracts, terms and conditions, and related materials as required by OSU Business and Finance. It also engages an accessibility assessment as required by OSU ADA Coordinator’s Office. This includes “free” software and any installers that utilize “click-through” licensing. The University does not extend the right to agree to contract terms, even those from simple software installs, to University personnel outside the central administrative offices.

3^rd Party Hosted and Cloud-based Assets: ETS does not manage assets hosted outside the College. Most use cases fall under “cloud” scenarios. Any person engaging a cloud service must first confirm that the service has been approved for their specific use case. An entry found on the Cloud Assessment Registry does not mean that the service is available for all use cases. If the service does not appear on the registry, or if it is not known if the existing registry entry applies to the current use case, an assessment request must be made with a service request through the ETS service portal. After the service is approved, it must still be utilized in a way that is compliant with all applicable policies, standards, practices and so on.

User Education: It is the responsibility of the self-managed asset’s custodian to ensure that users of their asset are aware of their responsibilities toward the compliant use of the asset.

All network equipment attached to the ETS-managed network must be managed by ETS. No self-managed network devices are permitted. This includes but is not limited to routers, switches, bridges, bastion hosts (aka jump hosts), firewalls, and VPN.

The purpose of ETS is to enable the business functions of the College in a compliant manner. Should a section of this policy conflict with the required business functions of a person/project within the College, an exception to this policy or its contents can be requested through the ETS service portal.