Recommended Data Practices

donkeyswarmMobile - Wireless

Nov 24, 2013 (3 years and 6 months ago)

136 views



Recommended Data Practices

1








Recommended Data Practices

Based on ISO 27001/27002

standards















This material was compiled as part of a
joint educational project of the University of Miami Ethics Programs and the
Collaborative Institutional Training Initiative

(CITI) Prog
ram. It is b
ased on the International Organization for
Standardization / International Electrotechnical Commission standards 27001 and 27002 (2005 revision, formerly
known as ISO/IEC 17799).


It may be reused for non
-
commercial, education purposes with a
ppropriate credit to the
source; credit must include the ISO/IEC.



Recommended Data Practices

2




INDEX



FAQ about the RDPs


--
What are these, and where do they come from?


--
Are these intended as organizational policies?


--
Are these a

guide to personal data security practices?


--
What are the conditions of use?


--
What if I have questions?



Organization of Information Security


--
Objective


--
Management commitment


--
Allocation of resp
onsibilities


--
Coordination of efforts


--
Authorization processes


--
Confidentiality and non
-
disclosure agreements


--
Contacts with authorities


--
Contacts with special interest groups


--
Contacts and contracts with external parties


--
Contacts and contra
cts with customers


--
Independent review of information security



Privacy and security policies


--
Objective


--
Scope


--
Approval


--
Documentation


--
Communication, training and awareness


--
Periodic revie
w


--
Coordination with other policies



Risk assessment and treatment


--
Objective


--
Risk assessment


--
Risk treatment


--
Risk documentation



Human resourc
es security


--
Objective


--
Scope


--
Roles and responsibilities


--
Pre
-
employment screening



--
Terms and conditions of employment



--
Additional pre
-
employment agreements


--
Management responsibilities



--
Information security awareness, education and tr
aining



--
Disciplinary process



--
Termination responsibilities



--
Return of assets



--
Removal of access rights



Physical and environmental security


--
Objective


--
Physical security perimeter





--
Phy
sical entry control


--
Protection against external and environmental threats


--
Working in sensitive areas



--
Public access, delivery and loading access


--
Equipment siting and protection




Recommended Data Practices

3





--
Supporting utilities



--
Cabling security



--
Equipment mainten
ance


--
Removal of property to off
-
premises locations


--
Security of property off
-
premises



--
Secure disposal or re
-
use of property



Asset management


--
Objective


--
Inventory of assets



--
Types of asset
s



--
Ownership (control) of assets


--
Classification of assets



--
Labeling and handling


--
Acceptable use of assets



Asset acquisition, development and maintenance


--
Objective


--
Requirements analysis a
nd specification



--
Correct processing in applications


--
Use of cryptographic controls


--
Cryptographic key management


--
Security of operational software


--
Security of software code and test data


--
Controls against malicious code


--
Change control pro
cedures



--
Outsourced software development


--
Information leakage



--
Control of technical vulnerabilities



Authentication and access control


--
Objective


--
Access control policy


--
Access control policy

content


--
User access management policy


--
User registration


--
Privilege management


--
User password management


--
User access token management


--
Review of user access rights


--
Policy on use of network services


--
User authentication for remote connec
tions


--
Equipment/location identification in networks


--
Remote diagnostic and configuration port protection


--
Segregation in networks


--
Network connection control


--
Network routing control



--
Control of use of systems


--
Secure log
-
on procedures


--
U
ser identification and authentication


--
Password management system


--
Access token management system


--
Biometric access management system


--
Use of system utilities that override controls


--
Session time
-
out


--
Limitation of connection time and location


--
Information access restriction


--
Sensitive system isolation



Mobile computing and tele
-
working



Recommended Data Practices

4





--
Objective


--
Mobile computing and tele
-
working controls


--
Applicability


--
Portable devices and media
controls


--
Controls against malicious mobile code


--
Tele
-
working controls





Operations management


--
Objective


--
Documented operating procedures


--
Segregation of duties


--
Separation of development, t
est and operational facilities


--
Controls for centralized resources


--
Security of centralized resources


--
Network controls



--
Security of network services


--
Client device controls


--
Security of client devices



--
Inter
-
connected information systems



--
Internet and electronic messaging



--
Electronic commerce


--
On
-
line transactions


--
Publicly available information


--
Change and project management


--
System acceptance criteria


--
Incident and problem management


--
Configuration management


--
Service
level and capacity management


--
Third
-
party service contracts


--
Monitoring and review of third
-
party services


--
Managing changes to third
-
party services





Data lifecycle management


--
Objective


--
Sens
itivity level


--
Retention period


--
Information handling



--
Information back
-
up



--
Management of storage media


--
Physical media in transit


--
Electronic data transfers


--
Disposal of media


--
Security of system documentation



--
Information exchange po
licies and procedures



--
Exchange agreements






Monitoring and audit logging


--
Objective


--
Monitoring


--
Audit logging



--
Protection of log information


--
Retention of log information


--
Administrator

and operator logs


--
Fault logging


--
Clock synchronization





Information security incident management


--
Objective


--
Reporting information security events



--
Reporting information security weaknesses


--
Responsibilities and procedures for security incident response



--
Investigation of incidents



Recommended Data Practices

5





--
Collection of evidence



--
Learning from information security incidents





Business continuity (disaster r
ecovery) management


--
Objective


--
Information security in the business continuity management process



--
Business continuity and risk assessment



--
Developing and implementing continuity plans


--
Business continuity planning framework


--
Testing, maint
aining and re
-
assessing plans





Compliance with external and internal requirements


--
Objective


--
Identification of external and internal requirements



--
Documentation


--
Communication, training and awa
reness


--
Periodic review



Data retention classification


--
Objective


--
Applicability


--
Retention criteria



--
Retention

classification level


--
Mixed collections of data


--
Retention "freezes"


--
Retent
ion classification responsibilities


--
Retention classification review


--
Documentation and historical record



Data sensitivity classification


--
Objective


--
Applicability


--
Sensitivity criteria



--
Sens
itivity classification level


--
Sensitivity classification responsibilities


--
Sensitivity classification review


--
Documentation and historical record


--
Data sensitivity classification matrix



Terms and d
efinitions


--
Asset


--
Authority


--
Capability


--
Control


--
Countermeasure



--
Guideline


--
Data controller


--
Data owner


--
Data subject


--
Data system


--
Identified/identifiable data


--
Incident


--
Include(s)


--
Information processing facilities


--
Inf
ormation security


--
Information security event


--
Information security incident


--
Mobile computing


--
Personal data


--
Policy


--
Procedure



Recommended Data Practices

6





--
Risk


--
Risk analysis


--
Risk assessment


--
Risk evaluation


--
Risk management


--
Risk treatment


--
Safeguard


-
-
Standard


--
Tele
-
working


--
Third party


--
Threat


--
Vulnerability

More information

See
ISO 17799/27001 Community Portal

(
portal for the 27001/27002 user group
) and
ISO 27001 and ISO 27002
Directory

(t
racks progress of the 27000 standards
)



Recommended Data Practices

7





FAQ about the RDPs

What are these, and where do they come from?

"Recommended Data Practices" (RDP) are a template for data security policies and procedures, based on the
I
nternational Organization for Standardization / International Electrotechnical Commission standards 27001 and
27002 (2005 revision, formerly known as ISO/IEC 17799).

Are these intended as organizational policies?

No.


RDP are an educational resource, listi
ng
recommended

practices.


RDP can be used as a guide to the core
components of information security, and thus provide one possible framework for organizations

that are creating (or
updating) their data security policies and procedures.

RDP should be regar
ded only as a starting point.


Where statutes, regulations, certifications or internal stakeholders
require

more stringent data security

practices, those imperatives should control.


Are these a guide to personal data security practices?

No. RDPs are

inten
ded as policy/procedure frameworks for organizations.


If you would like information on personal
data security do/s and don't/s, the topics in the
Learn About

section

are more suitable.

What are the conditio
ns of use?

RDP

content may be reused for non
-
commercial, education purposes with appropriate credit to the source.


That
must include the ISO/IEC.


What if I have questions?

Comments and ques
tions about this version of the
RDP should be directed the
RDP Pr
oject Manager

at
pdpp@miami.edu
.

For more information about ISO/IEC standards, see the
ISO 17799/27001 Community Portal

(portal for the
27001/27002 user group) and the

ISO 27001 and ISO 27002 Directory

(tracks progress of the 27000 standards).



Recommended Data Practices

8




Organization of information security

Objective

• The organization’s administrative structure and its relationships with external parties should promote
effective managem
ent of all aspects of information security.


This includes maintaining the security of the
organization's information, its information processing facilities, and any information or facilities that are accessed,
processed, communicated to or managed by exte
rnal parties.

Management commitment

• Management at all levels should actively support security within the organization with
clear direction, demonstrated commitment, and explicit acknowledgement of information security responsibilities.


This could includ
e:



clear direction and visible support for information security initiatives, including providing appropriate
resources for information security controls;



coordination of information security efforts across the organization, including designation of inform
ation
security officer(s) and committee(s);



assuring formulation, review and approval of appropriate organization
-
wide information security policy;



periodic reviews of the effectiveness of information security policy, including external review as appropr
iate,
and updating of the policy as needed; and



appropriate management controls over new information facilities, systems and capabilities, including the
planning for such facilities.

Allocation of responsibilities

• All information security responsibilit
ies should be clearly defined.


This could include:



identification and clear definition of assets and associated security controls for each information facility; and



identification of the individual or individuals responsible for security for each informa
tion facility.

Coordination of efforts

• Information security activities should be coordinated by representatives from different parts
of the organization with relevant security roles and job functions.


This could include:



ensuring that all information s
ecurity controls are executed in compliance with the organization’s information
privacy and security policies
;



coordinated efforts to assess the adequacy of implemented controls, and to recommend additional
measures based on the assessments;



proposing re
finements to assessment methodologies and processes (e.g., risk assessment) subject to
management approval;



evaluating
information security incident management

data from across the organization, reporting these
data to appropriate management, and recommen
ding appropriate action based on the data;



identifying significant threat and vulnerability changes, both internal and external, and recommending
appropriate action; and



promoting security awareness and training for all persons affiliated with the organi
zation.

Authorization processes

• A management authorization process for new information processing facilities and
capabilities, or for significant changes to existing facilities and capabilities, should be defined and implemented.


This
could include:



fo
rmal approval of purpose and use for each new system, or for existing systems that are materially
changed;



certification that hardware/software used by the new (or changed existing) system meets organizational
standards;



approval of any non
-
standard func
tions, locations, or users, including approval of any personal, privately
-
owned or extra
-
organizational hardware/software/facilities to be used; and



certification that the new (or changed existing) system complies with all applicable security controls
man
dated by the security policy.

Confidentiality and non
-
disclosure agreements

• Requirements for confidentiality and non
-
disclosure agreements
(C/NDA) should reflect the organization's needs for protection of information.


Such agreements should be


Recommended Data Practices

9




periodic
ally reviewed.


This could include:



definition of the information, information type(s) or information system(s) to be protected;



C/NDA agreements for that information rendered in clear, legally
-
enforceable terms, that accord with all
relevant statutory
-
re
gulatory and private certificatory authorities;



responsibilities of signatories, including limitations on use or disclosure of information and adherence to
security controls;



terms of ownership of information, including any trade secret or intellectual p
roperty requirements;



expected duration of the agreement;



required actions when the agreement is terminated, including requirements to return or destroy information;



right to monitor compliance with the agreement;



processes for reporting of and notice
of breaches; and



expected actions to be taken in the event of a breach.

Contacts with authorities

• Appropriate contacts with external authorities should be maintained.


This could include:



development of policies, procedures and contact lists that speci
fy when and by whom external authorities
should be contacted;



specification of the timing and manner in which breaches shall be communicated to external authorities, to
ensure appropriate reporting.

Contacts with special interest groups

• Appropriate con
tacts with special interest groups or other specialist
security forums and professional associations should be maintained.

Contacts and contracts with external parties

• Agreements with third parties that involve accessing, processing,
communicating or man
aging the organization's information or information processing facilities should cover all
relevant security requirements.


Content of such agreements could include:



the applicable information security policy or policies of all contracting organizations;

n
ecessary controls to ensure compliance with these policies;



requirements for user and system administrator awareness and training efforts;



responsibilities related to hardware/software selection and configuration;



a clear and specific process of change
management;



a clear and specific process of incident management, including requirements for reporting, notification and
investigation;



problem resolution processes, including escalation steps;



overall reporting structure, report contents and frequency,
and reporting formats;



levels of acceptable/unacceptable service and service continuity;



definitions of verifiable performance criteria;



rights to monitor and audit activities;



intellectual property rights and ownership of data;



policies regarding sub
contractors; and



conditions for renegotiation/termination of the agreements.

Contacts and contracts with customers

• All identified security requirements should be addressed before giving
customers access to the organization's information or assets.


Con
trol considerations are similar to those for other
external parties.

Independent review of information security

• The organization's approach to managing information security and its
implementation should be reviewed independently at planned intervals, and

when there are significant changes to
internal structure or the external environment.

SOURCES: ISO
-
27001/27002:2005 sects 6.1.1


6.1.8, 6.2.1


6.2.3.



Recommended Data Practices

10




Privacy and security policies

Objective

• Data privacy/security policies should provide management dir
ection and support for data protection, in
accordance with the norms of professional ethics, business requirements and all relevant laws, regulations and
private certificatory requirements.

Scope

• The organization’s data privacy/security policies, taken a
s a whole, should provide clear controls for all data
collected, used or stored in the organization’s data processing, communications, and storage systems, as well as for
data collected, used or stored in the systems of external parties under contract with

the organization.

Approval

• Data privacy/security policies should be formally approved by appropriate organizational authorities.

Documentation

• Data privacy/security policies should be fully documented in designated organizational document
repositories
.


Policy documentation could include:



overall objectives and scope, including statements of management intent, supporting goals and principles;



listing of identified authorities (statutory, regulatory, private) and requirements that condition or control
data
protection activities, including an explanation or listing of policies, principles, standards and compliance
requirements relevant to the organization;



framework for setting policy objectives and components of the policies themselves, including a str
ucture for
risk assessment and risk management;



definitions of general and specific responsibilities for the organization’s data security management;



references to additional documentation that supports or underpins the policies; and



formal historical r
ecord of material changes to the policies and any accompanying approvals.

Communication, training and awareness

• Data privacy/security policies should be communicated to all relevant
affiliates of an organization, as well as relevant external parties, vi
a an appropriate training and awareness program.

Periodic review

• Data privacy/security policies should be reviewed at planned intervals, and when significant
changes in the external environment occur, to ensure their continued suitability, adequacy and e
ffectiveness.


Review
steps could include:



solicitation and integration of feedback from all interested parties inside and outside the organization;



independent contracted external reviews;



checklists of recommendations and requirements of relevant autho
rities;



consideration of trends in threat types and threat capabilities, system vulnerabilities, and available
technologies for counter
-
measures and mitigation;



consideration of trends in compliance requirements of federal, state, local and private certi
ficatory
authorities;



consideration of trends in and anticipated changes to the organizational environment, business
circumstances, and resource availability;



historical data on information security incidents at the organization itself and at peer instit
utions; and



formal historical record of the reviews undertaken as part of policy development and refinement, and their
outcomes.

Coordination with other policies

• Review of data privacy/security policies should include consideration of other
relevant or
ganizational policies, to minimize inconsistencies and gaps.


This could include:



identification of all other relevant policies; and



inclusion of the representatives from the areas responsible for such policies in the periodic review of
information securi
ty policy.

SOURCES: ISO
-
27001/27002:2005, sects. 5.1.1


5.1.2.



Recommended Data Practices

11




Risk assessment and treatment

Objective

• Risk assessment and treatment should identify, quantify and prioritize risks in light of objectives and risk
criteria of the organization, and ensur
e steps to appropriately mitigate the identified risks in light of those objectives
and risk criteria.

Risk assessment

• Risk assessments should be performed, and updated at appropriate intervals, for all information
facilities.


This could include:



system
atic methods of assessing risks (threats, threat capabilities and facilities’ vulnerabilities to those
capabilities);



systematic methods of comparing assessed risks against risk criteria;



periodic re
-
assessments to address changes in security requirement
s and/or in the risk environment; and



clearly defined scope and limitations of the analyses, including specification of the systems assessed, the
means of assessment employed, and relationships with other risk assessments as appropriate.

Risk treatment



Risk treatment efforts should be undertaken to mitigate identified risks, using appropriate
administrative, technical and physical security controls.


This could include:



applying appropriate controls to avoid, eliminate or reduce risks as dictated by the

risk analysis;



transferring some risks to third parties as appropriate (e.g., by insurance), or



knowingly and objectively accepting some risks.

Risk treatments should take account of:



legal
-
regulatory and private certificatory requirements;



organizati
onal objectives, operational requirements and constraints; and



costs of implementation and operation relative to risks being reduced.

Risk documentation

• Risk treatment choices made, and the reasons for them, should be formally documented.

SOURCES: ISO
-
27001/27002:2005 sects. 4.1


4.2.



Recommended Data Practices

12




Human resources security

Objective

• Human resources policies and practices should reduce the risk of theft, fraud or misuse of information
facilities by employees, contractors and third
-
party users.

Scope

• The organiza
tion’s human resources policies, taken as a whole, should extend to all the persons within and
external to the organization that do (or may) use information or information processing facilities.


This could include:



tailoring requirements to be suitable fo
r particular roles within the organization for which persons are
considered;



ensuring that persons fully understand the security responsibilities and liabilities of their role(s);



ensuring awareness of information security threats and concerns, and the n
ecessary steps to mitigate those
threats; and



equipping all persons to support organizational
privacy and security policies

in the course of their normal
work, through appropriate training and awareness programs that reduce human error; and



ensuring that

persons exit the organization, or change employment responsibilities within the organization, in
an orderly manner.

Roles and responsibilities

• Security roles and responsibilities of employees, contractors and third
-
party users
should be defined and doc
umented in accordance with the organization's

information privacy and

security policies.


This could include:



requirements to act in accordance with the organization's policies, including execution of all processes or
activities particular to the individua
l's role(s);



requirements to protect all information assets from unauthorized access, use, modification, disclosure,
destruction or interference;



requirements to report security events, potential events, or other risks to the organization and its assets;

and



assignment of responsibility to individuals for actions taken or, where appropriate, responsibility for actions
not taken, along with appropriate sanctions for mal
-
, mis
-

or nonfeasance.

Pre
-
employment screening

• Appropriate background verification

checks (“screening”) for all candidates for
employment, contractor status, or third party user status, should be carried out by the organization or appropriate
third parties.


This could include screening that:



is commensurate with the organization's busi
ness needs, and with relevant legal
-
regulatory
-
certificatory
requirements;



takes into account the classification(s)/sensitivity(ies) of the information or information processing facilities to
be accessed, and the perceived risks;



takes into account all p
rivacy, protection of personal data and other relevant employment legislation; and



includes, where appropriate, components such as identity verification, character references, CV verification,
criminal and credit checks.



Terms and conditions of employme
nt

• Employees, contractors, and third party users should agree to and sign a
statement of rights and responsibilities for their affiliation with the organization, including rights and responsibilities
with respect to information privacy and security.


Thi
s statement could include specification of:



the scope of access and other privileges the person will have, with respect to the organization's information
and information processing facilities;



the person's responsibilities, under legal
-
regulatory
-
certific
atory requirements and organizational policies,
specified in that or other signed agreements (see
Additional pre
-
employment agreements
);



responsibilities for classification of information and management of organizational information facilities that
the pe
rson may use;



procedures for handling sensitive information, both internal to the organization and that received from or
transferred to outside parties;



responsibilities that extend outside the organization's boundaries (e.g., for
mobile devices and tele
-
working
);



the organization's responsibilities for handing of information related to the person him/herself, generated in


Recommended Data Practices

13




the course of an employment, contractor or other third party relationship;



an organizational code of conduct or code of ethics to th
e employee, contractor or third party; and



actions that can be anticipated, under the organization's disciplinary process, as a consequence of failure to
observe security requirements.

Additional pre
-
employment agreements

• Where appropriate, employees,
contractors and third
-
party users should
be required to sign, prior to being given access or other privileges to information or information processing facilities,
additional:



confidentiality or non
-
disclosure agreements (see
Confidentiality agreements
); an
d/or



acceptable use of assets agreements.

Management responsibilities

• Management should require employees, contractors and third party users to apply
security controls in accordance with established policies and procedures of the organization.


This co
uld include:



appropriately informing all employees, contractors and third party users of their information security roles
and responsibilities, prior to granting access to sensitive information or information systems (see
Terms and
conditions of employment
);



providing all employees, contractors and third parties with guidelines/rules that state the security
expectations of their roles within the organization;



achieving an appropriate level of awareness of security controls among all employees, contractors

and third
parties, relevant to their roles and responsibilities,



achieving an appropriate level of skills and qualifications, sufficient to execute those security controls;



assuring conformity to the terms and conditions of employment related to privacy

and security;



motivating adherence to the privacy and security policies of the organization, such as with an appropriate
sanctions policy; and



mitigating the risks of a failure to adhere to policies, by ensuring that all persons have appropriately
-
limit
ed
access to the organization's information and information facilities (see
Authentication and access control
).

Information security awareness, education and training

• All employees of the organization, and, where relevant,
contractors and third party us
ers, should receive appropriate awareness training in and regular updates of
organizational policies and procedures relevant to their job functions.


This could include:



a formal induction process that includes information privacy and security training, pr
ior to being granted
access to information or information systems; and



ongoing training in security control requirements, legal
-
regulatory
-
certificatory responsibilities, and generally
accepted security procedures, suitable to the person's rules and respo
nsibilities.

Disciplinary process

• There should be a formal disciplinary process for employees who have committed a security
breach.


This could include requirements for:



appropriate evidentiary standards to initiate investigations (e.g., “reasonable sus
picion” that a breach has
occurred);



appropriate investigatory processes, including specification of roles and responsibilities, standards for
collection of evidence and chain of custody of evidence;



disciplinary proceedings that observe reasonable requi
rements for due process and quality of evidence;



reasonable evidentiary and burden
-
of
-
proof standards to determine fault, that ensure correct and fair
treatment for persons suspected of a breach; and



sanctions that appropriately take into consideration f
actors such as the nature and gravity of the breach, its
impact on operations, whether it is a first or repeat offense, whether or not the violator was appropriately
trained, whether or not the violator exercised due care or exhibited negligence.

Terminat
ion responsibilities

• Responsibilities and practices for performing employment termination or change of
employment should be clearly defined and assigned.


This could include:



termination processes that ensure removal of access to all information resource
s (see also

Removal of
access rights
);



Recommended Data Practices

14






changes of responsibilities and duties within the organization processed as a termination (of the old position)
and re
-
hire (to the new position), using standard controls for those processes unless otherwise indicate
d;



processes ensuring that other employees, contractors and third parties are appropriately informed of a
person's changed status; and

any post
-
employment responsibilities are specified in the terms and conditions of employment, or a
contractor's or third

party's contract.

Return of assets

• All employees, contractors and third parties should return all of the organization's information and
physical assets in their possession upon termination of the employment relationship or contract.


This could include
:



a formal process for return (e.g., checklists against inventory) of the organization's hardware, software and
data media;



a formal process for return or destruction of organizational data of any kind; and



where the employee, contractor or third party u
ses personal equipment, requirements for secure erasure of
software and data belonging to the organization.

Removal of access rights

• Access rights to information and information processing facilities should be removed
upon termination of the employment
or contractual relationship.


This could include:



changes of employment or contractual status include removal of all rights associated with prior roles and
duties, and creation of rights appropriate to the new roles and duties;



removal or reduction of acc
ess rights in a timely fashion; and



removal or reduction of access rights prior to the termination, where risks indicate this step to be appropriate
(e.g., where termination is initiated by the organization, or the access rights involve highly sensitive
i
nformation or facilities).

SOURCES: ISO
-
27001/27002:2005 sects. 8.1


8.3.



Recommended Data Practices

15




Physical and environmental security

Objective

• Unauthorized physical access, loss, damage or interference to the organization's premises and
infrastructure, or interruptions to i
ts critical operations, should be prevented using physical and environmental controls
appropriate to the identified risks and the value of the assets protected.

Physical security perimeter

• Security perimeters should be used to protect sensitive areas tha
t contain information
and information processing facilities.


Physical security for other offices, rooms and facilities should also be designed
and implemented, commensurate to the identified risks and the value of the assets at risk in each setting.


This

could
include:



clearly defined and marked perimeters, except in situations where hidden or disguised perimeters would
enhance security;





restrictions on information about facilities, including directory and location information, where this would
enhance
security;



use of perimeter walls, windows and doors, protected with bars, locks, alarms and other supplemental
measures as appropriate;



controlled entry doors/gates, with manned reception desks or automated lock/ID systems, to control
passage into the re
stricted area;



use of additional physical barriers, where appropriate to prevent unauthorized access or physical
contamination;



provision of appropriate protection against fire, water or other reasonably anticipated environmental threats;



use of appropr
iate intrusion detection systems, such as motion and perimeter alarms, audio and video
surveillance; and



measures designed with sufficient redundancy such that a single point of failure does not compromise
security.

Physical entry control

• Sensitive are
as of information processing facilities should be protected by appropriate entry
controls to ensure that only authorized personnel are allowed access.


Appropriate entry controls for other offices,
rooms and facilities should also be designed and implement
ed, commensurate to the identified risks and the value of
the assets at risk in each setting.


This could include:



password, “token” or biometric authentication mechanisms for entry points (e.g., keycard and/or PIN);



supplementing automated authentication

methods with security personnel on site, where appropriate for
highly sensitive assets;



recording of date/time of entry and exit, and/or video recording of activities in the entry/exit area, as
appropriate;



requirement for authorized personnel to wear v
isible identification, and to report persons without such
identification;



appropriate authorization and monitoring procedures for third
-
party personnel who must be given access to
the restricted area; and



regular review and, when indicated, revocation of

access rights to secure areas (see also
Human
resources security
);



use of highly visible controls, where appropriate as a deterrent;



use of unobtrusive or hidden controls/facilities, where appropriate for highly sensitive assets.

Protection against ext
ernal and environmental threats

• Physical protection against damage from fire, flood, wind,
earthquake, explosion, civil unrest and other forms of natural and man
-
made risk should be designed and
implemented.


This could include:



consideration of probabil
ities of various categories of risks and value of assets to be protected against those
risks;



consideration of security threats posed by neighboring facilities and structures;



appropriate equipment (e.g., fire
-
fighting devices) and other counter
-
measures

provided and suitably located
on site; and



appropriate off
-
site/remote location for backup facilities and data copies.



Recommended Data Practices

16




Working in sensitive areas

• Protective measures and guidelines for working in sensitive areas should be designed
and implemented.


Th
is could include:



limiting personnel's awareness of, and activities within, a sensitive location on a need
-
to
-
know/need
-
to
-
do
basis;



limiting or prohibiting unsupervised/unmonitored work in sensitive areas, both for safety reasons and to
avoid opportuniti
es for mis
-

or malfeasance;



keeping vacant sensitive areas locked, subject to periodic inspection, and/or monitored remotely as
appropriate by video or other technologies; and



limiting video, audio or other recording equipment, including cameras in porta
ble devices, in sensitive areas.

Public access, delivery and loading access

• Access points such as delivery and loading areas, and other points
where unauthorized persons may enter the premises, should be controlled.


This could include:



limits on access

to the delivery and loading areas, and to other public access areas, to the degree consistent
with required operations;



inspection of incoming and outgoing materials, and separation of incoming and outgoing shipments, where
possible; and



isolation of th
ese areas from information processing facilities and areas where information is stored, where
possible.

Equipment siting and protection

• Equipment should be sited and protected to reduce the risks from environmental
threats and hazards, and to reduce the

opportunities for unauthorized access by human threats.


This could include
siting:



to minimize unnecessary risks to the equipment, and to reduce the need for unauthorized access to
sensitive areas;



to isolate items requiring special protection, to minim
ize the general level of protection required;



with particularized controls as appropriate to minimize physical threats
--

e.g., theft or damage from
vandalism, fire, water, dust, smoke, vibration, electrical supply variance, or electromagnetic radiation;
and



guidelines for eating, drinking, smoking or other activities in the vicinity of equipment.

Supporting utilities

• Equipment should be protected from power failures, telecommunications failures, and other
disruptions caused by failures in supporting u
tilities such as HVAC, water supply and sewage.


This could include:



assuring that the supporting utilities are adequate to support the equipment under normal operating
conditions; and



making reasonable provision for redundant equipment and backups (e.g.,

a UPS) in the event of supporting
utility failure.

Cabling security

• Power and telecommunications cabling carrying sensitive data or supporting information services
should be protected from interception or damage.


This could include:



physical measures
to prevent unauthorized interception or damage, including additional protections for
sensitive or critical systems;



alternate/backup routings or transmission media where appropriate, particularly for critical systems;



clearly identified cable and equipme
nt markings, except where security is enhanced by removing/hiding
such markings; and



documentation of patches and other maintenance activities.

Equipment maintenance

• Equipment should be correctly maintained to ensure its continued availability and
inte
grity.


This could include:



appropriate preventive maintenance, as specified by the manufacturer or regulatory
-
certificatory authorities;



documentation of all maintenance activities, including scheduled preventive maintenance;



documentation of all suspect
ed or actual faults, and associated remediation, in accordance with an incident
management policy;



Recommended Data Practices

17






maintenance only by authorized, certified employees or contracted third parties; and



appropriate security measures, such as clearing of information or supe
rvision of maintenance processes,
appropriate to the sensitivity of the information on or accessible by the devices being maintained.

Removal of property to off
-
premises locations

• Equipment, information or software should not be take off
-
premises withou
t prior authorization and subject to appropriate restrictions. This could include:



limitations on types or amounts of information, or types of equipment, that may be taken off
-
site;



recording of off
-
site authorizations and inventory of equipment and infor
mation taken off
-
site; and



for persons authorized to take equipment or information off
-
site, appropriate awareness of security risks
associated with off
-
premises environments and training in appropriate controls and counter
-
measures.

Security of property

off
-
premises

• Appropriate security measures should be applied to off
-
site equipment, taking
into account the different risks of working outside the organization’s premises.


This could include:



authorization of any off
-
site processing of organizational i
nformation, regardless of the ownership of the
processing device(s);



security controls for equipment in transit and in off
-
site premises, appropriate to the setting and the
sensitivity of the information on or accessible by the device;



adequate insurance

coverage, where third
-
party insurance is cost
-
effective; and



employee and contractor awareness of their responsibilities for protecting information and the devices
themselves, and of the particular risks of off
-
premises environments.



Secure disposal or

re
-
use of property

• All equipment containing storage media, and independent storage media
devices, should be checked to ensure that sensitive data and licensed software has been removed or securely
overwritten prior to disposal.


This could include:



use
of generally accepted methods for secure information removal, appropriate to the sensitivity of the
information known or believed to be on the media; and



secure information removal by appropriately trained personnel, or verification of secure information
removal
by appropriately trained personnel.

SOURCES: ISO
-
27001/27002:2005 sects. 9.1


9.2.



Recommended Data Practices

18




Asset management

Objective

• Asset management should achieve and maintain appropriate protection of organizational assets, to
ensure continuity of operations and
security of information.

Inventory of assets

• All significant information assets should be clearly identified and accounted for in an inventory
listing, and have assigned owners (controllers, stewards) who are responsible for their appropriate protection.


This
could include:



core attributes for each asset, including make/model/format, creation/manufacture date and any other
information necessary to specify type;



one or more identifiers for the asset, at least one of which should be unique itself or uniqu
e in combination
with other attributes (e.g., serial number, asset number, service tag number, part number, release number,
stock
-
keeping unit, universal product code);



additional attributes relevant to categorizing the asset (e.g., model or release year,

size or form factor,
color);



assigned owner (controller, steward);



logical or physical location, with a range
-
classification of physical locations if portable;



status and location of backup devices or backup information (if appropriate);



status and lo
cation of license information (if appropriate);



business value, security classification and level of protection;



acquisition cost, current depreciated value, purchase order or work order for acquisition, or other relevant
accounting attributes; and



any
additional data on the asset necessary to allow recovery from a disaster or otherwise assure continuity
of operations.

Types of assets

• Asset types managed within one or more “inventories” may include, depending on organizational
requirements:



hardware a
ssets, including computer and communications equipment, fixed location and removable storage
media;



software assets, including application and system software, development tools and utilities;



data assets in databases or data files;



contracts or agreeme
nts, systems documentation, user manuals, training materials, operational or support
procedures associated with these assets;



supporting services, including general utilities like HVAC, lighting and electric power supply;



support staffing, including qual
ifications and experience; and



intangibles, such as reputation and image of the organization.

Ownership (control) of assets

• All assets should be “owned” (controlled) by a designated person or part of the
organization, who/which has clearly
-
specified re
sponsibilities for the asset’s management.


This could include:



the name of the owner, with periodic review of appropriateness of assigned ownership;



owner responsibilities, including duties to ensure accurate data about the asset and appropriate
classifi
cation of any information on it; and



definition and periodic review of access restrictions and other controls associated with the asset.

Classification of assets

• Information assets should be classified in terms of value and criticality to the organizat
ion,
sensitivity and legal requirements.


This could include:



assigning responsibility for the asset owner or a central organizational authority to make this classification;



periodic review to ensure that classifications appropriately reflect business nee
ds, legal
-
regulatory
-
certificatory requirements and balance confidentiality
-
integrity
-
availability concerns against other
organizational goals.

Labeling and handling

• An appropriate set of procedures for asset labeling and handling should be developed by



Recommended Data Practices

19




the organization, and implemented in accordance with the classification scheme(s) adopted by the organization.


This
could include:



responsibility of the asset owner to assure/confirm classification and labeling, and subsequent handling
consistent with th
at label;



classifications that cover all information processing facilities and

information in all forms and media;



procedures for establishing ownership and chain of custody; and



procedures for logging and reporting security incidents associated with th
e asset.

Acceptable use of assets

• Rules for the acceptable use of information assets and assets associated with
information processing facilities should be identified, documented and implemented.


This could include rules and
guidelines for:



general use

of the organization’s resources, systems and devices;



use of particular systems or services (e.g., email,


Internet);



mobile devices;



non
-
mobile devices used off
-
site; and



asset users’ awareness of these rules and guidelines, including an appropriate
educational program.



SOURCE: ISO
-
27001/27002:2005 sects. 7.1


7.2



Recommended Data Practices

20




Asset acquisition, development and maintenance

Objective

• Security should be an integral part of asset acquisition, development/deployment and maintenance
processes.

Requirements analys
is and specification

• Statements of business requirements for new information systems, or
enhancements to existing information systems, should include specification of the requirements for security controls.


This could include:



consideration of legal
-
reg
ulatory
-
certificatory standards and business value of information assets affected by
the new/changed systems;



consideration of administrative, technical and physical controls available to support security for the systems;



integration of these controls ea
rly in the system design and requirements specification; and



a formal plan for testing and acceptance, including independent evaluation where appropriate.

Correct processing in applications

• Systems should be validated with respect to their handling of
input data,
internal processing, inter
-
process messaging and output data to prevent errors, loss, unauthorized modification or
misuse of information.


This could include:



certification (rating) of asset performance prior to acquisition by external parties;




audit/review of asset performance after acquisition;



on
-
going automatic or manual methods of data verification and cross
-
checking; and



defined responsibilities and processes for responding to errors detected by these automatic or manual
methods.

Use o
f cryptographic controls

• Appropriate cryptographic controls should be developed and implemented protect
the confidentiality, integrity and authenticity of information.


This could include:



statement of general principles and management approach to the us
e of cryptographic controls;



a thorough risk assessment to determine cryptographic implementation, that considers appropriate algorithm
selections, key management and other core features of the implementation;



consideration of legal restrictions on techn
ology deployments;



application, as appropriate, of the cryptographic controls to data at rest and fixed
-
location devices, data
transported by mobile/removable media and embedded in mobile devices, and data transmitted over
communications links; and



speci
fication of roles and responsibilities for implementation of and the monitoring of compliance with the
policy.

Cryptographic key management

• Key management policies and processes should be implemented to support an
organization's use of cryptographic tec
hniques.


This could include standards for:



distributing, storing, archiving and changing/updating keys;



recovering, revoking/destroying and dealing with compromised keys; and



logging all transactions associated with keys.



Security of operational softw
are

• Procedures should be implemented to control the installation of software on
operational systems, to minimize the risk of interruptions to or corruption of information services.


This could include:



ad hoc modifications to software packages discourage
d (or prohibited), limited to necessary changes, and
all changes strictly controlled;



updating performed only with appropriate management authorization;



updating performed only by appropriately trained personnel;



only appropriately tested and certified
software deployed to operational systems;



appropriate change management and configuration control processes for all stages of updating, including
documentation of the nature of the change and the processes used to implement it;



a rollback strategy in pla
ce, including retention of prior versions as a contingency measure; and



Recommended Data Practices

21






appropriate audit logs maintained to track changes.



Security of software code and test data

• Access to software source code should be appropriately restricted.


This
could include:



appropriate administrative, physical and technical safeguards for program source libraries, documentation,
designs, specifications, verification and validation plans;



test data appropriately logged, protected and controlled; and



maintenance and copying
of these materials subject to strict change management and other controls.

Controls against malicious code

• Appropriate controls should be implemented for prevention, detection and
response to malicious code.


This could include:



formal policies prohibit
ing the use or installation of unauthorized software, including a prohibition of obtaining
data and software from external networks;



formal policies requiring protective measures, such as installation of anti
-
virus and anti
-
spyware software,
and for the r
egular (automatic) updating of such software;



periodic reviews/scans of installed software and the data content of systems to identify and, where possible,
remove any unauthorized software;



defined procedures for response to identification of malicious c
ode or unauthorized software;



continuity/recovery plans to deal with system interruptions and failures caused by malicious code; and



user awareness training on these policies and methods.

Change control procedures

• Implementation of changes should be d
ocumented and controlled through the use of
formal change control procedures.


This could include:



formal processes for specification, testing, quality control and managed implementation;



risk assessments, analyses of actual and potential impacts of chang
es, and specifications of any security
controls required;



budgetary or other financial analyses to assess adequacy of resources;



formal agreements to and approvals of changes by appropriate management;



requirements for appropriate notifications of all a
ffected parties prior to implementations, on the nature,
timing and likely impacts of the changes;



scheduling of changes to minimize the adverse impact on business processes; and



review and testing of critical business processes after implementation to e
nsure that there have been no
adverse effects.

Outsourced software development

• Outsourced software development should be appropriately supervised and
monitored by the organization, using controls similar to those for internal development.

Information le
akage

• Opportunities for information leakage should be appropriately minimized or prevented.


This
could include:



risk assessment of the probable and possible mechanisms for information leakage, and consideration of
appropriate countermeasures;



regular m
onitoring of likely information leak mechanisms and sources; and



end
-
user awareness and training on preventive strategies (e.g., to remove meta
-
data in transferred files).

Control of technical vulnerabilities

• Timely information about technical vulnerab
ilities of information systems used
by the organization should be obtained, evaluated in terms of organizational exposure and risk, and appropriate
countermeasures taken.


This could include:



a complete inventory of information assets sufficient to identif
y systems put at risk by a particular technical
vulnerability;



procedures to allow timely response to identification of technical vulnerabilities that present a risk to any of
the organization's information assets, including a timeline based on the level
of risk; and



Recommended Data Practices

22






defined roles and responsibilities for implementation of countermeasures and other mitigation procedures.

SOURCES: ISO
-
27001/27002:2005 sects. 12.1.1


12.1.6.



Recommended Data Practices

23




Authentication and access control

Objective

• Authentication and access control
measures should ensure appropriate access to information and
information processing facilities


including mainframes, servers, desktop and laptop clients, mobile devices,
applications, operating systems and network services


and prevent inappropriate acc
ess to such resources.

Access control policy

• An access control policy should be established, documented and periodically reviewed,
based on business needs and external requirements.


Access control policy and associated controls could take
account of:



se
curity issues for particular data systems and information processing facilities, given business needs,
anticipated threats and vulnerabilities;



security issues for particular types of data, given business needs, anticipated threats and vulnerabilities;



r
elevant legislative, regulatory and certificatory requirements;



relevant contractual obligations or service level agreements;



other organizational policies for information access, use and disclosure; and



consistency among such policies across systems an
d networks.

Access control policy content

• Access control policies generally should include:



clearly stated rules and rights based on user profiles;



consistent management of access rights across a distributed/networked environment;



an appropriate mix o
f administrative, technical and physical access controls;



administrative segregation of access control roles
--

e.g., access request, access authorization, access
administration;



requirements for formal authorization of access requests ("provisioning");
and



requirements for authorization and timely removal of access rights ("de
-
provisioning").



User access management policy

• Policies should include a focus on ensuring authorized user access, and
preventing unauthorized user access, to information and i
nformation systems.


This could include:



formal procedures to control the allocation of access rights;



procedures covering all stages in the life
-
cycle of user access, from provisioning to de
-
provisioning; and



special attention to control of privileged (
"super
-
user") access rights.

User registration

• Formal user registration and de
-
registration procedures should be implemented, for granting and
revoking access to all information systems and services.


In addition to assignment of unique user
-
IDs to each

user,
this could include:



documentation of approval from the information system owner for each user's access;



confirmation by a reviewing party (supervisor or other personnel) that each user's access is consistent with
business purposes and with other se
curity controls (e.g., segregation of duties);



giving each user a written statement of their access rights and responsibilities;



requiring users to sign statements indicating they understand the conditions of access (see also
Terms and
conditions of empl
oyment

and
Confidentiality agreements
);



ensuring access is not granted until all authorization procedures are completed;



maintaining a current record of all users authorized to use a particular system or service;



immediately changing/eliminating access
rights for users who have changed roles or left the organization;
and



checking for and removing redundant or apparently unused user
-
IDs.

Privilege management

• Allocation and use of access privileges should be restricted and controlled.


This could
inclu
de:



development of privilege profiles for each system, based on intersection of user profiles and system
resources;



Recommended Data Practices

24






granting of privileges based on these standard profiles when possible;



a formal authorization process for all privileges, with additional
review requirements for exceptions to
standard profiles; and



maintaining a current record of privileges granted.

User password management

• Allocation of passwords should be controlled through a formal management
process.


This could include:



requiring u
sers to sign a statement indicating they will keep their individual passwords confidential and, if
applicable, keep any group passwords confidential solely within the group;



secure methods for creating and distributing temporary, initial
-
use passwords;



f
orcing users to change any temporary, initial
-
use password;



forcing users to periodically change passwords, and to use strong passwords at each change;



development of procedures to verify a user's identity prior to providing a replacement password ("pass
word
reset");



prohibiting "loaning" of passwords;





prohibiting storage of passwords on computer systems in unprotected form; and



prohibiting use of default vendor passwords, where applicable.

User access token management

• Allocation of access tokens,
such as key
-
cards, should be controlled through a
formal management process.


This could include:



requiring users to sign a statement indicating they will keep their access tokens secure;



secure methods for creating and distributing tokens;



use of two
-
fa
ctor tokens (token plus PIN) where appropriate and technically feasible;



development of procedures to verify a user's identity prior to providing a replacement token; and



prohibiting "loaning" of tokens.

Review of user access rights

• Each user's access

rights should be periodically reviewed using a formal process.


This could include:



review at regular intervals, and after any status change (promotion, demotion, transfer, termination); and



more frequent review of privileged ("super user") access rights
.

Policy on use of network services

• Users should be provided with access only to the network services that they
have been specifically authorized to use.


This could include:



authorization procedures for determining who is allowed to access to which net
works and network services,
consistent with other access rights; and



policies on deployment of technical controls to limit network connections.

User authentication for remote connections

• Where appropriate and technically feasible, authentication method
s
should be used to control remote access to the network.

Equipment/location identification in networks

• Where appropriate and technically feasible, access to the network
should be limited to identified devices or locations.

Remote diagnostic and configur
ation port protection

• Physical and logical access to diagnostic and configuration
ports should be appropriately controlled.


This could include:



physical and technical security for diagnostic and configuration ports; and



disabling/removing ports, servic
es and similar facilities which are not required for business functionality.



Segregation in networks

• Where appropriate and technically feasible, groups of information users and services
should be segregated on networks.


This could include:



Recommended Data Practices

25






separation
into logical domains, each protected by a defined security perimeter; and



secure gateways between/among logical domains.

Network connection control

• Capabilities of users to connect to the network should be appropriately restricted,
consistent with acce
ss control policies and applications requirements.


This could include:



filtering by connection type (e.g., messaging, email, file transfer, interactive access, applications access);
and



additional authentication and access control measures as appropriate
.

Network routing control

• Routing controls should be implemented to ensure that computer connections and
information flows do not breach the access control policies of/for applications on the network.


This could include:



positive source and destination

address checking; and



routing limitations based on the access control policy.

Control of use of systems

• Controls should be implemented to restrict operating system access to authorized
users, by requiring authentication of authorized users in accordan
ce with the defined access control policy.


This
could include:



providing mechanisms for authentication by knowledge
-
, token
-

and/or biometric
-
factor methods as
appropriate;



recording successful and failed system authentication attempts;



recording the us
e of special system privileges; and



issuing alarms when access security controls are breached.

Secure log
-
on procedures

• Access to systems should be controlled by secure log
-
on procedures.


This could
include:



display of a general notice warning about a
uthorized and unauthorized use;



no display of system or application identifiers until successful log
-
on;



no display of help messages prior to successful log
-
on that could aid an unauthorized user;



validation or rejection of log
-
on only on completion of
all input data (e.g., both user
-
ID and password);



no display of passwords as entered (e.g., hide with symbols);



no transmission of passwords in clear text;



limits on the number of unsuccessful log
-
on attempts in total or for a given time period;



limits

on the maximum and minimum time for a log
-
on attempt;



logging of successful and unsuccessful log
-
on attempts; and



on successful log
-
on, display date/time of last successful log
-
on and any unsuccessful attempts.

User identification and authentication


All system users should have a unique identifier ("user
-
ID") for their
personal use only.


A suitable authentication technique


knowledge
-
, token
-

and/or biometric
-
based


should be
chosen to authenticate the user.


This could include:



shared user
-
IDs are

employed only in exceptional circumstances, where there is a clear justification;



generic user
-
IDs (e.g., "guest") are employed only where no individual
-
user
-
level audit is required and
limited access privileges otherwise justify the practice;



strength
of the identification and authentication methods (e.g., use of multiple authentication factors) are
suitable to the sensitivity of the information being accessed;


and



regular user activities are not performed from privileged accounts.

Password managemen
t system

• Systems for managing passwords should ensure the quality of this authentication
method.


This could include:



log
-
on methods enforce use of individual user
-
IDs and associated passwords;



set/change password methods enforce choice of strong passwo
rds;



Recommended Data Practices

26






force change of temporary password on first log
-
on;



enforce password change thereafter at reasonable intervals;



store passwords separately from application data; and



store and transmit passwords in encrypted form only.

Access token management sys
tem

• Systems for managing access tokens should ensure the quality of this
authentication method.

Biometric access management system

• Systems for managing access via biometrics should ensure the quality of
this authentication method.

Use of system utiliti
es that override controls

• Use of system utilities that are capable of overriding other controls
should be restricted, and appropriately monitored whenever used (e.g., by special event logging processes).

Session time
-
out

• Interactive sessions should shu
t down and “lock out” the user after a defined period of inactivity.


Resumption of the interactive session should require re
-
authentication.


This could include:



time
-
out periods that reflect risks associated with type of user, setting of use and sensiti
vity of the
applications and data being accessed;



waiver or relaxation of time
-
out requirement when it is incompatible with a business process, provided other
steps are taken to reduce vulnerabilities (e.g., increased physical security, reduction in acces
s privileges,
removal of sensitive data, removal of network connection capabilities).

Limitation of connection time and location

• Restrictions on connection times should be used to provide additional
security for high
-
risk applications or remote communic
ations capabilities.


This could include:



requiring re
-
authentication at timed intervals;



restricting overall connection duration or connection time period (e.g., normal office hours); and





restricting connection locations (e.g., to IP address ranges).

Information access restriction

• Access to information and application system functions should be restricted in
accordance with a defined access control policy that is consistent with the overall organizational access policy.


This
could include any of the

controls listed herein.

Sensitive system isolation

• Sensitive systems should have a dedicated (isolated) computing environment.


This
could include:



explicit identification and documentation of sensitivity by each system/application controller (owner);



construction of appropriately isolated environments where technically and operationally

feasible; and



explicit identification and acceptance of risks when shared facilities and/or resources must be used.

SOURCES: ISO/IEC 27001/27002:2005 sects. 11.1


11
.6



Recommended Data Practices

27




Mobile computing and tele
-
working

Objective

• Policies for use of mobile computing devices and work in off
-
site settings (“tele
-
work”) should aim for
information security commensurate with that for non
-
mobile devices and work in on
-
site settings, where

technically
and operationally feasible.

Mobile computing and tele
-
working controls

• Controls should be implemented that are commensurate with the
types of users, settings of mobile/tele
-
working use, and sensitivity of the applications and data being acce
ssed from
mobile/tele
-
working settings.

Applicability

• Controls on mobile computing and tele
-
working should extend to any extra
-
institutional or non
-
traditional work setting where the organization’s information is accessed.


This could include controls on
:



desktop computers used off
-
premises;



laptop, notebook, and palmtop computers;



mobile phones and "smart" phone
-
PDAs;



portable storage devices and media; and



any other type of component

capable of

using, displaying, storing or transmitting the organiza
tion’s
information.

Portable devices and media controls

• Appropriate security measures should be required for mobile computing and
communications activities.


This could include guidelines and/or requirements for:



physical and environmental security meas
ures;



appropriate user authentication (knowledge
-
, token
-

or biometric
-
based) and access control;



minimization or prohibition of data storage on mobile devices or devices in off
-
premises locations,
particularly sensitive data;



cryptographic methods for
any stored sensitive data;



data backups for stored sensitive data;



secure communication methods for transmitted data (e.g., VPN);



anti
-
virus and other protective software;



operating system and other software updating; and



independent validation of app
ropriate device configuration.

Controls against malicious mobile code

• Appropriate controls should be implemented for prevention, detection
and response to mobile versions of malicious code, including appropriate user awareness.

Tele
-
working controls

• A
ppropriate security measures should be required for "tele
-
working" activities.


This could
include requirements for:



physical and environmental security measures;



appropriate user authentication and access control, given reasonably anticipated threats fro
m other users at
the site (e.g., family members);



cryptographic techniques for data storage at and communications to/from the site;



data backup processes and security measures for those backup copies;



security measures for wired and wireless network con
figurations at the site;



policies regarding intellectual property used or created at the site, including software licensing;



policies regarding organizational property used at the site (e.g., organizations' computing hardware and
software);



policies reg
arding private property used at the site (e.g., tele
-
workers' own computing hardware and
software); and



insurance coverage or other specification of financial responsibility for equipment repair or replacement.



SOURCE: ISO
-
27001/27002:2005 sects. 11.7.1



11.7.2.



Recommended Data Practices

28




Operations management

Ob
jective

• Operational procedures and assignments of responsibilities should ensure the correct and secure
operation of information processing facilities, including central (datacenter hosted) resources such as servers, l
ocal
and remote network infrastructure and client devices (desktop computers and portable devices that connect to the
network).

Documented operating procedures

• Operating procedures should be documented, maintained and made available
to all users who need

them.


This could include:



documentation of/for all significant system activities including start
-
up, close
-
down, back
-
up and
maintenance;



treatment of such documentation as a formal organizational record, subject to appropriate change
authorization, cha
nge tracking and archiving; and



provision of appropriate security for such documentation, including distribution control (see
Security of
system documentation
).

Segregation of duties

• Duties and areas of responsibility should be segregated to the degree

practicable, to reduce
opportunities for unauthorized or unintentional modification or misuse of the organization's assets.

Separation of development, test and operational facilities

• Development, test and operational facilities should be
separated, to t
he degree practicable, to reduce risks of unauthorized access or disruptive changes to operational
systems.

Controls for centralized resources

• Central information processing facilities, such as application servers and data
storage devices in “datacenters
,” should be appropriately managed and controlled, in order to be protected from
threats, and to maintain security for the systems and applications using those facilities.


This could include:



separation of operational responsibilities for centralized comp
uter systems and operations from those for the
network, where appropriate;



implementation of appropriate controls to assure the availability of centralized resources and information
services using them; and



establishment of responsibilities and procedure
s for management of equipment housed in centralized
facilities.

Security of centralized resources

• Security features, service levels and management requirements for all
centralized resources and services should be identified in reasonable detail, and inc
luded in a services agreement,
whether those services are provided in
-
house or outsourced.


This could include:



specification of technologies for security of centralized services, such as authentication, encryption and
connection controls;



rules for secur
e access to the centralized resources; and



procedures and processes to control/restrict access to the centralized resources in accordance with those
rules.

Network controls

• Networks should be appropriately managed and controlled, in order to be protect
ed from threats,
and to maintain security for the systems and applications using the network, including information in transit.


This
could include:



separation of operational responsibilities for networks from those for computer systems and operations,
whe
re appropriate;



implementation of appropriate controls to assure the availability of network services and information services
using the network;



establishment of responsibilities and procedures for management of network equipment, including
equipment in

user areas;



special controls to safeguard the confidentiality and integrity of sensitive data passing over the organization's
network and to/from public networks;



Recommended Data Practices

29






appropriate logging and monitoring of network activities, including security
-
relevant acti
ons; and



management processes to ensure coordination of and consistency in the elements of the network
infrastructure.

Security of network services

• Security features, service levels and management requirements for all network
services should be identif
ied in reasonable detail, and included in a network services agreement, whether those
services are provided in
-
house or outsourced.


This could include:



specification of technologies for security of network services, such as authentication, encryption and
connection controls;



rules for secured connection with the network; and



procedures and processes to control/restrict network access in accordance with those rules.

Client device controls

• Client devices that connect to the network should be appropriate
ly managed and controlled,
in order to be protected from threats and to maintain overall security.


This could include measures analogous to
those for centralized and network resources, applied to client devices where technically and administratively feasi
ble.

Security of client devices

• Security features, service levels and management requirements for all client device
services should be identified in reasonable detail, and included in a services agreement, whether those services are
provided in
-
house or
outsourced.


This could include measures analogous to those for centralized and network
resources.

Inter
-
connected information systems

• Policies and procedures should be developed and implemented to protect
information associated with the interconnection

of business systems.


This could include:



a risk assessment of and appropriate countermeasures for vulnerabilities associated with such
interconnections;



policies and appropriate controls to manage information sharing using such interconnections; and



fa
llback and recovery arrangements in the event of interconnection failure.

Internet and electronic messaging

• Information involved in electronic messaging should be appropriately
protected.


Electronic messaging includes email, IM, audio
-
video conferencin
g and any other one
-
to
-
one, one
-
to
-
many, or many
-
to
-
many personal communications.


This could include:



measures to protect messages from unauthorized access, modification or diversion;



ensuring correct addressing and routing;



ensuring the general reliabi
lity and availability of messaging services;



limiting the use of less
-
secure messaging systems (e.g., free/commercial email and IM); and



stronger levels of authentication and message content protection when using public networks.

Electronic commerce

• I
nformation involved in electronic commerce passing over public networks should be
appropriately protected from fraudulent activity, unauthorized disclosure and modification and any other activity that
could lead to contractual disputes.

On
-
line transaction
s

• Information involved in on
-
line transactions should be appropriately protected to prevent
incomplete transmission, mis
-
routing, unauthorized message alteration, unauthorized disclosure, unauthorized
message duplication or replay.

Publicly available inf
ormation

• The integrity of information provided on a publicly available system, such as a Web
server, should be appropriately protected to prevent unauthorized modification.

Change and project management

• Changes to information processing facilities and
systems should be controlled
using appropriate change and project management procedures.


This could include:



benefit
-
cost assessments, weighing benefits of the change or project

against required resources and other
costs;



Recommended Data Practices

30






risk assessments, including an a
nalyses of potential impacts and necessary countermeasures or mitigation
controls;



processes for planning and testing of changes, including fallback (abort/recovery) measures;



managerial approval and authorization before proceeding with changes or projec
ts that may have a
significant impact on operations;



advance communication/warning of changes, including schedules and a description of reasonably
anticipated effects, provided to persons who will or might be affected;



documentation of change steps and t
he success/failure of each change; and



documentation of updates to configuration or other “inventory” data about information and information
processing facilities.

System acceptance criteria

• Acceptance criteria for new information systems, upgrades, an
d new versions should
be appropriately established, and suitable tests carried out during development and prior to acceptance.


This could
include:



clear definition


and agreement on system acceptance criteria;



testing and documentation of compliance with

those requirements; and



consultation with affected persons, or representatives of affected groups, at all phases of the process.

Incident and problem management

• Variations from normal operations of information processing facilities should
be logged an
d investigated using appropriate incident and problem management procedures.


This could include:



standardized incident/problem reporting systems;



formal procedures for investigation of incidents/problems;



formal review processes (“lessons learned”); and




based on reviews, documented mitigation activities to prevent recurrences.

Configuration management

• The configuration of information processing facilities should be recorded, and updated
to reflect changes.


This could include:



standardized “inventory
” systems for information processing assets; and



periodic review of the accuracy of the inventory.

Service level and capacity management

• Service level expectations should be formally defined for all major
service components, both for the current enviro
nment and projected future requirements.


This could include:



on
-
going monitoring of the use of information and information facility resources;



identification of capacity requirements for each new and ongoing system/service;



projection of future capacity

requirements, taking into account current use, projected trends, and anticipated
changes in business requirements; and



system monitoring and tuning to ensure and, where possible, improve availability and effectiveness of
current systems consistent with s
ervice level agreements.

Third
-
party service contracts

• Security controls, service definitions and service level specifications should be
included in third
-
party service delivery agreements.

Monitoring and review of third
-
party services

• Services, repor
ts and records provided by the third party should be
regularly monitored and reviewed, and appropriate audits conducted.

Managing changes to third
-
party services

• Changes to the agreements for provision of services by third parties,
including maintaining
and improving existing information security policies, procedures and controls, should be
appropriately managed.


This could include:



taking into account the criticality of the particular systems and associated business processes;



considering changes to th
e business environment, legal
-
regulatory
-
certificatory controls, or the risk/threat
landscape;



Recommended Data Practices

31






using appropriate change management procedures, similar to those applied to internal service changes,
when alterations are necessary.


SOURCES: ISO 27001/27002
:2005 sects. 10.1


10.9.



Recommended Data Practices

32




Data lifecycle management

Objective

• Data lifecycle controls should ensure the confidentiality, integrity and availability of data collected, used
or stored by the organization, throughout the useful “life” of that data, includi
ng secure disposal at the end of that
cycle, to prevent unauthorized disclosure, modification, removal or destruction of information assets, or interruptions
to business activities.

Sensitivity level

• All data should be classified as to sensitivity, in or
der to assure appropriate security treatment
throughout the data lifecycle.


This could include classifications based on:



confidentiality, integrity and availability dimensions of each data type or collection;



intentions and capabilities of likely threats

to each data type or collection; and



legal
-
regulatory
-
certificatory authorities that condition data sensitivity determinations.

Retention period

• All data should be classified as to retention period, in order to assure its integrity and availability
fo
r an appropriate period.


This could reflect:



the organization’s business requirements; and



legal
-
regulatory
-
certificatory requirements.

Information handling

• Appropriate procedures for the handling and storage of information should be established to
pr
otect data from unauthorized disclosure or misuse.


This could include:



administrative, physical and technical access restrictions appropriate to the data sensitivity level;



handling and labeling of all media according to its indicated classification (sen
sitivity) level;



where appropriate to the sensitivity, maintenance of formal records of data transfers, including logging and
an audit trail; and



review at appropriate intervals of distribution processes and authorized recipient lists.

Information back
-
up

• Back
-
up copies of information and software should be made, and tested at appropriate
intervals, in accordance with an agreed
-
upon back
-
up policy.


This could include:



formal definition of the level of backup required for each system


scope of data to

be imaged, frequency of
imaging, duration of retention


on the basis of legal
-
regulatory
-
certificatory authorities and business
requirements;



complete inventory records for the back
-
up copies, including content and current location;



complete documentat
ion of restoration procedures for each system;



storage of the back
-
ups in a remote location, at a sufficient distance to make them reasonably immune from
damage to data at the primary site(s);



appropriate physical and environmental controls for the back
-
up copies where
-
ever located;



appropriate technical controls, such as encryption, for back
-
up copies of sensitive information in storage
locations and during transport to/from the primary site(s);



regular testing of back
-
up media; and



regular testing of

restoration procedures.

Management of storage media

• Policies and procedures should be established for management of storage media,
particularly removable media.


This could include, as appropriate to the sensitivity of the data:



logging and an audit tr
ail of removals of media from or relocations within the organization's premises;



a requirement for authorization prior to removal or relocation;



redundant storage, that reflects the risks to the media relative to the importance of the data;



cascading st
orage, where storage retention requirements exceed the rated life of the media;



restrictions on the types of media, and usages thereof, where necessary for adequate security;



registration of certain types of media; and



secure disposal of media when no l
onger needed.



Recommended Data Practices

33




Physical media in transit

• Media containing information should be protected against unauthorized access, misuse
or corruption while in transit.


This could include:



procedures and standards for authorizing couriers, and a list of currently
authorized couriers;



packaging standards, including technical protections (e.g., encryption); and



physical protection standards (e.g., locked containers, tamper
-
evident tagging).

Electronic data transfers

• Information transferred by electronic means sh
ould be appropriately protected.


This
could include:



protecting transferred information from unauthorized access, modification or diversion by appropriate
technical means (e.g., encryption);



ensuring correct addressing and routing;



ensuring the general
reliability and availability of information transfer services;



limiting the use of less
-
secure systems for transfers (e.g., public Internet); and



requiring authentication and message content protection mechanisms when using public networks (e.g.,
digital

signatures and content encryption).

Disposal of media

• Media should be disposed of securely and safely when no longer required, using approved
procedures.


This could include:



requiring use of generally
-
accepted secure disposal methods for media that co
ntains (or might contain)
sensitive data;



procedures and policies to identify data that qualifies as sensitive, or a policy that all information will be
considered sensitive in the absence of unequivocal evidence to the contrary; and



where appropriate to

the sensitivity of the data, logging and an audit trail of disposal operations.

Security of system documentation

• Like organizational data, documentation for organizational data systems
should be appropriately protected against unauthorized access.


Thi
s could include:



policies and procedures for secure storage of documentation, whether in paper and electronic form; and



authentication and access control measures, where appropriate to the sensitivity of the documentation.

Information exchange policies a
nd procedures

• Formal exchange policies and procedures should be developed
and implemented to protect the exchange of information both within and outside the organization, covering the use of
all types of communications facilities and data storage media.


This could include:



physical and technical measures designed to protect exchanged information from interception, copying,
modification, mis
-
routing or destruction;



procedures for the detection of and protection against malicious code (see also
Controls a
gainst malicious
code
);



procedures for the protection of wireless communications;



use of cryptographic methods where appropriate to achieve sufficient protections;



policies or guidelines about acceptable and unacceptable uses of communications facilitie
s and media;



retention and disposal guidelines for all exchanged information;



user awareness and training about these policies and guidelines; and



compliance with all relevant legal
-
regulatory
-
certificatory requirements for information exchange.

Exchan
ge agreements

• Agreements should be established for the exchange of information and software between
the organization and external parties and, where appropriate, within the organization.


This could include:



specification of management responsibilities f
or controlling/approving agreements about transmissions and
receipts of information;



procedures to ensure appropriate identification and labeling, appropriate notifications to sender and
recipient, traceability and non
-
repudiation;



minimum technical stan
dards for packaging and transmission; specification of ownership and responsibilities


Recommended Data Practices

34




for data protection, copyright, license compliance and similar considerations; and



specification of responsibilities and liabilities in the event of an information secur
ity incident.

SOURCES: ISO
-
27001/27002:2005 sects. 9.2., 10.5


10.8.



Recommended Data Practices

35




Monitoring and audit logging

Objective

• On
-
going system monitoring and logging for audit should allow timely detection of and response to
unauthorized information processing activitie
s.

Monitoring

• Procedures for monitoring use of information processing facilities should be established and the results
of monitoring activities regularly reviewed.


This could include:



event tracking and recording as specified in the
Audit logging

policy
;



monitoring and review of this data, as determined by the criticality of the application/system or information
involved, past experience with information security incidents, and general risk assessment.

Audit logging

• Audit logs that record user and sy
stem activities, exceptions, and information security events should
be produced, and kept for an agreed
-
upon time period, to assist in future investigations and access control
monitoring.


This could include recording, when relevant and within the capacity

of the logging system, all key
events.


Key event data could include:



date/time for the event, and the event type;



user
-
ID and/or system
-
ID associated;



terminal identity and/or location;



network addresses and protocols;



records of successful and unsuc
cessful system accesses or other resource accesses;



changes to system configurations;



use of privileges;



use of system utilities and applications;



files accessed and the kinds of access (e.g., read, modify, create, copy, delete); and



alarms raised by
the access control or any other protection system (e.g., ID/IP).

Balancing audit with operational requirements

• Audit controls should be implemented to allow collection of
appropriate audit data on operational systems, while minimizing the risk of disrup
tion to business processes.

Protection of log information

• Logging facilities and log information should be appropriately protected against
tampering and unauthorized access.


This could include:



privacy protection measures for logged data that may be sen
sitive or confidential; and



security protections of a technical, physical and administrative nature (e.g., division of responsibilities) to
ensure integrity and availability of audit logs.

Retention of log information

• A formal policy should specify the

minimum retention periods for log data, consistent
with legal
-
regulatory
-
certificatory requirements, business needs, and available storage/processing capacities.

Administrator and operator logs

• System administrator and system operator activities should
be appropriately
logged, as part of the general audit trail process.

Fault logging

• Faults should be appropriately logged, analyzed and actions taken.

Clock synchronization

• The clocks of all relevant information processing systems within an organization

or security
domain should be appropriately synchronized with an agreed
-
upon time source, as part of protecting the accuracy of
log information.

SOURCES:


ISO
-
27001/27002:200



Recommended Data Practices

36




Information security incident management

Objective

• Information security events

and discovered weaknesses should be communicated in a manner that
allows appropriate corrective actions to be taken promptly, and a consistent and effective approach

should be applied
to the subsequent management and remediation.

Reporting information sec
urity events

• All employees, contractors and third party users should be required to note
and report any observed or suspected security events through appropriate channels as quickly as possible.


This
could include:



establishment of formal event reportin
g processes and procedures, setting out actions to be taken and
points of contact;



awareness on the part of all employees, contractors and third
-
party users of the event
-
reporting processes,
including the requirement to report security events and weakness
es;



awareness of the requirement to report as quickly as possible, with sufficient detail to allow a timely
response; and



suitable feedback processes to ensure that persons who report events are appropriately notified of results.

Reporting information s
ecurity weaknesses

• All employees, contractors and third party users should be required
to note and report any observed or suspected security weaknesses in systems or services through appropriate
channels as quickly as possible.


This could include:



easy,

accessible channels for reporting, the availability of which is clearly communicated to employees,
contractors and third parties;



reasonable awareness on the part of employees, contractors and third parties of common signs and
symptoms of security weakne
sses;



reporting requirement extends to malfunctions or other anomalous events that may indicate a security
weakness;



awareness on the part of employees, contractors and third parties that they should report, but not attempt to
test, a suspected security
weakness, since this might be interpreted as a potential misuse.

Responsibilities and procedures for security incident response

• Management responsibilities and procedures
should be clearly established, to ensure a quick, effective and orderly response t
o information security incidents.


This could include:



processes to ensure routine use of data from the ongoing monitoring of systems to detect events and
incidents;



procedures specifically designed to respond to different types and severities of inciden
t, including
appropriate analysis and identification of causes, containment, communication with those actually or
potentially affected by the incident, reporting of the incident to appropriate authorities, and planning and
implementation of corrective acti
on to prevent reoccurrence as appropriate;



collection and use of audit trails and similar evidence as part of the incident management process, and
appropriate management of this evidence for use in subsequent legal or disciplinary proceedings; and



formal

processes for recovery and remediation, including appropriate documentation of actions taken.

Investigation of incidents

• Where disciplinary or legal action may be part of the follow
-
up to an information security
incident, any investigation should be in
itiated and conducted in a manner that follows documented procedures and
conforms to accepted practices.


This could include:



specifying what persons or classes of person may request an investigation, and on what basis;



specifying the necessary documentat
ion and approvals to initiate an investigation, and the documentation
required as the investigation proceeds;



specifying what persons or classes of person may participate in an investigation process, including collection
of evidence;


and



procedures for
securing and maintaining the integrity of all investigatory records.

Collection of evidence

• Where an investigation has been initiated as part of possible disciplinary or legal action,


Recommended Data Practices

37




evidence should be collected, retained and presented in a manner that

follows documented procedures and conforms
to accepted practices.


This could include procedures for:



securing and maintaining the integrity of copies of electronic records or other data on computer devices or
media that are relevant to the incident;



sec
uring and maintaining the integrity of copies of paper and other types of records, including "originals" if
such exist; and



observing appropriate procedures to assure "chain of custody" for any evidence collected.



Learning from information security inci
dents

• There should be mechanisms in place to enable the types,
volumes and estimated costs of information security incidents to be quantified and monitored.


This could include:



periodic summary reports on incident types, volumes and costs; and



detailed

reports on particular incidents.

SOURCES: ISO
-
27001/27002:2005 sects. 13.1


13.2.5 sects. 10.10.1


10.6.,15.3.1
-
2.



Recommended Data Practices

38




Business continuity management

Objective

• Organizational policies and procedures should ensure timely resumption from, and if possible
prevention
of, interruptions to business activities and processes caused by failures of information systems.

Information security in the business continuity management process

• A managed process should be
developed and maintained for business continuity t
hroughout the organization, that includes information security
requirements needed for the organization's business continuity.


This could include:



identification of information assets involved in critical business processes;



a risk assessment that addres
ses likely causes and consequences of information system failures;



identification and consideration of preventive and mitigating controls in light of these risks;



identification of sufficient financial, technical and human resources to address the preven
tive/mitigating
control requirements;



development and documentation of business continuity plans and processes, including assignment of
responsibilities and incorporation of these into the organization's general processes and structure; and



regular testi
ng and updating of business continuity plans and processes.

Business continuity and risk assessment

• Events that can cause interruptions to business processes should be
identified, along with the probability and impact of such interruptions and their con
sequences for information
security.


This could include:



identification of all significant risks and risk categories, including the probability and probable impact on
operations in terms of scale, likely damage and recovery period;



full involvement of ow
ners of significant organizational assets in the assessment process;



identification of acceptable and unacceptable losses and interruptions; and



formal documentation of the assessment's results, and a plan for regular updating to ensure completeness
and
currency.

Developing and implementing continuity plans

• Business continuity plans should be developed and implemented
to maintain or restore operations, and ensure availability of information at the required level and in the required time,
following inte
rruptions to or failures of business processes.


This could include:



identification of and agreement on all responsibilities for development of operational procedures;



specification of the disaster recovery/business continuity procedures to effect recover
y and restoration of
business processes;



a data backup plan to ensure recovery of all data following process restoration, including the ability to
replicate exact copies of data in its state prior to disruption of operations;



specification of alternative

operational procedures to follow pending completion of recovery and restoration,
including methods for accessing all critical data;



documentation of the above plan elements;



appropriate training and awareness efforts for staff on the plan elements; and

testing and updating of the plan (see
Testing, maintaining and re
-
assessing plans
).

Business continuity planning framework

• A single framework of business continuity plans should be maintained
to ensure that all plans are consistent, consistently assess
information security requirements, and to identify priorities
for testing and maintenance.


This could include:



specification of conditions and criteria for activating the plans;



formal assignment of responsibilities for making assessments about plan acti
vation, choices among
emergency procedures and processes, resumption procedures, etc.; and



formal assignment of responsibilities for keeping the plan current (see next).

Testing, maintaining and re
-
assessing plans

• Business continuity plans should be te
sted and updated regularly to
ensure that they are up to date and effective.


This could include:



Recommended Data Practices

39






periodic testing that assures that all persons with significant responsibilities under the plans are aware of
and competent to perform them;



a range and freq
uency of testing exercises, from table
-
top to complete rehearsals, performed as necessary
to ensure awareness and competence; and



regular reviews and updating of the plan(s) in light of testing results.

SOURCES: ISO
-
27001/27002:2005 sects. 14.1.1
-
5.



Recommended Data Practices

40




Com
pliance with external and internal requirements

Objective

• Data privacy/security policies should ensure compliance with all "external" obligations that derive from
statutory, regulatory, certificatory and contractual obligations.


Policies should also ens
ure compliance with other
"internal" organizational policies, procedures and standards.

Identification of external and internal requirements

• All applicable external and internal contractual requirements
with application to information security should be
identified.


This could include requirements to:



protect and preserve organizational records, including records necessary for auditing compliance with these
requirements;



protect the confidentiality of personal data;



regulate cryptographic and other sens
itive technologies; and



preserve intellectual property rights.

Documentation

• The organization's systematic approach to meeting these requirements should be explicitly
documented and kept up to date.

Communication, training and awareness

• External and
internal requirements should be communicated to all
persons affiliated with the organization, including relevant external parties that handle data on the organization’s
behalf, via an appropriate training and awareness program.

Periodic review

• Data, data

system and data facility controllers should periodically review all processes within their
areas of responsibility to ensure compliance with applicable internal and external requirements.

SOURCES: ISO
-
27001/27002:2005 sects. 15.1


15.2.



Recommended Data Practices

41




Data retention c
lassification

Objective

• To classify data as to retention period in order to assure appropriate storage measures throughout the
data lifecycle of organizational information.

Applicability

• Data retention classification should occur for all significant in
formation collections of the organization.

Retention criteria

• Retention classification should be based

should be based on confidentiality, integrity and
availability dimensions of the data relevant to all stakeholders, particularly

those related to avail
ability.


This could
include consideration of:



external legal
-
regulatory
-
certificatory and contractual requirements for data retention;



operational and other internal information requirements of the organization that condition retention; and



any other r
isks or benefits associated with data retention considered relevant by the organization.

Retention classification level

• Data should normally be assigned a retention classification that reflects the most
restrictive (longest duration) requirement for whi
ch it qualifies on any criterion.


Exceptions to this rule should be
noted and explained.


Mixed collections of data



Where multiple types of data are stored in a single collection, the collection should
normally be assigned a retention classification tha
t reflects the most restrictive (longest duration) requirement for any
constituent type.


Exceptions to this rule should be noted and explained.

Retention "freezes"

• Procedures should exist to suspend or extend the normal retention cycle for all or part o
f
a

data collection when necessary and appropriate.


Circumstances triggering a freeze could include:



a cause of legal action, pending or underway;



an audit, pending or underway;



legal
-
regulatory
-
certificatory retention requirement changed; or



internal
organizational retention requirement changed.

Retention classification responsibilities

• Data owners/stewards should provide a data retention assessment
based on their understanding of the applicable classification criteria.


Data owners/stewards may req
uest
--

or the
organization may require
--

an independent assessment of data retention classification.


Retention classification review

• Data owners/stewards should review the accuracy and adequacy of data retention
classifications at appropriate interval
s.


The organization may also require independent reviews.

Documentation and historical record

• Documentation for data collections and systems should include current
retention classification and, where relevant, past sensitivity classifications and the re
ason(s) for changes.




Recommended Data Practices

42




Data sensitivity classification

Objective

• To classify data as to "sensitivity," in order to assure appropriate security measures throughout the
lifecycle of organizational information and information processing facilities.

Applicab
ility

• Data sensitivity classification should occur for all significant information collections of the organization,
and for the information processing facilities used to access, store or transmit that information.

Sensitivity criteria

• Sensitivity class
ification should be based on confidentiality, integrity and availability dimensions
of the data relevant to all stakeholders.


This could include consideration of:



external legal
-
regulatory
-
certificatory and contractual requirements for information;



opera
tional and other internal information requirements of the organization;



likely human and non
-
human threats to this information and any information processing facilities used to
access, store or transmit it;



countermeasures in place to meet these threats;




vulnerabilities that remain despite countermeasures; and



any other risks or benefits considered relevant by the organization.

Sensitivity classification level

• Data should normally be assigned a sensitivity classification level that reflects the
most
restrictive rating for which it qualifies on any confidentiality, integrity or availability criterion.


Exceptions to this
rule should be noted and explained.


See
Data sensitivity classification matrix

below.


Sensitivity classification responsibilities



Data owners/stewards should provide a data sensitivity classification
assessment based on their understanding of the applicable criteria.


Data owners/stewards may request
--

or the
organization may require
--

an independent assessment of data sensitivity

classification.


Sensitivity classification review

• Data owners/stewards should review the accuracy and adequacy of data
sensitivity classifications at appropriate intervals.


The organization may also require independent reviews.

Documentation and histo
rical record

• Documentation for data collections and systems should include current
sensitivity classification and, where relevant, past sensitivity classifications and the reason(s) for changes.




Data sensitivity classification matrix



Low sensitivit
y
rating

Moderate sensitivity
rating

High sensitivity rating

Externally
-
imposed
requirements

None.

Contractual obligation to
data subjects or to another
organization for moderate
data confidentiality,
integrity or availability
protections.

Statutory, regu
latory or private
certificatory requirement for high
level of confidentiality, integrity or
availability protections (e.g., AHCA,
FDA, FERPA, GLBA, HIPAA,
JCAHO, NIH, PCI); or contractual
obligation to data subjects or
another organization for high
-
level o
f
data protections.


Some types of
data within this category may
require added protection levels
reflecting "special status" (e.g.
certain kinds of health data
covered by HIPAA and state laws)



Recommended Data Practices

43




Internally
-
imposed
requirements

None.

Organizational (internal

policy) requirement for
some data confidentiality,
integrity or availability
protections.


May be
based on risks to:

--
continuity of operations

--
financial viability

--
reputation

Organizational (internal policy)
requirement for high data
confidentiality,

integrity or availability
protections.


May be based on risks
to
:

--
continuity of operations

--
financial viability

--
reputation

Risks to
operational
continuity

Low or none.

Moderate.

High.

Risks to financial
viability

Low or none.

Moderate.

High.

Risk
s to
reputation and
"good will"

Low or none.

Moderate.

High.

Civil (tort) and
criminal risks

Low or none.

Moderate.

High.

Threat
environment risk
(capabilities and,
if human,
intentions of likely
threats)

Low or none.

Moderate.

High.

Intangible risks
th
at fall outside of
other categories

Low or none.

Moderate.

High.

Data examples

Most "public" data
of an organization:



--
most public web
site content



--
information in
the public
domain



--
business contact
(directory)
information



--
blog and wiki
postings



--
some
organizational
email (e.g.,
broadcast
notices)

"Internal" data of an
organization that is non
-
public:



--
some public web site
content (particularly if
high availability is
required)



--
most email content



--
limited
-
distribution
contact (directory)
information



--
less
-
sensitive operational
and financial data of the
organization Intranet

Almost everything that is protected
by statute or regulation:



--
identifiable clinical (health) data



--
identifiable research data



--
student transcripts



--
identifia
ble personal financial data
(including credit card numbers,
bank accounts)



--
more
-
sensitive operational and
financial data of the organization



--
restricted
-
use identifiers (e.g.,
social security numbers)



Recommended Data Practices

44




Access security

No requirement.

Authentication a
nd access
controls required, but set
of permitted users may be
large.

Authentication required, possibly
with multi
-
factor process.


Set of
permitted users is usually small.


Need
-
to
-
know (a.k.a., minimum
necessary) access enforced by
strong access controls
.

Storage security

No requirement.


Backups or
redundant storage
recommended.

Backups or redundant
storage required.

Backups or redundant storage
required.


Encrypted storage (and
transfer to storage) recommended.
Encrypted storage particularly
appropriat
e for mobile devices (or
non
-
mobile devices in less secure
settings) for "special status" data.

Transmission
security

No requirement.

Transmission protections
recommended, including
use of encryption (e.g.,
SSL/HTTPS).

Transmission protections required,
i
ncluding use of encryption for
message confidentiality, integrity
and non
-
repudiation.






Recommended Data Practices

45




Terms and definitions

The following terminology is used throughout the Recommended Data Practices:

Asset

• Anything that has value to the organization, including bu
t not limited to data (information) and data system
assets (information processing facilities).


(ISO 13335:2004)

Authority

• Any organizational, statutory, regulatory or certificatory requirement or standard for organizational
policies and procedures.

Cap
ability

• The capacity of an entity.


Usually used to refer to the capacity of a threat to exploit a vulnerability.

Control

• Any means of promoting positive outcomes, reducing negative outcomes, managing risk or otherwise
achieving some other organization
al objective, including policies, procedures, guidelines, practices, organizational
structures, and software/hardware functionality.


(ISO 27002:2005)

Countermeasure

• Any means of reducing negative outcomes or mitigating risk.


Partial synonym for control
.

Guideline

• A recommended, non
-
mandatory control.


Cf. standard.

Data controller

• The natural or legal person, department or other administrative unit of a private organization, public
authority or public agency, or any other body which alone or jointly

with others determines the purposes and means
of the processing of a particular collection of data.


(EU, ISO)

Data owner

• Synonym for data controller.

Data subject

• The object or “referent” of personal data.

Data system

• An information processing syst
em, service or infrastructure, or the physical location housing them.


Synonym for information processing facility.


(ISO 27002: 2005)

Identified/identifiable data

• Data which is, or reasonably could be, linked to a person.


See personal data.

Incident


Any event which is not part of the standard operation of a service and which causes, or may cause, an
interruption to, or a reduction in, the quality of that service.


(ITIL)

Include(s)

• Includes, but is not limited to.


That is, a not
-
necessarily
-
exhaust
ive listing.

Information processing facilities

• Any information processing system, service or infrastructure.


Synonym for data
system. (ISO 27002:2005)

Information security

• Preservation of the confidentiality, integrity and availability of information.

Information security event

• See information security incident.

Information security incident

• An incident with actual or potential information security consequences.


An identified
occurrence of a system, service or network state indicating an actual or

possible breach of information security policy
or failure of safeguards.


Used herein as a synonym for information security event, though in standard usage the term
incident is reserved for possible events, and events to mean confirmed events.


(ISO 27002
:2005)

Mobile computing

• Work from a non
-
fixed location using portable computing/communications devices such as
laptops, notebooks, palmtops, smart cell phones and PDAs.


Contrast with tele
-
working.

Personal data

• Any information relating to an identifie
d or identifiable natural person (data subject).


An identifiable


Recommended Data Practices

46




person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to
one or more factors specific to his physical, physiological, mental,

economic, cultural or social identity.


(EU)

Policy

• A high
-
level overall plan embracing the general goals and acceptable procedures especially of an
organization.


Can include specification of defined processes or methods in light of defined conditions,

to guide or
determine decision
-
making, but cf. procedure.

Procedure

• Specification of defined processes or methods in light of defined conditions, to guide or determine
decision
-
making.


Usually based on a policy.

Risk

• Combination of the probability of

an event and its consequences.


(ISO 73:2002)

Risk analysis

• Systematic use of information to identify sources and probabilities of risk.


See also threats and
vulnerabilities.


(ISO 73:2002)

Risk assessment

• Overall process that includes risk analysis,

risk evaluation.


(ISO 73:2002)

Risk evaluation

• Process of comparing estimated risks against given risk criteria to determine the significance of a
risk.


(ISO 73:2002)

Risk management

• Coordinated activities to direct and control an organization with
respect to risk based on risk
assessment.


(ISO 73:2002)

Risk treatment

• Process of selection and implementation of measures to modify risk.


Synonym for risk
management.


(ISO 73:2002)

Safeguard

• Synonym for control.

Standard

• A mandatory control.


Cf.

guideline.

Tele
-
working

• Work at a fixed location outside of the normal organizational environment.


Synonym for tele
-
commuting.


Contrast with mobile computing.


(ISO 27002:2005)

Third party

• A natural or legal person, department or other administrativ
e unit of a private organization, public
authority or public agency, that is independent of the parties involved, as concerns a particular issue.


(EU, ISO)

Threat

• A potential cause of an unwanted incident or event.


The capacity of a threat to damage or
ganizational
resources is sometimes referenced as its capability.


Includes computer
-
assisted fraud, espionage, sabotage,
vandalism, fire or flood.


(ISO 13335:2004, ISO 27002:2005)

Vulnerability

• A weakness in an asset or group of assets that can be expl
oited by one or more threats.


(ISO
13335:2004)