IM8 Reform

Validate all application inputs to ensure that they match the expected type, structure, or format.

Strictly validating inputs against a comprehensive schema prevents injection attacks caused by inserting special characters or content that would cause the application to perform incorrect operations.

Use parameterised interfaces for database queries or system commands.

Parameterised interfaces such Object-Relational Mapping (ORM) libraries ensure that parameters used in database queries or system commands are properly sanitised and prevent injection attacks.

Sanitise all application outputs that will be used to render a HTML document.

Any application outputs that are returned to the requester and used to render a HTML document can lead to cross-site scripting (XSS) attacks if they contain special characters that change the rendering of the HTML document by the browser.

Apply rate-limiting on all authentication mechanisms to deter brute-force attacks.

Consider rate-limiting to a maximum of 3 consecutive failed authentication attempts within 15 minutes. Time delays between log-on attempts reduce the risk of successful brute-forcing attacks. Bot mitigation tools such as CAPTCHA can further reduce this risk.

Where SSO or passwordless is not supported, verify that user-defined passwords are at least {{ insert: param, as-5_prm_1 }} characters in length and {{ insert: param, as-5_prm_2 }}.

Latest NIST [SP 800-63B](#e59c5a7c-8b1f-49ca-8de0-6ee0882180ce) guidelines found that password length is a primary factor in determining the strength of a password while composition and complexity rules provide marginal security benefits.

Store passwords as salted hashes using a password hashing scheme that is resistant to offline attacks such as those described in NIST [SP 800-63b](#e59c5a7c-8b1f-49ca-8de0-6ee0882180ce). The salt should be:

Refer to NIST [SP 800-90Ar1](#64357b22-9868-4453-9b9e-36c2665d12b3) for suitable pseudo-random number generators. Refer to NIST [SP 800-63b](#e59c5a7c-8b1f-49ca-8de0-6ee0882180ce) Memorized Secret Verifiers section for suitable hashing schemes, including Argon2, scrypt, and PBKDF2. For application source code, use a cryptographically secure pseudo-random number generator function instead of an insecure one, such as crypto.randomBytes instead of Math.random in Node.js and java.security.SecureRandom.nextBytes instead of java.util.Random in Java.

Perform access control checks on all authenticated requests.

Utilise authorisation filters or middleware to force all authenticated requests to undergo access control checks.

Encrypt and store application secrets in a secret management solution with appropriate access controls and do not hard-code secrets in source code.

Secret management solutions include cloud solutions like AWS Secrets Manager and Azure Key Vault as well as cloud-agnostic solutions like HashiCorp Vault and CyberArk Conjur.

Set minimally permissive CSP response headers to mitigate cross-site scripting attacks.

Utilise the relevant fetch directives such as `default-src`, `script-src`, `style-src`, `connect-src`, `img-src`, `media-src` and `object-src` to prevent loading of scripts from malicious sources. Refer to the [OWASP Secure Headers Project](#3101b27c-d39c-49fc-b227-e77df8c5e358) Best Practices for recommended header values.

Set HTTP Strict Transport Security (HSTS) response headers with a maximum age value of at least 1 year (31536000 seconds) to mitigate protocol downgrade attacks.

Refer to the [OWASP Secure Headers Project](#3101b27c-d39c-49fc-b227-e77df8c5e358) Best Practices for recommended header values.

Require users to re-authenticate after their session exceeds {{ insert: param, as-11_prm_1 }} hour(s) or terminate the session.

NIST SP 800-63B recommends re-authentication once per 30 days for Authenticator Assurance Level 1, 12 hours or 30 minutes inactivity for Authenticator Assurance Level 2, and 12 hours or 15 minutes inactivity for Authenticator Assurance Level 3. In addition to time period, system can consider re-authentication when roles, authenticators or credentials change or when the execution of privileged functions occurs.

Scan file uploads for malware before further processing by the system or users.

Consider uploading the files to temporary storage for malware scanning on ephemeral compute like serverless functions before moving safe files to another storage for further processing or unsafe files to quarantine storage.

Manage the codebase in a central code repository with version control.

Use common platforms such as SHIP-HATS 2.0 GitLab or equivalents.

Configure the code repository to reject unsigned commits.

Use GitLab's push rules, GitHub's branch protection rules or similar code repository controls to reject unsigned commits on push.

Require peer review and approval by a designated reviewer before merging into the default branch.

Use GitLab's protected branch and merge request settings, GitHub's branch protection settings or similar code repository controls to enforce this.

Pin direct and transitive dependency versions in the application's dependency manifest.

Dependency manifests such as package-lock.json for npm and Pipfile.lock for pipenv allow you to pin dependency versions.

Provision and operate systems in a consistent manner using automation.

Deploy and maintain Infrastructure and Applications with automated and repeatable tools such as CI/CD Pipelines, Infrastructure as Code (IaC) and other scripts. Automated build and deploy pipelines allow for signing and validation of build artefacts. Do not make manual changes directly into production systems.

When installing dependencies during deployment, only install pinned versions in the manifest.

Use package manager commands such as npm ci for npm and pipenv sync for pipenv that ensure only versions specified in the manifest are installed rather than the latest version.

Sign software artefacts such as code and container images using a trusted source during build.

Use tools or services like Cosign or AWS Signer to sign and verify code.

Verify the signatures of code and artefacts before deployment or runtime.

Implement a signature verification step such as a pipeline stage or Kubernetes Admission Controller.

Share source code within Government to enhance code quality, accelerate innovation, and improve problem-solving efficiency.

Adopt Innersource practices for internal collaboration, utilizing platforms like SHIP-HATS GitLab to manage and share code repositories in Government. Source code should be evaluated for suitability for innersourcing, such as the use of confidential algorithms or embedded sensitive data. The Innersource guidelines published in Developers Portal provide a useful framework for code sharing.

Run regular {{ insert: param, st-1_prm_1 }} vulnerability assessment scans for eligible hosts.

Select agent-based or network-based scans as necessary. Implement authenticated scans where possible for greater coverage. Use scanners such as Amazon Inspector or Microsoft Defender for Cloud for continuous scanning of cloud systems. For on-premises systems or systems that require periodic scans, subscribe to Vulnerability Management System (VMS).

Set up cloud security posture management that performs continuous configuration scans on cloud assets.

Use cloud security posture management tools such as CloudSCAPE, AWS Security Hub, and Datadog Cloud Security Posture Management.

Display a way to responsibly disclose vulnerabilities via the Government Vulnerability Disclosure Programme.

Add a link to https://go.gov.sg/report-vulnerability on all pages, such as in the footer.

Conduct and document a penetration test by internal teams or independent external parties every {{ insert: param, st-4_prm_1 }} day(s).

A white-box penetration test should be performed to effectively test the application.

Triage and then remediate or risk accept all true positive vulnerability findings discovered through security testing within the following timeframe based on severity:

Seek approval from the appropriate approving authority for risk acceptance.

Place private resources (e.g., databases) in private subnets and public resources (e.g., reverse proxies, web servers) in public subnets within a virtual network.

This control does not apply to serverless resources (API Gateways), static sites or assets fronted by CDNs (e.g., CloudFlare, CloudFront) which are located outside of the virtual network. Private subnets do not allow direct connections from the internet while public subnets do. However, resources in private segments can connect to the internet via NAT Gateways in public subnets in the same virtual network.

Restrict access to CSP resources outside of a virtual network (e.g., Lambda, DynamoDb, API Gateways, S3, CloudFront) using access controls or application layer authorisation.

Apply access restrictions appropriate to the resource type. Access through interface VPC endpoints is only required if the client is hosted in a private subnet. For example:

* Restrict access to DynamoDB with IAM policies.

* Restrict access to API Gateway with Lambda Authorizers or authorisation middlewares at the application layer. If the API Gateway is exposed to private subnets, create a [private API](#38e183ce-b5ab-420a-b910-94c444e878f3).

* Restrict access to S3 Buckets with IAM policies and block public access from the internet.

Deny network communications traffic by default and allow network communications traffic by exception at managed interfaces.

Configure network access control lists and security groups to deny all traffic by default. Only allow traffic to and from specific hosts and ports by exception. For egress traffic to the internet, consider whitelisting domains at the application layer or DNS resolver rather than just hosts or ports at the transport layer.

Route network traffic between private networks without going through the internet.

Use CSP Private endpoint services (e.g., AWS PrivateLink with VPC endpoints) when you want to allow one or more consumer VPCs unidirectional access to a specific service or set of instances in the service provider VPC. Otherwise, use VPC peering and Transit Gateway when you want to enable layer-3 IP connectivity between VPCs. Refer to the [Multi-VPC AWS Network Infrastructure Whitepaper](#9022563f-00b5-48d1-99a6-187503e7f869) for further guidance.

Filter direct traffic from the internet to protect against network and application layer attacks.

Deploy the following as required:

* Web Application Firewall

* Distributed Denial of Service Protection (e.g., AWS Shield)

* Content Delivery Network (e.g., CloudFront)

Ensure that deployed SSL/TLS certificates are:

Configure a certificate manager that auto-renews certificates and sends alerts before expiry (e.g., AWS Certificate Manager). Otherwise, automate these functions separately.

Ensure communications between services are secure by making them authenticated, authorised and encrypted.

Design and build inter-service communications (e.g., databases, microservices) to be authenticated, authorised and encrypted (e.g., via API gateways, proxies, private endpoint services, message queues, or service meshes). It is recommended to log communication (such as access logs, transaction logs or payloads) between services for detection, monitoring and investigation of incidents.

Route network traffic between on-premises systems and GCC systems through a secure intermediary.

Design and build secure communications to or from on-premises systems (e.g. Government Enterprise Network (GEN)) through a Gateway rather than direct connectivity (e.g. via API gateways, Application proxies or private endpoint services).

Set up and configure an Intrusion Prevention System (IPS)/Intrusion Detection System (IDS) in the network.

Configure network or host IPS/IDS to detect malicious traffic to/from public or untrusted networks.

Implement strong access controls, encryption, and logging for remote developer, maintainer, or administrator access to private network resources.

Use strong authentication and MFA (except for mobile GFE). Layered security mechanisms and controls include:

Inspect traffic from gateway to private network;

Terminate all remote access connections in a dedicated network segment within the network and restrict access to only systems and services allowed by the Agencies; Implement strong encryption for remote access into school staff network; Only authorised Government Furnished Equipment (GFE) shall be used for remote access connection to SSN; Make sure that remote access connections are not perpetual or to re-authenticate remote users to the VPN gateway on a periodic basis (such as every four hours); Set the maximum number of consecutive failed authentication attempts before account lockout for remote access into SSN; and Make sure that split tunnelling is not implemented.

Generate alerts to inform appointed administrators on changes to firewall rules, including the enabling or disabling of rules.

Implement real time alerts to inform administrators of creation, deletion, modification, enabling and disabling of firewall rules. Also alert administrators when unusual or sudden spike/drop in utilisation of firewall's system resources.

Regularly backup all important data and systems, and store backups in a secure and separate location.

Use default CSP-managed backup services (e.g., AWS Backup, Azure Backup, GCP Backup and DR Service). Consider alternative backup services only when default CSP services cannot be used. Store backups and snapshots separately to primary data storage with data encrypted-at-rest.

Conduct regular testing of recovery processes to ensure their effectiveness.

Ensure each test verifies the system's ability to fully restore all data and services.

Prevent backups from being modified or deleted for {{ insert: param, br-3_prm_1 }} day(s) or as stipulated in the agency's data retention policies.

Use S3 Object Lock or immutable storage for Azure Blob Storage to enforce time-based retention policies.

Enforce data residency of primary data in Singapore.

Use the Singapore region of cloud service providers for compute and storage of primary data, such as ap-southeast-1 for AWS.

Encrypt data at rest.

Many CSP services encrypt data at rest by default but this should be confirmed and validated depending on service usage.

Encrypt data in transit.

While some CSP services transparently encrypt data in transit at the network layer, data at the application layer should be encrypted using protocols such as Transport Layer Security (TLS).

Host systems classified as CONFIDENTIAL (CLOUD-ELIGIBLE), RESTRICTED, or OFFICIAL-CLOSED on Commercial Cloud hosting environments in GCC.

GCC allows oversight to be maintained at the Whole-of-Government level and implements several controls by default.

Sanitise all hardware that stores data at rest. Shred or incinerate data storage meant for retirement.

Use industry standards such as
a) Peter Gutmann Secure Deletion;
b) Bruce Schneier Algorithm
c) US Department of Defence's Standards (DoD 5220.22-M).

Witness the sanitisation and destruction process to ensure data is removed from storage.

Establish a SOP to ensure sanitisation and destruction are witnessed by an agency staff.

Store logs in a repository that is part of a different system or system component than the system or component being audited.

Send logs to the separate storage as soon as possible after the logged event. For cloud audit logs, store them in a separate service or account (such as AWS Organisation Cloudtrail in GCC). Sending logs to the Government Cyber Security Operations Centre (GCSOC) or the central Government Commercial Cloud (GCC) log bucket can also satisfy this control.

Protect logs from unauthorised access, modification, and deletion.

Apply access control policies to logs based on the principle of least privilege. As far as possible, only read access should be granted. Logs sent to GCC Central Logs are tamper-resistant.

Log network traffic going to and from network interfaces.

Enable VPC Flow Logs for AWS or its equivalents.

Log management and audit events on cloud resources.

Configure CloudTrail for AWS or its equivalents to log management and audit events such as changes to IAM policies and resources.

Log database audit events.

Enable RDS logging for AWS or its equivalents.

Log access requests sent to web application firewalls, load balancers, proxies or web servers.

Enable AWS WAF logging, Application Load Balancer logging, API Gateways, or their equivalents.

Log security events on hosts and other cloud resources.

Security events include operating system security events, authentication and audit logs, and endpoint detection and response alerts.

Retain security logs for at least {{ insert: param, lm-8_prm_1 }} day(s).

Security logs include network flow logs, cloud management logs, access logs, database logs and host logs. Retain non-security logs (e.g. application, operations and performance logs) as long as needed for incident resolution and debugging. Consider log lifecycle management automation, such as Amazon S3 Lifecycle configurations.

Configure security monitoring to identify potential security violations or breaches and send automated alerts.

Enable Amazon GuardDuty, Microsoft Azure Security Center, or their equivalents.

Configure resource usage monitoring to identify abnormal usage and send automated alerts.

Configure Amazon CloudWatch alarms, Azure Monitor alerts, or their equivalents to identify abnormal usage such as spike in usage, access to resources during expected hours, and excessive charges.

Monitor, maintain and alert on service level objectives (SLOs) and indicators (SLIs) to ensure consistent service performance, availability and reliability.

Implement a comprehensive monitoring system that tracks key SLIs and evaluates them against defined SLOs. This will help in identifying potential service level breaches early and take proactive measures to maintain service quality. Examples include Cloudwatch metrics and alerts, Amazon Route 53 health checks, Azure Monitor Application Insights, or their equivalents.

Centralise security log management and monitoring with {{ insert: param, lm-12_prm_1 }}.

Tenants on Government Commercial Cloud (GCC) already have Cloud Service Provider (CSP) tenant security logs stored centrally and available for forwarding to Government Cyber Security Operations Centre (GCSOC). Contact GCSOC for subscription and additional services.

Monitor database activities for anomalous behaviour.

Config RDS Activity Streams and logs with alerts or Database Activity Monitoring (DAM) tools to detect unusual authentication, reads or writes to a database.

Plan for and implement measures to detect and recover from web defacements.

The Government Cyber Security Operations Centre (GCSOC) offers centralised monitoring of web defacements of internet-facing systems.

Publish logs in a consistent, structured format that aligns with industry standards for easy parsing and analysis.

For security logs, implement or transform to OCSF (Open Cybersecurity Schema Framework), ECS (Elastic Common Schema) or similar schemas to standardize log formats for better threat detection and analysis. For operational logs, adopt OpenTelemetry or structured JSON formats to facilitate clear, structured, and efficient log analysis for system performance and diagnostics. Consistent log formatting aids in automated parsing and helps in integrating logs from various sources.

Monitor key user-facing signals to maintain robust service health and performance.

Implement monitoring of key signals such as latency, traffic, errors, and saturation (the 4 Golden Signals). Regularly track and analyse these indicators for proactive issue detection and resolution. Use this data to identify trends and areas for system improvement, ensuring continuous enhancement in service quality and reliability.

Measure and analyse software delivery performance to optimise development velocity and operational efficiency.

Implement tools and processes to track Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service (the DORA 4 Key metrics). Use these metrics as benchmarks to drive continuous improvement in the software development and deployment process, enhancing agility, reliability, and responsiveness to changes.

Deny access by default and grant only the minimum permissions required for authorised accounts or processes to perform a specific function.

Consider attribute- or feature-based access control for greater customisability and granularity.

Require MFA for remote developer, maintainer, or administrator access at login.

Ensure that the authentication factors are different and independent of the accessing device. For additional security, consider MFA for privileged actions at the application level (such as step-up MFA challenges via PIM tools).

Disable or remove accounts with privileged access within {{ insert: param, ac-3_prm_1 }} day(s) from last day of authorised use or have not been used for {{ insert: param, ac-3_prm_2 }} day(s).

Use automated checks to identify accounts and credentials that should be disabled. For privileged user accounts in applications, consider using automated workflows such as System for Cross-domain Identity Management (SCIM) or identity lifecycle management tools. For cloud service provider accounts, use tools such as AWS Config iam-user-unused-credentials-check to manage Identity and Access Management (IAM) users.

Perform an access review every {{ insert: param, ac-4_prm_1 }} day(s) and remove unauthorised or unintended privileged access rights within {{ insert: param, ac-4_prm_2 }} day(s).

For privileged user accounts in applications, implement automated review workflows or reports. For cloud service provider accounts and roles, use tools such as AWS IAM Access Advisor or Azure AD Access Review to facilitate and manage access reviews.

Require hardened endpoint devices for remote developer, maintainer, or administrator access.

Use Endpoint Management platfoms to continuously check and enforce device security posture and deny access if the hardening requirements are not met. Hardened devices include Government Standard Image Build (GSIB) and Security Suite for Engineering Endpoint Devices (SEED).

Change default credentials prior to first use.

Identify any default credentials used in any system components before deploying and change them. Configure end-user systems to prompt for password change on first login after account creation or reset.

Use SingPass or CorpPass MFA for digital services that require high level of identity assurance for external users.

For high impact or high risk transactions, use SingPass/CorpPass to identify external users (e.g. citizens). Internal users should use Government managed Single Sign-on (SSO) solutions (such as WOG AAD).

Implement automation of cloud and application account provisioning and deprovisioning using an account management tool.

Adopt Single Sign-On (SSO) with just-in-time provisioning or account lifecycle management tools (such as SCIM or CAM) to assist with account management. For systems unable to use SSO, it is recommended to leverage account management lifecycle tools with HR records (such as CAM) to automatically provision and de-provision accounts.

Implement and maintain an endpoint device management solution to ensure the security and integrity of endpoint devices used within the organisation.

Mobile Device Management (MDM) platforms enable management, monitoring, and secure configuration of endpoint devices. This includes enforcing disk encryption, managing configuration, ensuring regular updates, and providing the ability to remotely wipe data in case of device loss or theft.

Adopt Identity and Device-Based Access Control for secure and context-aware connectivity to private organisational resources.

Use solutions such as Secure Service Edge (SSE), Identity Aware Proxies (IAP) or other Zero Trust services (Entra ID Conditional Access, Okta Device Trust, etc) that integrate identity and device management systems to provide granular access control to resources based on user identity and device posture. For example, Security Suite for Engineering Endpoint Devices (SEED).

Assign each endpoint device to a single designated primary user and enforce the assignment to ensure accountability and enhance security monitoring.

Implement measures such as user authentication and endpoint management with device enrollment to enforce the single primary user per endpoint. If secondary accounts for local device support or maintenance activities consider securing with endpoint privilege management tools.

Use Single Sign-On (SSO) for internal users and services.

Configure multi-factor authentication (MFA) at the Single-Sign On (SSO) identity provider (IdP) and ensure that access to the system is only granted after the IdP authenticates the user. WOG AAD is recommended for public officers and TechPass AAD for developers.

Use unique base container image tags instead of rolling tags.

Avoid the `latest` tag or other common rolling tags for base images to minimise unintended changes during subsequent builds using the same instruction. A digest SHA can provide a unique identifier for the image if no tag is assigned during build time.

Build container images with minimal base images.

Use minimal container images such as alpine, scratch, wolfi, and distroless images as the base image to reduce attack surface.

Provide secrets and sensitive data to the container at runtime instead of image build time.

Ensure no secrets (e.g., TLS certificate keys, cloud provider credentials, SSH private keys, database passwords) are embedded in the container image by using dedicated features like Docker secrets or `podman-secret-create`.

Create a non-root user and set it as the default user in the container image build instructions.

Ensure the non-root user has the minimal set of permissions required to run the container.

Lint Dockerfiles before building container images.

Use linters such as Hadolint to check the Dockerfile (or similar build file) instructions and flag any issues that contravene best practices. Ensure Dockerfile linting stage is run as part of the Continuous Integration (CI) pipelines.

Configure the container filesystem to be read-only.

Use security policies (e.g., `readonlyRootFilesystem` for Kubernetes) to prevent any direct writes to the container's root filesystem during runtime and ensure immutable infrastructure. Do not directly apply patches or alter running containers as the containers are ephemeral and patches will disappear upon redeploy. Apply patches by rebuilding and redeploying container images.

Scan container images in the {{ insert: param, cs-7_prm_1 }} for known vulnerabilities.

Container image scanning tools (e.g., Amazon Inspector, Trivy, Grype) scan the contents of a container image for known vulnerabilities. Configure scans to run automatically and continuously, as well as enable scanning of image on push. Block deployment of container images with HIGH CVE being detected during scan (e.g., using Amazon ECR with Security Hub).

Host built container images in private container registries.

Use only private container registries (e.g., Amazon ECR private registry) to host container images built by the organisation as images may contain proprietary code or sensitive information.

Disable public access to Container Orchestrator API endpoints from the internet.

Restrict access to the Container Orchestrator API endpoints (such as the Kubernetes API Server) to specific address ranges or use CSP provided features such as disabling Endpoint public access and Private Clusters to disable public access.

Segregate container workloads to help contain attacks through isolation.

Create Kubernetes namespaces or similar container segmentation controls to isolate different workloads, services or projects.

Detect and remediate changes to running containers with container runtime protection tools.

Runtime protection tools, such as AWS EKS Protection, Microsoft Defender for Containers, or Falco, monitor threats and changes to running containers. Vulnerable container instances should be isolated for investigation and replaced with rebuilt and patched images. To avoid persistence if patches do not exist, the container instance should be replaced frequently with an un-compromised image until a patch released. These tools replace Malware Protection (IS-7) and EDR (IS-8) in container environments.

Develop, document, and disseminate an agency-level cybersecurity incident management plan to respond to cybersecurity incidents.

Refer to the Government Incident Reporting and Operations Centre (GIROC) ICT and Data Incident Reporting Resources for an incident management plan and best practices template.

Develop and document a project-level cybersecurity risk assessment prior to initial full release that includes:

Refer to the Cyber Security Agency of Singapore's Cybersecurity Toolkit for IT Teams for an example of a risk assessment template and modify accordingly.

Develop and maintain a comprehensive System Security Plan (SSP) that accurately reflects the system characteristics and security controls in place for the organisation's systems and environments.

The SSP should be detailed, covering all aspects of security controls, roles, responsibilities, and operational processes. Regular updates are necessary to reflect changes in the security landscape and system evolution.

Get approval of deviations from applicable Level 1 profile controls in the default System Security Plans (SSPs) from the agency's ICT and Digitalisation Steering Committee (IDSC) and document these deviations in the customised SSP.

Agencies should seek approval for deviation from their IDSC or delegated approval authority. Controls that are not applicable to the system do not need approval for deviations but the reasons why they are not applicable must be documented in the customised SSP.

Submit approved SSPs centrally to maintain a unified and up-to-date repository of security plans and practices.

Reference the IM8 Portal for submitting all approved SSPs.

Maintain detailed, up-to-date documentation of all system information and architecture.

Example system documentation includes architecture and network diagrams, architecture decision records, hardware and software inventories, data flows, and configurations. This documentation should be regularly reviewed and updated to reflect changes in the environment. Documentation should be accessible to relevant personnel while ensuring sensitive information is protected. Adopt documentation-as-code practices and machine-readable formats (such as Markdown, JSON, YAML, etc), to facilitate version control, collaboration, and automation in maintaining documentation.

Ensure that the Software as a Service (SaaS) provider is certified with {{ insert: param, pm-7_prm_1 }}.

Ensure that the certification is up-to-date. Avoid certifications that are only attestations without a pass/fail element.

Obtain a service level agreement with the Software as a Service (SaaS) provider that covers uptime, response times, downtime notifications, support avenues, and support content.

Ensure that the service level agreement is regularly checked for compliance.

Install CSP management agents on hosts to remotely and securely manage their configurations.

Most CSP compute instances preinstall management agents (e.g., AWS Systems Manager Agent, Azure Windows VM Agent) by default. If the image does not come with the preinstalled agent, install manually.

Automate patching of operating systems and applications.

Apply patch baselines via the CSP node management service, unless the patch management process is automated as part of the build and deploy phase. For on-premise systems, use tools like Azure Update Manager to schedule and automatically deploy patches to Windows and Linux OS.

Restrict administrator privileges by disabling remote login for the root/administrator user and restricting sudo/administrators group access for other users.

Further reduce the attack surface by running common services such as the web server or database without root/administrator/system privileges.

Disable or remove unnecessary functions, system ports, protocols, software, and services on the host.

Follow the principle of least functionality to configure the host to carry out only its intended purpose. CSP node management services can provide an inventory of software and services (e.g., AWS Systems Manager Inventory). Vulnerability assessment scanners (e.g., AWS Inspector) can also identify software vulnerabilities and network exposure.

Harden the host configuration with reference to industry standards.

Select the appropriate benchmark for the host such as from the [NIST National Checklist Program](#521952dd-5c57-4277-a069-4dae6bc0c28d) or [CIS Benchmarks](#09ba067b-8923-4f22-bb31-b8619edcaa07). Automate the configuration process or use hardened images instead of manually configuring.

Use remote administration tools instead of direct SSH or RDP.

In production environments, use remote administration (e.g., AWS Systems Manager Session Manager, AWS Systems Manager Fleet Manager, GCC Privileged Identity Management) only for break glass scenarios where remote monitoring and automation is not available. Document and remediate gaps in monitoring and automation to minimise the need for remote administration. If SSH is still required and remote administration tools are not available, only use it within a private non-production environment such as an encrypted tunnel and authenticate with short-lived certificates.

Detect and quarantine malware on hosts with anti-malware tools.

Configure anti-malware tools for all compute hosts (e.g. AWS Guardduty Malware Protection, Azure Antimalware, Trend Micro CloudOne). These tools should be kept up-to-date with the latest malware signatures. Regular scans should be scheduled to detect and quarantine potential threats.

Monitor security threats on hosts with an EDR tool.

Implement EDR tools for all compute hosts. Security incident response should be planned and documented for the tool. EDR tools with built-in malware protection should be favoured to reduce additional agents.

Ensure deployed {{ insert: param, is-9_prm_1 }} assets have not reached end-of-support (EOS). Use of EOS assets will require risk acceptance by approved authority.

Identify, track and replace EOS assets in a timely manner. Regularly review assets to identify upcoming EOS timeframe and replace them ahead of EOS date.

Synchronise internal clocks to a common reference time source.

Use common time source such as Network Time Protocol (NTP). In the cloud, it is recommended to use the default time sources provided by the CSPs.

Register .gov.sg and .edu.sg domain names with GovTech as the sole registrar.

Use the Whole of Government Domain Name Server (DNS) portal on the IT Service Management (ITSM) portal to register domain names.

Implement DNS Security Extensions (DNSSEC) for public DNS records and servers.

DNS services such as WOG DNS, Amazon Route 53 and Cloudflare support DNSSEC configuration.

Register second (.sg) and third (.com.sg, .org.sg, .net.sg, .edu.sg) level domain name variants of the system's primary domain name.

Consider defensive registration of domain names with typographical variants of the system's primary domain name. The Whole of Government Domain Name Server (DNS) portal on the IT Service Management (ITSM) portal automatically includes the second and third level domain names.

Register and use whitelisted SMS Sender IDs with the Singapore SMS Sender ID Registry for sending SMSes.

Agencies must use the "gov.sg" Sender ID via the Postman tool to send SMSes to members of public unless exempted. Whitelist Sender IDs used to send SMSes and blacklist Sender IDs which are variants of the whitelisted Sender IDs, agency names, or names of services.

Configure the code repository to prevent secrets from being pushed to the repository.

Use GitLab's push rules or GitHub's push protection to reject secrets on push.

Configure the code repository to prevent pushes (including force pushes) to the default branch.

Use GitLab's protected branch and merge request settings or GitHub's branch protection settings to enforce this.

Require Continuous Integration (CI) tests to pass before merging into the default branch.

Use GitLab's protected branch and merge request settings or GitHub's branch protection settings to enforce this.

Set up a static analysis job in the {{ insert: param, sd-4_prm_1 }}, and remediate or risk accept true positive vulnerability findings before deploying to production.

Static analysis tools (such as SAST or IaC security scanners) check source code for common vulnerabilities and misconfigurations. By running static analysis tools earlier in the DevSecOps cycle, vulnerabilities can be detected and prevented from being deployed to production.

Schedule a scan at least every {{ insert: param, sd-5_prm_1 }} day(s) in the {{ insert: param, sd-5_prm_2 }} to identify the use of vulnerable software libraries.

Dependency scanning checks the source code for dependencies with known vulnerabilities. By running scans regularly using bots or software composition analysis (SCA) tools, vulnerabilities arising from outdated dependencies can be quickly detected and patched. Software composition analysis can be performed using tools such as Gitlab, Nexus IQ, or their equivalent, with output in a common SBOM format such as SPDX or CycloneDX.

Set up secret detection in the {{ insert: param, sd-6_prm_1 }} and remediate true positives within {{ insert: param, sd-6_prm_2 }} day(s).

Ensure that the exposed secret is revoked and purged from the Git history.

Protect environment variable secrets used in CI jobs by limiting them to protected pipelines and masking them in job logs.

Use GitLab's CI/CD variable security settings or GitHub's encrypted secrets with the add-mask workflow command.

Segregate production and non-production environments including applications, services, data, secrets, roles, and networks.

Achieve segregation using separate Government on Commercial Cloud (GCC) accounts for environments such as production, development, test, and staging. Account segregation enhances security by limiting exposure, simplifies resource and cost management, maintains configuration integrity, facilitates compliance and auditing and streamlines operational tasks. Deploy and operate environments as similarly as possible to enhance debugging and time-to-market.

Physically separate Government resources from non-Government resources.

For on-premise environments, ensure government resources are physically stored and secured separately from non-government resources.

Implement physical access controls to prohibit unauthorised access to the hosting environment or network rooms.

Measures to consider include:

a) personnel security clearance and checks

b) Continuous monitoring

c) Immediate security response

d) Strong authentication card access system to regulate and log access of employees, visitors and contractors to the facility;

e) Guards deployed to guard the facility 24/7;

f) Restrict items (such as unauthorised computing devices) to be brought into the facility;

g) Intrusion Detection System installed to detect unauthorised access;

h) CCTV installed to monitor the facility.