Redundancy: Data history redundancy: How many copies of data history should be retained, where, and for how long?
Options:Option 1: Use a single data history repository
Option 2: Use at least two data history repositories
Option A: Co-located with the plant.
Option B: At multiple locations.
Option C: At multiple locations adequately distant for the common modes of import.
Option D: Where otherwise convenient.
Option U: Until not required for normal business uses.
Option V: Until regulatory mandates are fulfilled.
Option W: Until liability is mitigated.
Option X: Until forensic images made and secured.
Option Y: Until after action reports and related matters are settled.
Option Z: Until identified operational uses end.
Use all rows that apply.
The alternatives come down to Use [one | two | many] data history repositories located [with | separated from] the ICS and each other, and retained until [what condition].
Use a single data history repository well protected from all identified threats.
Use at least two data history repositories.
At multiple locations.
If the data history is used to detect and/or react and adapt to intentional abuse, then there is a need to prevent the alteration of the data history by intruders. This would seem to mandate an append-only storage process and a read-only access process. Redundant copies kept elsewhere are thus important in cases where insiders may be involved or threats are high.
Records of production details are often required for systems that ultimately effect human safety, such as safety-related automotive parts, systems used to control food and drug production, and so forth. In these cases, redundancy may be necessary to assure use in recalls and after incidents, and redundancy may be used to increase the assurance associated with these cases. Over time, separate and different mechanisms will be required to afford high surety.
In cases where plant events or other common mode failures can destroy or make inaccessible a data history repository, redundant copies may be required at remote locations both to perform after-action reviews and to support legal and regulatory mandates.
Kept until when?
In all cases: Data history repositories should be tested and verified periodically. This is typically done at least once per year as part of standard business processes. History and redundant copies of history should be verified as they are made to detect process errors as soon as feasible.
Since historical data is rarely time critical, there is no particular need to have live backup copies, and standard backup mechanisms may be adequate. If data history repositories are properly secured to allow append only access from ICS systems and read-only access for auditors, forensic examiners, and engineers seeking to debug and improve processes, no substantial value comes from additional redundancy.