Basis:

Overview: Notionally, we would like to
write-lock and control use of the past, control access to and use of
the present, and anticipate the future. Specific mechanisms are
available for achieving these goals, but there are tradeoffs
involved. For example, we can prevent alteration of historical records
for a period of time very inexpensively by making it unavailable for
use. But over time, the media deteriorates, and the utility is low for
practical use. Thus large tape repositories are often used for
medium-term storage. They retain data for perhaps 10 years and allow
robotic mounting for periods of use. Similar approaches are used for
microfiche. By using hardware write-lock mechanisms for such archives,
availability can be supported with reasonable delays and high surety
of non-alteration. However, access times are substantial and search
almost infeasible. This is often problematic.

Version control is closely related to change
management, content life cycle, backup, business continuity, disaster
recovery, and retention and disposition issues. Life cycles for
content are related to risk levels and deal with {Inception /
Observation / Entry / Validation / Verification / Attribution / Fusion
/ Separation / Analysis / Transforms / Transmission / Storage / Use /
Presentation / Modification / Loss / Recovery / Reconstruction /
Backup / Restoration / Destruction}. Change management is related to
risk and maturity. As a result, version control can reasonably be
related to risk and maturity. It is established that low maturity and
high risk are a highly undesirable mismatch. Retention and disposition
are almost entirely business decisions (in the sense that they are
determined by management in terms of the needs of the organization
and/or the promises they make). Continuity and disaster issues are
driven by real-time requirements and distance issue. Taking all of
these into account, we identify timeliness, surety (which is hopefully
matched to risk and linked to maturity), and control objectives
(IACUTRS) as the key factors in the decision, but decisions must also
support the other related protection aspects in order to be feasible
in an environment.

WORM: Write Once Read Many is typically a
hardware mechanism that writes onto a write-once read-many media such
as a non-erasable CD or special purpose WORM drive.

HW write-locked: Hardware write-lock
mechanisms cannot be defeated by any software approach. Typically,
they involve a mechanical switch that opens (locked) or closes (not
locked) a circuit to the write-head or other write mechanism.

SW write-locked: Software write lock is often
used in place of hardware write-lock for less surety traded off for
more convenience.

append-only: Append-only mechanisms allow more
information to be added but old information cannot be removed. This
is desired for audit trails, transaction systems, and other similar
mechanisms.

read-write: Read or write are permitted
leaving the storage subject to the control of other mechanisms.

Media: Protection is at the level of the
physical device or media.

File system: Protection is at the level of the
file system within the media. For example, an ISO 9660 read-only file
system has no write mechanism inherent to it while a file system may
also be mounted read-only.

Directories: Protection is at the directory
level within a file system. This may be done by mounting file systems
on directory stubs read-only or by directory level protections.

Files: File protection it typically done by
setting metadata within the file system.

off-line: Off-line storage is typically only
available upon request. For example, tape repositories commonly use
robotic mechanisms to mount a tape while in use, but in storage, the
tape is off-line.

in a file server: File servers are commonly
used to provide support for complex file system functions, such as
encrypted remote file systems, user directories with limited access,
remotely mounted file systems through encrypted tunnels, etc. They are
typically out of the control of the computer performing user-related
functions and are thus not subject to user actions or alterations of
the user's system.

in a NAS: Network addressable storage
typically acts as if portions of the overall storage were local disks
on various networked machines.

in a transaction system: Transaction systems
are specifically designed as append-only mechanisms with atomic
transactions, typically supporting checkpoints, roll-back, reversion,
and replay for databases, or for forward-only real-time systems, such
as financial systems, supporting detailed accountability for actions
and up-to-date state on accounts or similar entries.

on system: Storage on the end-user system, a
typical local disk drive.

physical: Hardware or other physical mechanisms.

logical: Software or other logic-based mechanisms.

cryptographic: Transformation through a hard
to invert or reproduce function, possibly more easily inverted with a key.

sequence number: Typically an integer that
increments with each close of a written file.

write time: The time of last write to the file
is recorded as meta-data and retained as associated with that version
and never changed from that time forward.

attributed to user: Typically a user identity
associated with the last write is retained.

attributed to role: If rules and roles are in
use, association to a roles as well as a user are appropriate. In
systems where there are not user identities (not suggested), use of a
role should be used.

attributed to organization: Typically the name
or an identifier for the organization including sub-organizational
units to the level of granularity desired.

attributed to system: Typically a system
identifier and/or hardware identifiers.

attributed to location: Typically an address,
floor, room, rack location, etc. Sometimes a GPS location may also be
used.

attributed to mechanism: Typically associated
with a specific mechanism used, such as a sensor, device, machine ID,
Ethernet card, etc.

retain: to keep the content available over time.

protect: meet a protective goal - typically IACUTRS.

revert to: to allow previous versions to be regenerated.

dispose of: to support removal and permanent destruction of content.

historic: over a long time frame including transitions from system, people, organization, etc.

recent: over time frames within local systems or not reaching the historic level.