ABCDEFGIJKLMOPQRSTUVWXYZ
1
Technology PolicySectionSub-SectionNIST FunctionItemControl DescriptionC/NC/NAResponsible by Vendor
14
GITP-001 Infrastructure Security PolicyNetwork Security (OT)Network Security Management (OT) PROTECT001-OT-C1 OT system network are documented and maintained, only authorised network devices are connected to the network.

Requirements:
• System components (e.g. server, workstation, programmable logic controller, firewalls, switches,
• Logical segmentation between the different network zones;
• Interfaces between the different network zones; and
• Interfaces with external networks, if applicable;
Y
15
Network Security Architecture (OT)PROTECT001-OT-C2OT network are segmented into network zones.

Requirements:
• Limited to network communications between the different network zones to only data required for operations
• Monitored on the network communication between the different network zone for anomalous network traffic. Examples of monitoring and detection mechanism include Intrusion Detection System (IDS) and Security Information and Event Management (SIEM).
Y
16
System Hardening (OT)PROTECT001-OT-C3Security baseline configuration standards are established and implemented on OT systems (applications, operating systems, network devices, security appliances). Compliance checks are performed annually.

Requirements:
• Security baseline configuration standards and technical security baseline configuration standards should be applied before deployment to production, when there are any new assets connected to OT network, or when there are any changes or enhancements made to the OT systems. Security principles to be included as follows:
i. Least access privilege;
ii. Enforcement of password complexities and policies;
iii. Removal/renaming of default administrator accounts;
iv. Removal of unused accounts;
v. Removal of unnecessary services and applications, e.g. removal of compilers and vendor support applications;
vi. Closure of unused ports and interfaces (e.g. USB, Serial Port, LAN);
• Checks on compliance with established security baseline configuration standards must be performed on OT systems annually
• Each established security baseline configuration standard must be reviewed at least once annually
• Any deviation from the established security baseline configuration standards must be documented and justified
Y
17
Remote Connection and Access (OT) PROTECT001-OT-C4Remote access sessions and user activities must be logged for detection of suspicious activites and audit purposes. Multi-factor authentication measures must be adopted for all remote accesses for system administrative tasks and/or high risk/impact business operations that pass through or originated from external networks.

Requirements:
• All remote connections must be explicitly authorised due to business needs
• The remote connection must be limited to the minimum function required of the connection
• All remote connections to OT systems and networks must be subjected to an authentication process to prove identities and validate credentials
• Multi-factor authentication measures must be adopted for all remote accesses for system administrative tasks and/or high risk/impact business operations that pass through or originated from external networks
• The network traffic for all remote connections must be protected with mechanisms that provide strong transmission security and message integrity (e.g. VPN)
• All remote access sessions and activities must be logged for detecting suspecious activities and for audit purposes
Y
18
Malware Control (OT)PROTECT001-OT-C5Protection mechanisms against malware must be put in place.

Requirements:
• Devices are configured with active and up-to-date malware protection
• Authorised applications and software are whitelisted
• Devices are configured to restrict unauthorised file sharing
• Risk mitigating measures must be in place if there are technical and operational constraints on adopting anti-malware mechanism within the OT system
• Only authorised software shall be installed and used on OT systems
Y
19
Removable storage media and portable computing devices (OT) PROTECT001-OT-C6Only authorised removable storage media and portable computing device shall be allowed to connect to OT system and network.

Requirements:
• The conformity removable storage media and portable computing devices must conform to cyber hygiene standards prior to connecting to OT system and network. Examples are:
i. Devices and files are scanned for malware
ii. Devices are installed with latest OS patches
iii. Devices are configured with active and up-to-date malware protection
iv. Network bridging is disabled.
Y
20
Wireless Security Deployment (OT)PROTECT001-OT-C7All wireless communications and devices must be protected and hardened with techniques that provide strong access control, transmission security and message integrity.

Requirements:
• Possible interference, jamming and denial of service (“DoS”) attacks on wireless communication technology should be considered and addressed
• All devices with wireless communications must be hardened based on established security baseline configuration standards
• Where system functionality supports, default settings must be changed prior to deployment to production environment
Y
24
GITP-002 Access Control PolicyAccess ManagementUser Identification and AuthenticationPROTECT002-C3Unique user IDs should be created according to predefined access rights or profile.

Requirements for user identification and authentication:
• Generic IDs shall be renamed wherever possible

• Use of shared account shall be restricted. If required, alternate procedures to identify the user of the shared account shall be established.
• Access to OT systems require an authentication process, including remote access. Multi-factor authentication must be enforced on internet accessible accounts.
Y
29
GITP-003 Password PolicyPolicy RequirementsPassword Management General PolicyPROTECT003-C1Passwords are enabled to follow an established password policy and procedures.

General Requirements for passwords:
• Sharing of user accounts and passwords is prohibited. Where shared account is required, alternate procedures to further identify the user of shared account shall be established.
• Password of super users should be encrypted and decryption key kept securely. Where system functionality supports, pre-staged emergency accounts will only be released to requestor under critical emergency through an established check-out method.
• For OT systems, where system functionality supports, all system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed periodically, at a minimum yearly
• Passwords must not be written or stored on computer systems without appropriate protection (e.g. encryption / hashing or access controls)
• Multifactor authentication for privileged user and users of critical systems, including all remote administrative access to OT systems from external network
• Default passwords must be changed
• Positively verify the identity of the recipient of the user account/password
• Provision of a new/temporary unique password must follow established procedures of verification and approval and must be done in secure manner
• Passwords should not be displayed in clear text on screen when they are entered
• Users should be provided confirmation during a password change session that passwords of their choice have been input correctly (i.e. prompt users to repeat a new password)
Y
30
Password Control SettingsPROTECT003-C2All password settings must comply with Keppel Group’s minimum password requirement.

Requirements for minimum password settings (OT systems):
• Minimum password length: 8 Characters
• Password complexity: Contains at least a combination of symbols, upper-case and lower-case characters
• Maximum password age: 1 year
• Pasword expiry warning: 2 weeks before expiry
• Password history: 8 previously used password
• Password Storage: Password not reversible
• Account lockout duration: 30 minutes
• Account lockout threshold: 6 invalid Login Attempts
• Account lockout action: Account disabled
• Reset account lockout counter after: 30 minutes

• Any deviations must be approved by appropriate management (e.g. BU management and IT department) and mitigating controls put in place
Y
32
GITP-004 Audit Logging PolicyPolicyAudit Log General PolicyDETECT004-C1Audit features must be enabled on all OT systems, servers, network devices and applications and set up according to respective Technical Security Baseline Standards.

Requirements for audit logging:
• Segregation of duties should be considered when assigning responsibilities to manage and administer audit logs
• Manual review of audit logs must be conducted where automated mechanisms are not in place to alert of security-related events

• Clocks of all critical information processing systems must be synchronised
• Deviation must be approved before 'go-live'
• Audit logs must be retained online or on back up media for a minimum period of either 3 months (non critical systems) or 1 year (critical systems) with access restricted to authorised personnel only
• Audit log configurations should be set in accordance to system level or application level approved documentation and hardening Requirements
Y
33
Events to be LoggedDETECT004-C2All events of interest shall be captured (e.g. authorisation, authentication, access events, change-related events, higher risk functionality events, availability related events, erroneous, unexpected, out-of-ordinary events).

Requirements of event logs:
• Systems shall be configured to include the time, source, subject, action and outcome of the event in the audit logs
Y
42
GITP-007 Patch Management Policy Patch ManagementPatch Management ProcessPROTECT007-C1A formal patch management program/process must be established to assess and implement security, functional and non-functional patches within a reasonable timeframe based on patches prioritisation and vulnerability criticality.

Requirements for patch management program:
• Roles and responsibilities must be established clearly according to BU processes
• Periodic review of the procedures must be conducted
• IT system configuration should include details on latest patch information
• Subscription to security advisory should be enabled to obtain alerts, advisories and patch notifications. Regular checks should be conducted with vendors
• Latest patches should be automtically downloaded and implemented as appropriate with vulnerabilities or weaknesses rectified
• Patches must be assessed for applicability, prioritized, tested on a non production / test environment and reported before application. Patch implementation should follow Change Management process. A report for tested patches must be provided to the BU IT Head / BU Digital Head for approval before implementation.
• A scheduled maintenance window must be established for cases where tested patches have become available. This should consider prioritisation based on criticality ratings of vulnerabilities.
• A rollback plan must be established prior to implementation of patches
• Any issue from the implementation or failure to implement a patch, must be recorded, reviewed, investigated and resolved
• Replace the unsupported system components and software for which patches are no longer available. Document any exceptions should the business decide to continue unsupported / outdated software based on business needs.
Y
43
PROTECT007-C2Patching must be implemented within the established Patch Priority and Timeframe in line with Policy and Service Level Agreement. Y
45
GITP-008 Backup PolicyPolicyBackup RequirementsPROTECT008-C1System and data backup strategy and plan must be established to carry out regular back ups.

Requirements for back up of information:
• Security measures and procedures for the protection of backup data/system should be established and documented
• Frequency of synchronisation and back up procedures must be established

• System backup shall be performed minimally every 6 months, while information backup shall be in accordance to business and regulatory requirements
• Backups status to be monitored, with failed backups investigated and rectified
• Ensure backup storage media to be encrypted, kept in a safe and controlled environment, movement recorded in a movement log and securely disposed of according to sensitivity and confidentiality of data, with the disposal period based on the procedures established
• Ensure backup media to be transported to a secured offsite location on a scheduled basis
• Identify and keep a register of the backup media kept for statutory or audit requirements
• Record and file media sanitisation records against inventory
Y
46
Restoration Procedure and Testing

Archival
RECOVER008-C2Restoration and testing procedures are established and performed minimally on an annual basis for critical system components.

Requirements for restoration:
• If BU is able to, backups of critical system component should be tested for restoration at least once a year.
• Restoration procedure should be trialed annually
• Restoration of backup data to be verified and endorsed by IT Team and Business owners
• Restoration test records to be signed off
Requirements for archival of media:
• Information should be retrievable and retained in compliance with security classification and legal/regulatory obligations
• Alternative archival methods should be considered
Y
49
GITP-009 Disaster Recovery PolicyDisaster Response MeasuresDisaster Recovery PlanRECOVER009-C2A Disaster Recovery Plan (DRP) should be formalized, approved and tested annually or upon major system changes to ensure that critical business applications can be recovered in the event of a disaster within an agreed period of time.

Requirements for DRP:
• Developed with the IT Head
• Distributed to key personnel and circulate only the latest copies. Secure the plan at alternate storage sites where it is protected from unauthorised disclosures and modification but can be retrieved when needed.
Include emergency contact list in DRP which includes Disaster Recovery Command team, IT Recovery Team, User Recovery Team and any supporting vendor teams
• For entities that outsource application support to vendors, they should ensure that such requirements are provided by the outsource vendor
Y
50
Disaster Recovery TestingRECOVER009-C3Requirements for DR Testing:
• Testing of the DRP should be conducted annually for full and partial shutdown scenarios, incapacitation of primary site and major system failures, and recovery dependencies between information assets including those managed by third parties, for all business processes and supporting IT systems
• DR test results should be declared on the day of the test and a report subsequently approved and released within two weeks
Y
61
GITP-011 Asset and Technology Refresh Management PolicyPolicyInventory of AssetsIDENTIFY011-C1Technology Asset Inventory must be drawn up and kept current, with annual review. Technology Asset Inventory should be maintained to track all Technology assets (systems, devices, storage media, peripherals, all software and hardware components used in production and disaster recovery environments). Management and maintenance of the asset inventory must be ensured, whether manually, locally, or cloud-based implementation.

Requirements for Technology Asset Inventory:
• All new technology assets must undergo the Technology and Data Risk Programme (TDRP)
• All details required to recover from a disaster inclusive of all software and hardware components
• For OT assets, periodic sightings of assets should be undertaken at least once every 24 months to verify existence of asset and appropriateness of asset classification. The OT asset inventory shall be reviewed and updated atleast once every 12 months OR as and when there are any changes to the OT system asset.
• Avoid duplication of other inventories, duplicate enteries should be documented according to procedures
Y
65
Asset ProtectionPROTECT011-C5All Technology Assets should be protected through establishment of Technical security baseline standards and hardening of all technology assets.

Requirements for compliance with the established standards:
• Technical security baseline configuration standards should be applied before deployment into production environment, where there are any new assets connected to the OT network, or where there are any changes or enhancements made
to the OT systems
• Each established security baseline configuration standard must be reviewed at least once annually
• Only authorised removable storage media and portable computing device shall be allowed to connect to OT system and network
• Network access to Keppel OT system should be tightly controlled. Only authorised software shall be allowed to be installed / run on Keppel OT systems
• OT system owner shall ensure all users who have access to Keppel’s OT systems are informed and sign off Keppel’s “End User Computing Policy”
• Deviation must be reported, review and approved by relevant authorised personnel before implementation
• Backup processes must be documented for critical assets
Y
75
GITP-013 Physical and Environmental Security PolicyOT Policy RequirementsRestricted AreaPROTECT013-OT-C1Areas hosting and operating OT systems and the supporting utilities shall be identified and Physical access to such areas (“restricted area”) shall be restricted only to authorised personnel. Y
78
Environmental ControlPROTECT013-OT-C4Preventive measures and controls are taken to protect OT system from power failures and other disruptions caused by the failure in supporting utilities and to protect power and network cables from interference, unauthorised interception and damage. Y
82
GITP-014 Technology Vendor Management PolicyVendor ManagementVendor EngagementIDENTIFY014-OT-C3Vendor’s responsibilities to protect Keppel’s OT system shall be clearly defined and documented in the agreement.

Requirements:
• For critical OT systems, agreements should include Keppel’s rights to audit Vendor’s compliance
• For regulated OT systems, agreements shall include Keppel’s rights to renegotiate in the event of new legislative or regulatory requirements
• Where applicable, all security requirements and obligations set in agreements shall extend to Vendor’s subcontractors who have access to Keppel’s OT systems and/or information.
• The inclusion of the following provisions in the agreements shall be considered:
i. Definitions
ii. Performance
iii. Representations and Warranties
iv. Confidentiality
v. Security Program
vi. Monitoring/Assessment of Vendor Performance
vii. Risk Event Reporting
viii. Remedies
ix. Termination
x. Insurance
xi. Indemnification
xii. Business Continuity/Resiliency
xiii. Miscellaneous
xiv. Software related
Y
88
GITP-015 Cloud Management PolicyCloud Security PolicyCloud Governance IDENTIFY015-C3Governance requirements shall be agreed upon with established day to day management set out in an agreed procedure.

Requirements on Governance:
• Critical activities, inputs and outputs with frequency and format of meetings to review KPIs and KRIs indicating the effectiveness of key information security controls shall be defined, along with accountabilities, and reviewed periodically based on risk assessments conducted
• Expectations regarding operational contract management, SLA management, technology risk management, business continuity management and contract exit shall be agreed upon with established day to day management set out in an agreed procedure
Y
89
IDENTIFY015-C4Training and awareness programs focused on management of cloud service and the risks associated with it should be conducted for all cloud service administrators, users and relevant employees and contractors.

Requirements for Training and Awareness:
• Standards and procedures for the use of cloud services
• Information security risk relating to cloud services and how those risks are managed
• System and network environment risks with the use of cloud services
• Applicable legal and regulatory compliances
Y
93
Cloud Infrastructure Security PROTECT015-C8Requirements for Infrastructure Security:
• The level of maturity, information and support, available to assist with virtual architectural models shall be in line with Keppel’s enterprise architecture when adopting cloud infrastructure
• Data sensitivity of information assets shall be considered when determining the type of infrastructure for adopting cloud services
• Hardening requirements for the Cloud infrastructure will be required, depending on services managed by third party service providers
• Patching requirements for the Cloud infrastructure will be required, depending on services managed by third party service providers
Y
94
PROTECT015-C9Requirements for Encryption:
• Encryption shall be used as an integral control to secure and protect the confidentiality of sensitive data while it is in motion and at-rest
• The details of the encryption algorithms and access control policies shall be specified. Minimum key length of 128-bit for Symmetric (e.g. AES) and 2048-bit for Asymmetric encryption (e.g. RSA).
• Proper key management practice and process must be documented
Y
95
PROTECT015-C10Procedures and controls should be established to monitor, detect and report incidents of IT systems and reviewed annually.

Requirements for Security Events Monitoring and Incident Management:
• IT systems shall be monitored beyond typical health and performance metrics to include security events and advanced analytics to correlate events across various systems at the network, infrastructure, and application layers of the IT environment
• Unscheduled downtime for critical functions implemented on cloud services shall be monitored to ensure that requirements defined by regulatory authorities are met
Y
100
Secure System Lifecycle Management (OT)System Lifecycle Management PROTECT016-OT-C1Business Unit should adopt the Secure SDLC for new OT systems, major changes and technology refresh, to the extent it is applicable.

Requirements:
Control gates shall be put in place to ascertain security activities in each phase are performed adequately before proceeding to the next phase
Y
101
InitiationPROTECT016-OT- C2SDLC projects should be properly defined and project documents approved and maintained throughout the project.

Requirements:
• Security planning is performed and should include security activities and milestones in the overall project lifecycle
• Roles and responsibilities to conduct the security activities in the project should be clearly defined
• A security officer role should be established and assumed by competent personnel/department to advise and support the project team on cybersecurity matters
• System security requirements should be identified based on applicable compliance requirements and cybersecurity risk profile of the OT systems
Y
104
Implementation and TestingPROTECT016-OT-C5Security testing prior commissioning should be performed/invigilated by independent assessors or qualified personnel, who are not part of the project implementation team, to ensure an appropriate level of checks and balances is implemented.

Requirements on security testing should include:
• Systems security acceptance testing
• Host configuration review
• Network vulnerability assessment; and
• If applicable, penetration testing (scope should minimally cover external network perimeter and remote connections)
Y
105
Operations and Maintenance PROTECT016-OT- C6Operations and maintenance of OT systems shall adhere to requirements stipulated in Keppel Group’s Policies whichever is applicable.Y
109
GITP-017 Cyber Security Incident Reporting and Management PolicyDetection and AnalysisCyber Security Incident Logging and Tracking017-C2All abnormal system events with a potential to impact data confidentiality, integrity an availability must be reported iin accordance with an incident tracking mechanism.

Requirements for Incident tracking:
• Cybersercurity Incident Tracking should be separate from IT service requests and IT incidents
Y
111
Forensic Analysis017-C4Forensic Analysis evidence should be acquired,preserved, secured and documented.

Requirements for obtaining evidence:
• Original evidence should be preserved and stored securely before working on the first copy
• Business impact should be considered at all times
Y
112
Containment, Eradication, Recovery and ClosureContainment and Eradication017-C5A containment strategy must be established and documented once the cybersecurity incident is identified and underlying and systemic causes should be determined to assess the cause and nature of the breach and remedies where malicious code and inappropriate material should be removed along with disabling of breached accounts.

Requirements for a containment strategy:
• Economic/ regulatory impact, potential breach of confidentiality/integrity, need for evidence preservation, time and resource needed, effectiveness and duration of the strategy should be considered
• Approriate approved should be obtained before shutdown of system, disconnection from network and disablement of functions
• IP address should be concealed during validation
• All passwords on the compromised and associated systems should be changed
• System and data protection should take precendence over identification of the hacker
Y
114
Recovery and Closure017-C7Resolution and recovery measures for all incidents must be documented.

Requirements on resolution:
• All relevant internal parties must be informed of the outcome of recovery measures
• Business owners affected must be informed once the incident is resolved
• Cybersecurity incident tickets should not be closed until appropriate review and consultation is obtained
Y
115
Post Incident Activity017-C8A follow up report and meeting should be created and held to document and review the cybersecurity incident response.Y
118
OT Cybersecurity Reporting and Management Testing and TrainingRESPOND017-OT-C3Appropriate OT Cybersecurity training are provided annually to all personnel assuming a cybersecurity incident response role or responsibility.

Requirements:
• Cybersecurity incident response training shall educate all personnel on how to recognise and report a cybersecurity incident
• All personnel are expected to follow cybersecurity incident response procedures and must be trained annually and otherwise acquainted with these procedures
• An exercise of the incident response plan shall be conducted once every 12 months
Y
122
GITP-018 Threat and Vulnerability Management PolicyThreat and Vulnerability ManagementMalware ProtectionPROTECT018-C5Malicious code protection programs should be implemented at information system entry and exit points to detect and eliminate malicious code.

Requirements on Malicious code protection:
• System vendors shall be consulted on anti-malware mechanisms (risk mitigating measures shall be in place if there are constraints on adopting anti-malware mechanisms)
• Anti-malware tools, malware definitions and signatures should be kept up-to-date
• Periodic scans should be peformed according to Keppel entity defined frequencies
• Real time scans should be peformed as files from external sources are downloaded, opened or executed
• Malicious codes should be blocked and quarantined with alerts sent to administrators
• False positives should be managed
Y
123
Cryptography and Key ManagementPROTECT018-C6Strong cryptography and key management procedures should be engaged to protect the confidentiality of sensitive data.

Requirements on encryption of sensitive data:
• Sensitive data in motion and at rest must be encrypted
• Key management should include the creation and issuance of keys; protection of private keys; changing or updating of keys; revocation of keys; recovery of lost or corrupted keys; backing up of keys; destroying keys and logging and monitoring of key management related activities
• Public key certificates should be issued based on a defined certificate policy or obtained from an authorised service provider
Y
126
VAPT For OT SystemsMitigations and RemediationPROTECT018-OT-C3Countermeasures shall be proposed and applied to address identified risks, threats and vulnerabilities to reduce or eliminate the impact of an attack, taking into consideration of the threat level, resource, and capabilities required for mitigation.

Requirements :
• An action plan to implement countermeasures shall be developed, followed and tracked
• Validations shall be performed to ascertain the effectiveness of the countermeasures in mitigating identified risks, threats and vulnerabilities
Y
131
V2.0 End User Computing PolicyPolicyMonitoring and ComplianceIDENTIFYEUCP-C4Users are required to read and understand the End User Computing Policy when applying for new user accounts and signing the acknowledgement forms. A declaration of understanding must be acknowledged by both Keppel and Non-Keppel employees for use of computing resources.Y
135
V3.0 Safe Guarding Information PolicyData PrivacyIndividual's ConsentIDENTIFYDG-C3Requirements on Individual's Consent:
• Individual’s personal information cannot be collected, used or disclosed without their consent
• Consent must be in a written contract or via electronic process with easy words to understand
Y
136
Collection of InformationIDENTIFYDG-C4Requirements on Collection of Information:
• Any collection of personal data is only carried out to the extent that it is necessary, considering the scope of the purpose. All details should be made available to the individuals at the time of collection.
• PII of customers should not be used for testing, training or research. When it is necessary, further approvals / authorised procedures must be established to ensure PII is protected.
Y
140
Data ProtectionMonitoring, Retention and DisposalPROTECTDG-C8All personal data should be monitored and disposed either at the request of the individual or once use is over.

Requirements on disposal and retention:
• Information media should be disposed promptly after no longer required
• Data retention policy should be established with consideration on laws and regulations in the location of operation
• Data retention should follow a minimum requirement for 7 years of retention
Y
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201