Section C: Infrastructure and Security Risk Management

To fill in the template for a requirement, simply click on the "Edit" tab at the top of the page and type text to replace the "..." where they appear under each requirement. When you have finished, click on "Save" at the bottom of the edit page.

C1 Technical infrastructure risk management (RM)

C1.1 Repository identifies and manages the risks to its preservation operations and goals associated with system infrastructure.

Supporting Text
The repository must conduct or contract assessments of the risks related to hardware and software infrastructure, and operational procedures. The repository must provide mechanisms that minimize risk from dependencies on proprietary or obsolete system infrastructure. The repository must provide mechanisms to minimize risk from operational error. This is necessary to ensure a secure and trustworthy infrastructure.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Infrastructure inventory of system components; periodic technology assessments; estimates of system component lifetime; export of authentic records to an independent system; use of strongly community supported software .e.g., Apache, iRODS, Fedora); re-creation of archives from backups.

Discussion
The degree of support required relates to the criticality of the subsystem(s) involved in long- term preservation. The repository should maintain a system that is scalable (e.g. able to handle anticipated future volumes of both bytes and files) without a major disruption of the system. The repository should maintain a system that is evolvable. That is, the system should be designed in such a way that major components of the system can be replaced with newer technologies without major disruption of the system as a whole. The repository system should be extensible. That is, the system should be designed to accommodate future formats (media and files) without major disruption of the system as a whole. The repository should be able to export its holdings to a future custodian. The repository should be able to re-create the archives after an operational error that overwrites or deletes digital holdings.

C1.1.1 Repository performs technology watch.

Supporting Text
The repository must employ technology watches or other technology monitoring notification systems to track when hardware or software components will become obsolete. This is necessary to track when migration is needed to new infrastructure.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Management of periodic technology assessment reports. Comparison of existing technology to each new assessment.

Discussion
The objective is to understand when any sub-system poses a risk of obsolescence, and enable planning migration to new technology before interoperability mechanisms are no longer available. This can be driven by proprietary software dependencies (the vendor no longer supports the sub-system component), and by emergence of new protocols (the mechanism for accessing the system has become obsolete and is no longer supported).

C1.1.1.1 Repository has hardware technologies appropriate to the services it provides to its designated communities.

Supporting Text
The repository must be aware of the types of storage, file management, preservation and access services expected by its designated community(ies), including where applicable, the types of media to be delivered, and needs to make sure its hardware capabilities can support these services. This is necessary to provide expected, contracted, secure, and persistent levels of service including: ease of ingest and dissemination through appropriate depositor and user interfaces and technologies such as upload mechanisms; on-going digital object management; preservation approaches and solutions, such as migration; and system security.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Maintenance of up-to-date designated community technology, expectations, and use profiles; Provision of bandwidth adequate to support ingest and use demands; systematic elicitation of feedback regarding hardware and service adequacy; maintenance of a current hardware inventory.

Discussion
The objective is to track when changes in service requirements by the designated communities require a corresponding change in the hardware technology, when changes in ingestion policies require expanded capabilities, and when changes in preservation policies require new preservation capabilities. This can be driven by changes in capacity requirements (the time needed to read all media is longer than the media lifetime), by changes in delivery mechanisms (new clients for displaying authentic records), and changes in the number and size of archived records.

C1.1.1.2 Repository has procedures in place to monitor and receive notifications when hardware technology changes are needed.

Supporting Text
The repository must conduct or contract frequent environmental scans regarding hardware status, sources of failure, and inter-operability among hardware components. The repository must also be in contact with its hardware vendors regarding technology updates, points of likely failure, and how new components may affect system integration and performance. This is necessary to ensure expected, contracted, secure, and persistent levels of service.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Audits of capacity versus actual usage; audits of observed error rates; audits of performance bottlenecks that limit ability to meet user community access requirements; documentation of technology watch assessments; documentation of technology updates from vendors.

Discussion
The objective is to track when changes in service requirements by the designated communities require a corresponding change in the hardware technology, when changes in ingestion policies require expanded capabilities, and when changes in preservation policies require new preservation capabilities. This can be driven by changes in capacity requirements (the time needed to read all media is longer than the media lifetime), by changes in delivery mechanisms (new clients for displaying authentic records), and changes in the number and size of archived records.

C1.1.1.3 Repository has procedures in place to evaluate when changes are needed to current hardware.

Supporting Text
Given information from technology watches or other technology monitoring notification systems, the repository must have procedures and expertise to evaluate this data and make sound decisions regarding the need for new hardware. This is necessary to ensure that the repository has the capacity to make informed and timely decisions when information indicates the need for new hardware.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Evaluation procedures in place; documented staff expertise in each technology sub-system.

Discussion
The objective is to track when technology providers have developed sub-systems that minimize risk, or that minimize cost, or that improve performance. This is necessary to track emerging technologies, and plan for upgrades before capacity limits occur. The evaluation should identify when the risk of using new technology outweighs the expected benefit, and when the new technology is sufficiently mature to minimize risk.

C1.1.1.4 Repository has procedures to replace hardware when evaluation indicates the need to do so.

Supporting Text
The repository must have a commitment and a financial escrow plan or certain funding streams by which it can demonstrate the capacity to purchase new hardware when evaluation indicates the need to do so. This is necessary to ensure hardware replacement in a timely fashion so as to avert system failure or performance inadequacy. Without such a commitment, and more importantly, without escrowed financial resources or a secure funding stream, technology watches and notifications are of little value. The repository must have mechanisms for evaluating the efficacy of the new systems before implementation in the production system.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Statement of commitment to provide expected and contracted levels of service; evidence of ongoing financial assets set aside for hardware procurement; demonstration of cost savings through amortized cost of new system.

Discussion
The objective is to demonstrate that the repository has the ability to incorporate new technology, both financially through funding commitments or cost reduction, and operationally through verification of the capabilities of the new systems.

C1.1.1.5 Repository has software technologies appropriate to the services it provides to its designated communities.

Supporting Text
The repository must be aware of the types of storage, file management, preservation and access services expected by its designated community(ies), including where applicable, the types of media to be delivered, and needs to make sure its software capabilities can support these services and be compatible with repository hardware. This is necessary to provide expected, contracted, secure, and persistent levels of service including: ease of ingest and dissemination through appropriate depositor and user interfaces and technologies such as upload mechanisms; on-going digital object management; preservation approaches and solutions, such as migration; and system security.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Maintenance of up-to-date designated community technology, expectations, and use profiles; Provision of software systems adequate to support ingest and use demands; systematic elicitation of feedback regarding software and service adequacy; maintenance of a current software inventory.

Discussion
The objective is to track when changes in service requirements by the designated communities require a corresponding change in the software components, when changes in ingestion policies require support for new data formats and when changes in software technology require new format migration capabilities. This can be driven by changes in access requirements (new clients become preferred that require new data formats), by changes in delivery mechanisms (new data transfer mechanisms), and changes in the number and size of archived records that require more scalable software.

C1.1.1.6 Repository has procedures in place to monitor and receive notifications when software changes are needed.

Supporting Text
The repository must conduct or contract frequent environmental scans regarding software evolution, likely points of failure, and inter-operability among the software and hardware components. The repository must also be in contact with its software vendors regarding technology updates, points of likely failure, and how new programs may affect system integration and performance. This is necessary to ensure expected, contracted, secure, and persistent levels of service.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Audits of capacity versus actual usage; audits of observed error rates; audits of performance bottlenecks that limit ability to meet user community access requirements; documentation of technology watch assessments; documentation of software updates from vendors.

Discussion
The objective is to track when changes in service requirements by the designated communities require a corresponding change in the hardware technology, when changes in ingestion policies require expanded capabilities, and when changes in preservation policies require new preservation capabilities. This can be driven by security updates (vendor supplied corrections to newly identified vulnerablities), by changes in delivery mechanisms (new software clients for displaying authentic records), and changes in the number and size of archived records (expanded database requirements).

C1.1.1.7 Repository has procedures in place to evaluate when changes are needed to current software.


Supporting Text
Given information from technology watches or other technology monitoring notification systems, the repository must have procedures and expertise to evaluate this data and make sound decisions regarding the need for new software. This is necessary to ensure that the repository has the capacity to make informed and timely decisions when information indicates the need for new software.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Evaluation procedures in place; documented staff expertise in each software technology sub-system.

Discussion
The objective is to track when technology providers have developed software infrastructure that minimizes risk, or that minimizes cost, or that improves performance. This is necessary to track emerging technologies, and plan for upgrades before capacity limits occur. The evaluation should identify when the risk of using new technology outweighs the expected benefit, and when the new technology is sufficiently mature to minimize risk.

C1.1.1.8 Repository has procedures to replace software when evaluation indicates the need to do so.

Supporting Text
The repository must have a commitment and a financial escrow plan or certain funding streams by which it can demonstrate the capacity to purchase new software when evaluation indicates the need to do so. This is necessary to ensure software replacement in a timely fashion so as to avert system failure or performance inadequacy. Without such a commitment, and more importantly, without escrowed financial resources or a secure funding stream, technology watches and notifications are of little value. The repository must have mechanisms for evaluating the efficacy of the new systems before implementation in the production system.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Statement of commitment to provide expected and contracted levels of service; evidence of ongoing financial assets set aside for software procurement; demonstration of cost savings through amortized cost of new system.

Discussion
The objective is to demonstrate that the repository has the ability to incorporate new technology, both financially through funding commitments or cost reduction, and operationally through verification of the capabilities of the new systems.

C1.1.2 Repository ensures that it has adequate hardware and software support for backup functionality sufficient for preserving the repository content and tracking repository functions.

Supporting Text
The repository must be able to demonstrate the adequacy of the processes, hardware and software for its backup systems. This is necessary in order to ensure continued access to and tracking of preservation functions applied to the digital objects in their custody.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Documentation of what is being backed up and how often; audit log/inventory of backups; validation of completed backups; disaster recovery plan, policy and documentation; fire drills;
BA 16April2009 - Do you literally mean "fire drills" or is this generic for a disaster planning practice exercise?
testing of backups; support contracts for hardware and software for backup mechanisms; demonstrated preservation of system metadata such as access controls, location of replicas, audit trails, checksum values.

Discussion
Repositories must be able to demonstrate the full range of ingest, preservation, and dissemination functions required of a repository entrusted with long-term preservation. Simple backup mechanisms must preserve not only the repository main content, but also the system metadata generated by the preservation functions. Repositories need to develop backup plans that ensure their continuity of operations across all failure modes.

C1.1.3 Repository has effective mechanisms to detect bit corruption or loss.


Supporting Text
The repository must be able to demonstrate that all the AIP's and accompanying metadata are uncorrupted. This is necessary in order to ensure that any data losses are detected and fall within the tolerances levels established by repository policy (see A3.5).

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Documents that specify bit error detection and correction mechanisms used; risk analysis; error reports; threat analysis; periodic analysis of the integrity of repository holdings.

Discussion
The objective is a comprehensive treatment of the sources of data loss and their real world complexity. Any data or metadata that is (temporarily) lost should be recoverable from backups. Routine systematic failures must not be allowed to accumulate and cause data loss beyond the tolerances established by the repository policies. Mechanisms such as checksums (MD5 signatures) or digital signatures should be recognized for their effectiveness in detecting bit loss and incorporated into the overall approach of the repository for validating integrity.

C1.1.3.1 Repository reports to its administration all incidents of data corruption or loss, and steps taken to repair/replace corrupt or lost data.

Supporting Text
The repository must record, report, and repair as soon as possible all violations of data integrity. This is necessary in order to ensure the repository administration is being kept informed of incidents and recovery actions, and to enable identification of sources of data corruption or loss.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Procedures related to reporting incidents to administrators; Preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss; tracking of sources of incidents; remediation actions taken to remove sources of incidents.

Discussion
Having effective mechanisms to detect bit corruption and loss within a repository system is critical but it is only the initial step of a larger process. In addition to recording, reporting and repairing as soon as possible all violations of data integrity, these incidents and the recovery actions and their results must be reported to administrators and made available to all relevant staff. Given identification of the sources of data loss, an assessment of revisions to software and hardware systems, or operational procedures, or management policies is needed to minimize future risk of data loss.

C1.1.4 Repository has a process to react to the availability of new security updates based on a risk-benefit assessment.


Supporting Text
The repository must maintain a record of all security updates containing an evaluation of the risk of applying the update vs. not doing so, and a record of which security updates were applied. This is necessary in order to protect the integrity of the archival objects from unauthorized changes or deletions.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Risk register (list of all patches available and risk documentation analysis); evidence of update processes (e.g., server update manager daemon); documentation related to the update installations.

Discussion
Decisions to apply security updates are likely to be the outcome of a risk-benefit assessment; security patches are frequently responsible for upsetting alternative aspects of system functionality or performance. It may not be necessary for a repository to implement all software patches, and the application of any must be carefully considered. Each security update implemented by the repository must be documented with details about how it is completed; both automated and manual updates are acceptable. Significant security updates might pertain to software other than core operating systems, such as database applications and Web servers, and these should also be documented. Security updates are not limited to software security updates. Updates to actual hardware or to the hardware system's firmware are included. Over time it is likely that security updates will also be needed for the repository processes and for its physical security. Although security updates can be considered as a part of the change control, they are identified separately here because there are often outside services that compile and circulate information on security issues and updates. At a minimum, repositories should be monitoring these services to ensure that repository held data is not subject to compromise by identified threats.

C1.1.5 Repository has defined processes for storage media and/or hardware change (e.g., refreshing, migration).

Supporting Text
The repository must identify the expected lifetime for each type of storage media (and its supporting hardware) in use at the repository and identify a process to copy the data off of the media prior to it reaching that point. This is necessary in order to ensure that data is not lost when either the media fail or the supporting hardware can no longer be used to access the data.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Documentation of migration processes; policies related to hardware support, maintenance, and replacement; documentation of hardware manufacturer's expected support life cycles; policies related to migration of records to alternate hardware systems.

Discussion
The repository should have estimates of the access speed and the quantity of information for each type of storage media. Then with estimates of the reliable lifetime of the storage media and information of system loading, etc., the repository can estimate the time required for storage media migration, or refreshing or copying between media without reformatting the bitstream. The repository can then set triggers for initiating the action at an appropriate time so the actions will be completed before data is lost. Copying large quantities of data can take a long time and can affect other system performance metrics. Repositories should also consider the obsolescence of any and all hardware components within the repository system as potential trigger events for migration. Increasingly, long-term, appropriate support for system hardware components is difficult to obtain, exposing repositories to risks and liabilities should they chose to continue to operate the hardware beyond the manufacturer or third-party support warranties. Repositories will likely need to perform media migration off of some types of media onto better supported media based on the estimated lifetime of hardware support rather than on the longer life expected from the media. It is important that the process includes a check that the copying has happened correctly. (See B4.2.2)

C1.1.6 Repository has identified and documented critical processes that affect its ability to comply with its mandatory responsibilities.

Supporting Text
The repository must ensure that each process that is applied to meet the mandatory preservation responsibilities (authenticity, integrity, chain of custody) is identified. This is necessary in order to ensure that the critical processes can be monitored to ensure that they continue to meet the mandatory responsibilities and to ensure that any changes to those processes are examined and tested.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Traceability matrix between processes and mandatory requirements.

Discussion
Examples of critical processes include data management, access, archival storage, ingest, and security processes. Traceability makes it possible to understand which repository processes are required to meet each of the mandatory responsibilities.

C1.1.6.1 Repository has a documented change management process that identifies changes to critical processes that potentially affect the repository's ability to comply with its mandatory responsibilities.

Supporting Text
The repository must ensure that changes to the preservation and management processes are tracked. This is necessary in order to ensure that the repository can specify not only the current processes, but the prior processes that were applied to the repository holdings.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Documentation of change management process; assessment of risk associated with a process change; analysis of the exptected impact of a process change; comparison of logs of actual changes to processes versus associated analyses of their impact and criticality.

Discussion
Examples of this would include changes to processes for data management, access, archival storage, ingest, and security. The really important thing is to be able to know what changes were made and when they were made. Traceability makes it possible to understand what was affected by particular changes to the systems. If unintended consequences are later discovered, then having this record may make it possible to reverse the changes or at least to document the changes that were introduced. Change management is a component of the broader topic of configuration mangement described by ISO 10007:2003 which includes configuration management planning, configuration identification, change control, configuration status accounting and configuration audit. Configuration Management efforts should result in a complete audit trail of decisions and design modifications.

C1.1.6.1.1 Repository has a process for testing the effect of changes to the repository's critical processes.

Supporting Text
The repository must test and evaluate the impact of every change to any critical process. This is necessary in order to protect the integrity of the repository's critical processes such that they continue in their ability to meet the repository's mandatory requirements.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Documented testing procedures; documentation of results from prior tests and proof of changes made as a result of tests; analysis of the impact of a process change.

Discussion
Changes to critical systems should be, where possible, pre-tested separately, the expected behaviors documented, and roll-back procedures prepared. After changes, the systems should be monitored for unexpected and unacceptable behavior. If such behavior is discovered the changes and their consequences should be reversed. Whole-system testing or unit testing can address this requirement; complex safety-type tests are not required. Testing can be very expensive, but there should be some recognition of the fact that a completely open regime where no changes are ever evaluated or tested will have problems.

C1.2 Repository manages the number and location of copies of all digital objects.

Supporting Text
The repository system must be able to identify all stored digital objects, including the location of each object (all copies and all versions). This is necessary in order to assert that the repository is providing an authentic copy of a particular digital object.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Random retrieval tests; validation of object existence for each registered location; validation of a registered location for each object on storage systems; provenance and fixity checking (see C1.5)
BA 16April2009 - There is no C1.5.

DG 20090419 - suggest we delete this reference

information; location register/log of digital objects compared to the expected number and location of copies of particular objects; .

Discussion
A repository can have different preservation policies for different classes of objects, depending on factors such as the producer, the information type, or its value. Repositories may require adifferent number of copies for each class, or manage versions needed to meet access requirements. There may be additional identification requirements if the data integrity mechanisms use alternative copies to replace failed copies. The location of each digital object must be described such that the object can be located precisely, without ambiguity. The location can be an absolute physical location or a logical location within a storage media or a storage subsystem. Provenance information about copying and moving the data, must be maintained/updated, including the identification of those responsible. This is necessary in order to track chain of custody and assert that the repository is providing an authentic copy of a particular digital object. The repository must be able to distinguish between versions of objects or copies and identical copies. This is necessary in order that a repository can assert that it is providing an authentic copy of the correct version of an object.

C1.2.1 Repository has mechanisms in place to ensure any/multiple copies of digital objects are synchronized.


Supporting Text
The repository must have a mechanism to ensure that intentional changes to an object are propagated to all copies of that object within a time established as acceptable by the repository. This is necessary in order to ensure that multiple copies of a digital object remain identical, and that a copy can be used to replace a corrupted copy of the object.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement
Synchronization workflows; system analysis of how long it takes for copies to synchronize; procedures/documentation of synchronization processes.

Discussion
The disaster recovery plan should address what to do should a disaster and an update coincide. For example, if one copy of an object is altered and a disaster occurs while the second is being updated, there needs to be a mechanism to assure that the copy will be updated at the first available opportunity. The mechanisms to synchronize copies of digital objects should be able to detect bit corruption, and validate fixity checks before synchronization is attempted.

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2009-04-20 - DavidGiaretta
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback