Regional · Singapore

MAS Technology Risk Management Guidelines (2021)

Attestkeep maps what your cluster's admission control and image scanning recorded in a period to 30 clauses of Monetary Authority of Singapore, 18 January 2021. 19 are assessed from those records; 11 are marked outside scope, each with the reason.

What the framework asks

19 clauses a cluster can answer.

Citations and titles as the report prints them. Open a clause to read what it asks, restated close to the instrument's own words.

Technology Risk Management Guidelines

Monetary Authority of Singapore, 18 January 2021

Sections 3.3 (information assets), 6.1 and 6.3 (application security and DevSecOps), 7.2 to 7.6 (configuration, technology refresh, patch, change and software release management), 11.3 and 11.4 (system and virtualisation security), 12.1 and 12.2 (cyber threat intelligence and event monitoring), 13.1 and 13.6 (vulnerability assessment and remediation) and 15 (IT audit)

CitationClauseReport sections
Paragraph 3.3.1
Information asset management practices

To have an accurate and complete view of its IT operating environment, the FI should establish information asset management practices covering the identification of the information assets that support its business and the delivery of financial services, the classification of an asset by its security classification or criticality, the ownership of assets and the roles and responsibilities of the staff managing them, and policies, standards and procedures to manage assets according to that classification.

CoverageSupply chain
Paragraph 3.3.2
An inventory of information assets, reviewed and kept current

The FI should maintain an inventory of all its information assets, review the inventory periodically, and update it whenever there are changes.

CoverageSupply chain
Paragraph 6.1.4
Tracking vulnerabilities in third party and open-source components

To facilitate the remediation of vulnerabilities in a timely manner, the FI should keep track of updates and reported vulnerabilities for the third party and open-source software codes incorporated in its software.

Supply chainCoverage
Paragraph 6.1.7
Issues tracked, and major defects remediated before deployment

All issues and software defects discovered from source code review and application security testing should be tracked, and major issues and software defects should be remediated before production deployment.

CoverageAdmission decisionsOutcomesControl statement
Paragraph 7.2.1
Configuration management keeps accurate information about each system

The FI should implement a configuration management process to maintain accurate information about the configuration of the hardware and software that makes up each IT system — model, version, specifications and the like — so as to have visibility and effective control of its IT systems.

CoverageSupply chainControl statement
Paragraph 7.2.2
Configuration information is reviewed and verified regularly

The FI should review and verify the configuration information of its hardware and software on a regular basis to ensure it is accurate and up-to-date.

CoverageAdmission decisionsEvidence chain
Paragraph 7.3.1
Outdated and unsupported software is avoided and end-of-support watched

The FI should avoid using outdated and unsupported hardware or software, which could increase its exposure to security and stability risks, and should closely monitor end-of-support dates, as service providers typically cease providing patches — including for security vulnerabilities found after that date.

Control statementCoverage
Paragraph 7.4.1
Patches applied within a timeframe set by criticality

A patch management process should be established to ensure applicable functional and non-functional patches, such as fixes for security vulnerabilities and software bugs, are implemented within a timeframe commensurate with the criticality of the patches and of the FI's IT systems.

Control statementCoverageAdmission decisionsOutcomesIssues
Paragraph 7.5.1
Changes are assessed, tested, reviewed and approved before implementation

The FI should establish a change management process to ensure changes to information assets are assessed, tested, reviewed and approved before implementation.

Admission decisionsEvidence chain
Paragraph 7.5.7
The change process is logged

As logs contain information that facilitates investigation and troubleshooting, the FI should ensure the logging facility is enabled to record the activities performed during the change process.

Evidence chain
Paragraph 7.6.2
Traceability and integrity for code moved between environments

Controls should be implemented to maintain traceability and integrity for all software codes moved between IT environments.

Supply chainControl statementAdmission decisionsEvidence chain
Paragraph 11.3.1
Security standards outline configurations that minimise exposure

The security standards for the FI's hardware and software, such as operating systems, databases, network devices and endpoint devices, should outline the configurations that will minimise their exposure to cyber threats, and should be reviewed periodically for relevance and effectiveness.

Control statementAdmission decisions
Paragraph 11.3.2
Standards verified as applied uniformly, and deviations addressed

The FI should establish a process to verify that the standards are applied uniformly on systems and to identify deviations from them, and risks arising from deviations should be addressed in a timely manner.

Control statementAdmission decisionsTriage decisions
Paragraph 11.3.6
Only authorised software may be installed

Security measures, such as application white-listing, should be implemented to ensure only authorised software is allowed to be installed on the FI's systems.

Control statementSupply chain
Paragraph 12.1.1
Cyber-related information is collected, processed and analysed

To maintain good cyber situational awareness, the FI should establish a process to collect, process and analyse cyber-related information — cyber events, cyber threat intelligence and information on system vulnerabilities — for its relevance and potential impact to the FI's business and IT environment.

ClusterCoverageControl statement
Paragraph 12.2.2
System logs are collected, reviewed, retained and protected

A process to collect, process, review and retain system logs should be established to facilitate the FI's security monitoring operations, and these logs should be protected against unauthorised access.

Evidence chain
Paragraph 13.1.1
Regular vulnerability assessment, with risks addressed in time

The FI should establish a process to conduct regular vulnerability assessment on its IT systems to identify security vulnerabilities and ensure the risks arising from these gaps are addressed in a timely manner, at a frequency commensurate with the criticality of the IT system and the security risk to which it is exposed.

CoverageAdmission decisionsOutcomesControl statementIssues
Paragraph 13.1.2
What a vulnerability assessment must minimally cover

When performing a vulnerability assessment, the scope should minimally include vulnerability discovery, identification of weak security configurations and open network ports, and application vulnerabilities, and for web-based systems it should include checks on common web-based vulnerabilities.

CoverageControl statementAdmission decisions
Paragraph 13.6.1
A remediation process that classifies, times and governs deviations

A comprehensive remediation process should be established to track and resolve the issues identified from cyber security assessments or exercises, minimally including severity assessment and classification of an issue, a timeframe to remediate issues of different severity, and risk assessment and mitigation strategies to manage deviations from the framework.

CoverageAdmission decisionsOutcomesControl statementTriage decisionsIssues
11 clauses marked outside scope, and why
CitationClause and reason
Paragraph 6.1.3 Third party and open-source code reviewed before integration

the review and the testing happen before integration, in a source tree and a build; this control meets the result as a built image and can say what is inside it, not what was done to it beforehand

Paragraph 6.1.6 Application security validation and testing

static, dynamic and interactive testing read source code, byte code and a running application; an admission decision reads an image's components and the findings standing against them, which is a different measurement of a different thing and not a substitute for it

Paragraph 6.3.1 DevSecOps aligned with the SDLC and IT service management

alignment between a pipeline and a framework is a property of how the FI organises the work; this cluster is where the pipeline's output arrives, and it sees the artefact rather than the process that produced it

Paragraph 6.3.2 Segregation of duties across development, testing and release

segregation of duties is a statement about which people hold which permissions in a build and release system, and none of it is visible from an admission decision taken on the artefact those people produced

Paragraph 7.3.3 Management dispensation for continued use of unsupported software

a dispensation is management authorising a risk and putting a date on it, recorded in the FI's own governance; this control can show that an image with an unsupported base OS was admitted and that the policy allowed it, and the risk acceptances it does record are decisions about findings, not about a platform nobody patches any more

Paragraph 7.4.2 Patches are tested before production

a patch is tested in the FI's own environments before it is applied; this control meets the rebuilt image afterwards and can say what it no longer carries, not what was done to satisfy anybody that it was safe to apply

Paragraph 7.6.1 Segregation of duties in the software release process

who may build and who may promote is decided by the permissions in a release pipeline; this cluster is the last environment in that chain and records what arrived, not who was entitled to send it

Paragraph 11.4.1 Security standards for every component of a virtualisation solution

the components this paragraph names are the hypervisor, the host operating system and the guest operating system, all of which sit beneath the node this operator runs on; a webhook admitting a container sees none of them

Paragraph 11.4.3 Policies and standards governing virtual images and snapshots

the assets this paragraph governs are virtual machine images and their snapshots, and the Guidelines define virtualisation as the simulation of hardware; a container image shares the word and not the artefact, and the controls this operator holds over container images are reported under 7.6.2 and 11.3.6 rather than borrowed for a section about hypervisors

Paragraph 12.1.2 Intelligence services and threat information sharing

procuring a service and joining a sharing arrangement are commercial and membership decisions of the FI; that this operator reads a public catalogue of exploited vulnerabilities is reported under 12.1.1 and is not a substitute for either

Paragraph 15.1.1 An independent IT audit opinion

this document is evidence an audit reads, not the audit itself; the opinion the paragraph asks for is formed by a function that has to be independent of the controls it examines, and a control cannot audit itself

What Attestkeep produces

Evidence from records the cluster already keeps.

Nothing is filled in by hand. Each clause's answer carries a status (met, partial, gap or outside scope), a note with the period's own numbers, and the report sections those numbers come from.

Statements the mapping draws on

Each assessed clause is answered by one or more of these statements about the period's records. The same statement answers the same question under every framework, so two reports for one period cannot disagree.

  • Every image in the inventory carries a scan record9 clauses
  • A bill of materials is held for the images in service5 clauses
  • Images carrying severe findings are refused4 clauses
  • Admission refuses non-compliant workloads3 clauses
  • Every decision and administrative action is recorded3 clauses
  • Every image change is recorded against the policy that governed it3 clauses
  • Workloads name images by digest, not by a movable tag3 clauses
  • Remediation windows are declared for each severity3 clauses
  • Workload privilege is constrained at admission3 clauses
  • Accepted risks are named, justified and expire2 clauses
  • Only images of established provenance may run2 clauses
  • Images whose base OS is past end of support are refused1 clause
  • Findings are matched against a national catalogue of exploited vulnerabilities1 clause
  • Images may enter only from named registries1 clause
The package

What the report contains.

Every package carries the same sections, whatever the framework. The ones marked are those MAS TRM answers cite, with the number of clauses citing each.

More on the package

  1. Organisation
  2. Framework mapping
  3. Cluster1
  4. Control statement12
  5. Coverage12
  6. Vulnerability findings
  7. Outcomes4
  8. Admission decisions10
  9. Supply chain6
  10. Triage decisions2
  11. Break-glass events
  12. Availability
  13. Evidence chain5
  14. Deployment context
  15. Issues3
  16. Ledger
  17. Population
  18. Runtime events
  19. Producer statements (VEX)
Scope

The scope paragraph, as the report states it.

This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto the Monetary Authority of Singapore's Technology Risk Management Guidelines of 18 January 2021. The Guidelines are supervisory expectations addressed to a financial institution, not a standard anybody is certified against, and nothing here is an assessment of the FI's technology risk management framework as a whole, of its IT service management processes, or of any control it operates outside this cluster. What the period's records support is the software-facing half of a few paragraphs: which images ran, what was inside them, whether their base operating system was still supported, what was known about them when they ran, what was refused, and what was admitted with an expiry on it. Section 7.3 is answered directly, because a scan records whether an image's base OS is past end of support and the policy decides what admission does about that. Hardware and network devices, endpoint protection, the hypervisor beneath the nodes, the FI's other system logs, and every paragraph whose subject is people rather than records — the change advisory board, segregation of duties in a release pipeline, the dispensation management grants for continued use of unsupported software, the independent audit function of section 15 — are named where a reader would look for them and marked outside what a cluster observes.

Questions

About MAS TRM and Attestkeep

Is this a MAS TRM certification?

No. The package is evidence produced from your cluster's own records. It is not a certification, and no auditor is obliged to accept it. The scope paragraph on this page is the one the report itself carries.

Why are 11 of the clauses outside scope?

They ask about things one cluster's admission and scanning records cannot show. They are listed with the reason rather than left out, so whoever reads the report can see the gap is deliberate.

Which plan includes MAS TRM?

Every plan can report against it. Community and Team include one framework of your choice, Business three, Enterprise every one. Prices are on the pricing page.

How does an auditor check the package?

In a browser at attestkeep.com/verify.html, where nothing is uploaded, or with the short script on the documentation site. Neither needs us. For auditors has the details.

Install it yourself.

Create an account, confirm your e-mail with the code we send, take the free Community key from the Licenses page, and install with Helm.

Create an account