Development and Maintenance of PUB Sensor Platform (PSeP)

CONTENTS
SECTION 1: INTRODUCTION ......................................................................................................... 2
1.1 OBJECTIVES ........................................................................................................................... 2
1.2 BACKGROUND ....................................................................................................................... 2
1.3 CONCEPT OF OPERATIONS ............................................................................................... 3
1.4 SCOPE OF WORK................................................................................................................... 5
SECTION 2: GENERAL ..................................................................................................................... 7
2.1 PROPOSED TEAM AND COMPLIANCE ........................................................................... 7
2.2 CONTRACTOR'S OBLIGATION ......................................................................................... 7
2.4 CONTRACTOR'S PERSONNEL ........................................................................................... 9
2.5 INSURANCES AND CLAIMS PROCEDURE .................................................................... 11
2.6 DEVELOPMENT ENVIRONMENT ................................................................................... 11
2.7 DOCUMENTATION .............................................................................................................. 12
2.8 TRAVEL AND RELOCATION ............................................................................................ 13
2.9 AGENCIES AND BOARD'S APPOINTED OFFICERS /CONTRACTORS................... 14
2.10 WORKING HOURS ............................................................................................................... 14
2.11 MANAGEMENT OF SUB-CONTRACTOR(S) .................................................................. 14
2.12 TECHNICAL EXPERT RESIDENT/S ................................................................................ 15
2.13 PHYSICAL SECURITY ........................................................................................................ 15
SECTION 3: TECHNICAL SPECIFICATIONS ............................................................................ 16
PART 1: DESIGN, DEVELOP AND IMPLEMENT A CENTRAL PUB SENSOR PLATFORM
(PSeP) 16
3.1 SENSOR PLATFORM ARCHITECTURE ......................................................................... 16
3.2 PLATFORM REQUIREMENTS .......................................................................................... 17
3.3 FUNCTIONAL REQUIREMENTS ...................................................................................... 20
3.4 SERVICE REQUIREMENTS ............................................................................................... 36
3.5 PROJECT IMPLEMENTATION APPROACH ................................................................. 37
PART 2: INTEGRATION JOBS....................................................................................................... 39
PART 3: MAINTENANCE AND SUPPORT................................................................................... 42
PART 4: CHANGE REQUESTS....................................................................................................... 49
SYSTEM AVAILABILITY AND SERVICE LEVEL AGREEMENTS: ...................................... 55
PROJECT & PAYMENT MILESTONES ....................................................................................... 56
LIQUIDATED DAMAGES ............................................................................................................... 61
HANDOVER ....................................................................................................................................... 63
REMEDIAL ACTIONS ..................................................................................................................... 64
COVID MEASURES .......................................................................................................................... 65
APPENDIX A: IT Security Requirements ....................................................................................... 66
APPENDIX B – LIST OF HARDWARE AND SOFTWARE ...................................................... 118

TS-1
 Development and Maintenance of PUB Sensor Platform (PSeP)

SECTION 1: INTRODUCTION
1.1 OBJECTIVES
1.1.1 This tender calls for the Development and Maintenance of PUB Sensor Platform
(PSeP) to manage all sensor systems/devices across PUB for a period of FIFTY-
EIGHT (58) MONTHS with TEN (10) MONTHS for development and FORTY-
EIGHT (48) MONTHS for maintenance of the PSeP.
1.1.2 The PSeP intends to provide a unified and scalable infrastructure for connecting,
managing, and analysing the sensor performance and the data collected by them.
1.1.3 The key objectives of PSeP are to:
i. Provide a simplified on-boarding process for sensors and devices.
ii. Manage sensors and devices centrally with user-friendly, intuitive, and intelligent
device and data management dashboards.
iii. Implement consistent data and cyber security policies and measures for all sensor
deployments.
iv. Set up a Single Source of Truth (SSOT) for all sensor data to derive higher level
insights.
1.1.4 The PSeP shall be capable of the following key functionalities but not limited to:
i. On-boarding and connecting all PUB sensors through this centralized platform
with real-time data processing and secure communication.
ii. Providing device and data monitoring services to ensure reliable data
communication and good data quality.
iii. Storing all the sensor data in this platform with tiered storage methods,
redundancies, and data exchange mechanisms.
iv. Dashboards for device management, data storage and exchange management,
data visualization, reports.
1.1.5 The system shall be designed with flexibility, scalability, and security in mind to
accommodate various sensor use cases.

1.2 BACKGROUND
1.2.1 PUB has numerous sensor systems supporting the water operations and asset
management. However, these systems are currently implemented in a distributed
manner with each department deploying and hosting many systems for different
function in various hosting environments. Each system has its own sensor platform

TS-2
 Development and Maintenance of PUB Sensor Platform (PSeP)

services to connect and manage devices and build the necessary applications. The data
collected by these sensor systems are also stored and managed within the respective
systems.
1.2.2 PUB intends to consolidate the sensor middleware layer across departments, allowing
all PUB sensors to connect to the same platform, for better governance, consistent
standards and security measures and improve efficiency of sensor on-boarding and
management. The platform is expected to provide scalability, interoperability, and the
ability to accommodate diverse devices and applications, thereby laying the foundation
for future innovation and growth.
1.2.3 PUB also intends for the PSeP to consolidate data from sensors deployed in PUB
treatment plants and installations which are consolidated via the Supervisory Control
And Data Acquisition (SCADA) systems. The inclusion of SCADA sensor data will
complete the SSOT for sensor data within PSeP and allow for it to be the central data
exchange platform.
1.2.4 The key stakeholders involved in the PSeP include PUB officers and its contractors
providing the sensors and devices. Their inputs and collaboration are essential for the
successful implementation and adoption of the platform.

1.3 CONCEPT OF OPERATIONS

1.3.1 The PSeP shall be a web-based PUB Intranet system that supports the various
stakeholders to carry out their business functions such as the following but not limited
to:
i. System owners
• System owners are PUB officers in various departments who manage sensors
and sensor systems, and the associated data. They engage contractors to install
sensors on location and enable their on-boarding on PSeP.
• System owners regularly monitor the following but not limited to
o sensors’ health status and report
o communication status and report
o alerts when there are deviations in the expected performance metrics (e.g.
downtimes, data validation errors, poor data quality, not meeting SLA,
etc)
• The PSeP shall facilitate system owners to

TS-3
 Development and Maintenance of PUB Sensor Platform (PSeP)

o manage their respective sensor systems for their specific operational

needs.
o define the locations where sensors are to be installed, the type of sensors
to be installed, the frequency of data collection, the data format and the
service level agreements for each sensor platform they manage.
o monitor and obtain reports on the sensor health and communication status,
sensor metadata, sensor locations in a geospatial format, trends, alerts,
downtimes, deviations etc required for their business functions.
ii. PUB Contractors
• These are PUB’s partners who install and connect the sensors to the platform
and maintain the sensors over the operational period.
• The PSeP shall facilitate PUB’s Contractors to carry out the following activities
but not limited to:
o configure their sensor systems and sensors.
o monitor sensor status (downtimes)
o monitor data quality.
o perform analytics to optimise their sensor system.
o check for vulnerabilities.
o configure the reports.
iii. System administrators
• System administrators are specific groups within PUB who can:
o have an overview of all sensor systems within PUB in either a list or a
geospatial format.
o approve, create, and manage account requests etc.
o monitor the performance of sensor systems at a sensor/device level.
o manage sensor models, cybersecurity configurations, profiles, etc
o perform analytics to assist system owners to achieve their business needs.
• The PSeP shall facilitate PUB’s system administrators with the above functions.
iv. Sensor platform vendor
• The sensor platform vendor is the developer of the PSeP and shall be responsible
for the design, development, deployment, and maintenance of the PSeP for
PUB’s operations.

TS-4
 Development and Maintenance of PUB Sensor Platform (PSeP)

• The platform vendor shall develop and implement functionalities that shall
assist the platform vendor to carry out the following scope of work but not
limited to:
o Sensor on-boarding and provisioning
o Platform updates and upgrades
o Maintenance of the system etc
1.3.2 The platform shall serve as PUB’s Single Source of Truth (SSOT) for all the sensor
data and shall serve as a central data base of sensor data from where stakeholders may
extract and use the data to carry out higher order analytics.
1.3.3 The diagram below highlights the concept of operation that is envisaged for the PSeP:

Figure 1 PSeP Concept of Operation

1.4 SCOPE OF WORK

1.4.1 The scope of services under this contract shall include the following FOUR (4) parts:
Part 1: Design, Develop and Implement PUB Sensor Platform (PSeP)

The Contractor shall Design, Develop, and Implement a cloud based Central PUB
Sensor Platform (PSeP) complete with all required modules and functionalities as stated
in Section 3 of the Technical Specifications within TEN (10) MONTHS of the contract
commencement date.

i. The Contractor shall carry out user engagement sessions to finalise the platform
design (system architecture document, dashboard design document, user
requirements report, etc) within TWO (2) MONTHS of the contract
commencement date.

TS-5
 Development and Maintenance of PUB Sensor Platform (PSeP)

ii. The Contractor shall carry out the User Acceptance Test (UAT) within SIX (6)
MONTHS of approval of the platform design stated in Section 1 Clause 1.4.1.i
(above) a sensor platform that is complete with all the features and functionalities
as indicated in Section 3 Clause 3.3 of the Technical Specifications.
iii. The Contractor shall implement in the production environment within TWO (2)
MONTHS upon completion of the UAT sign-off as stated in Section 1 Clause
1.4.1.ii (above) a fully developed sensor platform inclusive of onboarding sensor
systems as advised by the Board.

Part 2: Integrations Jobs

i. The Contractor shall integrate the Board’s SCADA data with the PSeP when
requested by the Board over the course of the Contract period upon completion
of Part 1 of the scope of work (above).
ii. The Contractor shall provision FIFTEEN (15) JOBS covering integration of the
Board’s systems that may include either sensor on-boarding or data storage or
data exchange or combination of the above over the course of the Contract period
upon completion of Part 1 of the scope of work (above).
iii. The Contractor shall provision FIVE (5) JOBS also carry out data acquisition &
integration of the Board’s existing systems already hosted on the cloud via Cloud-
to-Cloud integration over the course of the Contract period upon completion of
Part 1 of the scope of work (above).

Part 3: Maintenance and Support

i. The Contractor shall provision for Maintenance and Support services for the
remaining period of the contract from completion of Part 1 (above) of the scope
of services.

Part 4: Change Requests

i. The Contractor shall provision THREE HUNDRED (300) man-days to carry out
change requests to the PSeP during the contract period when requested by the
Board.

1.4.2 The contract shall be for a duration of FIFTY-EIGHT (58) MONTHS from the
commencement date.
TS-6
 Development and Maintenance of PUB Sensor Platform (PSeP)

SECTION 2: GENERAL

2.1 PROPOSED TEAM AND COMPLIANCE

2.1.1. The Tenderer shall provide a detailed proposal showing the organization chart with the
Project/Contract Manager, each team member, their roles and responsibilities, scope of
work, and involvement to meet the objectives of this Tender. The Tenderer shall submit
the resumes of proposed personnel highlighting relevant qualifications and experience
as supporting documents. The organisation chart, list of its key personnel, their
qualifications and experience, roles and responsibilities shall be provided in Annex G –
Project Organisation Chart and Resource Histogram and Annex H – Project Experience
of Individuals.

2.1.2. The Board shall at its discretion, during the period of the contract, request replacements
in the Contractor's project team if they are found unsuitable or non-compliant.
2.1.3. The specifications shall be strictly complied with and any absence of comment in the
Tenderer's submission shall be interpreted as acceptance and compliance with the
requirements of the specifications.

2.2 CONTRACTOR'S OBLIGATION

2.2.1. During the contract period, the Contractor’s obligations shall include the following but
not limited to:
i. carry out his obligations to the Board under this Contract.
ii. manage & provide all the services as specified in the Contract.
iii. monitor the employment status of the assigned Contractor Personnel and provide
back-up service to the Board as may be appropriate to ensure the efficient
performance of the service.
iv. avoid service disruption and shall not remove or replace any individual already
accepted by the Board without seeking prior approval from the Board in writing.
v. provide a Project/Contract Manager with relevant experience to coordinate all work
involved and liaise with all relevant parties for the contract scope of work.
vi. provide a team (Section 2, clauses 2.4.1 to 2.4.3) with relevant experience and
technical competency to work on and complete the contract scope of work.
vii. ensure the technical competency of its personnel deployed to this Contract,
including providing training etc. at no cost to the Board.

TS-7
 Development and Maintenance of PUB Sensor Platform (PSeP)

viii. conduct quality checks to ensure programs migrated to Production Environment

are free of defects.
ix. enforce compliances to adopted processes, procedures, and policies.
x. provide trainings to users for any refresher or major enhancements/deployment.
xi. provide documentation that are updated and easy to use.
xii. handover the complete set of documentation to the Board at the end of the contract
xiii. handover the services managed by the Contractor to the next party at the end of the
contract.
2.3 CONTRACTOR'S PROJECT/CONTRACT MANAGER
2.3.1. The Contractor shall provide a Project/Contract Manager who shall manage and
supervise all matters pertaining to this Contract on a full-time basis. The
Project/Contract Manager shall be stationed in Singapore. The Project/Contract
Manager must have the authority to make decisions on behalf of the Contractor.

2.3.2. The Contractor shall also provide a secondary point of contact. The secondary point of
contact acts as the covering officer during the absence of the Project/Contract Manager.

2.3.3. The Project/Contract Manager is required to have good supervisory, communication

skills and the relevant qualifications. The Project/Contract Manager shall be well
experienced in project management and have supported systems with the
relevant/similar software or platforms, with about FIVE (5) YEARS IT Project
Management experience. Project/Contract managers with experience of less than FIVE
(5) years can be included in Annex G for consideration by the Board.

2.3.4. The Project/Contract Manager shall be familiar with the Conditions of Contract and the
technical specifications stated in the Contract.

2.3.5. The Project/Contract Manager shall ensure that the deliverables are in accordance with
the specifications stated in the Contract and completed on schedule.

2.3.6. The Project/Contract Manager will serve as the liaison between the Board and his
Project Team members (Contract Personnel) and shall report to the Board’s Supervising
Officer and/or his representatives periodically on the progress of the Project.

2.3.7. The Project/Contract Manager shall prepare a programme of work which shall identify
all the tasks necessary by the Contractor to carry out his obligations in all areas of work
of the services and subsequent monitoring of the actual progress, advising the Board of
any development threatening the completion and recommending necessary action to the
Board to ensure timely completion of the works.

2.3.8. The Project/Contract Manager shall arrange and convene working meetings on dates

TS-8
 Development and Maintenance of PUB Sensor Platform (PSeP)

acceptable to the Board for the purposes of informing the Board on the progress and
development. Such meetings shall be held at monthly intervals, unless otherwise
requested by the Board. The Contractor shall address project progress issues and also
submit the minutes of the meeting to the Board’s Supervising Officer within 5 working
days of conducting the meeting.

2.3.9. The Project/Contract Manager shall arrange and attend meetings with the Board, the
appointed Contractor(s), other consultants etc. as necessary to carry out the Services.

2.3.10. The Project/Contract Manager shall chair all meetings with the Board.

2.3.11. The Project/Contract Manager shall be responsible for establishing the time and agenda
for all meetings. The Project/Contract Manager must be prepared for each meeting with
the necessary details for discussion and shall submit the details to the Board's
supervising officer prior to the discussion. The Contractor’s Project/Contract Manager
shall inform the Board’s Contract Manager and all required personnel from the Board
for the meeting.

2.3.12. The Project/Contract Manager shall coordinate all matters that require collaboration
between the Contractor Personnel and the Board’s users to ensure smooth progress of
the Project/Contract Manager.
2.3.13. The Project/Contract Manager shall observe any change or previously unknown
condition that may require modification to the plans and/or specification of the works,
thereby advising the Board of the same and recommending appropriate action and
propose modification work if any, subject to the Board’s approval.

2.4 CONTRACTOR'S PERSONNEL

2.4.1. The Contractor shall deploy only experienced personnel to this Contract who have
about THREE (3) years of relevant working experience. Personnel with experience of
less than THREE (3) years can be included in Annex H for consideration by the Board.

2.4.2. The proposed team shall include the following but not limited to:
i. Cloud Solutions Architect with about THREE (3) years of experience in:
• Cloud subject matters
• Design of robust and scalable cloud systems (eg., Azure, AWS, GCP) at
enterprise level
• Designing systems involving interfacing and integration with multiple systems
including device integration (eg., on-prem or C2C).
• Sg Govt projects (eg., GCC implementation) is preferred.

TS-9
 Development and Maintenance of PUB Sensor Platform (PSeP)

ii. Cyber security and networking specialist with about THREE (3) years of
experience in:
• Design and implementation of cyber security measures in enterprise/cloud
systems
• Implementing suitable security measures during the SDLC phase including
maintenance.
• Identifying vulnerabilities and implementing suitable measures for the same.
• Implementing and maintaining data security measures throughout the entire
life cycle of enterprise systems.
• Experience in Sg Govt projects is preferred.
• Note: The cybersecurity and networking specialist shall ensure that all
necessary cybersecurity related clauses stated in the IT security requirements
(Appendix A) are complied with.
iii. Software specialist/IoT specialist with about THREE (3) years of experience in:
• Software design and development in the cloud environment
• Interacting with and collecting user requirements and translating them to
software design wireframes and prototypes for stakeholders.
• Interfacing OPC UA systems with Azure Cloud IOT platform for real-time
data exchanging.
• Collaborating development teams and ensuring the delivery of the solution as
per the requirements.
• Continuous Integration & Continuous Deployment (CICD) experience is
preferred.
• Sensor platform development, implementation, and maintenance.
• Sg Govt projects (eg., Sensor/GCC integration) is preferred.
iv. Database administrator with about THREE (3) years of experience in:
• Designing databases for high throughput systems at enterprise level
• Implementing & maintaining robust and resilient database structures for
enterprise systems. Including monitoring databases
• Determining and enforcing database policies procedures and standards
• Performing appropriate tests and evaluations to ensure data security, privacy
and integrity of databases.
• Sg Govt projects is preferred.

TS-10
 Development and Maintenance of PUB Sensor Platform (PSeP)

v. Maintenance personnel with basic network, server, security and/or database skills.

2.4.3. The proposed team shall be able to cover all the following skills, but not limited to the
following:
i. Networking (lease lines, private APN, firewalls, routers etc)
ii. Servers (Virtual Machines, physical hardware, storage etc)
iii. Security (Application, network, database, data etc)
iv. Databases (eg: latest versions of MS SQL Server Database or any other databases
used in the system)
v. Data Analytics (refer to functional requirements)
vi. Azure IoT Platform software
vii. Device and/or OPC UA and API integration
viii. Basic troubleshooting of connected devices (eg., sensors) and providing remote
assistance

2.5 INSURANCES AND CLAIMS PROCEDURE

2.5.1. The Contractor shall insure the Board against any risk of loss or damage to the Solution
except for loss or damage caused by theft, negligence, or malice by any of the Board’s
employees or agents. The period of insurance shall be from the date this Contract comes
in to force to the end of the contract period.

2.6 DEVELOPMENT ENVIRONMENT

2.6.1. The Contractor’s computers are not allowed to connect to the Board's network.
2.6.2. The Contractor shall use its own computers for development, unit testing, and
maintenance/support work for the period of this Contract where applicable.

2.6.3. The Contractor shall provision their own laptops to access the system and servers for
maintenance and deployment purposes. The laptops shall be configured with the
Board’s necessary software/application to enable connection to the cloud environment.
The Board may also issue laptops to the Contractor on a case-by-case basis.

2.6.4. A secure USB device shall be used by the Contractor for copying the files to servers
when required.

2.6.5. The Contractor shall develop the change management process (ADKAR) and
procedures between the development, quality assurance and production platforms if
deemed necessary. The Contractor shall adhere strictly to the procedures to ensure
proper versioning and source control of the programs. All these information and

TS-11
 Development and Maintenance of PUB Sensor Platform (PSeP)

modifications must be clearly documented.

2.6.6. The Contractor shall provide its own licensed software tools for development during
this Contract.

2.6.7. The Contractor shall NOT use any production data on the development /UAT
environment without prior knowledge or the consent of the Board.

2.7 DOCUMENTATION
2.7.1. Upon the Board’s request, the Contractor shall supply the IP rights and source code of
new features and change requests required by the Board as part of the present contract,
excluding the source code that is part of the Background Intellectual Property of the
Contractor, pre-existing the present contract.

2.7.2. The Contractor Personnel shall keep all relevant documentation updated. All latest
enhancement/changes to the PSeP shall be reflected in the relevant documents at no
additional cost to Board. All enhancements/changes shall be reflected in the
documentation within FOUR (4) weeks upon production release of the new
features/changes.

2.7.3. All documents produced/maintained by the Contractor Personnel in fulfilling this

Contract, shall become the property of the Board. Prior approval shall be obtained from
the Board for any reproduction and distribution of documents produced by the
Contractor Personnel.

2.7.4. All documentation (e.g. reports, drawings, data and documents) shall be in good, simple
and concise English using accepted technical terms and symbols. All documents,
except for the standard documentation that accompanies the appropriate hardware and
system software, shall be made available in softcopy in electronic format such as docx,
.pptx, .xlsx, and .shp for ready reference and subsequent maintenance. All documents
shall have comprehensive indexes to facilitate quick reference. For maintainability, all
such documentation must be converted to the latest version of the documentation tool
which was used, if so required by the Board. Classified documentation shall be
encrypted and stored securely as necessary.

2.7.5. All documents produced by the Contractor in fulfilling this Contract, shall become the
property of the Board. The Board reserves the right to reproduce, at no cost whatsoever,
any documentation supplied with this Contract for its own use. Prior approval must be
obtained from the Board for any reproduction and distribution of documents developed
by the Contractor under this Contract.

2.7.6. The Contractor shall provide satisfactory answers to any queries raised by the Board
within FIVE (5) working days with the concerning information stated in the document.

TS-12
 Development and Maintenance of PUB Sensor Platform (PSeP)

2.7.7. The Contractor shall provide documentations with appropriate screen-dumps,

pictorials, and step-to-step guides for the ease of the users’ understanding.

2.7.8. In addition to the above, the Contractor shall also supply documentation on the
proposed system requirements.

2.7.9. The proposed system requirements document shall be used as a guide in the use of the
proposed system. It shall include detailed hardware configuration, detailed software
configuration, detailed client configuration and complete and comprehensive database
schemas:
i. User Acceptance Test Plans and Report
ii. System Administration and Management Manuals
iii. The documentation shall comprise the following:
iv. System security and administration of access control including maintenance of
security matrix.
v. List of Systems, Servers, and Database Administration IDs and their purposes
vi. Operational Manuals
vii. Detailed maintenance plan

2.7.10. These operation procedure manuals shall be used by the Board's officers. The
documentation shall comprise the following but not limited to:
i. Proposed system Overview
ii. System/Services start-up / shutdown procedures
iii. Backup and restoration procedure
iv. Operations management system configuration
v. System Configuration
vi. Problems, Error messages and Corrective actions

2.7.11. The documentations shall be completed and submitted to the Board within EIGHT (8)
weeks of commissioning the system. This shall be part of the final deliverable of Part 1
of the scope of services (Section 3 Clause 3.53.1)

2.8 TRAVEL AND RELOCATION

2.8.1. The Board officers are located across multiple premises in Singapore. The Contractor’s
Personnel may have to assist the Board’s Officers with the issues related to the
application at their located premises. The Contractor shall not claim from the Board any
transportation charge (local or international) incurred.

2.8.2. The Board shall have the right to relocate any or all its system resources within

TS-13
 Development and Maintenance of PUB Sensor Platform (PSeP)

Singapore where applicable. The Contractor shall comply with the Board's relocation
schedule to ensure that the system is in normal operating condition after the relocation.
No cost can be claimed against the Board for the relocation. This clause explicitly
excludes the relocation of the servers and IT infrastructure if applicable.

2.9 AGENCIES AND BOARD'S APPOINTED OFFICERS

/CONTRACTORS
2.9.1. The Contractor shall liaise with other agencies (e.g., GovTech) and the Board’s
appointed officers and contractors to carry out the work.

2.10 WORKING HOURS

2.10.1. This system is expected to be a highly available system and shall be available 24 hours
a day x 7 days a week and shall comply with the Service Level Agreement stated in
Section 3 Clauses 3.42 to 3.46.

2.10.2. The Contractor shall ensure that all troubleshooting, upgrade or maintenance work
involving system downtime shall be done strictly with prior approval of the Board to
minimize disruption of service.

2.10.3. The Contractor shall follow the change management process/procedure for any changes
that are to be carried out on the PSeP.

2.10.4. Scheduled maintenance services are normally to be carried out outside office hours.

2.10.5. The Contractor and Contract Personnel may need to work outside office hours and on
public holidays when the situation (e.g., extreme events and scheduled maintenance)
requires. These works outside office hours shall not incur additional costs and shall be
deemed to be included in the Bills of Quantities.

2.11 MANAGEMENT OF SUB-CONTRACTOR(S)

2.11.1. The Contractor is not allowed to sub-contract any services to any sub-Contractors
without the Board’s written consent. The Contractor shall be fully responsible for all
tasks that are undertaken by its sub-Contractors that are approved by the Board.

2.11.2. The Contractor shall manage the Sub-Contractor(s) in their respective areas and attend
to all technical issues and ensure minimum disruption to the progress of the works and
costs.

2.11.3. The Contractor shall coordinate the works with the Sub-Contractor(s) and other relevant
parties to ensure the proper execution and interfacing. All costs incurred in the
management and supervision of the Sub-Contractor shall be deemed to be included in
the contract sum.

TS-14
 Development and Maintenance of PUB Sensor Platform (PSeP)

2.12 TECHNICAL EXPERT RESIDENT/S

2.12.1. The Contractor shall maintain an office in Singapore and technical expert resident/s in
Singapore who can provide advice and support for the proposed scope of services
during the contract period.

2.12.2. The Contractor may seek assistance from overseas experts for the completion of certain
specialised tasks on a case-by-case basis subject to the approval of the Board. However,
this shall be included in the BQ and no additional payment shall be made for such
services.

2.13 PHYSICAL SECURITY

2.13.1. Contractor and the Contractor’s Personnel shall not, without prior consent from the
Board, bring any visitor to the Board’s premises.

TS-15
 Development and Maintenance of PUB Sensor Platform (PSeP)

SECTION 3: TECHNICAL SPECIFICATIONS

PART 1: DESIGN, DEVELOP AND IMPLEMENT A CENTRAL
PUB SENSOR PLATFORM (PSeP)

3.1 SENSOR PLATFORM ARCHITECTURE

3.1.1 The PSeP platform shall be a highly available intranet web-based system hosted on the
Government Commercial Cloud (GCC) Microsoft Azure environment.
3.1.2 The Contractor shall propose a three-tier architecture with clearly demarcated Web,
Application and Database tiers, each tier separated by firewalls or security groups as
applicable.
3.1.3 The Contractor shall propose a complete solution that shall include all the underlying
cloud platform and infrastructure, including compute resource, storage, network,
virtualisation, operating systems, middleware, security components, etc.
3.1.4 The Contractor’s solution shall include separate UAT and Production environments for
the PSeP. The UAT environment shall serve as the testing environment wherein all new
developments, upgrades, patches are tested prior to deployment in the production
environment.
3.1.5 The Contractor shall take reference from the proposed architecture below to design the
PSeP. The illustration provided below may only be used as a reference and is by no
means the final architecture of the system.

Figure 2 Proposed System Architecture

TS-16
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.1.6 The Contractor shall work with the Board’s appointed GCC vendors to confirm and
finalise the system architecture (both for UAT and production environments) to be
hosted in GCC upon commencement of the Contract.
3.1.7 The Contractor shall prepare and submit the GCC on-boarding form provided by the
Board upon commencement of the Contract to kick start the GCC onboarding process.
3.1.8 The Contractor shall ensure that the proposed system architecture shall be capable of
data exchange with external systems hosted on other hosting environments.
3.1.9 The Contractor shall also be expected to provide the necessary integration tier/Gateway
Utility Tier (GUT) to connect with all external systems where applicable.
3.1.10 The Contractor shall strictly comply with all security requirements as set out in
Appendix A IT Security Requirements.
3.1.11 The Contractor shall also comply with the latest IT security requirements as and when
communicated by the Board. All developments required as a result of new IT security
requirements during the period of the Contract shall be delivered to the Board within
the timeframe stipulated.
3.1.12 All costs associated with such developments shall be discussed and finalized with the
Board on a case-by-case basis.

3.2 PLATFORM REQUIREMENTS

3.2.1 The Contractor shall propose, design, develop and implement a sensor platform that
shall be owned by PUB inclusive of all its source codes (in line with section 2 clause
2.7). The source codes shall be made available for enhancement, development and
security purposes.
3.2.2 The platform shall be designed to support a minimum of 10,000 sensors and 200,000
SCADA tags with the capability to scale and include additional sensors/SCADA tags
over the duration of the Contract, at no additional development or license costs (other
than corresponding operational cost involving cloud computing resources and services
which would be borne by the Board).
3.2.3 The platform shall also be designed to cater for around 100 concurrent users’ login to
access the portal.

TS-17
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.2.4 The Contractor shall design, develop and implement a sensor platform that meets the
following requirements:
i. Interoperability
• The platform shall support multiple protocols and ensure seamless integration
between devices and applications belonging to different manufacturers and
using multiple communication protocols.
• The protocols supported by sensor platform shall include the following but not
limited to MQTT, OPC-UA, REST, MODBUS, LORAWANM2M, Kafka,
CoAP, HTTP endpoints-DA, and custom.
• The platform shall support a variety of connectivity options, including Wi-Fi,
Bluetooth, latest cellular comms (4G,5G and above), NB-IoT, and LoRaWAN.
• The platform shall be able to integrate with other enterprise systems and 3rd
party applications, and analytics tools.
ii. Customisable Services
• The platform shall be customizable to meet the specific needs of the application,
including custom dashboards, reports, and alerts. It shall also provide tools for
workflow automation and business process management.
iii. Scalability
• The platform shall be designed to handle a large number of connected devices
and data streams concurrently.
• The platform shall be designed to auto scale its resources depending on
increasing number of devices or data acquired by the platform over the contract
period.
iv. Reliability
• The platform shall be designed with redundant architecture to ensure the system
availability as required in the Service Level Agreement stated in Section 3
Clauses 3.42 to 3.46.
v. Independent from Proprietary Components
• To ensure long-term sustainability, the sensor platform shall be vendor-
agnostic, built with cloud-native and open-source components, without being
limited to a specific vendor ecosystem or products.
• Contractors may propose the use of licenced third-party products (e.g. Power
BI) or proprietary products to fulfil certain requirements of this tender.

TS-18
 Development and Maintenance of PUB Sensor Platform (PSeP)

However, PUB’s licence to use these components shall not be limited to the
contract period. i.e be perpetually available for PUB’s use in the case of
proprietary products or transferred to PUB in the case of third-party licences.
• The contractor shall deploy proprietary components in modular and extensible
architecture, allowing them to be replaced easily with alternatives.
vi. Security
• The platform shall:
o have robust security mechanisms to protect data, devices, and
communications. This includes encryption, secure authentication, access
control, and regular security updates.
o be compliant with all the IT Security Requirements set out in Appendix A
of the Technical Specifications document.
o support the utilisation of Public Key Infrastructure (PKI) that will support
all encryption functionalities within the PSeP and include compatibility
with Trusted Platform Module (TPM).
o support device authentication and authorization for all devices and
Gateways.
o support user authentication, role-based access control, and permissions
management to ensure secure access to data and functionalities.
vii. Data Privacy
• Strong data privacy measures shall be in place to protect the personal
information and sensitive data collected from users and devices.
viii. Update and Maintenance
• The platform shall allow for easy updates and maintenance of both software and
firmware to fix bugs, add features, and improve security.
ix. Multi-Tenancy and Service Management
• The platform shall support multi-system tenancies1 with logical access
separation.
• PSeP shall support data and device logical separation and administration among
the different tenants.

1
Multi-system Tenancy – ability to host/connect multiple systems to the sensor platform.

TS-19
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.3 FUNCTIONAL REQUIREMENTS

3.3.1 The Contractor shall propose, design/develop, and deploy a user-friendly Web-Based
sensor platform that supports data acquisition, dashboards and controls.
3.3.2 The web interface shall support latest Internet Explorer, Microsoft Edge, Google
Chrome and Safari versions not older than N-1. (N being latest supported version).
3.3.3 The web interface shall be responsive and accessible across different devices and screen
sizes, including desktops and tablets.
3.3.4 The “system response time” shall be defined as the amount of time taken from the
moment that a user initiates a request until the time that system finishes loading the
page/screen. It will be measured as the time taken end-to-end from the moment the
<Enter> key is depressed (or button is clicked) by the user in the web browser (laptop
and mobile devices) from various locations using Intranet or VPN, to the time the
response is displayed on the screen of the user. The end-to-end tests shall be from front-
end client to backend server and back shall be less than 5 seconds, it applies for all
functionalities inclusive of login, navigating the web pages and any transactional
processing in the web pages.
3.3.5 Device Management Module (DMM)
The Contractor shall design, develop and implement a Device Management Module to
manage the full lifecycle of sensor devices, minimally including the following sub-
modules:
• Device Model Library
• System & Device Provisioning
• Connectivity Management – comms protocol setup, authentication and secure
data transmission
• Data processing – Setup data receiving and processing, with support for real-
time and batch processing.
• Security Management – Setup end-to-end encryption, access control, identity
management, and secure device authentication
• Rules Engine - defining and executing business rules, triggers, and automated
actions based on IoT/Sensor data, events, and device states.
• System / Device Decommissioning
• Over The Air (OTA) upgrade:

TS-20
 Development and Maintenance of PUB Sensor Platform (PSeP)

a. Device Model Library

• The DMM shall support a Device Model Framework and Library.
• The DMM shall cater for the following (but not limited to) functions required
for device management as defined by the Device Model Framework:
o data ingestion
o data processing
o events engine
o APIs.
For example: the device measurements are mapped and uploaded to PSeP
using the schema of the device model, such that data can be processed and
stored according to the asset structure based on the device model.
• The framework and library shall be applied to standardise device attributes,
data points and general processing logics to support data collection, data
processing, data storage and data retrieval through APIs.
• The Contractor shall propose a sensor platform that supports the following
devices but not limited to from their Device Model Library. Eg, Water Meters,
Chargers, Batteries, Smoke Sensor, Weather Sensors, Water Sensors, Range
Sensors, etc.
• The Device Model Library shall be a central repository where system
administrators can create, store and manage sensor device models, allowing
users to intuitively browse, search, and access a comprehensive collection of
standardized device models for device on-boarding.
• The Device Model Library shall support standardized model formats such as
JSON-LD, RDF, or other industry-recognized formats to ensure consistency
and interoperability across device models.
• The Device Model Library shall have proper version control capability to
manage different versions of device models, enabling users to track changes,
updates, and revisions to device specifications over time.
• The Device Model Library shall allow users to use an existing model as a
template and modify it to be saved as a unique device model.
• The Device Model Library shall allow system administrators to manage the
lifecycle of the device models, including the archival and retiring of certain
device models, and promoting newer updated models for adoption.

TS-21
 Development and Maintenance of PUB Sensor Platform (PSeP)

• The Device Model Library shall allow for system administrators to ensure
compliance of device models, including validating that all currently used
models adhere to industry standards to maintain consistency and quality.
• The Contractor shall provision a dashboard for administrators of the sensor
platform to setup, edit and modify sensor attributes, data points, processing
logics and other parameters required to setup the device model library of a
sensor device.
• The Contractor shall ensure that these functionalities are made available to the
following groups of users with the corresponding roles and permissions.
User Type Role & rights
System Owner View only
Contractor View only
Admin Edit and modify
• The Device Model Framework and Library shall be included and described in
the PSeP Design document to be submitted by the Contractor.
• The Contractor shall submit a list of existing devices supported by their device
model library for evaluation as part of the tender submission in Annex I.

b. System & Device Provisioning Dashboard:

• The DMM shall provide a dashboard (System & Device provisioning
dashboard) with an intuitive and seamless workflow to onboard a new system
and register sensors/devices before deployment, assigning unique identifiers
and metadata to each device.
• The Contractor shall ensure that this dashboard shall allow users to:
o provision devices in bulk, allowing for the simultaneous registration and
configuration of multiple devices to streamline deployment processes.
o create and configure templates to provision different types of devices,
enabling efficient and consistent provisioning of device settings.
o configure device-specific settings and parameters prior to deployment.
o assign or select sensors under a new system or an existing system.
o configure and control devices where applicable.
o filter and select systems which are required to be configured.
o identify sensors in the systems that are non-compliant.

TS-22
 Development and Maintenance of PUB Sensor Platform (PSeP)

o update, add new, disable or remove existing sensors

o define and categorise the type of sensors being on-boarded to the platform.
o activate and successfully connect the sensors to the platform.
o view device status and operational metrics such as Key Performance
Indicators (KPIs) in real-time.
o customise widgets such as charts, graphs, maps and tables to display
relevant device information.
o view the status of connected devices including online/offline status, battery
levels, data validation alerts, active alarms where applicable.
o view the Security profile of the devices
o view historical data and trends and enable performance analytics on
devices
o view geospatial display of all devices deployed.
• The Contractor shall ensure that the sensors/devices are provisioned strictly
according to the Device Model Framework & Library.
• The platform shall provide integration testing of devices within a controlled
environment to validate their compatibility with the platform and associated
services.
• The Contractor shall ensure that these functionalities are made available to the
following groups of users with the corresponding roles and permissions.
User Type Role & rights
System Owner View edit and modify only their
system
Contractor View edit and modify only their
system
Admin View, edit and modify all systems

c. Connectivity Management – comms protocol setup, authentication and secure data

transmission
• The Contractor shall develop robust security mechanisms to protect data (data
at rest & Transit), devices, and communications. This includes encryption,
secure authentication, access control, and regular security updates.
• The PSeP shall support the protocols specified in the clause 3.2.4.

TS-23
 Development and Maintenance of PUB Sensor Platform (PSeP)

• The PSeP shall support for various communication protocols such as Wi-Fi,
cellular, Bluetooth, LoRa, and others. Ensuring reliable and robust
connectivity is essential for real-time data transmission.

d. Data processing – Setup data receiving and processing, with support for real-time
and batch processing.
• The Contractor shall develop data receiving and processing capabilities, with
support for both real-time and batch processing, is essential for an effective
data processing system in the PSeP.
• The PSeP shall support a robust data ingestion pipeline to receive data from
IoT devices, sensors, and other sources.
• The PSeP shall support real-time data processing components, configure real-
time processing pipelines to analyze, filter, and transform incoming data
streams in near real-time, enabling immediate insights and actions based on
the data.
• The PSeP shall support batch processing jobs to process large volumes of
historical data at scheduled intervals, enabling deeper analysis and reporting
over extended time periods.
• The Contractor shall propose and design a suitable data storage solution to
store both real-time and batch-processed data depending on the nature of the
data and the processing.

e. Security Management Dashboard:

• The Contractor shall cater for certificates to secure the web portals where
necessary. The cost for the purchase, installation, and maintenance (including
renewal) of certificates shall be deemed part of the contract price.
• Certificate Management
o The Contractor shall develop and implement a Certificate Management
Service that shall function as a Certificate Authority (CA) within the DMM.
o The Certificate Management service shall minimally include the following
features, but not limited to:

TS-24
 Development and Maintenance of PUB Sensor Platform (PSeP)

▪ Full certificate and key management capabilities: such as creation,

revocation, automatic update, management of histories, backup and
recovery.
▪ Support for batch or individual certificate creation or revocation.
▪ Application Programming Interfaces (APIs) to expose the certificate
management capabilities
▪ Support immediate certificate issuance in seconds
▪ Support custom certificate profile including X.509 v3 or latest
▪ Highly secure hosting complying with industry standards and best
practices.
o The Certificate Management Service shall allow issuance of private x.509
v3 or equivalent certificates that is used by the different endpoints and sub-
systems within the System.
o The Contractor shall, upon completion of installation and configuration,
provide the services to assist with the signing, installation and loading of all
the necessary certificates to support the various components in the System.
o Mechanism and processes shall be implemented to track the expiry of all
digital certificates in the System and such certificates shall be renewed
before their expiry and shall be automatically notified to the relevant PUB
stakeholders.
o The Security Management dashboard shall be available only for the PSeP
administrators.

f. Rules Engine - defining and executing business rules, triggers, and automated
actions based on IoT/Sensor data, events, and device states.
• The PSeP shall be capable of handling real-time data streams and enable real-
time data processing and decision-making features available to users in a
visualisation dashboard.
• The Contractor shall develop functionalities that allows developers to define
custom business rules and triggers based on incoming data via a rules engine.

TS-25
 Development and Maintenance of PUB Sensor Platform (PSeP)

This shall allow for real-time processing and automated actions based on
specific conditions.
• The Contractor shall ensure that these functionalities are made available to the
following groups of users with the corresponding roles and permissions.
User Type Role & rights
System Owner View edit and modify only their
system
Contractor View edit and modify only their
system
Admin View, edit and modify all systems

g. System /Device Decommissioning

• The Contractor shall provision the following decommissioning capabilities
within the DMM:
o a mechanism to disassociate the device from the platform, ensuring that it
no longer communicates or interacts with the platform.
o deactivation and deregistration of device, removing it from the active
device inventory and associated services.
o secure protocols for disconnecting the device from the network and
associated services to prevent unauthorized access.
o maintain an audit trail of the decommissioning process, including
timestamps, actions taken, and responsible users, and provide
comprehensive reporting on the decommissioning activities
o support the reassignment of the device to a different user or entity, ensuring
proper ownership transfer and reconfiguration.
o notify the device decommissioning activities to relevant stakeholders, such
as administrators, users, and affected parties.
• The Contractor shall ensure that these functionalities are made available to the
following groups of users with the corresponding roles and permissions.
User Type Role & rights
System Owner View edit and modify only their
system

TS-26
 Development and Maintenance of PUB Sensor Platform (PSeP)

Contractor View edit and modify only their

system
Admin View, edit and modify all systems

h. Over The Air (OTA) upgrade:

o The contractor shall ensure that the Security Management Dashboard shall
enable users to carry out OTA updates to the respective systems and devices
when necessary and applicable.
o The features of the OTA module shall include the following but not limited
to:

Firm Ware • Support the management of firmware versions for

Management: devices, including the ability to upload, store, and
organize different firmware versions.

Remote • Enable the remote deployment of firmware

Deployment: updates to devices over the air, without requiring
physical access to the devices.

Rollback • Provide the ability to roll-back to a previous

Capability: firmware version in case of issues or failures
during the update process.
Version Control: • Maintain a version history of firmware updates,
allowing users to track changes and updates made
to device firmware

Scheduled • Support the scheduling of firmware updates at

Updates: specific times or during maintenance windows to
minimize disruption to device operations.

Bandwidth • Include mechanisms to manage bandwidth usage

Management: during OTA updates, especially for large-scale
deployments with numerous devices.

Security and • Strong security measures shall be in place to

Authentication: ensure the authenticity and integrity of firmware

TS-27
 Development and Maintenance of PUB Sensor Platform (PSeP)

updates, including digital signatures and secure

authentication mechanisms.

Update Status • Provide real-time monitoring of the update

Monitoring: process, including progress indicators,
success/failure notifications, and detailed logs for
troubleshooting

Group-based • Support the grouping of devices for targeted

Updates firmware updates based on device type, location,
or other criteria.

Compliance and • Facilitate compliance with regulatory

Reporting requirements by providing audit trails, reporting
capabilities, and documentation of firmware
update activities.

3.3.6 Alert Management Module

a. The Contractor shall provision a dashboard for system owners, contractors and
administrators of the platform to manage system and device alerts.
b. The dashboard shall enable users to define custom alert rules based on specific
conditions, thresholds, or events from the devices.
c. The dashboard shall support the delivery of alerts through multiple channels such
as email, SMS, in-platform notifications, and integration with third-party
communication tools such as telegram, WhatsApp, etc.
d. The Contractor shall ensure that the dashboard shall provide features for users to
create escalation policies to ensure that alerts are routed to the appropriate
personnel or teams based on severity and response time.
e. The dashboard shall also allow users to acknowledge alerts and track the resolution
status, including timestamps for acknowledgement and resolution actions.
f. It shall allow for the prioritization of alerts based on the following but not limited
to severity levels, impact on operations, and criticality of the associated devices.
g. The dashboard shall allow users to maintain and view a historical log of alerts,
including details such as timestamps, affected devices, and actions taken in
response to the alerts.

TS-28
 Development and Maintenance of PUB Sensor Platform (PSeP)

h. The Contractor shall ensure that the Alert Management Module integrates with
relevant with incident management systems to facilitate the creation of incidents
from alerts and enable seamless collaboration for resolution. The effort and the
manpower for such integration jobs shall be considered part of Bills of Quantities
submitted by the Contractor.
i. The dashboard shall allow users of this module to suppress or snooze alerts
temporarily to prevent unnecessary notifications during planned maintenance or
known operational conditions.
j. The dashboard shall also provide tools for trend analysis of alert patterns, allowing
users to identify recurring issues and optimize alert configurations.
k. The dashboard shall allow users to configure predefined remediation actions in
response to specific alerts, reducing manual intervention for common issues.
l. The Contractor shall ensure that these functionalities are made available to the
following groups of users with the corresponding roles and permissions.
User Type Role & rights
System Owner Edit and modify
Contractor View only
Admin Edit and modify

3.3.7 Data Lake Module

a. The Contractor shall provision a data lake module within the PSeP with the
following features but not limited to:
• Data Collection and Ingestion:
The DLM shall enable data collection and ingestion from a variety of devices
in real-time, supporting various data formats and protocols.
• Data Storage and Retention:
o The DLM shall be designed to be a secure and scalable storage for the
collected data, with the ability to retain data for specified periods based on
retention policies without affecting the operational efficiency of the
platform.
o The DLM shall be allowed for users (Admin) to configure the storage policy
in Hot, Cold and Archive storages, the contractor shall propose to the Board
based on the operation need. For example:

TS-29
 Development and Maintenance of PUB Sensor Platform (PSeP)

Hot 1 year
Cold 2 years
Archive 5 years

• Data Payload Inspection and Encryption:

o The DLM shall support data encryption both in transit and at rest to ensure
the security and privacy of device data.
o The DLM shall be responsible for performing payload inspection to check
the data integrity, completeness of data before processing and ensure there
is no vulnerabilities and malicious content before store the data in to the
platform.
• Data Aggregation and Transformation:
The DLM shall be capable of aggregating and transforming raw data into
meaningful insights using data normalization, enrichment, extrapolation, or
any other appropriate techniques.
• Data Quality Monitoring:
The DLM shall provision mechanisms for monitoring the quality and integrity
of data, detecting anomalies and data inconsistencies.
• Time-series Data Management:
o The DLM shall support efficient storage and retrieval of time-series data
generated by the devices enabled by optimized querying and analysis.
o The DLM shall be capable of detecting/identifying gaps in time series data
in real-time and/or using post processing techniques for users to carry out
analysis and decision making.
o The module shall also be designed to enable users to implement customised
algorithms to process data received from the various devices.
• Data Access Control:
The DLM shall be strictly controlled by role-based access control mechanisms
to manage user permissions and roles for accessing, extracting and/or
modifying the device data.
• Data Query and Analysis:

TS-30
 Development and Maintenance of PUB Sensor Platform (PSeP)

o The DLM shall also be designed to provide tools for querying and analyzing
the device data, including support for complex queries, data visualization,
and trend analysis.
o The DLM shall be capable of deploying customisable widgets such as
charts, graphs, maps and tables to display relevant device data.
• Data Privacy and Compliance:
The DLM shall adhere to data privacy regulations and compliance standards,
ensuring that the device data is handled in accordance with relevant laws and
policies.
• Data Lifecycle Management:
The DLM shall be responsible for facilitating the management of the entire
data lifecycle, including data exchange, data archiving, deletion, and retention
policies in compliance with regulatory requirements.
3.3.8 Visualisation and Reporting Module
a. The Contractor shall develop dashboards with the following functionalities but not
limited to:

Real-time Data • Provide real-time visualization of data from the devices,

Visualization: including sensor readings.

Customizable • Customize the dashboard with various widgets such as

Widgets: charts, graphs, maps, and tables to display relevant data.

Device Status • Display the status of the connected devices, including

and Alerts: online/offline status, battery levels, and any active alerts
or alarms.

Historical Data • View historical data trends and perform analysis on past
Analysis: device performance and environmental conditions.

Geospatial • Support geospatial visualization to display the

Visualization: geographical distribution of devices and their data.

Customizable • Create multiple dashboards tailored to different use

Dashboards: cases or user roles, with the option to personalize
layouts and widgets.

TS-31
 Development and Maintenance of PUB Sensor Platform (PSeP)

Data Filtering • Filter and aggregate data based on different parameters

and Aggregation: such as time, device type, location, and sensor readings.

User • Support role-based access control for dashboards,

Management and allowing administrators to manage user permissions and
Access Control: access levels.
• Access for the users shall be automatically suspended
(inactive status) when they have not been used for 90
days and automatically deleted from the platform when
they have not been used for 180 days.
• Access for users who undergo staff movement, such as
but not limited to resignation, retirement, department
transfer and long leave, are removed within ONE (1)
working day of receiving the staff movement file in an
Excel, or XML format, or similar from the Board. The
Board shall provide the Contractor a Staff Movement
file in a folder on a Secure File Transfer Protocol (SFTP)
server for the automated program to import and read
automatically daily. The file will list user accounts to be
removed daily, in an Excel format or similar. A
cumulative list will also be provided for the Contractor.

Integration with • Integrate with external systems and applications to

External display data from other sources, such as weather
Systems: forecasts or business intelligence tools.

Responsive • The dashboard shall be responsive and accessible across

Design: different devices and screen sizes, including desktops,
tablets, and mobile phones.

Performance • Key performance indicators (KPIs) and performance

Metrics and metrics relevant to the sensor deployments shall be
KPIs: prominently displayed on the dashboard for quick
insights

TS-32
 Development and Maintenance of PUB Sensor Platform (PSeP)

Customizable • Receive alerts directly on the dashboard for the users to

Alerts and act on.
Notifications: • Configurable custom alerts with the ability to support
various types of data readings for example, support
minimum and maximum sensor data threshold, flag,
time out, and average readings, etc.

3.3.9 API Management (APIM) Module:

a. The Contractor shall develop an API Management module to ensure seamless data
provisioning and exchange between the platform and other downstream systems
(inclusive of systems outside the PUB environment).
b. The APIM shall provide well-documented and standardized APIs to facilitate
interoperability and integration with backend systems and data sources, providing
capabilities for request and response transformation, protocol mediation, and data
format conversion. It shall support seamless integration with diverse backend
technologies.
c. The module shall support industry-standard protocols and formats to enable
seamless integration with existing and future devices and applications.
d. The APIM module shall include a robust API gateway that serves as a single-entry
point for all incoming and outgoing API traffic and shall include capabilities for
routing, security, rate limitations, and request transformation.
e. The module shall enable rate limiting and throttling capabilities to control the
volume of API requests and prevent abuse or overloading of backend systems. It
shall also support configurable rate limits based on API usage patterns and user
roles.
f. The APIM module shall offer comprehensive security features, including
authentication, authorization, and encryption mechanisms to ensure secure access
to APIs. It shall support industry-standard security protocols and provide fine-
grained access control capabilities.
g. The module shall include a portal that offers self-service capabilities for
users/developers to discover, explore, and consume APIs. It shall provide
comprehensive API documentation, code samples, and interactive tools for testing
and integration.

TS-33
 Development and Maintenance of PUB Sensor Platform (PSeP)

h. The module shall support the entire API lifecycle, including API creation,
versioning, deprecation, and retirement.
i. The APIM module shall facilitate the management of API endpoints, methods, and
schemas.
j. The Contractor shall design, develop and implement a dashboard to carry out the
following but not limited to:
• Real-time monitoring and analytics to track API usage
• Assess performance, and health
• Derive insights into API traffic, error rates, latency, and usage patterns.
• View and export logs of API usage and traffic in a .xlsx or .csv format
k. The module shall allow for the enforcement of API usage policies, including
validation of API keys, OAuth tokens, and custom policies based on specific
business requirements. It shall also support the application of policies at various
levels, such as API, resource, and operation levels.
l. The module shall support governance and compliance requirements, including the
enforcement of regulatory standards, data privacy regulations, and industry best
practices with capabilities for auditing, logging, and compliance reporting.
m. The APIM module shall be designed for scalability and high availability, ensuring
that it can handle a growing number of APIs and API consumers with capabilities
for load balancing, clustering, and fault tolerance.
n. The module shall offer customization and extensibility options, allowing for the
implementation of custom policies, extensions, integrations with third-party
systems and shall support the development of custom plugins and extensions.
o. The module shall be accompanied by comprehensive documentation, including
user guides, API reference documentation, and administrative guides.
p. The Contractor shall provide ongoing support, training, and resources for
administrators and developers. The costs associated with training shall be deemed
as included in the Contractor’s Bills of Quantities (Bill No. 1).

3.3.10 User & System Management (USM) Module:

a. The Contractor shall identify the different levels of data and function accessibility
that is available for different users or departments and create an Access Control
Matrix.

TS-34
 Development and Maintenance of PUB Sensor Platform (PSeP)

b. The Contractor shall design, develop and implement a User & System management
dashboard for administrators of the platform to carry out the following functions
but not limited to:
• Create/edit/delete the following user types/roles but not limited to:
o department administrators
▪ Create/edit/delete users of their respective departments and Contractors
▪ Assign the roles (specified in each business function) to them.
o contractors
Note 1: The list of user types and roles shall be decided upon contract
commencement.
• The Contractor shall ensure that any and all the earlier transactions by any user
account is not impacted by changes to the user roles/types. Only authorized
users shall be able to assign this user’s ongoing cases to other users.
• Configure (create/edit/delete) role assignments/mapping based on
functionalities to the user types
• The USM module shall also allow the assignment of a single user to multiple
roles and functions as well.
• view all the systems on-board the platform, including key details such as
authorized users2 of the respective systems, activity logs, system status, no. of
devices in each system, patch status, etc.
• The USM module shall allow users to maintain personal particulars such as
phone number, email, addresses, etc.
• The USM module shall provide the ability to manage the user account:
o 1. User Login Id/Username/AD Identity
o 2. User Password
o 3. User account lock/unlock feature
o 4. User account password reset functionality
• The USM shall allow the ability to list the users and their status
(active/inactive) in a grid format.
• The Contractor shall implement a filter functionality to enable filtering of
users, their roles, departments etc.

2
The Authorized users shall be able to indicate the accessibility of information and functions
within the System to the users.
TS-35
 Development and Maintenance of PUB Sensor Platform (PSeP)

• The USM module shall allow for export of the information within the module
in .xlsx, .csv, .docx etc formats.
• All the privilege user activities shall be logged and view through applications.
c. The Contractor shall implement PSeP integration with Central Accounts
Management (CAM) as specified below.
• The Contractor shall integrate the System to Central Accounts Management
(CAM) for the timely removal and disabling of user accounts and access
rights/roles that are no longer needed due to staff movements and also
facilitates the review of accounts and access rights/roles.
• The Contractor shall develop REST API interfaces to interface with CAM.
CAM will consume the REST API interfaces from the System for prompt
removal of user access. The interfaces shall conform to the CAM API
specifications, which are based on the System for Cross-domain Identity
Management (SCIM) specifications as defined by IETF RFC 7642, RFC 7643
and RFC 7644.
• The System shall minimally develop the following APIs:
No API Description
1 Get User Retrieves detailed user account
2 Get User List Retrieves a list of users based on a search
criterion
3 Disable/Enable User Disables or enable the user account
4 Remove User Remove user account
5 Get Group Retrieves group info and the users in the group
6 Get Group List Retrieves a list of groups based on a search
criterion
7 Add/Remove user Add or remove a user from a group.
from Group
8 Remove Group Removes group and detach all users from that
group

3.4 SERVICE REQUIREMENTS

3.4.1 The Contractor may propose a suite of Devops Tools (if required) to carry out the
following but not limited to, quick System Provisioning, Device Management, Virtual
Hosting Provisioning, Dashboard Configurations, Account Provisioning, API
generation and Security Configurations.

TS-36
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.4.2 The tools shall be as automated as possible for manual tasks and processes required for
deployments, development & testing workflows, container management and
configuration.
3.4.3 The Contractor shall propose a continuous integration and continuous delivery service
for fast and reliable application and infrastructure updates. The tools shall support
builds, tests, and deploy codes whenever there is a code change.
3.4.4 The Contractor shall propose a tool for source code compilation, runs tests and produces
software packages that are ready to deploy. The tool shall also eliminate the need for
system admin from having to provision, manage and scale servers automatically.
3.4.5 The Contractor shall propose a tool that support code deployment to any instance on
platform. The tool shall allow rapid release of new features from test, staging to
production instances.
3.4.6 The Contractor shall propose a structure for platform whereby every on boarding
System can subscribe to instances for testing, staging and production.
3.4.7 Payment for this scope of work shall be carried out as per the clauses set out in Clauses
3.53.1 from 3.53.1 to 3.53.4 of Section 3.

3.5 PROJECT IMPLEMENTATION APPROACH

3.5.1 The Contractor shall deliver a sensor platform that is complete with all the features
and functionalities as indicated in Section 3 Clause 3.3 of the Technical
Specifications.

TS-37
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.5.2 The Contractor shall ensure that the development work and the timelines follow the
requirements set out in the scope of work Section 1 Clause 1.4.
3.5.3 Payment for this scope of work shall follow the payment milestones set out under
Section 3 Clauses from 3.53.1 to 3.53.4.

TS-38
 Development and Maintenance of PUB Sensor Platform (PSeP)

PART 2: INTEGRATION JOBS

3.6 SCADA data integration job
3.6.1 The Contractor shall integrate the PSeP with the Board’s SCADA data repository.
3.6.2 The platform shall be capable of acquiring at least 200,000 SCADA tags from the
Board’s SCADA data repository.
3.6.3 The PSeP shall be designed to acquire data in OPC-UA, MQTT and/or REST APIs
protocols.
3.6.4 The Contractor shall design the PSeP to adequately manage a large volume of SCADA
tags concurrently without compromising the performance of the system.
3.6.5 The PSeP shall be capable of exchanging SCADA data with downstream systems in
OPC-UA, MQTT and/or REST API protocols .
3.6.6 The scope of work under the SCADA data integration job shall include the following
but not limited to:
i. User requirement gathering activities and report submission.
ii. Data processing and storage set up where required.
iii. Visualisation setup if required.
iv. Downstream system interfacing where required.
v. User acceptance & Commissioning report of the Integration and deployment
services.
vi. interfacing with downstream systems as defined by the Board
3.6.7 The Contractor shall ensure that all the features and functionalities developed
(including ingestion, storage and exchange of data for real-time and historical) under
Part 1 of the scope of services are also available for the data ingested from the Board’s
SCADA systems.
3.6.8 Payment for this scope of work shall be carried out under item 1 of BQ No. 2 of the
Bills of Quantities.

3.7 Sensor Provisioning job

3.7.1 The Contractor shall provision FIFTEEN (15) JOBS covering integration of the
Board’s systems that may include either sensor on-boarding or data storage or data
exchange or combination of the above over the course of the Contract period.
3.7.2 The integration jobs shall cover the following scope of work but not limited to:
i. User requirement gathering activities and report submission.

TS-39
 Development and Maintenance of PUB Sensor Platform (PSeP)

ii. Sensor device on-boarding

iii. Data acquisition individually from sensors or collectively from sensor systems
hosted on other platforms whichever applicable.
iv. Data processing and storage set up.
v. Data analysis requirement set up.
vi. Threshold and notification configuration
vii. Visualisation setup
viii. Downstream system interfacing where required.
ix. User acceptance & Commissioning report of the Integration and deployment
services.
x. interfacing with downstream systems where required.
3.7.3 Payment for this scope of work shall be carried out under item 2 of BQ No. 2 of the
Bills of Quantities.

3.8 Cloud-to-Cloud Interfacing Job

3.8.1 The Contractor shall also provision FIVE (5) JOBS to carry out cloud to cloud
interfacing of data from external systems hosted on Commercial Cloud (CC),
Government Commercial Cloud (GCC) or Government Private Cloud (GPC)
3.8.2 The scope of work under the Cloud-to-Cloud interfacing shall include the following but
not limited to:
i. User requirement gathering activities and report submission.
ii. Sensor device on-boarding
iii. Data acquisition individually from sensors or collectively from sensor systems
hosted on other platforms whichever applicable.
iv. Data processing and storage set up
v. Data analysis requirement set up
vi. Threshold and notification configuration
vii. Visualisation setup
viii. Downstream system interfacing where required
ix. User acceptance & Commissioning report of the Integration and deployment
services.
x. interfacing with downstream systems where required

TS-40
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.9 The Board reserves the right to activate any of the above integration jobs package at
any point of time during the Contract period.
3.10 The Contractor shall work with the Board’s Sensor/SCADA/Cloud vendors to ensure
that all connections required for the successful transmission of data to the platform is
carried out as per the requirements of the Board.
3.11 The Contractor shall ensure that the platform is capable of sharing/exchanging data with
the Board’s downstream systems requiring the Sensor/SCADA/cloud data as per the
protocols defined in Section 3 Clause 3.2.4 over the duration of the Contract.
3.12 Where, downstream systems require real-time SCADA data (typically using OPC-UA
protocol for operationally critical systems), the Contractor shall ensure that the PSeP
shall be designed as a highly available system and shall be subject to the SLA as
described in Section 3 Clauses 3.42 to 3.46 upon successful integration with the Board’s
SCADA data repository.
3.13 The Contractor shall work with the Board’s vendors to ensure that the data exchange is
set up successfully and troubleshoot when necessary to ensure consistent and reliable
data exchange with the Board’s downstream systems.

TS-41
 Development and Maintenance of PUB Sensor Platform (PSeP)

PART 3: MAINTENANCE AND SUPPORT

3.14 The Contractor shall provide maintenance and support services that include the
following:
3.14.1 Addressing System bugs, downtime, user problems and performance related issues
that prevents the users from using the System for its intended purpose. Addressing
would include activities such as investigation, corrective maintenance (bug fixing)
and system recovery when required. Intended purpose would include purpose from
system changes made under this contract and its interfaces.
3.14.2 Provide corrective maintenance, troubleshoot, and isolate defects, including diagnosis
and correction of all latent errors in the applications.
3.14.3 Investigating and correcting defects in the applications as reported by the Board within
the service levels. The resolving effort includes but is not limited to resolving the
errors through developing, testing and implementing changes to the System. It also
includes temporary corrections and bypass of the defects until such time as standard
corrections and/or updates of the Application are available.
3.14.4 Troubleshooting functional and technical issues reported by the Board to identify the
root cause and resolve it.
3.14.5 Contractor Helpdesk support, contactable via email and mobile during and after office
hours. If the problem could not be addressed over the phone, the Contractor shall
provide on-site support. The Contractor shall provide a single point of contact for
users or the Board’s IT Helpdesk to report problems. The Contractor shall provide the
option to report problems through any means of communication such as phone, email,
or messaging platform e.g., Whatsapp. Direct contact from users through Whatsapp
groups shall be possible to get a faster response.
3.14.6 Attend to queries from the Board’s officers and provide on the job training to the
officers in daily operations of the platform.
3.14.7 Keep the Board and affected users informed immediately of any service disruption
and the expected date/time of resolution. If the problem takes longer than expected to
resolve, the Contractor shall update the Board and affected users of the revised
date/time of problem resolution. The Contractor shall also inform the Board and all
affected users of service resumption immediately. The Contractor shall work out the
proper communication channel(s) to effectively disseminate the information.

TS-42
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.14.8 Maintaining a log (an Incident Management Report) of all support cases, the time
taken to resolve them, and the solutions. For problems that require third party
Tenderers for troubleshooting and rectification, the Tenderer shall follow through with
the third-party Tenderers. The log is to report on the status of the support cases (e.g.
incidents/problems reported and queries) and to show evidence that the overall
response time and the other specified service levels are met when requested by the
Board.
3.14.9 Support testing/verification of existing external interface, including connectivity and
external systems change/upgrade. Work with other teams to resolve bottlenecks and
improve system performance.
3.14.10 Propose a regime to conduct quality assurance for the entire application (i.e., code
review) document and highlight any flaw or improvement to the Board during the
contract period.
3.14.11 Perform pro-active monitoring, recommendation, application and testing of hotfix,
service packs, upgrades and patches for all the application software and hardware
provided by the Contractor as per the list in Appendix B.
3.14.12 The Contractor shall assess impact of new releases (e.g., hotfix, service packs,
upgrades and patches) of system software (e.g., operating system), database software
and client software (e.g., Internet Browser) to ensure compatibility and make
recommendations for non-compatibility identified with platform.
3.14.13 The Contractor shall upgrade the software in order to ensure compatibility with new
upgrades of the OS as and when available.
3.14.14 Provide recommendations for improvements to the platform based on events analysis
and decision making.
3.14.15 Provide support for any system security review and audit activities.
3.14.16 Pro-active monitoring of data quality and troubleshooting of the data acquisition
chains to ensure that data is accurate and available with minimal latency. Follow-up
with the personnel appointed by the Board or with external parties appointed by the
Board, to analyse the problems and ensure a timely resolution.
3.14.17 Pro-active monitoring of the performance of the system in terms of anticipation
capacities and operational strategies. Functional and design improvements shall also
be proposed when necessary.

TS-43
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.14.18 Ensure that the database remains at a workable size for good performance of the
system for real-time functions. Ensure that the features requiring long data history
shall be accessible easily where applicable.
3.14.19 Recommend regular system and database housekeeping and maintenance activities
necessary to keep the system and database in a healthy state and at optimum
performance.
3.14.20 Recommend backup and recovery procedures and mechanisms to back up critical
system files and the Board’s information to ensure operational continuity.
3.14.21 Assess with the Board and if operationally feasible, perform data recovery from
backup storage media that holds the Board’s information.
3.14.22 Provide a monthly report on system and external interface status, maintenance
operations, and helpdesk incidents.
3.14.23 Rendering advice on the performance tuning of all items in the Application.
3.14.24 Recovering lost data, restoration and repair of damaged data and the correction of
erroneous data to the extent possible.
3.14.25 Restoring the System to an operable state where System Downtime is attributable to
Application defect or error.
3.14.26 Informing the Board of all future updates and new releases of the Software within one
(1) calendar week of their release for general distribution and, when so requested by
the Board, supplying and installing the relevant update and releases within four (4)
calendar weeks of receipt of the Board's request at no additional cost to the Board.
3.14.27 Providing other application support services including technical advice and assistance
as may be required by the Board from time to time.
3.14.28 Implementing and enhancing operational procedures as and when needed.
3.14.29 Producing and updating technical and user documentation such as the functional
specification, technical specification, and user manual of the System.
3.14.30 Monitoring the applications to ensure data integrity and efficient System performance
and provide expert advice on application performance monitoring and tuning.
3.14.31 Planning daily operations to ensure optimisation of resources and batch windows
utilisation.
3.14.32 Performing weekly/daily maintenance (as and when needed) for the optimisation of
the systems using scheduled jobs such as but not limited to:

i. Compress database

TS-44
 Development and Maintenance of PUB Sensor Platform (PSeP)

ii. Analyse database (run database statistics)

iii. Re-index database
iv. Delete user versions
v. Re-create user versions
vi. Archiving logs

3.14.33 Scheduling and ensuring successful completion of ad-hoc, daily, weekly, monthly and
other batch reporting and processing jobs in the applications and perform
troubleshooting for failed jobs.
3.14.34 Ensuring that all program source codes, and executable codes are properly maintained
(especially the versioning) and backed up. This is to allow the System to be rebuilt
from scratch if required.
3.14.35 The Contractor’s Project Manager shall act as a single point of contact for the Board
and follow through with the third-party vendors for problems that require third party
vendors or external organisations for troubleshooting and rectification. These third-
party vendors shall include but are not limited to the Board’s FM vendor, vendor of
systems that the System interfaces with, or any other vendor that provides a service or
a product that has relevance to the applications.
3.14.36 Managing and supporting changes to the Application to minimise impact on System
availability.
3.14.37 Working with Board’s FM vendor to provide hosting, back-up and recovery services
and procedures for the Application and data.
3.14.38 Providing applications briefings to end-users twice yearly or when necessary, as
mutually agreed.
3.14.39 Preparing technical feasibility proposal including impact analysis, when requested by
the Board.
3.14.40 The Contractor shall provide support and maintenance services in compliance with
security requirements. Refer to Appendix A. This includes carrying out the scope of
work and conducting periodic review on the compliance checklist and submitting as
part of the monthly report to the Board.
3.14.41 Advising the Board on Business Continuity and Contingency Plan for the System
upon request by the Board.
3.14.42 Providing Incident Response Services to support any incident response or rectification
related to the application in the event of System outage or cyberattack.
TS-45
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.14.43 Recommending functional and design improvements as and when required by the
Board within the schedule as agreed with the Board.
3.14.44 Performing user account and access control management activities promptly to ensure
that the System complies with requirements in Appendix A. This includes checking
and ensuring that passwords for all privileged accounts are changed annually.
3.14.45 Collating and submitting in the monthly report all approved user access requests sent
to them and implemented in the System.
3.14.46 Participating and provide assistance in the user access control review exercise. The
Contractor shall review the user accounts at the following frequency as indicated in
the table. This review includes comparison of deactivated / deleted accounts with the
Staff Movement File sent daily to ensure that all deactivation and deletions are carried
out by the automated script correctly.

Frequency Account Type

• Inactive / Deleted Accounts
• Accounts of personnel who has resigned, redeployed, retired or
Monthly changed job role
Privileged Accounts.
All other accounts including the normal user accounts.

3.14.47 Conduct a monthly health check for all platform services usage and performance
statistics. The reports for the health check shall be submitted as part of the monthly
report to the Board’s Contract Manager.
3.14.48 Provide regular checks (minimum monthly or as required by the Board) on application
and security logs so as to monitor the health of the applications and perform periodic
archive of the log files, if necessary. A report on the status check of all the log files
shall be forwarded to the Board along with the monthly report upon completion of the
check.
3.14.49 Pro-active monitoring of the annual maintenance and warranties of the software and
hardware in the System where applicable.
3.14.50 The Contractor shall engage an independent and competent party such as a Database
Administrator (which can be one of the Contractor’s staff but not the personnel
working under this contract) to conduct a monthly review of privileged user activities
including logs of activities carried out by privileged users, System/service accounts or

TS-46
 Development and Maintenance of PUB Sensor Platform (PSeP)

administrators, for security violation and security breaches. A report of such review
shall be submitted to the Board on a monthly basis.
3.14.51 When the Board suspects any cyber incident, or the System has an unplanned
downtime, or when the root cause of a severity A (as described in Section 3 Clause
3.44) problem cannot be explained by the Contractor to the satisfaction of the Board,
the Contractor shall conduct a security review using the checklist prescribed by the
Board. The checklist includes items such as the following, but not limited to:
i. Perform malware scans
ii. Check for Unauthorised Creation of Accounts
iii. Check for unauthorised access/activity
iv. Check for Unusual Files
v. Check for Suspicious System Processes/Services
vi. Check connection to corporate networks or vendors
vii. Check the database for unusual amount of querying
viii. Check the Task Scheduler
ix. Check the web server’s vulnerability / version and patching

3.14.52 Maintenance activities and monthly reports

i. The Contractor shall submit a detailed list of maintenance activities, scope,
deliverable, frequency, and schedule for the Board’s approval. The Contractor
shall demonstrate in writing that the list complies with the Contract
requirements. Such list must be submitted by the Contractor to the Board within
TWO (2) WEEKS upon commissioning of the System.
ii. The Contractor shall review the list of maintenance activities periodically,
update it based on problems / System change requests, and seek the Board’s
approval. The Board reserves the right to modify the list of maintenance
activities at any time and the Contractor shall comply.
iii. The Contractor shall ensure that the maintenance activities are carried in
compliance with the Contract, and these are recorded in the monthly report
together with evidence of works done and deliverables.
iv. If there is any deviation from the agreed maintenance activities / schedule, the
Contractor shall highlight these to the Board promptly, provide justification, and
seek approval.

TS-47
 Development and Maintenance of PUB Sensor Platform (PSeP)

v. The Contractor shall deliver to the Board written monthly progress and status
reports in a format approved by the Board. The submission and acceptance of
these reports shall not in any way prejudice the rights of the Board to make any
claims against the Contractor.
vi. The Contractor’s Project Manager shall provide monthly progress and status
report to the Board’s Contract Manager. The Contractor shall submit the
monthly report by the First Week of each month, starting from the first month
upon commissioning of the system to the completion of Contract.
vii. The monthly report shall cover all tasks that are in progress, commencing or
completing in the reporting month, and shall include the following but not
limited to the key items:
• All activities, check and reviews under this Contract such as maintenance
activities, health & performance checks, security & log reviews, etc.
• Problem logs
• Change request logs
• Generate list of amended user accesses in the month for review, aligned to
the daily scheduled automatic user accounts housekeeping job
• Follow-up items
viii. The monthly report shall include a summary page listing the status of the
maintenance activities done. It shall also include a declaration by the Contractor
of the planned maintenance schedule and the actual maintenance schedule, any
deviations, and the reasons for the deviation.
ix. The Contractor shall produce ad-hoc progress reports when required to do so by
the Board.
x. The Board reserves the rights to reject the reports submitted by the Contractor
and the Contractor shall make necessary changes and re-submit the report.
xi. The Board may implement an electronic workflow system for the creation of
scheduled / ad-hoc maintenance jobs and submission of monthly reports. If
implemented, the Contractor shall adopt such system at no additional cost to the
Board.
xii. The Contractor shall use the maintenance report template provided by the Board
for their monthly report submissions. The Board reserves the right to modify the
report format at any time and the Contractor shall comply.

TS-48
 Development and Maintenance of PUB Sensor Platform (PSeP)

PART 4: CHANGE REQUESTS

3.15 The Board may raise change requests describing the service required from the
Contractor to make changes to the System or support the Board within the contract
period from completion/acceptance of Part 1 of the scope of services. The Contractor
shall provide the required skills, expertise, tools or manpower resources to plan,
manage and deliver the System change accordingly.
3.16 The Contractor shall use the rates quoted in the Bills of Quantities (Bill No. 3) for
System Change (SC) support services. The Contractor shall adhere to the submitted
rates for the entire duration of this Contract.
3.17 The Contractor is to note that the Board reserves the right to exercise the utilisation of
the additional man-days and the Contractor shall not commence any work which
requires the use of the quotes in Bill No 3. unless prior written approval from the
Board has been obtained.
3.18 The Contractor shall provision 300 man-days3 for change requests for the duration of
the Contract.
3.19 After the Board submits a request to initiate a Change Request or a budgetary quote
seeking support to carry out a change request, the Contractor shall provide a proposal
within 5 days of date receipt of email, which includes the following:
3.19.1 Proposal of solution that can be implemented smoothly into the production
environment, impact analysis, solution architecture and wireframes.
3.19.2 Development schedule, including target completion and number of billable man-days.

3.20 The number of billable man-days for change requests shall account for the following:
3.20.1 Scoping the SCR with users
3.20.2 Presenting wireframes and proposals for users’ inputs
3.20.3 Development of new feature/functionality
3.20.4 User Acceptance Testing
3.20.5 Final report

3.21 The Contractor shall proceed to carry out the System CR after the Board approves the
proposal.

3
Definition of a man-day: A man-day in this contract shall be defined as EIGHT (8) working hours
excluding lunch breaks and half a man-day shall be defined as FOUR (4) working hours.

TS-49
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.22 The Contractor’s personnel may be required to perform the works and deployment
after office hours to avoid service disruption to the users.
3.23 The Contractor shall ensure the accuracy and quality of work done by its personnel or
agents. The Contractor shall rectify any errors or mistakes made by its personnel or
agents at no additional cost to the Board.
3.24 The Contractor shall comply with the following procedure that covers the progress of
a proposed request from its formal definition through to its implementation, or to its
disposal for other reasons. The procedure shall include the following:
3.24.1 The Board raises a System change request to the Contractor.
3.24.2 Within 5 days of receiving the Board’s request, the Contractor shall create a log entry,
meet with the Board’s users to understand the requirements, assess the feasibility &
impact to the System, estimate resources required, and man-days required to deliver
the change request, and submit a “change request proposal” detailing the works to be
carried, schedule, dependencies, impact to System, basis for man-days, and the total
cost to complete the Change Request.
3.24.3 The Board may require the Contractor to re-work the scope, schedule, effort / cost, etc
and resubmit the “change request proposal”. The Contractor shall submit a revised
“change request proposal”. The Contractor shall provide necessary and adequate
justification for any such revisions to the satisfaction of the Board.
3.24.4 The Contractor must discuss and ensure that there is common understanding between
the Contractor and the Board’s designated officer(s) regarding the scope of work,
deliverables and completion criteria for each service request, the number of resources
required and their costing.
3.24.5 The “change request proposal” shall also include details of the specific changes to be
applied to the modules of software, hardware, updating documentation, and handling
of changes to the existing System.
3.24.6 Evaluation and approval of the proposed works, man-days, and charges by the Board.
3.24.7 The Contractor shall implement the Change Request in the UAT/QA environment (if
applicable).
3.24.8 The Contractor shall conduct testing and acceptance of the works executed under the
change request with the users.
3.24.9 The Contractor shall deploy/implement the Change Request to the Production
Environment (if applicable); and

TS-50
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.24.10 The Contractor shall update the relevant documentation such as technical
specification, functional specifications, online help, user guides etc.

3.25 The scope of work for the System Change Requests implementation services shall
include but not limited to the following:
3.25.1 Gathering and supporting of functional requirements where applicable.
3.25.2 Analysis of user requirements and propose optimal solution for the requirement.
3.25.3 Establishing connectivity where applicable.
3.25.4 Ensuring successful data transmission.
3.25.5 Use Story Boards, wireframes or equivalent to illustrate the requirements and seek
confirmation by the Board (for change requests where it is deemed applicable by the
Board)
3.25.6 Application programs design and development.
3.25.7 QA, Testing and documentation, inclusive of interfacing systems testing.
3.25.8 Conduct user acceptance testing (UAT) together with users and obtain UAT sign-off;
Conduct User Training and post-implementation support.
3.25.9 Problem troubleshooting and resolution related to the change request.
3.25.10 Application and configuration changes.
3.25.11 System performance optimisation.
3.25.12 Software and hardware upgrading.
3.25.13 Source code review.
3.25.14 Data migration where applicable; and
3.25.15 Authorisation roles in alignment with the authorisation framework

3.26 The Contractor shall deliver the following:

3.26.1 Solution architecture and proposal for the User Requirement Estimation of effort to
complete the change request, with mobile design and mobile performance in mind
3.26.2 Change request proposal, including impact analysis and target completion within:

i. ONE (1) WORKING DAY for urgent requests

ii. FIVE (5) WORKING DAYS for non-urgent requests
from date of receipt of email from PUB officer requesting for budgetary quote for
Change Requests, failing which, the development period will be reduced according to
the delay in provision of the budgetary quote.

TS-51
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.27 The Contractor shall ensure that all Change Requests are completed within the time
frame proposed by the Contractor in his proposal and upon the approval of the Board.
3.28 The Contractor shall complete change requests based on the Service Level Agreement
in the table below.
Classification of Estimated effort for Change Completion Time (from the day
Change Request (CR) Request the request is raised to the day
of UAT sign-off)
Urgent CR Change Request that is <= THREE (3) working days or
urgently requested that any other timeline subject to the
requires < ONE (1) man-day Board’s approval.
to complete
Minor CR Change request that require <= FIVE (5) working days or
<= THREE (3) man-days to other timeline subject to the
complete. Board's approval.
Medium CR Change request that require > <= TEN (10) working days or
THREE (3) man-days or <= other timeline subject to the
SEVEN (7) man-days to Board's approval.
complete.
Major CR Change request that require > Timeline subject to the Board's
SEVEN (7) man-days to approval.
complete.
3.29 The Contractor shall ensure that the Completion Time approved by the Board for the
System Change Requests are met.
3.30 The Contractor shall provide the necessary resources to comply with the Completion
Times approved by the Board.
3.31 The Contractor shall submit a monthly Excel tracking file and a cumulative Excel
tracking file of all Change Requests raised by the Board, in a format with information
as approved by the Board. The Board may make changes to the information / format
as and when required and the Contractor shall comply at no additional cost to the
Board.
3.32 The Contractor shall provide monthly updates to the Board on the Change Requests
in the Excel Tracking file. The Board reserves the right to modify the report template
at any time and the Contractor shall comply.
3.33 The Contractor shall use the Excel tracking file to show evidence of compliance to the
Change Request procedure and that the specified service levels are met.

TS-52
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.34 The Excel tracking file (monthly and cumulative) shall include the following but not
limited to:
3.34.1 date and time the Board raises the System change request to the Contractor.
3.34.2 deadline set by the Board for submission of change request proposal and any
extensions approved by the Board.
3.34.3 date of submission of “Change request proposal” by the Contractor
3.34.4 compliance check for submission of “change request proposal”
3.34.5 date on which the Board required re-submission of the “change request proposal”.
3.34.6 date of re-submission of “change request proposal” by the Contractor.
3.34.7 compliance check for re-submission of “change request proposal”.
3.34.8 total number of rounds of revisions required for the Change Request.
3.34.9 date of approval of Change Request by the Board.
3.34.10 total man-days for Change Request.
3.34.11 total amount of Change Request.
3.34.12 classification of Change Request (urgent, minor, medium, major).
3.34.13 stipulated completion time of Change Request.
3.34.14 completion time (date) approved in the Change Request.
3.34.15 UAT sign-off date.
3.34.16 actual completion time (date).
3.34.17 compliance check for Change Request.
3.34.18 date of Change Request deployment to production.
3.34.19 date of completion of update of relevant documentation.

3.35 The implemented Change Requests shall have the following System Warranty
Periods. The warranty period shall be covered within the contract period.
Classification Warranty Period

Service Request that requires less than ONE (1) calendar month from the Date
or equal to SIXTY (60) man-days to System change request is deployed in
complete Production

Service Request that requires more TWO (2) calendar months from the
than SIXTY (60) man-days to Date System change request is
complete deployed in Production

TS-53
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.36 The Contractor must document and file every change request raised and approved by
the Board for billing and audit purposes.
3.37 The Board shall only pay for services “delivered fully” by the Contractor through a
change request raised and approved by the Board in writing.
3.38 A change request shall be considered to be “delivered fully” by the Contractor when
all completion criteria stated by the Board has been completed to the satisfaction of
the Board, the works have been deployed to the Production Environment, and the
relevant documentation (such as functional specifications, technical specifications,
and user manual) are updated.
3.39 All implemented Change Requests shall fall under the system maintenance upon
acceptance by the Board.
3.40 The Contractor shall be liable for liquidated damages if the Contractor fails to meet
the Service Level Agreements for the System Change Requests specified in Section 3
Clause 3.28.

3.41 User acceptance test

3.41.1 The Contractor Personnel shall provide an Acceptance Test Plan for testing the new
changes to the applications. The Plan shall include the acceptance criteria, test cases
and test schedule. The plan shall be submitted within FOUR (4) WEEKS of
commencement of the Contract.
3.41.2 The Plan shall be thorough enough to verify that the new applications meet the
functional and technical specifications. The Plan shall also demonstrate the error
handling mechanisms built into the applications.
3.41.3 The Contractor Personnel shall conduct, together with the users, the acceptance testing
of the applications based on the agreed Test Plan. The Contractor Personnel shall
repeat the acceptance test or part of the acceptance test until the Users are satisfied
that the applications have met all the requirements specified in the agreed Test Plan.
3.41.4 The Contractor Personnel shall unconditionally guarantee that the changes applied to
the System comply with the Board’s specifications.
3.41.5 All test results shall be properly documented by the Contractor Personnel and made
available to the Board for inspection or verification, when necessary.

TS-54
 Development and Maintenance of PUB Sensor Platform (PSeP)

SYSTEM AVAILABILITY AND SERVICE LEVEL

AGREEMENTS:
3.42 The Contractor shall ensure that the uptime of PSeP meets the System Availability of
99.9% for each calendar month or part thereof commencing from the start date of the
Contract, except during the time when the platform is shut down for system
maintenance (i.e. planned maintenance shutdowns). The Contractor shall maintain
System Availability and minimize System Downtime.
3.43 System Availability is defined as the percentage of the total time during which the
platform is available to the customers and users. It is calculated as:
System Availability = ((SOT – SD) x 100%) / SOT
Where,
SOT: Scheduled Operation Time is defined to be the scheduled operating hours (24
hours x 7 days a week) excluding the planned maintenance periods (i.e. scheduled
downtime).
SD: System Downtime (i.e. unplanned downtime) is the accumulated time during
which the platform or its component is inoperable or partially inoperable due to system
failure.

3.44 The Contractor shall adhere to the Service Level Agreement as specified in the Table
below for the platform maintenance and support services and during the warranty
period of any system changes.
Severity Description Phone Onsite Resolution
Response Response Time 3
Time 1 Time (if
applicable) 2
A Causes severe loss of 5 minutes Within one (1) Within 3
service. Affect the hour on report hours on
business operation of problem report of
continuity or unable to problem .
process critical functions

Example:
System crash,
System hangs,
Network outages,
Operationally critical
component crashes etc.

TS-55
 Development and Maintenance of PUB Sensor Platform (PSeP)

B Causes minor loss of 1 hour Within four Within two

services. Affects a (4) hours on (2)
particular work area but it report of working
can continue to function problem days on
using a temporary work report of
around; other work areas problem
are not affected.

Example:
Report modules only
affected
1 Phone Response Time: The time between notification of problem and the response by the Contractor
to the problem.
2 Onsite Response Time: The time between notification of problem and the on-site attendance by the
Contractor to the problem.
3 Resolution Time: Resolution Time shall begin upon notification of the problem to the time the defect
is restored to a satisfactory operating condition.
3.45 There shall be exceptions to the Service Level Agreement in the event that
investigation and resolution progress are hindered (e.g. cannot be conducted or
implemented).
3.46 Any exceptions to the Service Level Agreement shall be mutually agreed upon in
writing between the Board and the Contractor.

PROJECT & PAYMENT MILESTONES

3.47 Except as variation orders are issued, the remuneration of the Contractor for the
performance of the Services shall not exceed the total amount as stated in Bills of
Quantities.
3.48 Payment shall be made on actual Services provided based on rates given in Bills of
Quantities.
3.49 Invoices are to be submitted based on the rates given in Bills of Quantities.
3.50 Payment shall be made within thirty (30) days from the date of receipt of the invoice.
3.51 The payments under this clause shall not prejudice the Board's right to reject deficient
Services or the Contractor's responsibility to re-perform deficient Services.
3.52 Without limiting the Board’s right under the Contract, the amount of any payment or
debt owed by the Contractor to the Board under the Contract may be deducted by the

TS-56
 Development and Maintenance of PUB Sensor Platform (PSeP)

Board from any monies payable by the Board to the Contractor pursuant to this
Contract.
3.53 The Contractor shall ensure that the following milestones are met as per the timeline
indicated in the table below:
3.53.1 PART 1: Design, Develop and Implement a Central PUB Sensor Platform (PSeP)

Payment for Part 1 shall be made under Bill No. 1 in the Bills of Quantities. The
Contractor shall only issue the invoice upon completion of each milestone.
i. User engagement and document submissions:
• The Contractor shall deliver the following for sign-off and acceptance within
TWO (2) months of Contract commencement:
o Cloud architecture documents
o Dashboard design documents
o Carry out user engagement, collect requirements and submit a User
Requirements report.
o GCC on-boarding documents
ii. Security Hardening Documents clearance:
• The Contractor shall ensure that all security hardening documents where
applicable are cleared and signed-off by PUB IT security team before UAT
and Commissioning the system.
• The Contractor shall ensure that a Vulnerability Assessment and Penetration
Test (VAPT) is conducted by certified and qualified professionals to identify
all vulnerabilities in the platform.
• The Contractor shall ensure that all vulnerabilities are remediated in a timely
manner prior to commissioning the system.
• The Contractor shall submit all necessary supporting documents such as the
following but not limited to:
o Cloud Risk Assessment documents4
o Project Risk Assessment
o Bill of Materials consisting of any and all software, licenses, libraries
and any other components being used in the platform5.

4
The Cloud Risk Assessment template shall be provided by the Board upon commencement of the Contract.

5
The BOM template shall be provided by the Board upon commencement of the Contract.

TS-57
 Development and Maintenance of PUB Sensor Platform (PSeP)

o VAPT reports with all findings remediated with risks accepted where
necessary/applicable.
iii. UAT:
• The Contractor shall submit a User Acceptance Test Plan for clearance by the
Board at least TWO (2) WEEKS prior to the commencement of the UAT.
• The UAT test plan shall minimally consist of the following:
o acceptance criteria
o test cases
▪ Functional and non-functional test cases
▪ Positive and negative scenarios for the test cases
o test schedule.
• The Contractor shall use the UAT script template attached in the Appendix
XX for the same.
• The plan shall be thorough enough to verify that the application meets the
functional and technical specifications. The plan shall also demonstrate the
error handling mechanisms built into the application.
• The Contractor shall conduct, together with the users, the acceptance testing
of the application based on the agreed Test Plan.
• The Contractor personnel shall repeat the acceptance test or part of the
acceptance test until the Users are satisfied that the applications have met all
the requirements specified in the agreed Test Plan.
• The Contractor shall rectify all failures that were observed during the UAT
before commissioning the system.
iv. Commissioning:
• The Contractor shall arrange to commission the system within TWO (2)
MONTHS of the acceptance and sign-off of the UAT.
v. Training
• The Contractor shall prepare for and conduct user training sessions to
familiarise the users with the functionalities of the platform alongside the
commissioning of the platform.
• The training materials shall be comprehensive and shall include relevant
demonstration and hands-on sessions for users to familiarise themselves with
the platform.

TS-58
 Development and Maintenance of PUB Sensor Platform (PSeP)

• The Contractor shall also provide self-training videos for users to follow and
train themselves in the use of the platform.
• The Contractor shall submit the training materials for clearance at least ONE
(1) WEEK prior to the commencement of training.
vi. Final Documents Submission:
• The Contractor shall ensure that all documentations, system manuals and
standard operating procedures are formally signed-off and accepted by the
Board within TWO (2) MONTHS from the date of commissioning of the
system.
vii. Payment Schedule
• The Board shall follow the following payment schedules for the deliverables
stated above.
Progress Payment
Deliverable
under Bill No. 1
User Engagement Sessions and Documents
Submission
System Architecture document 25%
Dashboard Design document
User Requirements report
Security Hardening and VAPT Documents
15%
UAT Acceptance and Sign-off
Training and Commissioning 35%
Handover of all Documentation, system manual and
15%
SOPs
Total 100%

3.53.2 Part 2: Integration Jobs

i. Payment for this scope of work shall be made on a per JOB basis under Bill No.
2.
ii. Liquidated Damages stated in Section 3 Clause 3.55 shall apply for any delay in
the delivery of the items under Part 1 of this Contract.
iii. The Contractor shall note that the scope for the integration shall include either the
basic integration package or the interfacing package or both as applicable.

TS-59
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.53.3 Part 3: Maintenance and Technical support Services

i. The Board shall pay for the PSeP maintenance and support services (Bill No. 3
of Bills of Quantities) monthly on acceptance of the Maintenance and Support
Services Report for that month as per the report requirements stated in Section 3
Clause 3.14.52.
ii. The Contractor shall strictly adhere to the Service Level Agreement stated in
Section 3 Clauses 3.42 to 3.46.
iii. The Contractor shall issue the monthly maintenance invoice only upon resolution
of Severity Level A and Severity Level B cases under the Service Level
Agreement.
iv. Payment for any maintenance activities conducted on the system during partial
months shall be pro-rated.
v. The Contractor shall follow the maintenance report template provided by the
Board upon commencement of the Contract. Any changes to the template shall
be informed by the Board ONE (1) MONTH prior to the upcoming monthly report
submission.

3.53.4 Part 4: Change Requests

i. The Board shall only pay for services “delivered fully” by the Contractor through
a change request raised and approved by the Board in writing.
ii. A change request shall be considered to be “delivered fully” by the Contractor
when all completion criteria stated by the Board has been completed to the
satisfaction of the Board, the works have been deployed to the Production
Environment, and the relevant documentation (such as functional specifications,
technical specifications, and user manual) are updated.
iii. The Contractor shall issue the invoice only after the Board has verified that the
change request made is satisfactory and validated the report.

TS-60
 Development and Maintenance of PUB Sensor Platform (PSeP)

LIQUIDATED DAMAGES
Part 1: Design, Develop and Implement a Central PUB Sensor Platform (PSeP)

3.54 If the Contractor fails to meet the stipulated milestones within the timelines set for
Part 1 of the scope of work (Section 1 Clause 1.4), the Board may then impose
liquidated damages at the rate of ONE-TENTH OF A PERCENT (0.1%) of the price
of the respective module under Bill No. 1 of the Bill of Quantities per ONE (1) day of
delay after the stipulated commissioning date.
Part 2: Integration Jobs

3.55 If the Contractor fails to meet the timelines agreed upon for each integration job under
Part 2 of the scope of work (Section 1 Clause 1.4), the Board may then impose
liquidated damages at the rate of ONE-TENTH OF A PERCENT (0.1%) of the price
per integration job under Bill No. 2 of the Bill of Quantities per ONE (1) day of delay
after the stipulated commissioning date.
Part 3: Maintenance and Technical support Services

3.56 The Board may impose the liquidated damages if the contractor is unable to meet the
service level agreement for Part 3 as stipulated in Section 3 Clauses from 3.42 to 3.46.
Severity Description Liquidated Damages
A Causes severe loss of service. Affect the Deduction of FIVE PERCENT (5%)
business operation continuity or unable to each day beyond resolution time of
process critical functions the monthly application maintenance
Example: and support fees per occurrence of
System crash, failure to meet service level for severity
System hangs, A until resolution.
Network outages,
Operationally critical component crashes etc. If only one or few components or
systems or both are affected, the LD
shall be apportioned based on the
number of systems failed.

Eg: if 10 systems have been onboarded

to PSeP and 1 is facing a downtime,
then the LD is 1/10*5% of the monthly
application cost.
B Causes minor loss of services. Affects a Deduction of THREE PERCENT
particular work area but it can continue to (3%) of the monthly application

TS-61
 Development and Maintenance of PUB Sensor Platform (PSeP)

function using a temporary work around; other maintenance and support fees per
work areas are not affected. occurrence of failure to meet service
level for severity B.
Eg:
Report modules only affected If only a one or few components are
affected, the LD shall be apportioned
based on the number of sites on-
boarded to PSeP.

Part 4: Change Requests

3.57 If the Contractor fails to meet the service level agreement for Part 4 system change
requests as specified in Section 3, then the Board may impose Liquidated Damages
on the Contractor as stipulated in the table below.
Value of each work LD Rate
Not exceeding FIVE HUNDRED At rate of FIVE DOLLARS ($5/-) per day
DOLLARS ($500/-)
Exceeding FIVE HUNDRED At rate of TEN DOLLARS ($10/-) per day
($500/-) but not exceeding TWO
THOUSAND AND FIVE
HUNDRED DOLLARS ($2,500/-)
Exceeding TWO THOUSAND At rate of TWENTY DOLLARS ($20/-) per day
AND FIVE HUNDRED DOLLARS
($2,500/-) but not exceeding FIVE
THOUSAND DOLLARS ($5,000/-
)
Exceeding FIVE THOUSAND At rate of THIRTY DOLLARS ($30/-) per day
DOLLARS ($5,000/-) but not
exceeding TEN THOUSAND
DOLLARS ($10,000/-)
Exceeding TEN THOUSAND At rate of FORTY DOLLARS ($40/-) per day
DOLLARS ($10,000/-)

TS-62
 Development and Maintenance of PUB Sensor Platform (PSeP)

3.58 The total Liquidated Damages imposed on the Contractor is subject to a maximum of
TEN PERCENT (10%) of the total awarded contract sum.
3.59 The period of delay in completion shall include Saturdays, Sundays and Public
Holidays.
3.60 The payment or deduction of such sums shall not relieve the Contractor from his
obligations to complete the project or from his other obligations and liabilities under
this Contract.
3.61 In the event of a severe loss of service such that the system availability for the month
falls below the system availability requirement defined in Section 3 Clause 3.42, the
monthly maintenance payment will be deducted based on the following formula. The
Contractor shall not incur this deduction if the Contractor can provide the Board with
evidence within FIVE (5) working days of the incident that the cause is not attributable
to the application or the Contractor.

Reduced monthly payment =

𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑡 𝑀𝑜𝑛𝑡ℎ𝑙𝑦 𝑃𝑎𝑦𝑚𝑒𝑛𝑡 𝑅𝑎𝑡𝑒 𝑥 (𝑁𝑜.𝑜𝑓 𝑑𝑎𝑦𝑠 𝑖𝑛 𝑝𝑎𝑦𝑚𝑒𝑛𝑡 𝑚𝑜𝑛𝑡ℎ−𝑁𝑂.𝑜𝑓 𝑑𝑎𝑦𝑠 𝑜𝑓 𝑠𝑒𝑣𝑒𝑟𝑒 𝑙𝑜𝑠𝑠 𝑜𝑓 𝑠𝑒𝑟𝑣𝑖𝑐𝑒)
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑑𝑎𝑦𝑠 𝑖𝑛 𝑝𝑎𝑦𝑚𝑒𝑛𝑡 𝑚𝑜𝑛𝑡ℎ

i. “Severe loss of service” refers to a Severity A incident as defined in Section 3

Clause 3.44.
ii. “Day of severe loss of service” is defined as any calendar day after the system
availability for the month falls below the system availability requirement defined
in Section 3 Clause 3.42.
3.62 The period of delay in completion shall include Saturdays, Sundays and Public
Holidays.
3.63 The payment or deduction of such sums shall not relieve the Contractor from his
obligations to complete the project or from his other obligations and liabilities under
this Contract.

HANDOVER
3.64 The Contractor is required to handover the technical support to the takeover party at
the end of the contract. The takeover party shall be the Board’s officers or the Board’s
appointed Contractor. The Contractor shall ensure all relevant knowledge and

TS-63
 Development and Maintenance of PUB Sensor Platform (PSeP)

information acquired and required for the support services are conveyed to the
takeover party.
3.65 The Contractor shall furnish the Board with a detailed Handover Plan at least One
Month before the expiry (or termination) of the Contract. The Handover Plan shall
include a detailed schedule of handover activities. The Contractor shall provide a list
of handover documents to facilitate the tasks. A description of the documents with key
information and purpose shall be clearly stated.
3.66 The handover shall be completed in two weeks. The Contractor shall conduct a
comprehensive handover of maintenance work to the takeover party during the last
two weeks of the Contract. The handover activities shall not affect the maintenance
service level.

REMEDIAL ACTIONS
3.67 If Contractor’s services cause any defects, changes or modifications to the
functionality of any Computer System, inclusive of the PSeP, the Contractor shall at
its own costs, take the necessary remedial action within the time frame set by the
Board in writing. If the Contractor is unable to effect the necessary repairs or
necessary remedial action, the Board shall be entitled to do so by itself or by engaging
a third party; and all costs shall be recoverable from the Contractor by deduction of
any monies due to the Contractor or as a debt due from the Contractor in any court of
competent jurisdiction.
3.68 If the Contractor, after receipt of a written notice from the Board’s Contract Manager
requiring compliance within Seven (7) Working Days, fails to comply with the Board
Contract Manager’s Instructions, the Board may employ and pay other agencies to
execute any work necessary to ensure the Board’s business operations are not affected.
All related costs incurred shall be recoverable from the Contractor by the Board as a
debt or may be deducted by the Board from any money due or to become due to the
Contractor.
3.69 If the Contractor defaults in his performance of this Contract, the Board may issue a
notice of default to the Contractor informing the Contractor of its default. The
Contractor shall, within THIRTY (30) DAYS of the date of the notice of default,
remedy the default. If the Contractor fails to do so, the Contractor shall be taken to
have repudiated the Contract. The Board shall, after giving seven (7) days prior written
notice to the Contractor, have the right to suspend or terminate the Contract without

TS-64
 Development and Maintenance of PUB Sensor Platform (PSeP)

the Board being liable therefore in damages or compensation. The said termination
shall take effect seven (7) days from the date of the notice of termination.
3.70 In the event of termination, the Board shall have the right to purchase from other
sources all the Services which remains unperformed at the time of termination or
similar Services, and all increased costs reasonably incurred by the Board shall be
recoverable from the Contractor.
3.71 Notwithstanding anything contained herein, the Contractor shall not be entitled to
claim for any reimbursement and loss of anticipated profit for the value of any of the
Services not rendered.
3.72 The Contractor shall upon the termination of this Contract immediately deliver to the
Board all materials, correspondence, documents, paper and property belonging,
connected or related to the Board which may be in his possession or under his control.

COVID MEASURES
3.73 The Contractor shall comply with all relevant Authorities’ requirements including any
latest amendments thereof that are imposed in relation to COVID-19 pandemic so as
to enable the Contractor to fulfil all its obligations under the Contract. All costs
incurred in compliance with this requirement shall be deemed to be included in the
tender rate.

TS-65
 Development and Maintenance of PUB Sensor Platform (PSeP)

APPENDIX A: IT Security Requirements

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,

TS-66
 Development and Maintenance of PUB Sensor Platform (PSeP)

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. Assets Management
2.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.

2.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.

2.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.

3. Information Classification and Handling

3.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.

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

3.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 prosecution.

3.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

TS-67
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

3.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.

3.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.

3.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.

3.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.

3.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.

3.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.

3.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.

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

3.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

TS-68
 Development and Maintenance of PUB Sensor Platform (PSeP)

approval of the Board before sending to the third party.

4. Personnel Requirements
4.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.

4.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.

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

4.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.
4.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.

4.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.

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

4.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.

4.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.

4.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;

TS-69
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

4.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. Based locally; and
f. Contactable via mobile phone on a 24x7 basis.
5. Physical and Environmental Security
5.1. The Contractor shall ensure policies and procedures for physical and environment
protection for any facilities (e.g. operation centres, data centres, helpdesk centre, etc)
relating to this System is put in place.

5.2. The Contractor shall ensure facility (e.g. operation centres, data centres) access lists for
identifying individuals with authorised physical access are developed, approved by
management and maintained. The list shall be reviewed and updated regularly. The
Contractor shall ensure that individuals who no longer require access to the facilities are
promptly removed from the list.

5.3. The Contractor shall ensure that physical access controls are enforced at the facilities
(e.g. operation centre, data centre), such that anyone without authorisation is strictly not
allowed to gain physical access.

5.4. The Contractor shall ensure that assets and information shall not be taken out of country
and the premises used to perform services under this Contract without prior approval in
writing by the Board. The protection provided shall commensurate with the identified
risks if approval is granted.

TS-70
 Development and Maintenance of PUB Sensor Platform (PSeP)

5.5. The Contractor shall ensure the equipment are

a. sited away or protected from physical and environmental threats; and
b. protected against unauthorised access and against loss or damage.

5.6. The Contractor shall ensure that all visitors to the facilities are always escorted and
monitored. The Contractor shall ensure the facilities maintain an audit log of all physical
access.
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

TS-71
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

7.3. The Contractor shall transmit security event logs or application/device logs in near real-
time to the Board’s designated security monitoring service and the Board’s Security
Information and Event Monitoring (SIEM) solution for overall situation awareness of the
System ICT infrastructure and security incidents in accordance to requirements specified
in this Tender.

7.4. The Contractor shall ensure that any problem affecting the SIEM’s capability to monitor
the System is investigated and resolved within the stipulated turnaround time to be
provided by the Board. The final decision for resolutions shall be at the sole discretion
of the Board.

7.5. Designated Security Monitoring

7.6. The Contractor shall provide assistance to ensure smooth installation and operation of
intrusion detection software on the System for the Board’s designated security
monitoring.
8. Log requirements
8.1. The Contractor shall make available all required logs, where applicable, for security
monitoring. Examples of sources of such logs are: —
a. Operating Systems;
b. Databases;

TS-72
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.
9. Security Testing
9.1. The Contractor shall ensure security tests are conducted for the Systems to ensure they
are implemented securely.
9.2. The Contractor shall reference the latest industry security standards and best practices
for security testing such as:
a. Open Source Security Testing Methodology Manual (OSSTMM);
b. Open Web Application Security Project (OWASP) Testing Guide;
c. OWASP Mobile Security Testing Guide; and/or
d. Penetration Testing Execution Standard (PTES).

9.3. If scripts and/or programs are used as part of the security testing, the Contractor shall
ensure that these scripts and/or programs shall not cause any disruption or damage to the
System.

9.4. The Contractor shall engage an independent and competent third-party assessor to
conduct the following security testing activities prior to System commissioning or when
System undergo changes that impact security controls or have high impact to business
functions, where applicable:
a. IT Vulnerability Assessment (VA);
b. Source Code Review / scanning (SCR) for non-COTS products; and
c. IT Penetration Test (PT).

9.5. The Contractor shall work with the Board to conduct System Security Acceptance Test
(SSAT) prior to System commissioning or when System undergo changes that impact
security controls or have high impact to business functions, where applicable.

9.6. The Contractor shall provide the necessary resources to assist in the security testing
(including VA, PT and SCR) / audit, and to perform mitigations / follow-ups at no charge
to the Board. The IT security testing / audit shall cover at least the following areas:
a. Compliance to established policies, standards and procedures defined specifically
TS-73
 Development and Maintenance of PUB Sensor Platform (PSeP)

for the System.

b. System hardening and security configuration review of all hardware and software of
the entire System (including devices, firmware, Operating System, middleware,
databases, applications, etc.);
c. Vulnerability assessment of the entire System (including network, system, and
security components);
d. Application security assessment and penetration testing for vulnerabilities.

9.7. The Contractor shall ensure that the independent third-party assessor performing the
security testing / audit documents all the security findings and the recommendations in
the form of a report. The report shall be submitted to the Board for approval within TWO
(2) weeks after completion of security testing. The Contractor shall ensure the approved
recommendations and rectifications are implemented according to schedule approved by
the Board.

9.8. The Contractor shall work with the Board to verify the findings and assess the
recommendations in the report at no charge to the Board.

9.9. The Contractor shall take reasonable steps to check through the rest of the system for
similar instances of the reported security findings.

9.10. The Contractor shall present all the findings, security risks and remediation report for the
Board’s approval. This shall include a remediation report that show the list of patches /
fixes applied, evidence that the findings are properly rectified and any outstanding
patches / fixes with justifications and follow-up actions.

9.11. The Contractor shall also ensure that any risks and / or vulnerabilities identified are
mitigated and / or rectified through proper change management processes no later than
ONE (1) month or within a mutually agreed period after approval by the Board, and at
no charge to the Board.

9.12. The Contractor shall analyse the risk and assign a risk rating (Critical, High, Medium,
Low) for each identified vulnerability. The results shall be documented and should
include the following:
a. Findings and observations;
b. Risk rating;
c. Implications;
d. Recommendations (by independent security consultant); and
e. Remediation status (applicable to follow up testing).

9.13. The Contractor shall ensure that all known IT security vulnerabilities are addressed.

9.14. The Contractor shall provide adequate justifications for security-related findings deemed
as false-positive. The Contractor shall otherwise perform the necessary remediation if it

TS-74
 Development and Maintenance of PUB Sensor Platform (PSeP)

has been assessed not a false-positive.

9.15. The Contractor shall track and maintain a list of false-positives associated with the
System and furnish it upon request.
10. Security Test Plan Requirements
10.1. For all Security testing activities, the Contractor shall propose an appropriate test plan,
subjected to approval by the Board. The plan should include:
a. Scope of each test;
b. Objective of each test;
c. Assumptions and limitations (if any);
d. Detailed test cases (i.e. including test scenario / setup, detailed steps to perform the
test, tools to be used, required inputs, expected outputs/results, actual outputs/results,
etc.);
e. Designated Contractor personnel expected to be performing the test;
f. Other personnel expected to be involved (i.e. supporting or assisting) in the test;
g. Schedule to perform the test and follow-up action (if any);
h. Environment to be tested (i.e.as close to production environment as possible). The
gaps between the environment for testing and production environment should be
documented to aid in future reference;
i. Assets to be tested;
j. Accounts and roles required for the tests; and
k. Reporting format.
11. Ad-hoc Security Testing
11.1. The Board reserve the rights to conduct security testing (includes VA, PT and SCR) and
audit, on the System whenever the need arises. The rights to test and audit shall also be
extended to the Contractor’s premises and its Subcontractors that are also involved in the
System.

11.2. The Contractor shall work with the Board and/or the Board-appointed security assessor
to provide the necessary services and resources to assist in the security testing and audit
at no charge to the Board.

11.3. The Contractor shall implement the remediation recommendations according to the
timeline agreed with the Board at no charge to the Board.
12. Vulnerability Assessment (VA)
12.1. The Contractor shall ensure Vulnerability Assessment shall cover all components (i.e.
third-party components, components as part of COTS or System) of the System.

12.2. The Contractor shall ensure the scan tools are updated with the latest vulnerability

TS-75
 Development and Maintenance of PUB Sensor Platform (PSeP)

detection signatures and rules, and that scanned targets are directly reachable from the
scanner.

12.3. The Contractor shall ensure the application (e.g. web, mobile, thick client software) and
infrastructure (e.g. operating system, firewalls, appliance, networking devices, wireless,
telephony) are tested using authenticated vulnerability scans, where possible.

12.4. The Contractor shall perform mitigations / follow-ups at no charge to the Board.
13. Penetration Test (PT)
13.1. The Contractor shall ensure penetration is conducted by independent and competent
personnel with industry recognised certifications, such as the following:
a. Offensive Security Certified Professional (OSCP);
b. Offensive Security Web Expert (OSWE);
c. Offensive Security Certified Expert (OSCE);
d. Offensive Security Exploitation Expert (OSEE); and/or
e. Relevant certification from the Council of Registered Ethical Security Testers
(CREST).

13.2. The Contractor shall ensure the penetration test includes the following:
a. System hardening and security configuration review of all components of the entire
System (including Operating System, middleware, databases, applications, etc.);
b. Vulnerability assessment of the entire System (including security components); and
c. Application security assessment and penetration testing for vulnerabilities (i.e.
Clause 22).

13.3. The Contractor shall perform mitigations / follow-ups at no charge to the Board.
14. Source Code Review (SCR)
14.1. The Contractor shall ensure all source codes (i.e. application codes and infrastructure
codes that are developed) shall be subjected to source code review so that the application
does not have vulnerabilities (i.e. in Clause 22 ), erroneous code, hidden code or
malicious code before deployment to production.

14.2. The Contractor should conduct source code review for Infrastructure as a Code (IaC)
and/or Software-defined Everything (SDx) such as Software-defined Infrastructure
(SDI). The review scope should include minimally configuration management,
deployment scripts, provisioning and the package.

14.3. If source code review cannot be performed due to the lack of access to application source
code (i.e. commercial off the shelf software), the Contractor shall provide security
assurance that the application is written correctly, implements the desired design, and
does not violate any security requirements. Examples of security assurance: 3rd party

TS-76
 Development and Maintenance of PUB Sensor Platform (PSeP)

security testing of the source code or equivalent, as well as evidence of secure

development lifecycle during the development of the application.
15. ICT and Data Security Incident Management
15.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.

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

15.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 Timeframe for Follow-on Reports

Severity
Classification Verbal Report Incident Report Form Status Update

Within ONE (1) hour Every FOUR (4) hours

Very Severe
upon detection of until normal operations
Within FIFTEEN suspected or confirmed have resumed or as
Severe
(15) minutes upon incident directed by the Board
detection of Every TWELVE (12)
Within TWELVE (12)
suspected or hours until normal
hours upon detection
High confirmed incident operations have resumed
of suspected or
or as directed by the
confirmed incident
Board

TS-77
 Development and Maintenance of PUB Sensor Platform (PSeP)

Within TWO (2) Within TWENTY- Every TWENTY-

hours upon FOUR (24) hours FOUR (24) hours until
Medium detection of upon detection of normal operations have
suspected or suspected or confirmed resumed or as directed
confirmed incident incident by the 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

15.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.

15.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.

15.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.

15.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.

15.8. The Contractor shall implement measures to prevent the recurrence of system or data
incidents.
15.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.

15.10. The Contractor shall perform root cause analysis on all incidents. The Board, however,

TS-78
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.
16. Security Training and Awareness
16.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.

16.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.

16.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.

TS-79
 Development and Maintenance of PUB Sensor Platform (PSeP)

17. Business Continuity Management

17.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; and
18. System Security
18.1. The Tenderer shall propose a detailed system design in its Tender Offer, which shall at
least include the network and security architecture, components, interfaces, protocols,
security controls, as well as management and administration mechanisms.

18.2. The Contractor shall develop and maintain the security architecture or design of the
System together with the Board. The security architecture and its subsequent updates
shall be subjected to the approval of the Board.

18.3. The Contractor shall develop, apply and maintain security configuration guides,
hardening guides and baselines for the System to ensure configurations are secure, for all
parts of the System, including Operating Systems, applications, and databases, subjected
to the Board’s approval. The Contractor shall take reference from security configuration
guides published by Center for Internet Security (CIS) or equivalent security standard
body, and product principals.

18.4. The Contractor shall establish a system-hardening framework that governs the processes
of hardening all parts of the System and applications. The established framework shall
be clearly documented in a “System Hardening Framework Document” and be provided
to the Board for approval within the timeline determined by the Board. The Framework
document shall be maintained, review and updated by the Contractor annually, subjected
to the Board approval. The Framework document shall minimally include:
a. Methodology and process of creating the system hardening checklists and whether
the checklists are based on industry standard hardening baselines such as CIS, NIST
or equivalent;
b. Process to implement the hardening checklists and how all items stated in the
hardening checklists can be verified to be correctly implemented on each system;
and
c. Roles and responsibilities of various parties that are involved in the system hardening
and verification process.

18.5. The Contractor shall also review and update the security baseline (e.g. hardening

TS-80
 Development and Maintenance of PUB Sensor Platform (PSeP)

configuration) every TWELVE (12) months or whenever informed by the Board. If the
relevant guides and baselines do not exist, the Contractor shall provide information on
how the systems can be secured to a level that is acceptable to the Board.

18.6. The Contractor shall ensure system review is conducted every TWELVE (12) months to
identify and remove unused resources and unused services. The Contractor shall provide
justification if the unused resource or unused service cannot be removed.

18.7. The Contractor shall implement a mechanism to track the expiry dates of all digital
certificates to ensure timely renewal of expiring certificates. The mechanism is subjected
to approval by the Board.

18.8. If any digital certificates expire at any time during the Contract Period, the Contractor
shall inform the Board TWO (2) months before expiry or mutually agreed timeline and
ensure timely renewal of expiring digital certificates.

18.9. The Contractor shall not use Contractor-supplied external media such as hard disk or
thumb drives. Where instructed by the Board to use Contractor-supplied external media,
the Contractor shall ensure that these external media are free of malicious content before
using.

18.10. The Contractor shall ensure all test data, test accounts, and test credentials are removed
from production system before the system commissioning.

18.11. The Contractor shall run applications and batch jobs using accounts with the least
privileges unless otherwise approved by the Board.

18.12. The Contractor shall ensure that adequate security measures are taken throughout the
entire lifecycle of the System to meet the security requirements for the System.

18.13. The Contractor shall periodically review and identify any possible security risks and
threats pertaining to the design of the System. Based on the risks and threats identified,
the Contractor shall propose and implement mitigation measures, subjected to the Board
approval.
18.14. The Contractor shall ensure that all part of the System, including IT assets and tools
used in relation to the System is not end-of-support (EOS). Should any part of the System
reach EOS, the Contractor shall propose and implement alternative solutions while still
maintaining compliance with this Contract, at no additional cost to the Board.

18.15. The Tenderer shall propose Common Criteria (CC) certified products, whenever
feasible. For products that are CC certified, the Tenderer shall indicate the conformance
to Collaborative Protection Profile (cPP) or Evaluation Assurance Level (EAL). For
products that are in the midst of CC certification, the Tenderer shall elaborate on the
schedule of activities and relevant protection profiles for CC certification.

TS-81
 Development and Maintenance of PUB Sensor Platform (PSeP)

18.16. The Contractor shall install anti-malware software in their Operating Systems, except
mainframes to detect (i.e. on-access, on-demand) malware, stop malware activities and
remove malware from the System. The anti-malware shall be kept up-to-date to upkeep
its ability to detect, stop and remove malware.

18.17. The Contractor shall work with the Board-appointed Contractors to ensure that any
malware detected by the anti-malware solution is removed from the System across all
environments (i.e. user-acceptance test, development and production environments)
immediately, and the appropriate security event logs generated to record the detection
and removal of the malware. The Contractor shall also ensure that personnel designated
by the Board is alerted of all security incidents.

18.18. The Contractor shall work with the Board-appointed Contractors to ensure full system
malware scans throughout the System is performed periodically, and immediately report
to the Board any findings from such scans. The frequency of the scan shall be specified
by the Board.

18.19. The Tenderer shall develop and maintain a security guidelines document covering the
scope of the System based on minimally
a. System and data confidentiality, integrity and availability;
b. Data privacy;
c. Data handling; and
d. Secure coding procedures in the language chosen for the application.

18.20. The Contractor shall review and update the content of the security guidelines document,
subjected to approval by the Board.

18.21. The Contractor shall ensure that where a web source offers HTTPS access, the System
will use HTTPS for retrieving and transporting data.

18.22. The Contractor shall ensure that all remote file transfers to / from / within the System
are performed using SSH File Transfer Protocol (SFTP) or other secured file transfer
mechanisms subjected to approval by the Board.

18.23. The Contractor shall ensure that all administration modules of the System are accessible
only from pre-identified network addresses.

18.24. The Contractor shall ensure all classified sections of the System are protected by
authentication and proper access control.

18.25. The Contractor shall not use production data for use in non-production environments
unless all the following security measures are applied:
a. Risk assessment for the use of production data in non-production environments has
been performed and the residual risks on whether the production data has been

TS-82
 Development and Maintenance of PUB Sensor Platform (PSeP)

sufficiently secured for use in non-production environment has been approved at

appropriate approving committee;
b. Amount of data requested is not excessive;
c. Sensitive information within the data is sanitised;
d. Processes to ensure data is only used for the approved purpose is implemented;
e. Data is encrypted prior to its transfer from production to non-production
environments;
f. Authorised storage media is used for data transfer;
g. Processes to ensure that each data transfer is authorised;
h. The use of production data is logged and reviewed; and
i. The production data is securely erased when no longer required.

18.26. The Contractor shall not use production Uniform Resource Locator (URL) and secrets
(e.g. passwords, API keys, cryptographic keys) in non-production environment.

18.27. The Contractor shall ensure the System have proper authentication (e.g. API Keys) and
secure channel for access (e.g. TLS) to all exposed APIs.

18.28. The Contractor shall ensure the System have proper validation of all API requests.

18.29. The Contractor shall only use accounts which is managed by GCC Active Directory, as
well as configuring the enforcement of hardening policies by the Active Directory to
endpoints for consistency.

18.30. The Contractor shall configure their CSP-managed Object Storage services (e.g., Azure
Blob storage) with the following settings:
a. Do not allow public read and write access by default;
b. Enable bucket versioning where required;
c. Enable encryption for Object storage;
d. Enable access logging; and;
e. Enable object locks for buckets which store log information.

19. Database Security

19.1. The Contractor shall ensure access to the database is performed by authorised personnel
only. All activities on the database by these personnel shall be logged and monitored.

19.2. The Contractor should ensure that all queries and actions (e.g. insert, update, delete) to
database(s) in the System are performed through secure programmatic methods (e.g.
stored procedures).

19.3. The Contractor shall ensure proper measures are built into the application to improve
security and robustness for each end-user queries and actions. These measures shall at

TS-83
 Development and Maintenance of PUB Sensor Platform (PSeP)

least include the following:

a. Ensure the immutability of database query structures by using means such as
parameterised SQL queries, whenever possible;
b. Enforce the type of query parameters;
c. Limit the volume of records returned from user’' queries in a single query instead of
providing a data dump; and
d. Encode output for all data returned to the requester.

19.4. The Contractor shall ensure that application/service accounts for accessing the database,
are not used by any individual users to login to the System.
20. Time Synchronisation
20.1. The Contractor shall synchronise the System’s clock / time to a common, accurate and
secured time source.
21. Network Security
21.1. The Contractor shall manage and implement their network operation processes to ensure
the network operate securely.

21.2. The Contractor shall provide a detailed description of the network, which shall at least
include the topologies, architecture and design, the protocols, the System and their
interfaces, the security features, the technologies and solutions, the administration and
usage processes and procedures.

21.3. The Contractor shall segment their systems’ network into public segments and private
segments. Each segment shall serve a specific purpose, such as presentation, business
logic, micro-services and data. An example is as shown in the diagram below:

Public Segments

TS-84
 Development and Maintenance of PUB Sensor Platform (PSeP)

a. Public Segments (Internet) are segments which route traffic directly to/from the
internet.
b. Public Segments (Intranet) are segments which route traffic to/from Government
Enterprise Network (GEN).
c. Public Segments typically host resources such as load balancers, WAFs, firewalls
and API gateways.

Private Segments
d. Private Segments are segments that do not have a route to/from the internet or GEN.
e. They typically host resources such as application servers and databases. Resources
within private segments may initiate access to the internet via a NAT Gateway.

21.4. For systems using CSP-managed PaaS services (such as Lambda and DynamoDB) that
do not reside in public or private segments, the Contractor shall provision such PaaS
services as private, ensure access to such PaaS services are via service endpoints only
and from permitted service consumers (e.g., accounts, roles, IP address, subnet, etc.).:

21.5. The Contractor shall deny all outbound traffic from their systems by default through CSP-
managed firewall (including security groups and Network ACL), third-party firewall or
forward proxy

21.6. For systems that require interactions between internet to internet or intranet to intranet,
traffic shall be routed via:
a. Private link (service endpoints such as, Azure VNET service endpoints )
b. Peering (e.g., VNET peering),
c. Private gateway (e.g., transit gateway, VPN gateway),
d. Tunnelling (e.g., VPN tunnel, Cloudflare tunnel); or
e. Whitelisted by permitted destination IP addresses and/or domains and ports
following the principles of least privilege.

21.7. The Contractor shall ensure incoming requests from the Internet or other systems are
routed through:
a. CSP-managed firewall (including security groups and Network ACL) or third-party
firewall, which controls access to accounts and applications;
b. CSP-managed or third-party service providers’ anti-DDOS services, or equivalent,
which protect against unintended voluminous traffic from reaching internet-facing
systems; and
c. CSP-managed or third-party service providers’ Web Application Firewall (WAF) to
protect against application-level attacks.

21.8. The Contractor shall configure their CSP’s Virtual Private Cloud (VPC) services with the

TS-85
 Development and Maintenance of PUB Sensor Platform (PSeP)

following settings:
a. Enable VPC’s flow logs; and
b. Configure VPC’s resources to only use private IP addresses by default.

21.9. The Contractor shall use service endpoints (such as AWS VPC endpoints, Azure VNET
service endpoints, Google Service Connect) to access CSP services from private
segments to minimise the sending and receiving data across the public internet and
improve security.

21.10. The Contractor shall track and renew their TLS/SSL certificates automatically, 30 days
before they expire using CSP-managed certificate services that offers TLS/SSL
certificates inventory tracking, pre-expiry alert notifications and management features.

21.11. The Contractor shall implement the following security design practices into the System:
a. Deny network traffic by default;
b. Isolate the internal network segments from the external network (e.g. Internet, other
networks not part of this System) and other geographically separate sites through
appropriate access controls such as firewalls (network-layer and application-layer),
proxy servers or application security gateways. Where possible, all incoming and
outgoing traffic shall be subjected to filtering and inspection;
c. Use network-based and/or application firewalls for the perimeter, and ensure
network perimeter firewalls does not provide unrelated and non-security application
services;
d. Ensure web proxy server implements authentication mechanism for web access
validation and tracking, implements content filtering with reputation-based filtering
for URLs (and URL blacklisting, if possible), implements signature-based/heuristic-
based scanning, detection and blocking of all malicious files and web objects, and
filters malicious file types (e.g. executable files);
e. Implement segregation of networks into zones based on the required service (e.g.
Internet, Intranet, management, logging, etc) to facilitate isolation and containment
of potential damage due to cybersecurity incidents or detected anomalous activities;
f. Implement strict network access controls (NAC) to restrict remote administrative
access to selected network addresses;
g. Use non-default network ports for access to remote administration features;
h. Implement authentication, authorisation, or payload inspection for all incoming
connections;
i. Implement network-based firewalls to block both unauthorised inbound and
outbound network traffic;
j. Implement host-based firewalls to protect endpoint devices against unauthorised
network connections, where possible; and
k. Implement application firewalls to filter unauthorised application and service
requests, whenever required.

21.12. The Tenderer shall submit proposal of, unless there is good reason, a System design

TS-86
 Development and Maintenance of PUB Sensor Platform (PSeP)

based on a multi-tier architecture that differentiates major functions and components like
presentation tier, application tier and data-tier to segregate input/output screens, business
and interface logic, and functions related to the processing of data. The Contractor shall
implement the proposed design subjected to the agreement of the Board.

21.13. The Contractor shall ensure that there is no network connection to any external network,
e.g. modem dial-up connection that bypass the controls enforced at the central gateway.

21.14. The Contractor shall ensure all inter-system communication (i.e. communication with
an external system) channels (the transmission of all transactions and data traffic with
external networks) shall be protected using channel encryption and authentication.

21.15. The Contractor shall ensure all intra-system (e.g. server-to-server, client-to-server.)
communication channels shall be protected using channel encryption (i.e.
communication channel encryption must not be broken between source to destination
machine).

21.16. The Contractor shall use the network security protocols listed below to protect the
confidentiality and integrity of network traffic, where possible:
a. Transport Layer Security version 1.2 (TLS 1.2) and above;
b. Security Shell protocol version 2 (SSH2) and above;
c. Internet Protocol Security version 3 (IPsec v3) with Internet Key Exchange version
2 (IKE v2) and above; or
d. Wi-Fi Protected Access 2 Enterprise (WPA2-Enterprise) or above.

21.17. The Contractor shall implement appropriate security measures to ensure that transport
level security measures (for example TLS, etc.) are implemented subjected to approval
by the Board. The measures shall minimally cover the following:
a. Set the secure flag on all sensitive cookies;
b. Set the HttpOnly flag on all sensitive cookies;
c. Use only approved cipher suites as defined in Section 18;
d. Use valid digital certificates; and
e. Encrypt backend connections.

21.18. The Contractor shall ensure the proposed System have an encryption scheme to protect
classified and/or sensitive on storage components (such as database) of the system from
unauthorised access, modification and destruction.

21.19. The Contractor shall ensure all proposed servers in the System support policy
configuration over secured communications channels from authorised management
system.

21.20. The Contractor shall ensure all administration and management access can only be

TS-87
 Development and Maintenance of PUB Sensor Platform (PSeP)

accessible from authorised network addresses and workstations.

22. Application Security
22.1. The Contractor shall design application architectures securely to check for malicious
traffic and route only legitimate encrypted traffic to applications.

22.2. 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.

22.3. The Contractor shall perform code scanning to identify common vulnerabilities as part
of the SDLC, and ensure identified vulnerabilities are remediated before deploying to
Production environment. The Contractor shall furnish the code scanning result and
remediation status for approval by the Board before deploying to Production
environment.

22.4. 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.

22.5. The Contractor shall use security control libraries such as OWASP’s Enterprise Security
API (ESAPI) for the programming languages used in the System, which can help enforce
application wide security practices, and additional validation measures instead of
individual page-based measures to provide a consistent level of security across the
application.

22.6. The Contractor shall ensure that the application is not affected by at least the following

TS-88
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

22.7. 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.

22.8. 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.

22.9. 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.

22.10. The Contractor shall implement appropriate session management for application

TS-89
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

22.11. 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.

22.12. 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.

22.13. 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.

22.14. 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.

22.15. 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

TS-90
 Development and Maintenance of PUB Sensor Platform (PSeP)

and recovering any lost or damaged data or software.

22.16. The Contractor shall ensure that traffic between any applications are:
a. outed via secure proxies such as CSP-managed API gateway that is protected using
WAF, Message queues (e.g., SQS, Kafka or Kinesis.), Database endpoints (e.g.,
DynamoDB), and File services endpoints (e.g., S3, SFTP) in descending order of
preferences;
b. authenticated and authorised based on the principles of least privilege; and
c. validated for expected content before processing.

Examples are as shown in the diagrams below:

TS-91
 Development and Maintenance of PUB Sensor Platform (PSeP)

22.17. The Contractor shall ensure that service endpoints are being used.

22.18. The Contractor configure their CSP-managed API Gateway (e.g. Azure API
Management) with the following settings:
a. Public API Gateway is protected by WAF; and
b. Cached data is encrypted at rest.

22.19. For the systems with multiple services that serve APIs, the Contractor shall use CSP-
managed API gateway or SGTS API gateway to manage incoming API requests from
other systems.

22.20. For systems with service-based architecture, the Contractor shall ensure that services
are configured with load balancing, micro-segmentation (e.g., security group, IAM
roles), service discovery (e.g., AWS Cloud Map, private DNS), encryption,
authentication, and authorisation.

22.21. The Contractor shall configure their CSP-managed Content Distribution Network
(CDN) services (e.g., Azure CDN) with the following settings:
a. CDN is associated with a WAF to control access to your content;
b. Default root object is configured to avoid exposing the contents of your distribution
or returning an error.
c. Use of HTTPS only; and
d. Configure Origin Access Identity to prevent bypass and direct access.

22.22. The Contractor shall configure their CSP-managed API Gateway (e.g. Azure API

TS-92
 Development and Maintenance of PUB Sensor Platform (PSeP)

Management) with the following settings:

a. Enable deletion protection.
b. Configure to use encryption in transit (using TLS);
c. Redirects HTTP traffic to HTTPS; and
d. Drop invalid HTTP headers.

22.23. The Contractor shall design software securely to implement countermeasures that
mitigate against common vulnerabilities.

22.24. The Contractor shall ensure that application cookies enable the "Secure" flag for
cookies to be served over HTTPS only.

22.25. The Contractor shall ensure that their mobile applications, excluding COTS products,
are securely coded, by adopting recommended secure coding guidelines for the coding
frameworks and languages used, and supplemented with the following secure coding
practices:
a. Implement certificate pinning to mitigate man-in-the-middle attacks;
b. Disable the use of applications on rooted/jailbroken devices
c. Implement anti-tampering measures and disable the use of applications when
tampering attempts are detected; and
d. Obfuscate applications’ resources and information

22.26. The Contractor shall encrypt and store authentication credentials and secret keys that
are used in program codes such as automation scripts, mobile and web applications,
inside secure protected storages that are available in secret management tools or as
recommended by the programming language/framework providers or runtime/operating
system/hosting platforms or CSP-manged services such as, Azure key vault.

22.27. The Contractor shall configure the patching of their CSP-managed Platform as a
Service (e.g. Azure App Service) to be managed by the CSP.

22.28. The Contractor shall configure all their CSP-managed database related services
(including Relational Databases, NoSQL Database, Big Data Platform, In-memory Data
Stores) with the following settings:
a. Ensure Database clusters, instances, and snapshots are not directly accessible from
the Internet;
b. Enable encryption for database and snapshots;
c. Enable data in-transit encryption;
d. Enable deletion protection for database cluster and instances;
e. Enable database backups;
f. Configure database instances for minor version upgrades;

TS-93
 Development and Maintenance of PUB Sensor Platform (PSeP)

g. Configure database event notifications subscription for critical database events; and
h. Enable logging of management events to the CSP-managed Log management tool.

22.29. In the event where the system is running multiple Containerised applications on the
same container runtime cluster, the Contractor shall ensure that each of the Containerised
applications is secured with the same security standards as Containerised applications
which have been assessed to be of the highest:
a. Security classification;
b. Information sensitivity; and
c. System criticality.

22.30. The Contractor shall ensure that updates to production Containers are applied by
rebuilding and redeploying a new Container image; The Contractor shall not apply patch
directly into the running container.

22.31. The Contractor shall configure their CSP-managed container registries to log the
following events:
a. Container registry authentication events;
b. Container registry account management events; and
c. Container registry repository events.

22.32. The Contractor shall configure their CSP-managed container services (e.g. Aws Elastic
Container Service, Azure App Service, Google Cloud Run) with the following settings:
a. Remove privileged mode from containers;
b. Configure containers to only use private IP address; and
c. Ensure only signed container images are used.

22.33. The Contractor shall configure their CSP-managed Kubernetes services (e.g. Azure
Kubernetes Service) with the following settings:
a. Kubernetes secrets are encrypted using CSP-managed Key Management Service
(KMS); and;
b. Kubernetes’ cluster endpoints are not directly publicly accessible

22.34. The Contractor shall configure their CSP-managed Serverless computing (e.g. Azure
Functions) with the following settings:
a. Deploy signed code or signed container images; and;
b. Restrict inbound and outbound traffic using firewall controls such as security groups

TS-94
Development and Maintenance of PUB Sensor Platform (PSeP)

TS-95
 Development and Maintenance of PUB Sensor Platform (PSeP)

Container Security

22.35. Should the system be running multiple Containerised applications on the same host
Operating System, the Contracor shall ensure that each of the Containerised applications
is secured with the same security standards as Containerised applications which have
been assessed to be of the highest:
a. Security classification;
b. Information sensitivity; and
c. System criticality

22.36. The Contractor shall run their Containers in non-privileged mode. The Contractor shall
assess the risk during risk assessment, implement the necessary risk mitigation measures,
and seek the appropriate approving authority’s acceptance of residual risks for Containers
which need to run in privileged mode.

22.37. The Contractor shall ensure that updates to production Containers are applied by
rebuilding and redeploying a new Container image; The Contractor shall not apply patch
directly into the running container.
23. Registry
23.1. The Contractor shall remove unused Container images found to be vulnerable from
registries managed. If these images need to be retained, the Contractor shall assess the
risk, implement the necessary risk mitigation measures and seek the appropriate
approving authority’s acceptance of residual risks.:

23.2. For Container registries managed by the Contractor, the Contractor shall log the
following Container registry event categories:
a. Container registry authentication events;
b. Container registry account management events; and
c. Container registry repository events.
24. Access Control
24.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.

24.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.

TS-96
 Development and Maintenance of PUB Sensor Platform (PSeP)

24.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.

24.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.

24.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.

24.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.

24.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.

24.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.

24.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.

TS-97
 Development and Maintenance of PUB Sensor Platform (PSeP)

24.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).

24.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.

24.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.

24.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.

24.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.

24.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.

24.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.

24.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.

24.18. The Contractor shall encrypt and store authentication credentials and secret keys that
are used in program codes such as automation scripts, mobile and web applications,
inside secure protected storages; The Contractor can either use secure protected storage
methods that are recommended as best practices by the programming
language/framework providers or runtime/hosting platforms, or use secure protected
storage that are available in secret management tools. When the use of secure protected
storage is not possible, program codes used by the Contractor shall retrieve the
authentication credentials and secret keys directly from the computer memory using
means such as exporting credentials and secret keys to environment variables.

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

24.20. 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

TS-98
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

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

24.22. The Contractor shall ensure the System only return relevant authentication responses
for users’ reporting purpose only.
25. Privilege Access
25.1. The Contractor shall not allow remote access to the Systems and network unless the
access is properly justified and approved by the Board. The Contractor shall provide
dedicated project developer/maintenance laptops for privilege access to the Systems. The
Contractor shall implement all the following security measures if remote administrative
access is required:
a. All remote administration to servers shall be performed from within a management
LAN meant only for administration (separate from user traffic);
b. Remote administrative access shall only be performed by authorised personnel from
specific systems and access filtering based on IP address shall be implemented.
MAC-based access filtering can be implemented as an additional layer of protection
over IP-based access filtering;
c. Personnel that are authorised to have remote administrative access shall use multi-
factor authentication (MFA) to authenticate to the servers and applications;
d. 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
e. Remote administrative sessions shall be terminated upon the completion of
administration activities.
26. Password Management
26.1. 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.

TS-99
 Development and Maintenance of PUB Sensor Platform (PSeP)

26.2. The Contractor shall ensure the System is implemented with the following features when
using passwords:

26.3. 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:
c. Upper case alphabet (A through Z);
d. Lower case alphabet (a through z);
e. Digits (0 through 9);
f. Special Characters (! $, #, %, etc.);
g. Passwords cannot be the same as account ID or user ID;
h. Prohibit accepting passwords that are commonly used, guessable or compromised;

26.4. 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;

26.5. 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.
e. Limit consecutive failed authentication attempts that can be made on a single account
to TEN (10) times or less; and
f. Protect internet-facing systems against brute force log-on attempts (i.e. CAPTCHA
and delays between failed log-on attempts)

26.6. The Contractor should ensure the System transmit only cryptographically protected
passwords (e.g. encryption of passwords at application layer before transmitting over a
TS-100
 Development and Maintenance of PUB Sensor Platform (PSeP)

secure channel);
27. Identity Access Management Security
27.1. The Contractor shall enforce segregation of duties, principle of least privilege and ensure
access rights of users are authorised and approved by appropriate authorities and granted
according to their roles and responsibilities of the user to mitigate against risk of
unauthorized access.

27.2. The Contractor shall ensure that each user account is provisioned to a unique individual
and each IAM account is provisioned to a unique service, which serves a specific
purpose:

27.3. The Contractor shall use separate CSP accounts for production and non-production cloud
environments to ensure that production infrastructure is logically isolated from non-
production infrastructure.
27.4. The Contractor shall assign user to user groups and grant appropriate permissions to user
groups. Examples of standard user groups are Admins, Developers, Testers, Auditors, etc:

27.5. The Contractor shall establish a process to promptly revoke credentials such as API keys,
access token and passwords, in the event of a security incident:

27.6. The Contractor shall enable automated key rotation at an interval of 1 year for each
cryptographic key stored in their CSP-managed Key Management Service. Should the
system require a longer key rotation interval or cannot automate key rotation, The
Contractor shall assess the risk, implement the necessary risk mitigation measures, and
seek the appropriate approving authority’s acceptance of residual risks.

28. Data Confidentiality and Integrity

28.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.

28.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. (Details in Section 19 - Cryptography)

28.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.

28.4. The Contractor shall implement full disk encryption at key areas (e.g. database servers)

TS-101
 Development and Maintenance of PUB Sensor Platform (PSeP)

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.

28.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.

28.6. The Contractor shall implement all necessary measures and processes to prevent
unauthorised disclosure, modification or destruction of the Board’s security-classified
information.
29. Personal Data and Data Protection
29.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.
29.2. The Contractor shall configure all their CSP managed services with the following
settings.
a. Enable encryption for data at-rest; ;
b. Enable encryption for data in-transit;
c. Enable logging and live stream logs to CSP-managed log management tool; and
d. Configure the instance metadata service on each instance such that local code or
users that uses session-oriented requests or include specific HTTP headers in their
requests to access IMDS.

29.3. The Contractor shall use the Singapore region (e.g. southeast Asia ) for compute and
storage of Primary data, to enforce data residency and data sovereignty.
30. Cryptography
30.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.

30.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 of Algorithm Cryptographic Strength
Type

TS-102
 Development and Maintenance of PUB Sensor Platform (PSeP)

Secure Hash Algorithm At least SHA3-256

Cryptographic 3 (SHA-3)
Hashing Algorithm Secure Hash Algorithm At least SHA2-256
2 (SHA-2)
Advanced Encryption At least AES-128
Standard (AES)
1. Galois Counter Mode (GCM) shall
Symmetric-Key be 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 1. At least P-256
Cryptography (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 L at least 2048, N at least224
Algorithm (DSA) Where
L is the bit length of the prime
modulus
N is the bit length of the prime divisor
Digital Signature Elliptic Curve 1. For IKE v2, at least P-256
Algorithm Cryptography Digital 2. For TLS, at least B-233, K-233 or
Signature Algorithm P-256
(ECDSA)
RSA Probabilistic Use key size of at least 2048-bits
Signature Scheme (RSA-
PSS)
Elliptic Curve Diffie- 1. For IKE v2, at least P-256
Key Exchange Hellman (ECDH) 2. For TLS, at least B-233, K-233 or
P-256

TS-103
 Development and Maintenance of PUB Sensor Platform (PSeP)

Finite Field Diffie- 1. For IKE v2, at least MODP-3072

Hellman (FFDH) (ID=15)
2. For TLS, at least ffdhe3072
(ID=257)
Key Wrapping Advanced Encryption At least AES-128
Standard (AES)
Hash-based Any hash functions specified in FIPS-
Deterministic Random 180 or FIPS-202.
Bit Generator
Hash_DRBG
HMAC-based Any hash functions specified in FIPS-
Random Bit
Deterministic Random 180 or FIPS-202.
Generation (RBG)
Bit Generator
HMAC_DRBG
Counter Deterministic At least AES-128.
Random Bit Generator
CTR_DRBG
Keyed-hash MAC Implemented with approved
(HMAC) cryptographic hash algorithms.
Message
Cipher-hash MAC Implemented with approved AES
Authentication
(CMAC) algorithm.
Code (MAC)
Galois MAC Implemented with approved AES
algorithm.

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

30.4. The Contractor shall ensure that access to cryptographic materials generation function is
authenticated.

30.5. The Contractor shall ensure that cryptographic mechanisms implemented in the System
can handle the peak loads without degrading the performance of the System.

30.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.

30.7. The Contractor shall ensure that cryptographic keys and passwords are not hard-coded

TS-104
 Development and Maintenance of PUB Sensor Platform (PSeP)

or stored in clear in the System, and are not made known to unauthorised person.
31. Digital Certificates
31.1. The Contractor shall define the certificate generation template, subjected to approval
from the Board.

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

31.3. The Contractor shall ensure all digital certificates implemented within the System are
from a trusted Certificate Authority designated by the Board. The Contractor shall ensure
no self-signed certificates is used in the System unless approved by the Board.
32. Key Management
32.1. 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;
b. Seek approval from the Board before implementation;
c. After development and implement, review and update the key management process
annually or otherwise determined by the Board; and
d. Seek approval from the Board for subsequent updates.

32.2. The Contractor shall propose a key management system for the System, in-line with the
Clause 32.1 key management process to ensure that all cryptographic keys and materials
are securely stored and managed. In the event the Contractor is unable to propose a key
management system due to technical limitations, the Contractor shall propose alternate
mechanism including process control to manage the keys, subjected to approval of the
Board. The Contractor shall implement and maintain the approved key management
system or alternate mechanism.

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

32.4. The Contractor shall ensure that the System allows proper backup and recovery of
cryptographic keys. The Contractor shall work with the Board-appointed Contractors to
ensure periodic testing of the backup and the recovery process to verify that
cryptographic keys can be recovered within the stipulated timeframe.

32.5. 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.
33. Information Backup Security
TS-105
 Development and Maintenance of PUB Sensor Platform (PSeP)

33.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 ___4___ hours and __4_____ hours.

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

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

33.4. The Contractor shall ensure the proposed backup solution maintain the access rights of
the source data onto the backup data.

33.5. The Contractor shall ensure access of all backup administrators to the backup System
shall require strong multi-Factor Authentication (MFA).

33.6. The Contractor shall the following security measures are implemented:
a. Use backup media in accordance with manufacturers’ instructions;
b. Backups are performed at a frequency that can meet the system’s RPO.
c. Backups can only be deleted as stipulated in the Board’s data retention policies.
d. Backups are encrypted;
e. Recovery tests are performed on a regular basis; and
f. Backups cannot be overwritten;

33.7. The Contractor shall ensure a copy of the backup data is not kept locally, is configured
to be immutable and is kept disconnected from the System so that the backup copy can
be recovered in the event of a successful ransomware attack.

33.8. The Contractor shall store backups and snapshots separately to primary data storage; The
Contractor shall use default CSP-managed Backup services (e.g. Azure Backup) and only
consider the following alternatives when default Backup services cannot be used.
a. Encrypt backup media that contain classified information or sensitive entity data;
b. SP-managed object storage services (e.g. Azure Blob,);
c. CSP-managed File System services (e.g. Azure files storage ) to store backups;
34. Change Management and Patch Management
34.1. Change Management
a. The Contractor shall ensure that any changes to the original design, implementation
and setup of the System are approved by the Board before making the change.
b. The Contractor shall propose and implement a change control process, subjected to
the Board’s approval, to ensure that all intended changes to the original
configurations and/or changes to the production environment are properly reviewed,
tested in staging environments, authorised before implementations, and verified

TS-106
 Development and Maintenance of PUB Sensor Platform (PSeP)

properly implemented.
c. The Contractor shall provide detailed description of the change control process,
which shall at least include the people involved in the reviewing, authorising and
implementing the change, the System products or solutions used if any.

34.2. Patch Management

a. The Contractor shall develop and maintain a security patch management plan that
is specific to the System, which includes the monitoring of availability of security
patches and the actions needed to address the System vulnerabilities, the timeline
and the function responsible for reviewing or testing, authorising and implementing
the security patches.
b. The Contractor shall implement and adhere to the approved Patch Management
process which shall consist at least the following phases:
c. Assessment of the environment,

i. System baselining;

ii. Asset inventory;

iii. Patch management architecture;

iv. Infrastructure and configuration review;

d. Identification of new software update,

i. Identify new patches;

ii. Determine patch relevance;

iii. Verify patch authenticity and integrity;

e. Evaluation and planning of software update, and

i. Impact analysis;

ii. Patch acceptance testing;

iii. Patch deployment plan and approval;

f. Deployment of software update.
i. Patch deployment;

ii. Progress report;

iii. Exception handling; and

iv. Deployment review.

g. The Contractor shall proactively monitor information about latest software updates
on a monthly basis.
h. The Contractor shall determine whether the software update should be considered
a normal change or an emergency one.
i. The Contractor shall submit a request for change to the Board to seek approval to

TS-107
 Development and Maintenance of PUB Sensor Platform (PSeP)

deploy the software update. The submission of the request to the Board shall be
completed within SEVEN (7) calendar days from the time the official patch is made
available by the vendor to the time request is received by the Board.
j. The Contractor shall ensure security and relevant patches, when released officially
by the vendors or when notified by the Board, are applied to the System in a timely
and controlled manner, within the implementation timeframe specified in table
below:
Type of System Type of Patch Deployment upon availability of Patch

All Emergency TWENTY-FOUR (24) hours

1. Critical Information Infrastructure (CII) High THIRTY (30) calendar days

and Significant Information
Medium / Low SIXTY (60) calendar days
Infrastructure (SII) systems
2. Internet-accessible Application Systems
3. Service-Wide Systems and
Infrastructures

Intranet Application Systems High SIXTY (60) calendar days

Medium / Low NINTY (90) calendar days

Table 2: Deployment Type and Schedule

k. The Contractor shall submit the test results to the Board to seek approval for
deployment to production environment. The submission shall include a rollback
plan. The submission shall also include any forward schedule of change and user
communications messages.
35. Vulnerability Management
35.1. The Contractor shall establish and implement vulnerability management processes (to
manage and remediate discovered vulnerabilities related to the System.

35.2. The Contractor shall assess all security vulnerabilities related to the System (including
all parts, components or dependencies), whether reported to it or uncovered by its own
means, and provide an assessment and report to the Board.

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

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

35.5. The Contractor shall obtain security patches from authorised sources and verify their
integrity before working with the Board to test and apply the patches.

35.6. If any vulnerability is found to be due to parts, components and dependencies supplied

TS-108
 Development and Maintenance of PUB Sensor Platform (PSeP)

by the Contractor, the Contractor shall provide remedial actions to rectify the problem at
no additional cost to the Board.
36. Logging and Audit Trails
36.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.

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

36.3. The Contractor shall ensure that sensitive information (e.g. password) is not stored in the
logs.
36.4. The Contractor shall ensure that the logs are accessible to authorised personnel only.

36.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.

36.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). The Board
TS-109
 Development and Maintenance of PUB Sensor Platform (PSeP)

reserves the rights to decide on the types of user activities to be logged in the audit trails.

36.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.

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

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

36.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.

36.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. The protection measures are subjected to the approval of the
Board.

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

36.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, subjected to approval of the
Board

36.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.

36.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.

36.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)

TS-110
 Development and Maintenance of PUB Sensor Platform (PSeP)

36.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 3: Turnaround Time for Logs

TS-111
 Development and Maintenance of PUB Sensor Platform (PSeP)

37. Third Party Development or Testing Environment

37.1. The Contractor shall ensure the following security measures when development or testing
environment outside of the Board’s ownership and control:

37.2. General
a. Security classified information used for testing purposes shall be desensitised prior
to copying out of PUB environments.
b. The desensitized data shall be erased on timely basis, such as upon completion of
the test or development phase;
c. IP whitelist to trusted addresses on a least privilege basis for access, implementation
of hardening access rules not limited to failed login attempts and strong password
(clause 26.2);
d. The environments shall not use production URLs;
e. The environments shall be decommissioned at the end of the contract;
f. Anti-virus or anti-malware protection is up-to-date and maintained; and
g. Vulnerability and Patch management process is in place.

37.3. Access Control

a. The Contractor shall implement multi-factor authentication for access to the
development environment. A jumphost will be used for access to the development
environment (For e.g., Azure Active Directory accounts shall be used for access
through the Bastion jumphost. Extraction of government data from the development
environment via jumphost to the connecting device is prohibited. Approval shall be
sought from PUB for any data extraction.
b. The Contractor shall restrict access to Singapore IP addresses if no offshoring
resources are required. Hardened access rules will be implemented, including
limiting failed login attempts and setting a minimum number of password characters.
Access will be allowed only to approved unique users, adhering to the principle of
least privilege.
c. The Contractor shall implement controls to prevent, detect, and mitigate the effects
of unauthorized and unnecessary access.

37.4. Privileged Access

a. Multi-factor authentication shall be implemented for privileged access. The

development environment shall be accessed from authorised and secured endpoints
(e.g., with Mobile Device Management). The Contractor shall ensure all asset related
to the project and used by vendors is inventoried (e.g., SEED laptops, endpoint
computers, on-prem devices).

37.5. Network Security

a. Access from the internet shall be blocked and whitelisted network firewall rules shall
be configured for authorised traffic. The Contractor shall deploy the development

TS-112
 Development and Maintenance of PUB Sensor Platform (PSeP)

environment with a multi-tiered architecture with network segmentation. All data in

transit shall be encrypted using the industry standard protocol such as TLS with the
use of stronger cipher suites. The network traffic should be logged with the details
such as date and time of access, the source and destination IP addresses, and the
actions performed.

37.6. Protection

a. All software libraries (including open-source libraries) shall be tracked and updated
regularly. Systems shall be patched to the latest versions and system hardening
measures based on CIS Benchmarks shall be implemented. The Contractor shall
install Anti-virus software in all endpoints and ensure they are updated regularly and
automatically. The Development Environment should be shut down or isolated with
network rules when not in use.

b. All cryptographic keys or secrets shall be stored securely to mitigate against

unauthorised access and/or modifications. A crypto lifecycle management plan shall
be established for the lifecycle of the keys/secrets.

37.7. Detection

a. Security log auditing and monitoring shall be implemented. The security logs of the
development environment shall be reviewed regularly, and alerts shall be sent in real-
time to the Contractor (e.g., through emails).

37.8. Data Security

a. Data at rest will be encrypted. Access to sensitive data will be restricted to authorized
personnel only.

37.9. Backup

a. Regular backups of the development environment shall be performed daily.

37.10. Incident Response

a. In the event of a cybersecurity and/or data incident, the Contractor shall immediately
notify the Board upon becoming aware of the incident. Notification shall be made in
writing and shall include all relevant details known to the Contractor at the time of
notification, including the nature and scope of the incident, the potential impact on
the Board's systems and data, and any remedial actions taken or proposed to be taken
by the Contractor.

b. In the event of a cybersecurity and/or data incident, the Contractor shall adhere to
industry best practices to respond to the incident (e.g., the VMs should not be shut
down but isolated through the network instead). The affected host machines shall be

TS-113
 Development and Maintenance of PUB Sensor Platform (PSeP)

isolated through the network for further investigation by the forensic investigation.

c. The Contractor shall engage a forensic investigator to investigate the cybersecurity

and/or incident.

37.11. Governance

a. Risk assessments shall be conducted, and approval shall be obtained from the
appropriate authority when production data is used in a non-production environment.

38. Third Party Management

38.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.

38.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.

38.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:

38.4. Onboarding

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

b. 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.

c. 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.

38.5. Service Management

a. 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

TS-114
 Development and Maintenance of PUB Sensor Platform (PSeP)

in the Contractual Agreement have adequately managed the identified risks in their
work.

b. The monitoring and review include the following areas:

• 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.

• 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.

• Adherence to incident management process.

• Sub-contracting requirements.

• Dispute resolution and management

• Verification checks on assets and equipment assigned to the Contractor.

• Where the control environment at the Contractor has been audited, provide the audit
reports to monitor findings, remediation and impact to PUB.

• Ensure that the Contractor conducts a self-assessment annually against contractual

obligations and requirements. e.g. refresher briefings are attended annually.

• 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.

• Remediation status of audit findings are monitored quarterly.

38.6. The Contractor shall procure independent auditors services once every two (2) years, to
audit and ensure the Contractor carry out their assigned work in compliance with
contractual obligations and applicable Board policies and standards. The Contractor shall
provide evidences and interviews at no extra cost to the independent auditors. The
Compliance Audit shall be conducted by an independent auditor approved by the Board.
The Compliance Audit scope shall be approved by the Board. The auditor shall possess
industry-recognised certification, such as Certified Information Systems Auditor (CISA)
or equivalent certification. All costs and expenses relating to the Compliance Audit shall
be borne by the Contractor.

39. Exit Management and Audit

TS-115
 Development and Maintenance of PUB Sensor Platform (PSeP)

39.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:

• Obligations of the Third Party during the transition period, including transfer of
knowledge, deliverables or services to another Third Party or to the Agency;

• Option for the Agency to buy back equipment and software from the Third Party based
on a formula for price determination;

• Transfer of relevant sub-contractor contracts and leases (e.g., maintenance and

licensing contracts) to another Third Party or to the Agency;

• Transfer of data, data structures and methodologies to another Third Party or to the
Agency;

• Transfer of critical Third Party staff to another Third Party or to the Agency;

• Destruction of data by the Third Party;

• Retrieval of any assets that are provided to the Third Party; and

• Any other agency-specific requirements to be adhered to by the Third Party.

39.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 procure independent auditors
services 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.

39.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.

39.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.

39.5. The Contractor shall submit a remediation plan within two weeks from the issuance of

TS-116
 Development and Maintenance of PUB Sensor Platform (PSeP)

the exit 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.

40. Offshoring Security Requirements

40.1. The Contractor shall not provide any services from any country other than Singapore.

TS-117
 Development and Maintenance of PUB Sensor Platform (PSeP)

APPENDIX B – LIST OF HARDWARE AND SOFTWARE

Table 4 List of Hardware and Software

Operating System/
SNo List of Components
Software/Hardware

10

TS-118