Predefined states of operation are documented and can be implemented based on the cybersecurity state of the function or when triggered by activities in other domains

Predefined states of operation are distinct operating modes (which typically include specific IT and OT configurations as well as alternate or modified procedures) that have been designed and implemented for the function and can be invoked by a manual or automated process in response to an event, a changing risk environment, or other sensory and awareness data to provide greater safety, resilience, reliability, and/or cybersecurity. Defining predefined states of operation typically requires use of detailed architectures or topologies, documentation and detailed understanding of your assets and their priorities (ASSET-1c, ASSET-1d), categories (ASSET-2c, ASSET-2d), and attributes (ASSET-1e, ASSET-2e). The defined states might include criteria for invoking the state, such as who has the authority to trigger a state change in either direction, checklists that must be completed before moving from a degraded state to an operational state, how long the organization can survive in a particular state, or how the organization will conduct monitoring to determine when the criteria are met. Information from monitoring activities is used to trigger decisions about invoking the predefined states of operation. For example, if monitoring activities indicate an outage, this might trigger a manual process in which some analysis is done that determines that not all operations can be supported, specific decision makers must sign off on temporarily curtailing nonessential operation, and a predefined state is invoked in which certain assets are shut down. Other situations might make use of an automated process. For example, based on threat intelligence received through monitoring activities (SITUATION-3f), a ruleset triggers an upgrade of the threat level, which triggers invocation of a predefined state that shuts down critical assets. Another example of predefined states of operations could be limiting communications between IT and OT environments during a cybersecurity incident. As another example, high-risk situations may be identified that warrant additional logging, such as a safety-related emergency that requires an immediate elevation of access privileges, but they also may increase the verbosity of logging on affected devices.

Related Practices · Input From: Implementing RESPONSE-3l and THREAT-2J provides input that may be useful for implementing this practice.