Fri Apr 8 06:47:17 PDT 2016

Content control: Version control: How are versions of data over time protected?


Use {WORM / HW write-locked / SW write-locked / append-only / journaling / read-write} {Media / File system / Directories / Files} stored {off-line / in a file server / in a NAS / in a transaction system / on system} with access controlled by {physical / logical / cryptographic} means and versions identified with {sequence number / write time / attributed to {user / role / organization / system / location / mechanism}} to {retain / protect / revert to / dispose of} {historic / recent / current} versions of content.


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.

current: the most recent and currently in-use version.

Copyright(c) Fred Cohen, 1988-2015 - All Rights Reserved