GP.Facilities Monitoring
Page maturity This page has maturity level 3 (usable) |
GP | Facilities Monitoring | Version: | 0.4 | ||
---|---|---|---|---|---|
Document type: | Generic Pattern | Owner: |
This Pattern helps Operations and Security personnel to monitor other facilities for noteworthy events. |
Description
This Generic Pattern belongs to "Operations". Realizations of this Pattern can be used monitor other facilities for noteworthy events. This kind of facility is often used to help Operations and Security personnel in their functions.
The Pattern has functionality to trigger reactive management actions, but it can also trigger events pro-actively if patterns of suspect behaviour or suspect state are supplied to the Rules Engine. Therefore, this Pattern covers many use cases, among others:
- Centralized log services, that allow (automated or manual) inspection of system event logs.
- Central system monitoring services provide status information to their users, be they infrastructure administrators and/or service managers;
- Security Incident and Event Monitoring (SIEM) systems, that can alert when a security incident occurs, and report on the security state of the connected facilities.
- Intrusion Detection Systems (IDS), that monitor network or system activities for suspect or malicious activities or policy violations. To this end, the Filtering function of the Pattern is implemented in each facility that's being guarded, to scan the streaming data in those facilities. It is the job of the Rules Engine to match the normalized data with patterns that are identified as suspect or malicious.
- Intrusion Prevention Systems (IPS), that work like IDS systems, but are also capable of shutting down the data streams and/or other activities in the guarded facilities if a suspicious activity or policy violation is detected. Note that in this case the Filtering function does not only provide the Pattern with the information needed to determine intrusion; it also directly interacts with the guarded facility. If an IPS takes more elaborate actions, then you may have to augment this Pattern with matching Generic Functions.
Services realized
This Pattern realizes the following service(s):
- Facilities Monitoring (This service allows its users to monitor IT facilities with the aim of guarding operational continuity or security.)
Functional and Integration view
This is the graphic representation of the functional model of this Generic Pattern:
Generic Pattern Composition
This pattern is an aggregation of the following (mandatory and optional) functions, expressed in Generic Functions:
Icon | Function | Inclusion | Rationale |
Rules Engine | recommended | This function represents the intelligence that drives the services provided by the Pattern. All data collected by the facility should be normalized, and must be investigated for patterns that signal noteworthy security or operational events. Active collection of information, responses caused by incoming information, and ways and means to alert and/or report are all directed by (implicit or explicit) rules. | |
Data Scanning | optional | This function is used to collect data from in transit data traffic (network flows and traffic patterns). | |
Logging | optional | This function is often included, as it enables Facilities Monitoring to monitor (operational or security) events that have occurred in the monitored systems. | |
Status Retrieval | optional | This function enables Facilities Monitoring to monitor parameters that define the status of the monitored systems. | |
Configuration Retrieval | optional | This function can be used to monitor the configuration of the monitored systems, so that any change in a system's configuration can be detected. | |
Configuration Register | optional | If Facilities Monitoring is to monitor system configurations, it may be necessary to compare the detected configuration with a target configuration, and/or to store the detected configuration for reference purposes; for either of these purposes the Configuration Register function can be of use. | |
Scheduling | optional | Scheduling can serve to run monitoring jobs, such as configuration retrieval, on regular or predetermined times | |
Reporting | recommended | This function creates and delivers the reports that reflect the operational and security state of the monitored facilities. | |
Alerting | optional | This function delivers warning messages and/or signals that are triggered by the processing of all manners of (combinations of) detected facility events. | |
Controlling | recommended | If implemented, this function can be used by administrators, and possibly by authorized clients, to change the way the Pattern works. Among the changes that can be made via this function are:
Care must be taken to limit access to this function to authorized systems and users. |
Services connected with this Generic Pattern
This Generic Pattern has the following mandatory and optional relations with adjacent Generic Services.
Service | Adjacency | Summary | Rationale |
Data Management | recommended | This service provides its consumers the ability to manage strictly structured data. | A Facilities Monitoring Pattern is likely to require some sort of structured data store to keep records of the data and events it has collected, reports generated et cetera. |
Authentication & Authorization | optional | This service can validate an identity claim, and it can validate the permissions required for an action, as part of an Authentication & Authorization process. | Access to the services provided by the Facilities Monitoring Pattern is likely to be limited to authorized personnel; furthermore, the Facilities Monitoring system itself may require permissions to be able to collect data from the facilities that it's monitoring |
Applied Patterns based on this Generic Pattern
The following Applied Patterns are based wholly or in part on this Generic Pattern: