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.
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)
| Citation | Clause | Report sections |
|---|---|---|
| Paragraph 3.3.1 |
Information asset management practicesTo 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 currentThe 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 componentsTo 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 deploymentAll 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 systemThe 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 regularlyThe 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 watchedThe 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 criticalityA 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 implementationThe 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 loggedAs 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 environmentsControls 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 exposureThe 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 addressedThe 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 installedSecurity 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 analysedTo 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 protectedA 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 timeThe 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 coverWhen 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 deviationsA 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
| Citation | Clause 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 |
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
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.
- Organisation
- Framework mapping
- Cluster1
- Control statement12
- Coverage12
- Vulnerability findings
- Outcomes4
- Admission decisions10
- Supply chain6
- Triage decisions2
- Break-glass events
- Availability
- Evidence chain5
- Deployment context
- Issues3
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
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.
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