22 - Pub It Requirements

Download as pdf or txt
Download as pdf or txt
You are on page 1of 38

PUB IT REQUIREMENTS

Contents
IT1. General Security Requirements ......................................................................................... 3
IT2. Commercial Cloud Certifications ...................................................................................... 4
IT3. Assets Management ........................................................................................................... 4
IT4. Information Classification and Handling ........................................................................... 5
IT5. Personnel Requirements..................................................................................................... 6
IT6. Security Risk Management ................................................................................................ 8
IT7. Security Monitoring ......................................................................................................... 10
IT8. ICT and Data Security Incident Management ................................................................. 11
IT9. Security Training and Awareness .................................................................................... 13
IT10. Business Continuity Management ................................................................................ 15
IT11. Application Security ..................................................................................................... 15
IT12. Access Control .............................................................................................................. 19
IT13. Data Confidentiality and Integrity ................................................................................ 25
IT14. Personal Data ................................................................................................................ 26
IT15. Cryptography ................................................................................................................ 26
IT16. Information Backup Security ........................................................................................ 29
IT17. Vulnerability Management ........................................................................................... 30
IT18. Systems using Commercial Cloud ................................................................................ 31
IT19. Logging and Audit Trails .............................................................................................. 33
IT20. Third Party Management .............................................................................................. 35
IT21. Exit Management and Audit ......................................................................................... 37
1. General Security Requirements

1.1 The Contractor shall ensure that all security requirements under this section,
regardless of the sub-section it is located, are applied to the entire scope of this
Contract unless otherwise stated. Where the Board has exercised the option within
the Contract, the Contractor shall ensure that all applicable measures set out in
this document are implemented.

1.2 The Contractor shall ensure the System and personnel (including Sub-Contractors)
comply with the required legislation, regulation and contractual requirements.

1.3 The Contractor shall ensure data and information is protected from leakage, loss,
destruction and falsification in accordance with statutory, regulatory, contractual and
business requirements. The Contractor shall protect the data and information regardless
of the format in which they are held in.

1.4 The Contractor shall incorporate the following security principles in the design,
implementation and operations of the System:

a. Confidentiality (non-disclosure of information to unauthorised entities);

b. Integrity (substantiate the accuracy and completeness of the information);

c. Availability (accessible and usable when authorised entities require access);

d. Compliance (conformance to established policies, regulations and standards); and

e. Access control (manage and control access to resource by authorised entities).

1.5 The Contractor shall fully comply with any written instructions on ICT security related
matters that are issued by the Board from time to time.

1.6 The Contractor shall provide technical advice on the network, system, database and
applications when requested during security risk analysis, security standards and policy
implementation specific to the System.

1.7 The Contractor shall ensure that all security procedures within their area of responsibility
are implemented correctly to achieve compliance with relevant security policies and
standards.
1.8 The Tenderer shall declare all security limitations relating to the security design and
implementation for System.

1.9 The Contractor shall ensure that unless otherwise stated explicitly, all additional
resources and manpower provided to resolve IT security related issues under the
responsibilities of the Contractor, such as rectifying vulnerabilities and mitigating risks,
shall not incur additional cost to the Board.

1.10 The Tenderer shall state any security-related certifications they have attained, such as
ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, CSA STAR or Information Technology
Infrastructure Library (ITIL) v3, for security management, governance framework and
operations.

2. Commercial Cloud Certifications

2.1 All Commercial Cloud Provider shall be certified with either CSA-STAR or all three of
the following ISOs: 27001, 27017, and 27018; audited by independent third parties
according to Service and Organisation Control (SOC) standards at least once every 12
months to identify if the SaaS providers have any major audit findings. For any major
findings identified by the auditors, the Board shall also be apprised of the Service
providers’ responses and remediation plans to those findings. The audit reports shall be
provided to the Board upon request.

2.2 All services such as Cloud compute services, resources and system hosting services shall
be provided by Contractor. The Tenderer is required to include all CCS, Commercial
Cloud Services, costs in the Tender.

2.3 The contractor shall host the system on commercial cloud but ensure the data is processed
and stored within Singapore. This includes data on hosting environments, back-up
facilities and off-host media.

3. Assets Management

3.1 The Contractor shall develop and maintain an inventory of all materials and assets
relevant to this Contract, and update the Board within ONE (1) month upon a change in
the inventory. The inventory shall include the software bill of materials which shall
include details of any software library dependencies used in the IT System.

3.2 The Contractor shall ensure the Board’s assets and/or information shall be protected from
loss, leakage, destruction, unauthorised modification, and falsification, in accordance with
statutory, regulatory, contractual, and business requirements.

3.3 The Contractor shall report any loss of the Board’s assets and/or information immediately
in accordance with the Board’s security incident response plan.

4. Information Classification and Handling

4.1 The Contractor shall be accountable to protect all information related to the System
entrusted to them to ensure that it is not used for other purposes unless the use is
authorised by the Board. The Contractor shall be responsible for the safeguarding of
security-classified information under their care.

4.2 The Contractor shall observe the secure usage and handling of all data/information
according to its classifications.

4.3 The Contractor’s personnel shall sign confidentiality agreements prescribed by the Board
to ensure no unauthorized disclosures of security-classified or sensitive information
received or generated under this Tender or Contract unless specifically authorized by the
Board in writing. The Contractor shall ensure that all its personnel and Subcontractors
are informed that failure to comply with this agreement would be a criminal offence and
may lead to persecution.

4.4 The Contractor shall not disclose security-classified information received or generated
under this Contract or Tender to unauthorised personnel unless specifically authorised in
writing by the Board. This includes the source of the information. In addition, the
Contractor shall ensure that discussions on the information shall be conducted in secured
areas where it is not subjected to disclosure to unauthorised personnel. For example, the
Contractor must not conduct discussions on classified matter (e.g. system design and
architecture) in public areas such as cafes and restaurants.

4.5 The Contractor shall ensure that all security classified information in its portable
computers and external storage devices, such as flash drives, are stored in an encrypted
form using desktop security software authorized by the Board. Portable computers
unable to support such designated desktop security software shall not be used to store or
transmit any security classified information. The Contractor shall also bear the costs
involved with the use of the designated desktop security software.

4.6 The Contractor shall not transfer security-classified information or personal data held in
connection with this Contract outside Singapore, or allow parties outside Singapore to
have access to it, without prior approval in writing by the Board.

4.7 Upon completion of the Contract, the Contractor shall return all security classified
materials received or generated under this Contract (including approved photocopied
materials) and perform secure erasure/destruction of security classified data. The tools
and procedures for secure erasure / destruction shall be subjected to approval by the
Board.

4.8 The Contractor shall not publicly disclose information even if information has been
declassified. The Contractor shall request for approval for public disclosure of such
declassified information from the Board.

4.9 The Contractor shall ensure that its personnel and Subcontractor do not keep any
security-classified information upon departure from his/her appointment or retain such
information when he / she no longer requires them.

4.10 The Contractor shall define and implement procedures to ensure that all data and
information stored in the System are securely erased when they are no longer required
such that the stored data and information cannot be recovered. The tools and procedures
for secure erasure/destruction shall be subjected to approval of the Board.

4.11 The Contractor shall immediately notify the Board when it becomes aware of a disclosure
or leakage of any security-classified or sensitive information acquired in connection with
this Contract.

4.12 The Contractor, its employees, agents, and Subcontractors shall not disclose information
from the Contract upon termination or expiration of this Contract.

4.13 In the event Contractor need to send information (e.g. logs for troubleshooting) to third
party, sensitive information such as Internet-Protocol (IP) address, hostname, user ID
must be sanitised prior to sending it out. The sanitised information shall be subjected to
approval of the Board before sending to the third party.

5. Personnel Requirements

5.1 The Contractor shall subject all their personnel who will be involved in the System to
security clearance by the Board before commencing their work.
5.2 The Contractor shall ensure that all the Contractor’s personnel’s security clearance
commensurate with the highest security classification of information that he/she has been
be given access to.

5.3 The Contractor’s personnel shall only be granted access to information that is relevant to
the discharge of his/her duty.

5.4 The Board reserves the right at any time to reject any of the Contractor’s personnel and
the Contractor is responsible to find replacements immediately and at the Contractor’s
own expense.

5.5 The Contractor shall define and communicate the roles and responsibilities to all
personnel involved in the project in accordance with the requirements of this Contract.
The defined roles and responsibilities shall consider the need for separation of duties to
avoid potential for conflict of interests and the level of authorisation accorded to the roles.

5.6 The Contractor shall provide detailed description of the roles and responsibilities vis-à-
vis the list of personnel who will be involved in the project.

5.7 The Contractor shall conduct appropriate background checks on all its personnel
involved in this project.

5.8 The Contractor personnel who will be assigned to perform the required security services
under this Contract shall already be trained and possess the relevant technical expertise
and experience to carry out the security services.

5.9 the Board reserve the rights to require the personnel to undergo a technical assessment
pertaining to cybersecurity for their specific roles, prior to their appointment to the
project team.

5.10 The Contractor shall designate an Information-Technology Security Manager (ITSM)


and/or Information-Technology Security Officer (ITSO) to perform the scope of work as
follows:

a. Conduct IT Security Risk Assessment together with the Board to identify the security threats to
the System, assess the risk and propose measures for approval of the Board to mitigate the risk;

b. Provision of IT security risk assessment report, which will be used as input to security design /
architecture of the System delivered by the Contractor;

c. Coordinate incident handling;

d. Coordinate security audits and testing;

e. Consolidate security testing (e.g. vulnerability scanning, penetration testing results) and ensure
remediation of all findings;

f. Maintain all the security documentation (including policies, standards and procedures); and

g. Overall responsible for IT security of the System, in accordance with the security requirements
specified in this section of the Tender.

5.11 The ITSM shall possess relevant security competencies required for this Contract. At a
minimum, the independent ITSM possess the following:

a. A minimum of THREE (3) years work experience in IT Security field involving enterprise
systems / network / cloud infrastructure;

b. A current professional information security certification (such as CISSP, CISM, CRISC,


CGEIT, GSE) or equivalent;

c. Comprehensive knowledge and experience in IT security management and governance, IT


security risk assessment and management, IT security incident response and management,
vulnerability assessments, IT security audit, penetration testing and other IT security tests,
International standards and best practices for IT security such as those published by ISO/IEC,
NIST, Center for Internet Security (CIS), etc, and technical expertise in proposed System;

d. Good interpersonal, presentation, written and communication skills;

e. Contactable via mobile phone on a 24x7 basis.

6. Security Risk Management

6.1 The Contractor shall implement the security risk management processes, standards and
procedures for the System and demonstrate conformity via deliverables such as audit
reports or security testing reports. The security risk management process shall align with
the Board’s risk management methodology.
6.2 The Tenderer shall provide a detailed description of the risk management process and
how it will be applied to the System. The risk management process shall minimally include
the following:

a. Risk identification;

b. Risk assessment;

c. Risk response;

d. Risk control activities; and

e. Risk monitoring and review.

6.3 The Contractor shall implement appropriate control strategies that are consistent with
the Board’s security policies and standards to mitigate the identified risks, threats and
vulnerabilities.

6.4 The Contractor shall perform annual ICT security risk assessments for the System
together with the Board according to the Board’s risk management methodology, and
maintain an updated security risk register for the duration of the Contract. The ICT
security risk register, as well as its subsequent updates and changes shall be subjected to
review and approval of the Board.

6.5 The Contractor shall review ICT security risks for the System together with the Board,
when instructed by the Board or whenever there is any major change. Examples of major
change are:

a. Impacts the security function of the application system (such as authentication, access
controls, logging, etc.); or

b. Has high or medium business impact to the application system (such as those affecting
key business functions).

6.6 The Contractor shall submit the ICT security risk assessment report to the Board within
TEN (10) working days upon the completion of each security risk assessment.

6.7 The Contractor shall propose alternative controls to address or mitigate the risks to a
level that is acceptable to the Board.
6.8 The Contractor shall propose response and recovery plans for each corresponding risk
identified in the event a risk materialises despite the security mitigations put in place.

6.9 The Contractor shall ensure that the risk register is updated with the latest security risk
information including inputs from the security assessments performed by the independent
security assessors. The risk register shall be provided to the Board upon request.

7. Security Monitoring

7.1 The Contractor shall implement security monitoring mechanisms to monitor all security-
related events for timely detection of suspicious events or malicious activities and alerts
shall be triggered to relevant personnel when such events or activities are detected.

7.2 The Contractor shall ensure the security monitoring rules defined, implemented and
maintained are relevant and specific to the System, and the Board shall reserve the rights
to provide inputs and change security monitoring rules at no charge to the Board.

Log requirements
7.3 The Contractor shall make available all required logs, where applicable, for security
monitoring, when requested by the Board. Examples of sources of such logs are: —

a. Operating Systems;

b. Databases;

c. Applications;

d. Network intrusion Detection and Prevent Solutions (NIDPS);

e. Anti-malware solutions;

f. Firewalls;

g. Authentication and authorisation services;

h. Remote access solutions;

i. Web proxies;
j. Domain Name Services (DNS);

k. Dynamic Host Configuration Protocol (DHCP) Service.

8. ICT and Data Security Incident Management

8.1 The Contractor shall develop, implement and maintain an ICT and Data Incident
Management Plan and handling procedures for the System together with the Board. The
Contractor shall ensure that the developed ICT and Data Incident Management Plan and
its subsequent updates are subjected to approval of the Board. The ICT and Data Incident
Management Plan shall minimally include the following:

a. Pre-incident preparation including incident management planning, awareness and education as


well as training and exercises;

b. Detection and analysis including scenarios, thresholds and procedures for activation of incident
reporting and response;

c. Response and remediation including impact containment, service and system recovery,
investigation and forensics, and evidence preservation including log and equipment acquisition,
seizure of evidence and placement of monitoring equipment where applicable; and

d. Post-recovery inquiry including post-incident reviews and recommended mitigating actions to


prevent a recurrence.

8.2 The Contractor shall ensure that all their personnel involved in the System are briefed on
the incident handling procedures.

8.3 The Contractor shall notify the Board and the Board designated representative within the
specified time upon detection of incident. The Contractor shall adhere to the response
time and frequencies stated in the following table:

Incident Severity Timeframe for Follow-on Reports


Classification
Verbal Report Incident Report Form Status Update
Within FIFTEEN Within ONE (1) hour Every FOUR (4) hours
Very Severe
(15) upon detection until normal
Severe minutes of suspected or operations have
upon confirmed resumed or as
detection of incident directed by the
suspected or Board
confirmed Every TWELVE (12)
Within TWELVE (12)
incident hours until
hours upon
normal
detection of
High operations have
suspected or
resumed or as
confirmed
directed by the
incident
Board
Every TWENTY-
Within TWENTY-
Within TWO (2) FOUR (24)
FOUR (24)
hours upon hours until
hours upon
detection of normal
Medium detection of
suspected or operations have
suspected or
confirmed resumed or as
confirmed
incident directed by the
incident
Board

Contractors shall maintain an internal record of these incidents based on


Low the above information gathered and submit this record to the Board
on a monthly basis for review and verification of the impact
assessment or when the record is requested by the Board
Table 1: System and Data Incident Reporting Schedule

8.4 The Contractor shall note that the incident severity classification level of a system or data
incident may be escalated or reduced over time. For example, an incident that is classified
as “Severe” may be escalated to “Very Severe” if the seriousness or impact is bigger than
initially determined.

8.5 All suspected or confirmed incidents, e.g. virus infection, system or data compromises,
unauthorised access, data exposure, etc. shall be reported to the Board immediately. The
Contractor shall take the necessary actions to ensure that all system and data incidents
are reported, handled and managed in accordance to the timeframe agreed with the
Board.

8.6 In the event of any ICT system or data security incidents, the Contractor’s responsibilities
shall include:
a. Impact containment, service and system recovery, investigation and forensics, and evidence
preservation including log and equipment acquisition, seizure of evidence and placement of
monitoring equipment where applicable;

b. Ensuring the preservation and admissibility of evidence by protecting and documenting all
access to incident information; and

c. Exercising the prescribed incident response guidelines and procedures of the ICT and Data
Incident Management plan of the System.

8.7 The Contractor shall generate detail incident report for each system or data incident and
submit it to the Board. The format of the incident report shall be subjected to the approval
of the Board.

8.8 The Contractor shall implement measures to prevent the recurrence of system or data
incidents.

8.9 The Contractor shall work with the Board in resolving system and data incidents by
activating appropriate personnel and resources for investigation and resolution purposes.

8.10 The Contractor shall perform root cause analysis on all incidents. The Board, however,
reserves the right to undertake parallel investigations or take over any ongoing
investigations that it deems as critical. The Contractor shall ensure that tools used in the
root cause analysis are able to preserve evidence for admission in court.

9. Security Training and Awareness

9.1 The Contractor shall ensure that all personnel are equipped with the relevant knowledge,
skillsets and experience to implement and maintain the System in a secure manner. The
personnel shall be familiar with the security requirements of the System and shall adhere
to the security policy, standards and procedures as approved by the Board and the Board.

9.2 The Contractor shall ensure that all their personnel involved in the System are informed
of their security responsibilities and accountabilities/liabilities before putting the person
in his/her assigned areas of work. The Contractor shall also ensure that their personnel
(including Subcontractors) are briefed on established security policies, rules and
procedures pertaining to working with the Board designated hosting environment and the
Board-appointed Contractors. The briefing shall minimally include
a. IT security threats and protection mechanisms;

b. Security policies, standards, processes and procedures required for their work;

c. Information handling requirements;

d. Process for reporting issues that may lead to an IT security incident; and

e. Security incident root cause analysis, case studies, reflection on past incidents.

9.3 The Contractor shall be responsible for the security education and training of their
personnel (including Subcontractors) and formulate a learning roadmap to meet the
needs, especially for new recruits and those taking on new posts and duties for this
Contract and whenever there is significant change to the usage of the System. The
Contractor shall ensure security training is conducted for all its staff and keep records of
all staff who have successfully completed the training.
10. Business Continuity Management

10.1 The Contractor shall work with the Board to develop and document business continuity
framework for the system / service, and plan to ensure core business operations can
continue when disruptive events occur. The plan shall minimally include:

a. Security considerations;

b. Emergency response;

c. Incident response;

d. Recovery procedure

11. Application Security

11.1 The Contractor shall ensure that security is built into each stage of the Software
Development Life Cycle (SDLC) by:

a. Implementing industry standards or framework, such as Open Web Application


Security Project (OWASP) Application Security Verification Standard (ASVS) to
meet this objective. The Contractor shall identify security weaknesses, propose
mitigation and improvement measures for review with the Board.

b. Performing threat modelling, scanning using automated testing tools for common
vulnerabilities and security code review. The Contractor shall share details of the
activities carried out, counter-measures or fixes used, tools used in the testing and the
findings with the Board.

11.2 The Tenderer shall submit a security risk profile for all proposed commercially off-the-
shelf (COTS) software. The security risk profile should contain the following:

a. Any security vulnerability or weakness pertaining to the COTS software;

b. Accreditations, certifications of the COTS software;

c. Known vulnerabilities affecting COTS in the past FIVE (5) years or as determined
by the Board;
d. Latest security penetration testing report and independent-party audit report;

e. Details on the development lifecycle;

f. Names and versions of third-party software/libraries/dependencies used in COTS


software; and

g. Proposal of mitigation measures or workarounds to address the identified


vulnerability or weakness, subjected to approval by the Board.

11.3 The Contractor shall ensure that the application is not affected by at least the following
vulnerabilities:

a. Broken Access Control;

b. Cryptographic Failures;

c. Injection;

d. Insecure Design;

e. Security Misconfiguration;

f. Vulnerable and Outdated Components;

g. Identification and Authentication Failures;

h. Software and Data Integrity Failures;

i. Security Logging and Monitoring Failures;

j. Server-Side Request Forgery (SSRF);

k. Broken Session Management;

l. Insecure Direct Object References;

m. Failure to Restrict URL access;


n. Insufficient Transport Layer Protection;

o. Unvalidated Redirects and Forwards; and

p. Improper error handling.

11.4 The Contractor shall implement input validation for all data that is received and
processed by an application. The input validation shall be performed at the server end,
and where applicable at the client end. The validation shall minimally cover the following:

a. Usage of positive input validation (i.e. accept what is allowed only);

b. Type validation (e.g. numbers should not include alphabets or special characters);

c. Length validation (e.g. minimum number of characters, maximum number of


characters);

d. Syntax validation and null validation;

e. Escaping of special characters, if parameterized APIs are not available; and

f. Escaping of all untrusted data in HTML contexts.

11.5 The Contractor shall reference the latest Open Web Application Security Project
(OWASP) Top 10 security risks as well as other emerging risks not covered by the
OWASP Top 10, and implement mitigation measures against these risks.

11.6 The Contractor shall implement appropriate application exception handling mechanisms
to display error messages, which does not provide any sensitive information (e.g. stack
traces with details of the source code) in the event of any exception in the application.

11.7 The Contractor shall implement appropriate session management for application
subjected to approval by the Board. The implementation shall minimally cover:

a. Generation and destruction of session ID;

b. Session ID in the cookie instead of URL;


c. Secure transmission of session ID;

d. Configurable session timeout periods (THIRTY (30) minutes or as determined by the


Board); and

e. Session renewal.

11.8 The Contractor shall implement appropriate measures to protect sensitive information or
functionality with strong access control mechanisms to ensure users accessing different
levels of the application are properly authorized. The application shall minimally include the
following:

a. Check access control permissions, whenever performing direct object references;

b. Disable directory browsing;

c. Authentication and authorization for each private page;

d. Use of role-based authentication and authorization; and

e. Deny all access by default.

11.9 The Contractor shall ensure that all magnetic or other storage media and other
materials capable of being stored on such media, whether supplied as a software or part
thereof or with any software, or used in the performance of any services do not contain
any Unauthorised Code. “Unauthorised Code” means any virus, Trojan Horse, worm,
logic bomb or other software routine or hardware components designed to permit
unauthorised access, to disable, erase, or otherwise harm software, hardware or data, or
to perform any such actions.

11.10 Prior to and at the time of software delivery and installation, the Contractor shall conduct
a complete and thorough security scan to detect Unauthorised Code using reliable and
supported anti-virus/anti-malware tool(s) on all software and materials provided under
this Contract.

11.11 In the case of breach where Unauthorised Code is introduced into the System by the
Contractor (as per clauses above), the Contractor shall indemnify the Board fully against
all costs incurred by the Board in the course of or incidental to removing the Unauthorised
Code and recovering any lost or damaged data or software.

11.12 If, after the performance of any Maintenance Services, the System is discovered to contain
or be affected by any Unauthorised Code and it is shown that this was the result of any
default of or negligent act or omission of the Contractor, its sub-Contractor, or their
respective employees, the Contractor shall indemnify the Board fully against all costs
incurred by them in the course of or incidental to removing the Unauthorised Code and
recovering any lost or damaged data or software.

12. Access Control

12.1 The Contractor shall develop, enforce and maintain an account management process
specific to the System. The Contractor shall also review and update the account
management process periodically and whenever necessary, subjected to approval by the
Board.

12.2 The Contractor shall ensure that accounts and its access rights are granted based on
principle of least privilege, on job needs, and there are proper procedures for the lifecycle
of the accounts (i.e. include handover and transferring user access credentials due to
personnel movement), subjected to approval of the Board.

12.3 The Contractor shall ensure access control validation test are conducted on the system
integrated with account management tool. The test cases shall minimally include the
following as part of the validation test:

a. Accounts shall only be provisioned using the account management tool, and not directly on the
System,

b. Accounts on the account management tools system are disabled on their last day of authorised
use,

c. Access to the System is granted after the account management tool validates that the user is an
authorised user, and

d. Access rights granted to an account cannot be mapped to another account.

12.4 The Contractor shall ensure all roles and responsibilities for this System are clearly
defined, distinct, there is segregation of roles, and documented, subjected to approval by
the Board.
12.5 The Contractor shall review the accounts and its access rights on regular basis for this
System to ensure privileges granted are still appropriate for the corresponding roles and
responsibilities. Accounts or access rights for removal shall be identified within FIVE (5)
working days from the completion of the review.

12.6 The Contractor shall implement measures to ensure that

a. Redundant or inactive user accounts and its access rights are disabled when they are not
used for NINETY (90) calendar days,

b. All accounts are disabled on the last day of their authorised use. These accounts shall be
removed and have their access rights revoked within FIVE (5) working days. For disabled
accounts that cannot be removed, the access rights of the disabled accounts shall be
revoked,

c. Unnecessary accounts shall be disabled,

d. Default credentials shall be changed to prevent unauthorised login, and

e. Where applicable, automated tools shall be implemented.

12.7 The Contractor shall ensure that all accounts (i.e. administrative, system or user accounts)
are assigned to individual, who shall be accountable for all actions performed under their
assigned account. The Contractor shall ensure that accounts are not shared for
accountability reason.

12.8 The Contractor shall develop, enforce and maintain an access control policy specific to
the System. The Contractor shall also review and update the access control policy
periodically or whenever necessary, subjected to the approval of the Board.

12.9 The Contractor shall implement strong authentication and access control mechanisms to
ensure that only authorised users are granted access to controlled features of the System,
subjected to approval of the Board.

12.10 The Contractor shall ensure that management consoles or devices for managing the
System are dedicated for administration only and not used for any other purpose (e.g.
surfing Internet, access email).
12.11 The Contractor shall have proper approval process and tracking mechanism for all access
to the System and information to ensure proper usage and accountability.

12.12 The Contractor shall implement role-based access control mechanism with sufficient
granularity and flexibility that enforces controlled access to all part of the System.

12.13 The Contractor shall develop, implement and maintain an access control matrix for the
System. The Contractor shall also review and update the access control matrix
periodically and whenever necessary, subjected to approval by the Board.

12.14 The Contractor shall ensure that there is clear separation of duties for privileged roles in
the System such as system, database and application administrators.

12.15 The Contractor shall ensure that the System allow single user logon session only, such that
users (including privileged user) cannot logon to multiple (i.e. concurrent) sessions at any
given time using the same user credentials. The Tenderer and Contractor shall highlight
any part of the System that cannot enforce single user logon session, and propose
mitigation measures subjected to approval of the Board.

12.16 The Contractor shall ensure that access controls are implemented in a fail-secure mode,
such that access to the system is not allowed when any part of the System failed.

12.17 The Contractor shall ensure that credentials (i.e. account ID and password) are
provisioned to personnel in such a manner that their confidentiality is maintained.

12.18 The Contractor shall implement physical security control measures and procedures to
prevent any unauthorised access to the System.

12.19 The Contractor shall implement one or more of the approved authentication mechanisms
as listed below:

a. Authentication using Kerberos, RADIUS, TACACS+, SAML, LDAP, or LDAPS for


Windows-based systems or systems supporting Windows application;

b. Certificate-based mutual authentication using at least TLS version 1.2;

c. Authentication using One-Time-Password (OTP) generated by hardware tokens;


d. Authentication using digital certificates securely stored in password-protected physical
smartcards or hardware tokens;

e. Challenge-Handshake-based authentication using EAP-TLS (RFC-5216) or EAP-IKEv2 (RFC-


5106); and

f. Form-based authentication using at least TLS version 1.2.

12.20 If the Contractor proposes to use authentication mechanisms not listed in Clause 15.19,
the Contractor shall provide full technical details and security risk assessments for
approval by the Board before they are implemented.

12.21 The Contractor shall ensure the System only return relevant authentication responses for
users’ reporting purpose only.

Remote Access
a. All remote administration to servers shall be performed from within a management LAN meant
only for administration (separate from user traffic);

b. Personnel that are authorised to have remote administrative access shall use multi-factor
authentication (MFA) to authenticate to the servers and applications;

c. Logging of date time, IP addresses of the source and destination systems, user information as
well as the type of action performed on devices or management consoles implemented by the
Contractor for administrative access.; and

d. Remote administrative sessions shall be terminated upon the completion of administration


activities.

Password Management
12.22 The Contractor shall ensure the System support strong password administration, secure
creation, distribution, termination, storage and destruction of passwords. User’s
credentials (i.e. User ID and Password) shall be distributed to users in such a manner that
their confidentiality is maintained.

12.23 The Contractor shall ensure the System is implemented with the following features when
using passwords:
Creations of Password
a. Passwords to be made up of at least TWELVE (12) characters;

b. Passwords to be made up of TWO (2) of the following categories:

i. Upper case alphabet (A through Z);

ii. Lower case alphabet (a through z);

iii. Digits (0 through 9);

iv. Special Characters (! $, #, %, etc.);

c. Passwords cannot be the same as account ID or user ID;

d. Prohibit accepting passwords that are commonly used, guessable or compromised;

Change of passwords
a. Passwords to be changed upon the first login;

b. Passwords change once every TWELVE (12) months;

c. Prohibit password reuse for a minimum of THREE (3) generations;

Secure usage of passwords


a. Protect stored passwords from offline attacks;

b. Transmit passwords over an encrypted channel (e.g. Transport Layer Security (TLS),
Secure Shell (SSH));

c. Passwords must not be displayed in clear;

d. Passwords to be resistant to offline attack when stored by implementing the following:

i. Only password hashes and salts can be stored;

ii. Salt shall be at least 64-bit length;


iii. Salt shall be unique for every password [SP 800-63];

iv. Salt shall be generated using a cryptographically secure random number


generator [SP 800-90Ar1, ISO/IEC 19790:2012]

v. Password hashes shall be derived from a suitable one-way Key Derivation


function (e.g. PBKDF2). The cost factor should be at least 10,000 iterations.

d. Limit consecutive failed authentication attempts that can be made on a single account
to TEN (10) times or less; and

e. Protect internet-facing systems against brute force log-on attempts (i.e. CAPTCHA
and delays between failed log-on attempts)

12.24 The Contractor should ensure the System transmit only cryptographically protected
passwords (e.g. encryption of passwords at application layer before transmitting over a
secure channel);
13. Data Confidentiality and Integrity

13.1 The Contractor shall provide detailed description of the control measures and implement
them to protect the confidentiality and integrity of security-classified data and other
sensitive information (e.g. credentials), subjected to the approval of the Board.

13.2 The Contractor shall ensure that all classified or sensitive data in-transit and at-rest
(including backup and archived data) within the System are encrypted with approved
cryptographic algorithms.

13.3 The Contractor shall implement file & folder encryption in the System to prevent
administrators or privileged personnel (e.g. system, database and application
administrators, etc.) from having access to classified and sensitive data that they are not
authorised to access.

13.4 The Contractor shall implement full disk encryption at key areas (e.g. database servers)
of the System where classified or sensitive data is stored, to prevent leakage of classified
or sensitive data in the event of device loss at hosting environment.

13.5 The Contractor shall ensure that all classified data or sensitive data in-transit and at-rest
(including backup and archived data) within the System are encrypted with approved
cryptographic algorithms.

13.6 The Contractor shall implement all necessary measures and processes to prevent
unauthorised disclosure, modification or destruction of the Board’s security-classified
information.
14. Personal Data

14.1 The Contractor shall take all reasonable measures to ensure that personal data held in
connection with this Contract is protected against loss, and against unauthorised access,
use, modification, disclosure or other misuse.

15. Cryptography

15.1 The Contractor shall ensure that the management and implementation of cryptography
for the System is secure so that the confidentiality and integrity of the network and data
are protected.

15.2 The Contractor shall use the strongest cryptographic algorithm possible for protecting
the confidentiality and integrity of data in the System or devices, and ensure that all
proposed cryptographic-based implementations in the System supports minimally the
following algorithms or its equivalent. If the Contractor proposes to use cryptography
standards not listed below, the Contractor shall provide full technical details and security
risk assessments for approval by the Board before they are implemented.

Cryptographic Type Type of Algorithm Cryptographic Strength


Secure Hash Algorithm 3 At least SHA3-256
Cryptographic Hashing (SHA-3)
Algorithm Secure Hash Algorithm 2 At least SHA2-256
(SHA-2)
Advanced Encryption At least AES-128
Standard (AES)
1. Galois Counter Mode (GCM) shall be
Symmetric-Key used where possible,
Algorithm 2. Electronic Code Book (ECB) shall not
be used, and
3. Cipher Block Chaining (CBC) shall
not be used when using TLS.
Elliptic Curve Cryptography 1. At least P-256
(ECC) 2. Curve Curve25519 or
Public-Key 3. Curve448
Cryptography Rivest-Shamir-Adleman Key size of at least 2048-bits
(RSA) Public Key
Encryption
Digital Signature Algorithm L at least 2048, N at least224
(DSA) Where
L is the bit length of the prime modulus
N is the bit length of the prime divisor
Digital Signature
Elliptic Curve Cryptography 1. For IKE v2, at least P-256
Algorithm
Digital Signature 2. For TLS, at least B-233, K-233 or P-
Algorithm (ECDSA) 256
RSA Probabilistic Signature Use key size of at least 2048-bits
Scheme (RSA-PSS)
Elliptic Curve Diffie-Hellman 1. For IKE v2, at least P-256
(ECDH) 2. For TLS, at least B-233, K-233 or P-
256
Key Exchange
Finite Field Diffie-Hellman 1. For IKE v2, at least MODP-3072
(FFDH) (ID=15)
2. For TLS, at least ffdhe3072 (ID=257)
Key Wrapping Advanced Encryption At least AES-128
Standard (AES)
Hash-based Deterministic Any hash functions specified in FIPS-180 or
Random Bit FIPS-202.
Generator
Hash_DRBG
HMAC-based Deterministic Any hash functions specified in FIPS-180 or
Random Bit
Random Bit FIPS-202.
Generation
Generator
(RBG)
HMAC_DRBG
Counter Deterministic At least AES-128.
Random Bit
Generator
CTR_DRBG
Keyed-hash MAC (HMAC) Implemented with approved cryptographic hash
Message
algorithms.
Authentication
Cipher-hash MAC (CMAC) Implemented with approved AES algorithm.
Code (MAC)
Galois MAC Implemented with approved AES algorithm.

15.3 The Contractor shall ensure activities related to the lifecycle of cryptographic materials
are logged in the audit trail.

15.4 The Contractor shall ensure that access to cryptographic materials generation function is
authenticated.
15.5 The Contractor shall ensure that cryptographic mechanisms implemented in the System
can handle the peak loads without degrading the performance of the System.

15.6 The Contractor shall ensure that cryptographic materials (e.g. keys, seed, hash, etc.) used
within the System are always protected, such that there is no unauthorised access or
decrypting / deriving the information protected by these cryptographic materials.

15.7 The Contractor shall ensure that cryptographic keys and passwords are not hard-coded
or stored in clear in the System, and are not made known to unauthorised person.

Digital Certificates
15.8 The Contractor shall define the certificate generation template, subjected to approval
from the Board.

15.9 The Contractor shall ensure the implementation of digital certificate and certificate
revocation lists shall comply with X.509 v3 standard.

Key Management
15.10 The Contractor shall develop, implement and maintain a key management process
specific to the System as follows

a. Cover key generation, registration, storage, distribution, installation, usage, rotation,


backup, recovery, revocation, suspension, and destruction.

15.11 The Contractor shall ensure all direct access to cryptographic keys and materials in the
System at any time are logged.

15.12 The Contractor shall ensure that the System allows proper backup and recovery of
cryptographic keys.

15.13 The Contractor shall ensure cryptographic keys used to protect data are encrypted and
stored in secure protected storages or be minimally secured in cloud native key
management tools which are certified FIPS 140-2 Level 2 or higher.
16. Information Backup Security

16.1 The Contractor shall propose and implement backup and recovery plans based on the
Systems’ Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). The
RTO and RPO of this system are 168 hours and 168 hours.

16.2 The Contractor shall ensure the proposed backup solution maintain the same integrity
state of the source data onto the backup data.

16.3 The Contractor shall ensure the proposed backup solution ensure the confidentiality and
integrity of all backup data.

16.4 The Contractor shall ensure the proposed backup solution maintain the access rights of
the source data onto the backup data.
17. Vulnerability Management

17.1 The Contractor shall establish and implement vulnerability management processes (to
manage and remediate discovered vulnerabilities related to the System.

17.2 The Contractor shall ensure the assessment include a determination of the threat posed
by the vulnerability, its impact and its severity.

17.3 The Tenderer shall provide details of and implement the security measures to prevent
malicious codes from harming the System and networks.

17.4 If any vulnerability is found to be due to parts, components and dependencies supplied by
the Contractor, the Contractor shall provide remedial actions to rectify the problem at no
additional cost to the Board.
18. Systems using Commercial Cloud

18.1 The Contractor shall implement logging of all security-related events such as:

a. Privileged account activities (i.e. administrations, configuration changes,


application/system policy changes, or API access permission changes);

b. Logon, logoff and usage activities (i.e. abnormal logon attempts, logon success and
failures, escalation of privileges, certificate activities);

c. Database activities (i.e. configuration changes, account and access rights activities,
connection attempts, database errors); and

d. Network activities (i.e. traffic to/from malicious network addresses or domain names,
suspicious outbound connections, rejected and dropped network traffic).

18.2 The Contract shall implement the following security measures:

a. Cloud native network firewalls (i.e. AWS Security Groups, Azure Network Security
Groups, Google Armor)

b. Cloud security detection tools (i.e. AWS GuardDuty, Azure Sentinel, Google
Stackdriver)

c. Cloud native logging whenever possible (i.e. AWS CloudWatch, Azure Audit logs,
Google VPC Flow logs)

d. Notification when suspicious activities are detected; and

e. Stream logs to central logging servers.

18.3 The Contractor shall implement the following key management measures:

a) Ensure cryptographic keys are rotated regularly (e.g. every SIX (6) months, annually);

b) Ensure that all the accounts that are granted with the permission to manage and
administrate the keys are regularly reviewed according to the agency's requirement, and
remove all excessive permissions timely; and

c) Ensure proper process when managing cryptographic key policies (e.g. key lifecycle,
key allocations, key rotation).

18.4 The Contractor shall implement the following data security measures:

a) Ensure that data at rest is encrypted (e.g. block, file, directory and snapshot level);

b) Ensure data in-transit is encrypted over untrusted networks;

i. Use of encrypted channel for communication over the Internet or any other
untrusted networks (e.g. HTTPS, TLS, IPSec, SFTP).

c) Identify all possible data flows and critical path;

i. Details of all communication channels of the residing data (e.g. TCP traffic,
API calls, Intranet and Internet Compartments).

d) Ensure data are segregated according to agency's requirements and environment;

i. Ensure all data are separated clearly according to agency’s project


environment. (E.g. Pro, Non-Pro, UAT, Development, Operations).

e) Ensure data life span is kept in accordance with agency’s requirements; and

f) Ensure data that has reached its end of its lifecycle is securely deleted;

18.5 Delete both the encrypted data and their corresponding encryption keys in their storages,
when data is no longer required.
19. Logging and Audit Trails

19.1 The Contractor shall implement log management solution to store all security-related logs
(e.g. application, database, network, Operating System, security solutions, etc.) of the
System for a period of at least ONE (1) year. For network packets and flows, the logs shall
be kept for at least ONE (1) calendar month and THREE (3) calendar months
respectively.

19.2 The Contractor shall ensure the security-related logs are collected and stored on dedicated
logging servers.

19.3 The Contractor shall ensure that sensitive information (e.g. password) is not stored in the
logs.

19.4 The Contractor shall ensure that the logs are accessible to authorised personnel only.

19.5 The Contractor shall ensure the System is implemented with logging mechanism to log all
activities in the System including actions performed by privileged user accounts (for e.g.
system administrators, auditors, and database administrators). The activities to be logged
minimally include the following: —

a. User administration activities (e.g. add / delete / amend user accounts and profiles);

b. Privileged user activities in application (e.g. add / delete / amend application


configurations);

c. System administration activities (e.g. add / delete / amend system configuration);

d. Database activities (e.g. configuration change, account and access rights activities,
connection attempts, database errors);

e. Network activities (e.g. configuration traffic to and from malicious network addresses
or domain names, suspicious outbound connections, rejected and dropped network
traffic);

f. System backup and recovery activities;

g. User log in and out activities;


h. Successful and unsuccessful attempts to logins and logouts of the System;

i. Use of privileged functions and utilities;

j. Access violations from local and remote requests;

k. Service start up and shutdown;

l. Service backup and recovery; and

m. Configuration changes.

19.6 The Contractor shall ensure the System is capable of logging transaction performed by
users (e.g. adding, editing, and deletion of records, cases, documents).

19.7 The Contractor shall ensure information in audit logs contain minimally the following: —

a. Date of transaction;

b. Time of transaction;

c. Source of occurrence;

d. Account and name who made the transaction;

e. Information before and after the transaction;

f. Online screen reference/id if changes were made online; and

g. Batch job reference/id if changes were made in batch.

19.8 The Contractor shall identify and include additional information for the audit log if
necessary.

19.9 The Contractor shall ensure that the individual actions of all personnel working on the
System are accounted for and auditable.

19.10 The Contractor shall enforce segregation of roles to ensure that roles that can review logs
have no rights to any other part of the System except to the Log Repository solution.

19.11 The Contractor shall implement tamper protection measures to safeguard the integrity of
logs and audit trails, e.g. intentional abuse or unintentional misuse through modification
or deletion, no access to logs by operations personnel to prevent risk of tampering or
deletion.

19.12 The Contractor shall ensure the System prompt authorised users to archive the audit
trails when the records reach or exceed the retention period.

19.13 The Contractor shall provide and maintain a backup or archival plan specifying details
on the frequency and method to backup or archive the logs.

19.14 The Contractor shall ensure the System present the logs in a format that is easy to read
by authorised users, such as ASCII or UTF-8 encoded text files.

19.15 The Contractor shall implement process for all necessary logs to be reviewed monthly or
when necessary such as after configuration changes to scan for security violations, issues
or concerns and highlight them to the Board. The Contractor shall use automated tools
for log review, where possible.

19.16 The Contractor shall ensure logging functionalities for the System and all applicable
components within are working properly. (i.e. before and after commission, after any
change that could impact logging functionalities)

19.17 Upon notification by the Board or the Board appointed parties, the Contractor shall make
available the logs of the requested systems in accordance to the following schedule:

Age of logs Turnaround Time

Up to THREE (3) months old Within ONE (1) calendar day

More than THREE (3) months old Within FIVE (5) calendar days

Table 2: Turnaround Time for Logs

20. Third Party Management

20.1 The Contractor shall submit a self-assessment plan annually, to ensure they carry out
their assigned work in compliance with contractual obligations and applicable Board
policies and standards. The scope of the self-assessment review shall be stipulated by the
Board, and the results and report arising from such a self-assessment review shall be put
up by the Contractor and shall be made available for the Board to review.

20.2 The Contractor shall submit a remediation plan within two weeks from the issuance of
the compliance audit report. The remediation plan shall include the target remediation
timelines for all findings, which shall be no longer than 12 months from date of the
compliance audit report.

20.3 The compliance audit will cover the Contractor’s contractual obligations and assess if the
Contractor have adequately managed the identified cybersecurity risks in their work.
This includes performance against Service Level Agreement (SLA) defined in the
contractual agreement and procedures. Details of the scope of the compliance audit are:

Onboarding
20.4 The Auditor will assess if the Contractor has complied to all the contractual obligations
and have adequately managed the identified risks in their work.

20.5 This includes performance against Service Level Agreement (SLA) defined in the
contractual agreement and procedures. Check that applicable penalties and service
credits are provided by the Contractor when SLA was not satisfactory as well as proper
follow-up/timeline rectification of identified issues. Any waivers should also been
documented.

20.6 The Auditor will assess if the Contractor’s personnel working on the project have
attended the on-boarding sessions and have the necessary security clearance.

Service Management
20.7 The Auditor will assess if the Third Party has complied to all the contractual obligations
and have implemented all the control requirements stated by the Agency in the
Contractual Agreement have adequately managed the identified risks in their work.

20.8 The monitoring and review include the following areas:

a) Performance against Service Level Agreement (SLA) defined in the contractual agreement and
procedures. Check that applicable penalties and service credits are provided by the
Contractor when SLA was not satisfactory.
b) For the identified controls, the compliance with ICT policies & standards, including protective
measures for data security. Issues such as compliance gaps and audit findings are
monitored, have identified concrete action plans to treat the residual risks, and the
residual risks accepted and approved by the risk approving authority.
c) Adherence to incident management process.
d) Sub-contracting requirements.
e) Dispute resolution and management
f) Verification checks on assets and equipment assigned to the Contractor.
g) Where the control environment at the Contractor has been audited, provide the audit reports
to monitor findings, remediation and impact to PUB.
h) Ensure that the Contractor conducts a self-assessment annually against contractual obligations
and requirements. e.g. refresher briefings are attended annually.
j) Contractor submitted remediation plan within 2 weeks from the issuance of the audit report.
The target completion dates for audit findings should be within 12 months from the report
issuance.
k) Remediation status of audit findings are monitored quarterly.
20.9 The Contractor is encouraged to be certified with the Data Protection Trustmark
(“DPTM”) to demonstrate that the Contractor’s accountable data protection practices
are in compliance with the Personal Data Protection Act. For Contractors that have Data
Protection Trustmark (DPTM) certification, the audit scope will be reduced by excluding
the checks covered by the DPTM certification process from the third party compliane
audit. If the Tenderer has DPTM, it shall submit evidence of such certification at the time
of the tender submission.

21. Exit Management and Audit

21.1 On award of the contract or equivalent instrument, the Contractor shall put in place an
exit management plan that minimally includes the following, where applicable, and ensure
that it is updated regularly:

a) Obligations of the Third Party during the transition period, including transfer of knowledge,
deliverables or services to another Third Party or to the Agency;
b) Option for the Agency to buy back equipment and software from the Third Party based on a
formula for price determination;
c) Transfer of relevant sub-contractor contracts and leases (e.g., maintenance and licensing
contracts) to another Third Party or to the Agency;
d) Transfer of data, data structures and methodologies to another Third Party or to the Agency;
e) Transfer of critical Third Party staff to another Third Party or to the Agency;
f) Destruction of data by the Third Party;
g) Retrieval of any assets that are provided to the Third Party; and
h) Any other agency-specific requirements to be adhered to by the Third Party.

21.2 Upon contract expiry date or the effective date of termination of the Contract, or such
later date as informed by the Board, the Contractor shall conduct a self-assessment for
the exit audits to ensure that the Contractor has fully performed the Transition Services
and complied with the Exit Plan. The audit scope shall be approved by the Board. The
Exit Audit may extend after the expiry or termination of the Contract in order for the
Contractor to ensure that the Contractor has complied with its obligations. The auditor
shall possess industry-recognised certification, such as Certified Information Systems
Auditor (CISA) or equivalent certification. All costs and expenses relating to such Exit
Audit shall be borne by the Contractor.

21.3 The Contractor shall, as soon as reasonably practicable, address any findings, failure to
perform any Transition Services or non-compliance with the Exit Plan revealed in the
Exit Audit, and shall fully indemnify the Board for any Losses suffered by the Board
arising from the aforementioned failure or non-compliance.

21.4 The Exit Audit shall cover the following:

a) The Auditor will assess if the Contractor has put in place the measures according to the exit
management plan as well as work with the agency to update the plan when there are changes in
the system design/architecture/ operations
b) The Auditor will assess if the Contractor executed the requirements using the exit management
plan.

21.5 The Contractor shall submit a remediation plan within two weeks from the issuance of
the compliance audit report. The remediation plan shall include the target remediation
timelines for all findings, which shall be no longer than 12 months from date of the
compliance audit report.

You might also like