YALE-MSS-2.1.1: Identify and document a current inventory of all components and dependencies

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

YALE-MSS-2.1.1: Identify and document a current inventory of all components and dependencies

Low Risk Endpoint Not Required Moderate Risk Endpoint Not Required High Risk Endpoint Not Required Low Risk Server Not Required Moderate Risk Server Required High Risk Server Required Low Risk Mobile Device Not Required Moderate Risk Mobile Device Not Required High Risk Mobile Device Not Required Low Risk Network Printer Not Required Moderate Risk Network Printer Not Required High Risk Network Printer Not Required

Details

Examples of component information to identify and maintain over time are:

Basic Information

  • Component names and IP addresses (e.g., web-host.yale.edu, 192.168.1.10)
  • Component purposes
  • Locations of components such as Yale West Campus, AWS, Azure, vendor's Cloud, etc.
  • Integrations with other systems 

Detailed Information

  • Authentication and authorization methods used by components (CAS, Shibboleth, DUO, Active Directory, Grouper groups, etc.)
  • Component types, including "physical machine," "virtual machine," and "Docker container"; as well as operating system and version (Windows 11, Linux Redhat 8, etc.)
  • Component storage (local, NetApp, AWS S3 bucket, etc.)
  • Whether a given component resides behind a proxy or load balancer
  • Data flows
  • Major software packages (and version numbers) installed on components (e.g., Apache HTTP Server version 2.4.56)

The system owner is responsible for maintaining the security of the IT system's components. This includes documenting dependencies even if they are managed by another team/individual.

How a system's inventory information is captured and maintained over time is up to the system owner. In some cases, gathering the relevant data may require help from an IT support contact. The inventory should be stored in a secure fashion and kept up-to-date.

Your documentation should cover the following:

  • Necessary facilities
  • Dependent components and integrations
  • Impacts to the IT system in terms of specific component or facility loss
  • Last update date

This documentation is often represented by architectural diagram(s). Architectural diagram(s) are pictures that depict relationships between components.

The value of maintaining this documentation is it:

  • Ensures you revisit the question of dependencies and security posture of those dependencies
  • Ensures you make sure all the components of the IT system are actively managed and responsibilities clearly understood
  • Ensures you can get support, outside opinions, or coverage in the event of a disaster
  • Ensures you have the basis for creating financial plans for the ongoing support of the system