Re-expression of requirements using uniform template: Section C

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. System infrastructure

C1.1 Repository functions on well supported operating systems and other core infrastructural software.

Supporting Text

The repository must provide the normal requirements for a well-managed IT operation. This is necessary to ensure a secure and trustworthy infrastructure. The repository must provide and document a level of support for the long-term preservation functions sufficient to ensure a secure and trustworthy infrastructure for those elements of the operating system utilized in its functions.

-- DavidGiaretta - 02 Feb 2009 We should make it clear that the archive has some estimate the date up to which the key s/w will be supported. It should also be clear that we can export the appropriate details to any follow on system.

This is necessary in order to provide the level of support for these elements of the infrastructure appropriate to an open archival information system The repository must show that it understands the risks to its operations and provides the degree of support required for the criticality of the functions involved. This is necessary in order to meet both current and future operating needs as envisioned in the repository’s mission.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Software inventory; system documentation; support contracts; use of strongly community supported software .e.g., Apache); periodic market analyses.

-- DavidGiaretta - 02 Feb 2009: evidence to support the estimate of soonest expected obsolescence data; evidence of the export possibilities. ...

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. ...

-- DavidGiaretta - 02 Feb 2009: and also will be able to export its holdings to a future custodian.

C1.2 Repository ensures that it has adequate hardware and software support for backup functionality sufficient for the repository’s services and for the data held, e.g., metadata associated with access controls, repository main content.

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 understandability of 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”—testing of backups; support contracts for hardware and software for backup mechanisms.. ...

Discussion

Repositories must be able to demonstrate they understand that backup routines are not equivalent to full ingest, preservation, and dissemination routines required of a repository entrusted with long-term preservation. Some repositories will need to develop more elaborate backup plans than others to ensure their continuity of operations. ...

C1.3 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. 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.

-- DavidGiaretta - 02 Feb 2009: Provenance information about e.g. copying and moving the data, must be maintained/updated, including the identification of those responsible.

This is necessary in order to 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.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Random retrieval tests; system tests; location register/log of digital objects compared to the expected number and location of copies of particular objects.

-- DavidGiaretta - 02 Feb 2009: add Provenance and fixity checking (see C1.5) information

Discussion

A repository can have different policies for different classes of objects, depending on factors such as the producer, the information type, or its value. Some repositories may have only one copy (excluding backups) of everything, stored in one place, though this is definitely not recommended. There may be additional identification requirements if the data integrity mechanisms use alternative copies to replace failed copies...

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

Supporting Text

The repository must have some way to ensure that intentional changes to an object are propogated to all copies of that object. In addition, there must be an element of timeliness to these changes so they occur within a time esstablished as acceptable by the repository.

This is necessary in order to ensure that if multiple copies of a digital object exist, then intentional changes to one copy are propogated to all other copies of the object.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Workflows; system analysis of how long it takes for copies to synchronize; procedures/documentation of relevant operating procedures;

Discussion

There should also be something in the disaster recovery plan which addresses 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 some assurance that the copy will be updated at the first available opportunity.

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

Supporting Text

The repository must be able to demonstrate 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.6).

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.

Discussion

The objective is a comprehensive treatment of the sources of data loss and their real world complexity. Any data 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 policys. Mechanisms such as MD5 signatures should be recognized for their effectiveness and role within the overall approach of the repository to detecting bit loss.

C1.6 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 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.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Procedures related to reporting to administrators; Preservation metadata (e.g., PDI) records; comparison of error logs to reports to administration; escalation procedures related to data loss.

Discussion

Having effective mechanisms to detect bit corruption and loss within a repository system is critical but it is only one important part of a larger process. In addition to recording, reporting and repairing as possible all violations of data integrity, these incidents, recovery actions and their results must be reported to administrators and made available to all relevant staff.

C1.7 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.

-- DavidGiaretta - 02 Feb 2009 relate to C1.1, but that covers also operating systems and other s/w

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 processes; policies related to hardware support, maintenance, and replacement; documentation of hardware manufacturers’ expected support life cycles.

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”—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.

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. 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.)

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

Supporting Text

The repository must ensure that each process that makes significant contributions to fulfilling the mandatory responsibilities are identified and the contribution made is documented in association with that process.

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 this would 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. Once these critical processes are identified, changes to them can be monitored to ensure that repository will continue to meet its obligations.

C1.8B 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 unexpected or unexamined changes to the preservation and management systems.

This is necessary in order to ensure the integrity of the archival objects over time.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Documentation of change management process; comparison of logs of actual system changes to processes versus associated analyses of their impact and criticality.

Discussion

Examples of this would include changes in processes in 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.

-- MarkConrad - 22 May 2007 - I believe that this requirement is actually referring to configuration management rather than change management. There are several relevant sets of best practices/standards. For example:

ISO 10007:2003 gives guidance on the use of configuration management within an organization. It is applicable to the support of products from concept to disposal. It first outlines the responsibilities and authorities before describing the configuration management process that includes configuration management planning, configuration identification, change control, configuration status accounting and configuration audit. Since ISO 10007:2003 is a guidance document, it is not intended to be used for certification/registration purposes.

See also:

U.S. DoD - MIL-HDBK-61A

ANSI/EIA 649A, Configuration Management

IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans. This plan establishes the minimum required contents of a Software Configuration Management Plan and defines the specific activities to be addressed and their requirements for any portion of a software product's life cycle.

IEEE1042-1987, Guide to Software Configuration Management

ISO/IEC 12207-1995 "Information technology -- Software life cycle processes

-- ChrisRusbridge - 18 Jul 2007 - See also ISO 20000-2:2005 section 9.2.

-- MarkConrad - 22 May 2007 - I believe we need a separate item that says, Configuration Management efforts should result in a complete audit trail of decisions and design modifications.

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

Supporting Text

The repository must test every significant? 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.

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.10 Repository has a process to react to the availability of new software 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 was 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.

C2. Appropriate technologies

C2.1 Repository has hardware technologies appropriate to the services it provides to its designated communities and has procedures in place to receive and monitor notifications, and evaluate when hardware technology changes are needed.

Supporting Text
The repository much 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: 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.

The repository must ...

This is necessary in order to ...

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Text found in the Evidence section of the current TRAC document goes here.

...

Discussion

Text found in the supporting text section of the current TRAC document that does not apply to all repositories goes here.

...

C2.2 Repository has software technologies appropriate to the services it provides to its designated community(ies) and has procedures in place to receive and monitor notifications, and evaluate when software technology changes are needed.

Supporting Text

Mandatory text that applies to all repositories goes in this section. The text should have pairs of sentences for each mandatory requirement or sub-requirement found in the supporting text of the existing document. The sentence pairs should begin with the phrases, "The repository must..." and This is necessary in order to..." .

The repository must ...

This is necessary in order to ...

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Text found in the Evidence section of the current TRAC document goes here.

...

Discussion

Text found in the supporting text section of the current TRAC document that does not apply to all repositories goes here.

...

C3. Security

C3.1 Repository maintains a systematic analysis of such factors as data, systems, personnel, physical plant, and security needs.

Supporting Text

Mandatory text that applies to all repositories goes in this section. The text should have pairs of sentences for each mandatory requirement or sub-requirement found in the supporting text of the existing document. The sentence pairs should begin with the phrases, "The repository must..." and This is necessary in order to..." .

The repository must ...

This is necessary in order to ...

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Text found in the Evidence section of the current TRAC document goes here.

...

Discussion

Text found in the supporting text section of the current TRAC document that does not apply to all repositories goes here.

...

C3.2 Repository has implemented controls to adequately address each of the defined security needs.

Supporting Text

The repository must show how it has dealt with its security requirements. If some types of material are more likely to be attacked, the repository will need to provide more protection, for instance.

This is necessary in order to ensure that controls are in place to meet the security needs of the repository.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

ISO 17799 certificationEmploys the codes of practice found in the ISO 27000 series of standards; system control list; risk, threat, or control analyses; addition of controls based on ongoing risk detection and assessment.

Discussion

Repositories that have experienced incidents could record such instances, including the times when systems or content were affected and describe procedures that have been put in place to prevent similar occurrences in the future.

C3.3 Repository staff have delineated roles, responsibilities, and authorizations related to implementing changes within the system.

Supporting Text

The repository must assign individuals to be responsible for implementing changes within the system and provide them with the authority and resources to implement such changes.

This is necessary in order to ensure that individuals have the authority to implement changes, that adequate resources have been assigned for the effort, and that the responsible individuals will be accountable for implementing such changes.

Examples of Ways the Repository can Demonstrate it is Meeting this Requiremen

ISO 17799 certificationEmploys the codes of practice found in the ISO 27000 series of standards; organizational chart; system authorization documentation.

Discussion

Authorizations are about who can do what—who can add users, who has access to change metadata, who can get at audit logs. It is important that authorizations are justified, that staff understand what they are authorized to do, and that there is a consistent view of this across the organization. .

C3.4 Repository has suitable written disaster preparedness and recovery plan(s), including at least one off-site backup of all preserved information together with an offsite copy of the recovery plan(s).

Supporting Text

The repository must have a written plan with some approval process for what happens in specific types of disaster (fire, flood, system compromise, etc.) and for who has responsibility for actions.

This is necessary in order to ensure that sufficient backup and recovery capabilities are in place to facilitate continuing preservation of and access to systems and their content with limited disruption of services.

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

ISO 17799 certificationEmploys the codes of practice found in the ISO 27000 series of standards; disaster and recovery plans; information about and proof of at least one off-site copy of preserved information; service continuity plan; documentation linking roles with activities; local geological, geographical, or meteorological data or threat assessments._

Discussion

The level of detail in a disaster plan, and the specific risks addressed need to be appropriate to the repository’s location and service expectations. Fire is an almost universal concern, but earthquakes may not require specific planning at all locations. The disaster plan must, however, deal with unspecified situations that would have specific consequences, such as lack of access to a building. In the event of a disaster at the repository, the repository may want to contact local and/or national disaster recovery bodies for assistance.

-- SimonLambert - 11 Feb 2008

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2009-02-07 - 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