Layers
v1.0 · in consultationOperations & Security (OPS)
Layer OPS of Public Framework Modelling Language 1.0 answers the question “How is it operated and protected?”. This page describes the layer's concepts, how they relate, and its 10 element types.
Describes specification v1.0
What the layer describes
The OPS layer answers the question “How is it operated and protected?”. It describes technical operation and recovery: service levels, monitoring, backups, incidents (Incident) and security. Continuity of the public service (PublicService) belongs to CNT.
Concepts and how they relate
A monitor (Monitor) observes an operational condition. Optionally, it triggers an alert rule (AlertRule), and the rule triggers a runbook (Runbook). The relationship is “triggers” (triggering) and connects behaviours and events.
Optionally, a security control (SecurityControl) and a backup policy (BackupPolicy) mitigate risks (Risk), through the “mitigates” relationship (mitigates). So does a disaster recovery plan (DisasterRecoveryPlan), which restores technical systems after a severe disruption. The target of the relationship is a risk, a disruption scenario (DisruptionScenario) or a vulnerability (Vulnerability).
An incident or a vulnerability affects the exposed elements, for example a software system (SoftwareSystem) or a node (Node). The relationship is “affects” (affects).
Element types
The layer has 10 element types, in these families: behaviour (3), information (3), event (3), intent (1). Each type's own fields are listed under its definition; the fields common to every element are described under the core concepts.
ServiceLevelAgreementService level agreement · information familyAn agreement defining operational service-level commitments.
Key attributes:availabilityPercentresponseTimesupportHoursMonitorMonitor · behaviour familyA mechanism or definition for observing an operational condition.
Key attributes:kindtoolregionhorizonProfileexternalReferencemonitorKindsignalqueryobservesverifiesControlsserviceLevelsAlertRuleAlert rule · event familyA condition that raises an operational alert.
Key attributes:conditionseverityregionhorizonProfileexternalReferenceincidentSeveritymonitorsresponseRunbookRunbook · behaviour familyAn operational procedure for handling a defined situation.
Key attributes:regionhorizonProfileexternalReferencepreconditionsprocedureverificationrollbackappliesToBackupPolicyBackup policy · information familyA policy defining backup coverage, scheduling and retention.
Key attributes:frequencyretentioncoversregionhorizonProfileexternalReferencemethodbackupSubjectsdestinationrunbookDisasterRecoveryPlanDisaster recovery plan · information familyA plan for restoring technical systems after a serious disruption.
Key attributes:rtorpolastTestedOncoversregionhorizonProfileexternalReferenceproceduretestOutcometestedAtrestoresbackupPoliciesrunbooksrecoveryLocationIncidentIncident · event familyA recorded operational disruption and its handling.
Key attributes:severitystartedAtresolvedAtreportedToCsirtAtregionhorizonProfileexternalReferenceofincidentSeverityopenedAtclosedAtsummarystatusaffectedElementsdetectedByresponseRunbooksSecurityControlSecurity control · intent familyA safeguard intended to reduce a security risk.
Key attributes:frameworkReferencekindstatusregionhorizonProfileexternalReferencecontrolKindimplementationprotectsVulnerabilityVulnerability · event familyA weakness that can expose software or infrastructure to harm.
Key attributes:cveIdcvssScorestatusOperationalScheduleOperational schedule · behaviour familyA schedule governing recurring operational activity.
Key attributes:regionhorizonProfileexternalReferenceofcronExpressiontimezonekindcronDialectwindowStartwindowEndtargets
In the “Family support benefit” example
Figure 4.9 (page 37) shows the OPS layer in the example. The recovery plan “Benefits technical recovery” mitigates the risk “Risk of unreconciled paper cases”, from X. The plan brings the software system “Benefits case platform” and its data back into service before the paper applications are reconciled. The monitor “Benefit availability monitor” checks the availability of the channel (ServiceChannel) “Public benefit portal”, from ORG, and of the API (API). The monitor raises an operational alert. The monitor observes the platform, and the plan covers and restores it. These links are fields, which is why the platform does not appear in the figure.
