Information Security in System Acquisition, Development, and Maintenance

Standards
1. Security is an integral part of information systems. Information systems include operating
systems, infrastructure, business applications, off-the-shelf products, services, and user-developed
applications. The design, development, acquisition and implementation of the information system
supporting the business process can be crucial for security. These standards have been developed
toward that purpose.

Scope

2. These standards apply to all usage by persons involved in the acquisition, development and
maintenance of UNDP’s IT environment and are applicable to all UNDP networks and systems
including any UNDP applications/systems developed for the Internet. All authorized UNDP users
are bound by the provisions and intent of these standards and the UNDP Information Security
Policy it supports.

3. These standards will cover how information security is ensured during the acquisition,
development and maintenance of information systems at UNDP. It covers the following:

a) Security requirements analysis and specification

b) Correct processing in applications
c) Cryptographic or secure communication controls
d) Security in development and support processes
e) Technical vulnerability management
f) Data availability in new applications

Approvals of new ICT Projects, Systems, and Applications

4. New enterprise or corporate ICT projects, systems and applications must be coordinated and
validated with the UNDP Chief Information Officer (CIO), Information and Technology
Management (ITM) / Bureau for Management Services (BMS).

5. No new enterprise or corporate ICT projects, systems or applications shall proceed without first
having been coordinated with the CIO and arrangements made for its support, security and
integration within the existing UNDP ICT environment. All implementations shall also have been
tested and validated by the Change Control Board or relevant ICT body.

6. Since UNDP ICT projects, systems, or applications can be invoked locally, local Country Offices
should apply the rigorous principles of these security standards in all local Country Office
settings. UNDP offices are allowed to share UNDP ICT infrastructure or services in field locations
with other UN entities (or vice versa) on a cost recovery basis in order to achieve effectiveness
of service and economies of scale. To facilitate this, UNDP recognizes corresponding policies of
relevant UN entities in the spirit of mutual recognition of each other’s policies and procedures.
Security Requirements - Analysis and Specification

Page 1 of 11 Effective Date: 30/12/1899 Version #: 2

 7. All security requirements shall be identified at the requirements phase of a project and justified,
agreed, and documented as part of the overall functional requirements for an information
system. At a minimum the following documentation that must be developed at this point are:

a) User functional requirements including security requirements

b) Design specifications of system or application
c) User Acceptance Test Requirements (including security requirements)

8. After the application has been developed but prior to its being placed into production, at a
minimum the following documentation must be developed:

a) User guides
b) System administrator guides to include installation instructions, backup mechanisms,
monitoring capabilities and a troubleshooting guide
c) Documented test results for unit, system, integration, and user testing. The test results
shall verify that user and security requirements have been met prior to being placed
into production.

Note: Under incremental development approach it may not be possible to fully specify all of the
user requirements at the outset. Thus, the functional requirements document may change as
the project matures and depending on the feedback from business users.

9. Statements of functional requirements for new information systems, or enhancements to

existing information systems shall specify the requirements for security controls needed to
ensure the confidentiality, integrity and data availability for the information system. These
specifications should consider the automated controls to be incorporated in the information
system, and the need for supporting procedural controls. Similar considerations should be
applied when evaluating software packages, developed or purchased, for applications.

10. All new information processing systems shall be required to be approved by a minimum of the
Change Control Board or other ICT governance body and the sponsoring unit prior to being
taken into production or operations. Contracts with suppliers shall address the identified
security requirements. Where the security functionality in a proposed product does not satisfy
the specified requirement, then the risk introduced and associated controls required to address
the risk should be reconsidered prior to purchasing the product. Where additional functionality
is supplied which causes a security risk, this shall be disabled or the proposed control structure
should be reviewed to determine if advantage can be taken of the enhanced functionality
available.

Correct Processing in Applications

11. Appropriate and adequate input validation controls shall be designed and incorporated into any
operational or production application. Controls should be applied to the input of transactions,
standing data and parameter tables. Specific areas to check can include, but are not limited to:

a) Dual input or other input checks, such as boundary checking or limiting fields to
specific ranges of input data, to detect the following errors:

Page 2 of 11 Effective Date: 30/12/1899 Version #: 2

  Out-of-range values
 Invalid characters in data fields
 Missing or incomplete data
 Exceeding upper and lower data volume limits
 Unauthorized or inconsistent control data
 Known scripting or injection-based attacks

b) Periodic review of the content of key fields or data files to confirm their validity and
integrity
c) Procedures for testing the plausibility of the input data
d) Defining the responsibilities of all personnel involved in the data input process

12. Validation checks should be incorporated into production applications to detect any corruption
of information through processing errors or deliberate acts. Data that has been correctly
entered can be corrupted by hardware error, processing errors, or through deliberate acts.
Validation checks required will depend on the nature of the application and the business impact
of a corruption of data. Specific areas to check can include, but are not limited to:

a) The use of add, modify, and delete functions to implement changes to data
b) The procedures to prevent programs running in the wrong order or running after failure
of prior processing
c) The use of appropriate programs to recover from failures to ensure the correct
processing of data
d) Protection against attacks using buffer overruns/overflows

Examples of controls that can be included in an application include:

a) Session or batch controls, to reconcile data file balances after transaction updates
b) Balancing controls, to check opening balances against previous closing balances,
namely:

 Run-to-run controls
 File update totals
 Program-to-program controls

c) Validation of system-generated input data

d) Checks on the integrity, authenticity or any other security feature of data or software
downloaded, or uploaded, between central and remote computers
e) Hash totals of records and files
f) Checks to ensure that application programs are run at the correct time
g) Checks to ensure that programs are run in the correct order and terminate in case of a
failure, and that further processing is halted until the problem is resolved
h) Creating a log of the activities involved in the processing
i) Recovery and roll-back controls which ensure data accuracy, completeness and integrity
j) Audit trails

Page 3 of 11 Effective Date: 30/12/1899 Version #: 2

 13. Requirements for authenticity and message integrity in applications shall be identified during
the requirements phase of a project, and appropriate controls identified and implemented.

14. Data output from an application should be validated to ensure that the processing of stored
information is correct and appropriate to the circumstances. Output validation may include:

a) Plausibility checks to test whether the output data is reasonable

b) Reconciliation control counts to ensure processing of all data
c) Providing sufficient information for a reader or subsequent processing system to
determine the accuracy, completeness, precision, and classification of the information
d) Procedures for responding to output validation tests
e) Defining the responsibilities of all personnel involved in the data output process
f) Creating a log of activities in the data output validation process

Cryptographic or secure communication controls

15. Any use of encryption shall be based on a risk assessment. The required level of protection
should be identified taking into account the type, strength, and quality of the encryption
algorithm used. Encryption should be considered for protection of sensitive information
transported by mobile or removable media devices or across communication lines which include
both physical and wireless networks.

16. All information exchanged between trusted/trusting applications on operational or production

systems shall be encrypted to enforce trust levels and message integrity between systems.
Where encryption cannot be used for message exchanges between trusted/trusting systems,
this must be explicitly authorized by ITM/BMS. Use of specific encryption algorithms and
associated key lengths is subject to approval by ITM/BMS. Before using encryption, there
should be a well-defined approach including the following:

a) Methods to protect the cryptographic keys and the recovery of information in the case
of lost or compromised cryptographic keys
b) Roles and responsibilities for implementing encryption, key management, and key
generation.

17. When implementing encryption, consideration should be given to the regulations and national
restrictions that might apply to the use of cryptographic techniques in different parts of the
world and to the issues of trans-border flow of encrypted information.

18. All cryptographic keys should be protected against modification, loss, unauthorized disclosure
and destruction. Appropriate procedures for key generation, assignment, distribution, re-use
and recovery shall be established for each operational or production system using encryption.
Procedures for responding to key loss or compromise shall be established.

Security of Development, Test and Support Processes

Page 4 of 11 Effective Date: 30/12/1899 Version #: 2

 19. Access to system files and program source code will be controlled and IT projects and support
activities conducted in a secure manner. Care should be taken to avoid exposure of sensitive
data in development and test environments.

20. Only approved software may be installed on operational or production systems, and software
may only be installed by authorized staff in the execution of their officially approved duties.

21. Vendor supplied software used in operational systems should be maintained at a level
supported by the supplier. Physical or logical access should only be given to suppliers for
support purposes when necessary, and with appropriate management approval. The supplier’s
activities should be monitored with sufficient controls in place.

22. Specific sets of test data should be created to provide the basis for the conduct of tests to meet
the acceptance criteria of any program to develop, procure or, upgrade any operational or
production system. Such test data should be representative of operational data, but shall not be
actual operational/production data. The use of operational databases containing personal
information or any other sensitive information shall not be used for testing purposes unless
explicitly authorized by the CISO and the data owner. In any such case, the following apply:

a) The same levels of protection which apply to operational application systems shall also
apply to test application systems
b) There should be a separate authorization each time operational information is copied to
a test application system
c) Operational information should be erased from a test application system, in a manner
consistent with that used on operational application systems, immediately after the
need for testing is complete
d) The copying and use of operational information should be logged to provide a trail of
accountability

23. Program source code shall be adequately protected against unauthorized access or change.
Access to development systems and their program source code and associated items will be
strictly controlled, in order to prevent the introduction of unauthorized functionality and to
avoid unintentional changes. All changes to source code shall be coordinated via approved
change control procedures. Version control shall be implemented and enforced.

24. Project and support environments should be strictly controlled. Managers responsible for
application systems should also be responsible for the security of the project or support
environment. They should ensure that all proposed system changes are reviewed to check that
they do not compromise the security of either the system or the operating environment.

25. Formal change control procedures shall be documented and enforced in order to minimize the
corruption of information systems. Introduction of new systems and major changes to existing
systems shall follow a formal process of documentation, specification, testing, and quality
control and managed implementation.

26. The change control process shall include a risk assessment, analysis of the impacts of changes
and specification of security controls needed. This process shall also ensure that existing

Page 5 of 11 Effective Date: 30/12/1899 Version #: 2

 security and control procedures are not compromised, that support programmers are given
access only to those parts of the system necessary for their work, and that formal agreement
and approval for any change is obtained.

27. If required, adequate and appropriate regression and performance testing shall be conducted as
part of the change management procedures using appropriate test data sets and test facilities.

28. Outsourced software development should be supervised and monitored by the ICT unit (e.g. HQ
ITM or ICT staff in a country office). Where software development is outsourced, the following
points should be considered:

a) Licensing arrangements, code ownership, and intellectual property rights

b) Certification of the quality and accuracy of the work carried out
c) Escrow arrangements in the event of failure of the third party
d) Rights of access for audit of the quality and accuracy of work done
e) Contractual requirements for quality and security functionality of code
f) Testing before installation to detect malicious and Trojan code
g) Subcontracting restrictions

Control of Technical Vulnerabilities

29. Appropriate timely action shall be taken in response to the identification of potential
vulnerabilities in operational systems. The organization should define and establish the roles
and responsibilities associated with technical vulnerability management, including vulnerability
monitoring, vulnerability risk assessment, patching, asset tracking and any coordination
responsibilities required. Once a potential technical vulnerability has been identified, the
organization should identify the associated risks and the actions to be taken; such action could
involve patching of vulnerable systems and/or applying other controls. Depending on how
urgently a technical vulnerability needs to be addressed, the action taken shall be carried out
according to the controls related to change management or by following information security
incident response procedures.

30. If a patch is available, the risks associated with installing the patch shall be assessed (the risks
posed by the vulnerability shall be compared with the risk of installing the patch). Patches shall
be tested and evaluated before they are installed to ensure they are effective and do not result
in side effects that cannot be tolerated; if no patch is available, other controls should be
considered such as:

a) Turning off services or capabilities related to the vulnerability

b) Adapting or adding access control
c) Increased monitoring to detect or prevent actual attacks
d) Raising awareness of the vulnerability
e) An audit log shall be kept for all procedures undertaken
f) The technical vulnerability management process should be regularly monitored and
evaluated in order to ensure its effectiveness and efficiency
g) Systems at high risk should be addressed first

Page 6 of 11 Effective Date: 30/12/1899 Version #: 2

Data Availability in New Applications and Systems

31. Before new systems are deployed in an operational environment, the unit’s business continuity
plan shall be updated as necessary with the information on the new system.

Guidelines and Further Information

32. Work instructions or guidelines on the implementation of these standards may be developed to
address internal requirements. Such working instructions and guidelines shall be read in
conjunction with these standards. If there is a discrepancy between any provision of the
standard and any such guideline, the provisions of the standard shall take precedence.

Roles and Responsibilities

33. The Chief Information Security Officer (CISO) shall be responsible for the periodic review and
updating of this document. He shall be considered the “owner” of these standards.

34. Staff members tasked with responsibilities in information systems acquisition, development and
maintenance is responsible for following the requirements of these standards and the
Information Security Policy. Toward that end, a checklist has been developed at the end of these
standards that can assist in ensuring compliance with information security requirements.

Templates and Forms

35. ICT Security Requirements Checklist - The following checklist is a recapitulation of the security
requirements contained in these standards. It is recommended that the checklist be completed prior to
any system being brought into production status. Consider the following aspects relating to the
information system or application being acquired or developed. Tick one box for each aspect.

Standard on Acquisition, Development and YES PARTIAL N/A

Maintenance Requirement
a) Have the following documentation
been developed:

 Design specifications of system or

application
 User Acceptance Test
Requirements (including security
requirements)
 User manuals
 System administrator manuals to
include installation instructions,
backup mechanisms, monitoring
capabilities and a troubleshooting
guide

Page 7 of 11 Effective Date: 30/12/1899 Version #: 2

  Test plans and results for unit,
system, integration and user testing

b) Has the system or application been

approved by the UNDP ICT Board (or
local ICT governance bodies) and
coordinated within ITM and respective
ICT unit for its support, security and
integration with the existing ICT
environment?

c) Have the following data input controls

been considered incorporated?

 Out-of-range values
 Invalid characters in data fields
 Missing or incomplete characters
 Exceeding upper and lower data
volume limits
 Unauthorized or inconsistent
control data
 Known scripting or injection-based
attacks
 Periodic review of content of key
fields
 Periodic inspection of hard copy
input documents for unauthorized
changes
 Procedures for responding to
validation errors
 Plausibility checks for input data
 Defined responsibilities for
personnel involved in data input
process

d) Have the following data validation

checks been incorporated to detect any
corruption of information through
processing errors or deliberate acts?

 Use of add, modify and delete

functions to implement changes to
data
 Procedures to prevent programs
running in the wrong order or
running after failure of prior

Page 8 of 11 Effective Date: 30/12/1899 Version #: 2

 processing
 Use of appropriate programs to
recover from failures to ensure the
correct processing of data
 Protection against attacks using
buffer overruns/overflows

e) Has the application implemented the

following controls:

 Session or batch controls

 Balancing controls
 Validation of input data
 Checks on integrity, authenticity
 Hash totals of records or files
 Checks to ensure application runs
at correct time
 Checks to ensure program runs in
the correct order and terminate in
case of failure
 Creating a log of activity processing
 Recovery and roll-back controls

f) Has data output from the application

been validated?

 Plausibility checks
 Reconciliation controls counts
 Providing sufficient information for
a subsequent processing system to
determine accuracy, precision, and
classification
 Procedures for responding to
output validation tests
 Defined responsibilities of all
personnel involved in data output
processing
 Creating a log of activities in
validation of output

g) Is information being exchanged

between trusted/trusting systems? Has
this been authorized by ITM/BMS for
HQ and by a local ICT governance body
for local offices?

Page 9 of 11 Effective Date: 30/12/1899 Version #: 2

 h) If vendor-supplied software is being
used, will it be maintained at a level
supported by the vendor?

i) Has test data been created for the

acceptance test? If personal or
sensitive data must be used for the test,
have the following requirements been
met?

 Same levels of protection applied as

operational data
 Separate authorization each time
operation information is copied to
the test system
 Operational information should be
erased from a test application
immediately after the need for
testing is complete
 The coping and use of operational
information should be logged to
provide an audit trail

j) Have project and support environments

been strictly controlled?

k) Has adequate and appropriate

regression testing been performed in a
test environment?

l) Has the system owner’s business

continuity plan been updated with the
information on the new system?

Page 10 of 11 Effective Date: 30/12/1899 Version #: 2

 36. If you have ticked any of the boxes marked either PARTIAL or N/A, you should indicate the
reasons and justification in the following boxes.

Requirement Reasons and justification (with Action to be taken

from above reference to supporting
evidence)

COMMENTS: Enter a wider explanation of the reason(s) indicated above. Where aspects are
already addressed, it may be helpful to detail them.

Page 11 of 11 Effective Date: 30/12/1899 Version #: 2