4. Planning, procuring, configuring and deploying systems

This section provides standards and guidelines for use by government agencies in ICT planning, and systems procurement, configuration and deployment. They aim to ensure that TC/DRM implications are considered throughout the system’s lifecycle.

These considerations apply even at the enterprise/technical architecture level. Use of TC/DRM technologies could form part of an agency’s ICT strategy, e.g. trusted computing forms the basis for some network access control solutions. TC/DRM technologies could come bundled as part of a product that forms a fundamental part of an agency’s technical platform, e.g. embedded in desktop computer and mobile phone hardware and operating systems. It is important these implications are thought through in advance, so that an agency’s ICT planning positions it for compliance with the government’s TC/DRM Principles and Policies.

There are steps that can be taken during the procurement process to ensure adequate disclosure of TC/DRM functionality, to ensure that the product being purchased will be compliant with the TC/DRM Policies and Principles.

In some cases, a product’s compliance with the TC/DRM Principles and Policies will hinge upon how it is configured, what it is used for and how it is used. This section provides some measures to address this aspect.

4.1 Support for informed consent

Standard

Software must support user awareness of DRM encumbrances

Software that enforces DRM encumbrances must either:

• have a notification mechanism, to tell the user each time an encumbered file is opened that restrictions apply, and allow viewing of the restrictions if desired, or
• in the case of software where most or all of the information handled by the software is encumbered in a standard manner, an acceptable alternative to 'per use' notification is for agencies to ensure that users know that all such information should be regarded as encumbered.

Rationale

Notification of an encumbrance on each usage will enable users to know whether they need to make separate notes, in order to maintain an appropriate record.

This standard supports Policy 2, Conditions for externally-imposed digital encumbrance.

4.2 Ensuring continued access to information

Standard

Attestation criteria must remain stable

For government systems that use hardware or software attestation, agencies must ensure that the attestation criteria cannot be changed without the agency’s prior approval.

Rationale

Unapproved changes to attestation criteria could result in an agency losing access to its information.

This standard supports Policy 5, Assurance of future accessibility.

Standard

Requirement for access to information independent of attestation

Government systems that use hardware or software attestation, must either have a means to bypass it, or must keep a backup of the system’s information in an open data format in unencumbered form in a suitably secure data store.

Rationale

These provisions mitigate the risk of a failure in the attestation mechanism resulting in loss of access to government information. The data backup provision ensures there is no dependence on proprietary hardware or software, or decryption.

This standard supports Policy 5, Assurance of future accessibility.

4.3 Ensuring effective security

Standard

Ensuring effectiveness of defences

Before implementing TC/DRM features, an agency must ensure that its security systems (including anti-virus, firewalls, intrusion prevention and detection systems) remain effective for information imported using the TC/DRM services/channels, or if not, that such information is processed only in an isolated environment.

Rationale

Agencies may receive information that is encrypted in order to enforce externally imposed digital restrictions, and consequently be unable to check for harmful content. There is a risk that such information may be accepted with harmful content.

There will always be a risk of DRM-protected information being a vector for viruses, and no way for anti-malware software to check it, unless there is some far-reaching cooperation between software vendors and anti-malware developers.

This standard supports Policy 13, Ability to identify harmful communications.

Guideline

Seek vendor assurance against unauthorised information modification/deletion

Agencies may wish to safeguard their ability to comply with Policy 9, Modification/deletion by hardware/software, by seeking an assurance from ICT product vendors. This will need to be built into an agency’s procurement process. Clearly the agency will have power to obtain a stronger assurance when purchasing a bespoke system, than when it purchases a commodity product. In the case of a bespoke system, the agency could require provision of a warranty as part of the contract. In the case of a commodity product, it may be not be possible to get any sort of direct assurance from the vendor, and may instead be necessary to rely on market intelligence, including information sharing with other governments and New Zealand government agencies.

Guideline

Use unencrypted mode when running remote attestation

When using remote attestation, agencies should always run the attestation communications in unencrypted form (if able to do so), so that the traffic can be inspected. If this is not possible, then agencies should ensure that they have some other way of mitigating the risks resulting from not being able to inspect system-initiated communications leaving or entering their systems.

4.4 Ensuring compliance of new systems with policies

Guideline

Issues to consider in the IT procurement process

Procurement processes need to have checks to identify what TC/DRM functionality is included in the vendor products. The functions should be assessed against the requirements of the TC/DRM Policies and Standards.

Agencies should ensure that any TC/DRM solution proposed for procurement has a communications specification that meets the requirements of Policy 12, Communications specifications.

Guideline

Seek RFP disclosure of inclusion of TC/DRM functionality

Agencies are required by Policy 10, Awareness of TC/DRM functionality, to ensure that they are aware of the inclusion of TC/DRM functionality when deploying hardware or software, or using externally-provided information.

One measure that can be taken is to seek a declaration by vendors in RFP responses that propose IT products. The RFP should seek a declaration from the vendor as follows:

• Which of the proposed products include TC/DRM features, as defined by the TC/DRM Principles and Policies.
• Which features are activated by default, and which are present but de-activated.
• What functions, if any, rely on the TC/DRM features and will become unavailable when the TC/DRM features are disabled.

Alternately, the vendor can declare that TC/DRM functionality is absent.

An example of ‘present but de-activated’ is the Trusted Platform Module (TPM) which now ships in most new PCs and laptops, but is turned off by default, and requires user initiative to activate.

Of particular interest is the inclusion of functionality using:

• remote attestation
• system-controlled encryption of information (rather than user-controlled)
• date and duration-based restrictions (for instance, where software or information is only going to be accessible for three months from activation, or until 1 January 2008, or opened 20 times)
• information that installs its own reader or modifies the platform it runs on.

Guideline

Managing risks to privacy of personal information

Agencies are required by Policy 11, Knowledge of information flows, to be sufficiently aware of information flows into or out from their TC/DRM systems, to ensure that their systems don’t contribute to a breach of the Privacy Act. TC/DRM systems may involve transmission of encrypted information, or communications with third party systems, and this may result in a privacy risk profile that differs from most of an agency’s other applications. Suppliers of DRM-protected content in particular are likely to have an interest in who is using the information supplied and how they are using it.

The third party communications risk is as follows:

• Information viewing software may ‘phone home’ (i.e. contact the software vendor’s server) and transmit personal information (e.g. name of the user, name of the file they’re reading) without the agency’s full knowledge and acceptance.
• Alternately, the agency may be aware of it, but the individual user may not be informed.
• Alternately, all relevant parties may be informed, but a third party receiving the information may not comply with the Privacy Act, nor be subject to its provisions unless explicitly contracted to be so.

Agencies can avoid these risks by using software known or warranted to not collect personal information. If collection of personal data is to occur, then ensure that it is consistent with the requirements of the Act, and that there is legal protection against non-compliance by a third party. Users need to be advised in advance of what information would be collected, why, and how it will be managed, etc (as per the Privacy Act).

Guideline

Recognising policy implications of deploying software to browse DRM-encumbered information

Use of TC/DRM could require communications, e.g. to check rights against the information provider’s rights management server, or to attest that the viewing software is uncompromised. Policy 12, Communications specifications requires that agencies will only operate TC/DRM solutions when they are fully cognisant of the content of any communications, and the events or conditions that trigger them. Agencies should note that software which enables a DRM-protected file to be accessed, constitutes a TC/DRM solution, and so is subject to Policy 12, Communications specifications. Agencies should take measures to reduce the risk that staff will install such software without regard for the consequences, in order to get access to the information they wish to use.

Guideline

Perform impact assessment when activating trusted computing

Agencies should note that when a TPM (Trusted Platform Module) or other trusted computing equivalent is activated on a computer, there is the potential for it to be used by operating system or application software on the computer to encrypt previous openly accessible information in an attempt to make the platform more secure. This could also have the effect of preventing migration of information to a different application, or preventing usage of the information on a different machine. Agencies should perform an assessment to identify such possibilities and their impact, prior to activating trusted computing on their computers.

Guideline

Ensure system compatibility with TC/DRM Policies

Agencies should not deploy a TC/DRM system until they have satisfied themselves that its characteristics and usage will meet the requirements of the Trusted Computing and Digital Rights Management Principles and Policies. If in doubt, advice should be sought from the steward of the policies.

Agencies are encouraged to share information about TC/DRM products with each other, and make use of any information-sharing facilities provided by the steward.

Guideline

Preventing unwanted auto-installs of TC/DRM software

There have already been examples of TC/DRM software being bundled with encumbered information, and auto-installing when the recipient attempts to access the information, e.g. some Sony-BMG music CDs. The installation could be performed without the user’s knowledge. Agencies can reduce the likelihood of auto-install by locking down desktop and browser environments.

Guideline

Avoid deploying software in auto-update mode

Software products, especially those that already have TC/DRM features, should not be run in auto-update mode which could change their functionality, unless the agency can first assess how that change in functionality could affect government requirements.

4.5 Configurability

Guideline

Minimise needless exposure to unexpected TC/DRM side-effects

As TC/DRM security features become freely available, e.g. as standard hardware components, or as operating system or application system features, agencies should turn off such features by default. They should only be used in situations when the agency has identified a specific purpose for them, and their unique strengths are better than alternatives. Otherwise, their effects could be largely transparent until something goes wrong, or until the agency finds itself unable to make a change to software or to migrate data, as a consequence of passively allowing the TC/DRM features to operate.

4.6 Appropriate use

Guideline

Don’t deploy TC/DRM solely for email security

Agencies should avoid deploying DRM-based systems solely as a means of securing emails. Other systems can be used to achieve this goal (e.g. GSN or SEEMail for agency-to-agency communications), without the risks to accessibility of government information that DRM introduces.