Regional · Singapur

MAS Technology Risk Management Guidelines (2021)

Was Admission Control und Image-Scan Ihres Clusters in einem Zeitraum erfasst haben, ordnet Attestkeep 30 Anforderungen zu (Quelle: Monetary Authority of Singapore, 18. Januar 2021). 19 davon werden aus diesen Einträgen bewertet; 11 sind als außerhalb des Umfangs markiert, jede mit Begründung.

Konto anlegen Wie ein Paket entsteht

Was das Framework verlangt

19 Anforderungen aus Clustersicht.

Fundstellen und Titel so, wie der Bericht sie druckt, also auf Englisch. Öffnen Sie eine Anforderung, um zu lesen, was sie verlangt – nah am Wortlaut des Regelwerks wiedergegeben.

Technology Risk Management Guidelines

Monetary Authority of Singapore, 18. Januar 2021

Abschnitte 3.3 (Informationswerte), 6.1 und 6.3 (Anwendungssicherheit und DevSecOps), 7.2 bis 7.6 (Konfiguration, Technologieerneuerung, Patch-, Änderungs- und Software-Release-Management), 11.3 und 11.4 (System- und Virtualisierungssicherheit), 12.1 und 12.2 (Cyber Threat Intelligence und Ereignisüberwachung), 13.1 und 13.6 (Schwachstellenbewertung und Behebung) sowie 15 (IT-Audit)

Fundstelle	Anforderung	Berichtsabschnitte
Paragraph 3.3.1	Information asset management practices Um ein genaues und vollständiges Bild seiner IT-Betriebsumgebung zu haben, soll das Finanzinstitut Praktiken für das Management von Informationswerten einführen: die Identifizierung der Informationswerte, die sein Geschäft und die Erbringung von Finanzdienstleistungen stützen, die Einstufung jedes Werts nach Sicherheitsklassifizierung oder Kritikalität, die Eigentümerschaft und die Rollen und Verantwortlichkeiten der Mitarbeitenden, die sie verwalten, sowie Richtlinien, Standards und Verfahren, um die Werte entsprechend dieser Einstufung zu verwalten.	CoverageSupply chain
Paragraph 3.3.2	An inventory of information assets, reviewed and kept current Das Finanzinstitut soll ein Inventar aller seiner Informationswerte führen, es regelmäßig überprüfen und bei jeder Änderung aktualisieren.	CoverageSupply chain
Paragraph 6.1.4	Tracking vulnerabilities in third party and open-source components Damit Schwachstellen zeitnah behoben werden können, soll das Finanzinstitut Updates und gemeldete Schwachstellen des Drittanbieter- und Open-Source-Codes verfolgen, der in seine Software eingeht.	Supply chainCoverage
Paragraph 6.1.7	Issues tracked, and major defects remediated before deployment Alle bei Quellcode-Prüfung und Anwendungssicherheitstests gefundenen Probleme und Softwarefehler sollen verfolgt werden, und schwerwiegende Probleme und Fehler sollen vor dem Produktiveinsatz behoben werden.	CoverageAdmission decisionsOutcomesControl statement
Paragraph 7.2.1	Configuration management keeps accurate information about each system Das Finanzinstitut soll einen Konfigurationsmanagementprozess einführen, der genaue Informationen über die Konfiguration der Hardware und Software jedes IT-Systems vorhält, etwa Modell, Version und Spezifikationen, um Einblick in seine IT-Systeme und wirksame Kontrolle über sie zu haben.	CoverageSupply chainControl statement
Paragraph 7.2.2	Configuration information is reviewed and verified regularly Das Finanzinstitut soll die Konfigurationsinformationen seiner Hardware und Software regelmäßig überprüfen und verifizieren, damit sie genau und aktuell sind.	CoverageAdmission decisionsEvidence chain
Paragraph 7.3.1	Outdated and unsupported software is avoided and end-of-support watched Das Finanzinstitut soll veraltete und nicht mehr unterstützte Hardware oder Software meiden, die Sicherheits- und Stabilitätsrisiken erhöhen kann, und Support-Enddaten genau beobachten, da Anbieter danach meist keine Patches mehr liefern, auch nicht für später gefundene Sicherheitsschwachstellen.	Control statementCoverage
Paragraph 7.4.1	Patches applied within a timeframe set by criticality Ein Patch-Management-Prozess soll sicherstellen, dass zutreffende funktionale und nichtfunktionale Patches, etwa Korrekturen von Sicherheitsschwachstellen und Softwarefehlern, in einem Zeitraum eingespielt werden, der der Kritikalität der Patches und der IT-Systeme des Finanzinstituts entspricht.	Control statementCoverageAdmission decisionsOutcomesIssues
Paragraph 7.5.1	Changes are assessed, tested, reviewed and approved before implementation Das Finanzinstitut soll einen Änderungsmanagementprozess einführen, damit Änderungen an Informationswerten vor der Umsetzung bewertet, getestet, geprüft und genehmigt werden.	Admission decisionsEvidence chain
Paragraph 7.5.7	The change process is logged Da Protokolle Informationen für Untersuchung und Fehlersuche enthalten, soll das Finanzinstitut sicherstellen, dass die Protokollierung aktiviert ist und die Tätigkeiten während des Änderungsprozesses festhält.	Evidence chain
Paragraph 7.6.2	Traceability and integrity for code moved between environments Es sollen Kontrollen umgesetzt werden, die Nachvollziehbarkeit und Integrität für jeden Softwarecode wahren, der zwischen IT-Umgebungen bewegt wird.	Supply chainControl statementAdmission decisionsEvidence chain
Paragraph 11.3.1	Security standards outline configurations that minimise exposure Die Sicherheitsstandards für Hardware und Software des Finanzinstituts, etwa Betriebssysteme, Datenbanken, Netzwerkgeräte und Endgeräte, sollen die Konfigurationen beschreiben, die ihre Angriffsfläche für Cyberbedrohungen minimieren, und regelmäßig auf Relevanz und Wirksamkeit überprüft werden.	Control statementAdmission decisions
Paragraph 11.3.2	Standards verified as applied uniformly, and deviations addressed Das Finanzinstitut soll einen Prozess einführen, der prüft, dass die Standards auf allen Systemen einheitlich angewendet werden, und Abweichungen davon erkennt; Risiken aus Abweichungen sollen zeitnah behandelt werden.	Control statementAdmission decisionsTriage decisions
Paragraph 11.3.6	Only authorised software may be installed Sicherheitsmaßnahmen wie Application Whitelisting sollen sicherstellen, dass auf den Systemen des Finanzinstituts nur autorisierte Software installiert werden darf.	Control statementSupply chain
Paragraph 12.1.1	Cyber-related information is collected, processed and analysed Für ein gutes Cyber-Lagebild soll das Finanzinstitut einen Prozess einführen, der cyberbezogene Informationen sammelt, verarbeitet und analysiert – Cyberereignisse, Cyber Threat Intelligence und Informationen über Systemschwachstellen –, und zwar auf ihre Relevanz und mögliche Auswirkung für das Geschäft und die IT-Umgebung des Finanzinstituts.	ClusterCoverageControl statement
Paragraph 12.2.2	System logs are collected, reviewed, retained and protected Ein Prozess zum Sammeln, Verarbeiten, Prüfen und Aufbewahren von Systemprotokollen soll die Sicherheitsüberwachung des Finanzinstituts unterstützen, und diese Protokolle sollen vor unbefugtem Zugriff geschützt sein.	Evidence chain
Paragraph 13.1.1	Regular vulnerability assessment, with risks addressed in time Das Finanzinstitut soll einen Prozess für regelmäßige Schwachstellenbewertungen seiner IT-Systeme einführen, um Sicherheitsschwachstellen zu erkennen und die daraus entstehenden Risiken zeitnah zu behandeln, in einer Häufigkeit, die der Kritikalität des Systems und seinem Sicherheitsrisiko entspricht.	CoverageAdmission decisionsOutcomesControl statementIssues
Paragraph 13.1.2	What a vulnerability assessment must minimally cover Eine Schwachstellenbewertung soll mindestens die Suche nach Schwachstellen, die Erkennung schwacher Sicherheitskonfigurationen und offener Netzwerkports sowie Anwendungsschwachstellen umfassen; bei webbasierten Systemen auch Prüfungen auf gängige Web-Schwachstellen.	CoverageControl statementAdmission decisions
Paragraph 13.6.1	A remediation process that classifies, times and governs deviations Ein umfassender Behebungsprozess soll die in Cybersicherheitsbewertungen oder -übungen gefundenen Probleme verfolgen und lösen und mindestens Folgendes umfassen: Bewertung und Einstufung des Schweregrads, einen Zeitrahmen für die Behebung je Schweregrad sowie Risikobewertung und Minderungsstrategien für Abweichungen vom Framework.	CoverageAdmission decisionsOutcomesControl statementTriage decisionsIssues

11 Anforderungen außerhalb des Umfangs, und warum

Fundstelle	Anforderung und Grund
Paragraph 6.1.3	Third party and open-source code reviewed before integration Prüfung und Tests finden vor der Integration statt, in einem Quellbaum und einem Build; diese Kontrolle trifft das Ergebnis als gebautes Image an und kann sagen, was darin steckt, nicht was vorher damit geschah.
Paragraph 6.1.6	Application security validation and testing Statische, dynamische und interaktive Tests lesen Quellcode, Bytecode und eine laufende Anwendung; eine Admission-Entscheidung liest die Komponenten eines Images und die Befunde, die gegen sie vorliegen – eine andere Messung an einem anderen Gegenstand und kein Ersatz dafür.
Paragraph 6.3.1	DevSecOps aligned with the SDLC and IT service management Die Abstimmung zwischen einer Pipeline und einem Framework ist eine Eigenschaft der Arbeitsorganisation des Finanzinstituts; dieser Cluster ist der Ort, an dem das Ergebnis der Pipeline ankommt, und er sieht das Artefakt, nicht den Prozess, der es erzeugt hat.
Paragraph 6.3.2	Segregation of duties across development, testing and release Funktionstrennung ist eine Aussage darüber, welche Personen in einem Build- und Release-System welche Berechtigungen haben, und nichts davon ist in einer Admission-Entscheidung über das Artefakt dieser Personen sichtbar.
Paragraph 7.3.3	Management dispensation for continued use of unsupported software Eine Ausnahmegenehmigung bedeutet, dass das Management ein Risiko genehmigt und befristet, festgehalten in der eigenen Governance des Finanzinstituts; diese Kontrolle kann zeigen, dass ein Image mit nicht mehr unterstütztem Basis-OS zugelassen wurde und die Policy das erlaubte, und die Risikoakzeptanzen, die sie festhält, sind Entscheidungen über Befunde, nicht über eine Plattform, die niemand mehr patcht.
Paragraph 7.4.2	Patches are tested before production Ein Patch wird in den eigenen Umgebungen des Finanzinstituts getestet, bevor er eingespielt wird; diese Kontrolle trifft das neu gebaute Image danach an und kann sagen, was es nicht mehr enthält, nicht was getan wurde, um jemanden davon zu überzeugen, dass das Einspielen sicher war.
Paragraph 7.6.1	Segregation of duties in the software release process Wer bauen und wer freigeben darf, entscheiden die Berechtigungen in einer Release-Pipeline; dieser Cluster ist die letzte Umgebung in dieser Kette und hält fest, was ankam, nicht wer es schicken durfte.
Paragraph 11.4.1	Security standards for every component of a virtualisation solution Die Komponenten, die dieser Absatz nennt, sind Hypervisor, Host-Betriebssystem und Gast-Betriebssystem, alle unterhalb des Nodes, auf dem dieser Operator läuft; ein Webhook, der einen Container zulässt, sieht keine davon.
Paragraph 11.4.3	Policies and standards governing virtual images and snapshots Die Werte, die dieser Absatz regelt, sind Images virtueller Maschinen und ihre Snapshots, und die Leitlinien definieren Virtualisierung als Simulation von Hardware; ein Container-Image teilt das Wort, nicht das Artefakt, und die Kontrollen dieses Operators über Container-Images werden unter 7.6.2 und 11.3.6 berichtet, statt für einen Abschnitt über Hypervisoren herangezogen zu werden.
Paragraph 12.1.2	Intelligence services and threat information sharing Einen Dienst zu beziehen und einem Austauschverbund beizutreten sind kaufmännische und Mitgliedschaftsentscheidungen des Finanzinstituts; dass dieser Operator einen öffentlichen Katalog ausgenutzter Schwachstellen liest, wird unter 12.1.1 berichtet und ersetzt keines von beiden.
Paragraph 15.1.1	An independent IT audit opinion Dieses Dokument ist ein Nachweis, den ein Audit liest, nicht das Audit selbst; das Urteil, das der Absatz verlangt, bildet eine Funktion, die von den geprüften Kontrollen unabhängig sein muss, und eine Kontrolle kann sich nicht selbst auditieren.

Was Attestkeep erzeugt

Nachweise aus Einträgen, die der Cluster ohnehin führt.

Nichts wird von Hand ausgefüllt. Jede Antwort zu einer Anforderung trägt einen Status (erfüllt, teilweise, Lücke oder außerhalb des Umfangs), eine Notiz mit den Zahlen des Zeitraums und die Berichtsabschnitte, aus denen diese Zahlen stammen.

Worauf sich das Mapping stützt

Jede bewertete Anforderung wird durch eine oder mehrere dieser Aussagen über die Einträge des Zeitraums beantwortet. Dieselbe Aussage beantwortet dieselbe Frage in jedem Framework; zwei Berichte über denselben Zeitraum können sich daher nicht widersprechen.

Jedes Image im Bestand hat einen Scan-Eintrag9 Anforderungen
Für die laufenden Images liegt ein SBOM vor5 Anforderungen
Images mit schweren Befunden werden abgelehnt4 Anforderungen
Admission lehnt nicht konforme Workloads ab3 Anforderungen
Jede Entscheidung und jede administrative Aktion wird festgehalten3 Anforderungen
Jede Image-Änderung wird zusammen mit der Policy festgehalten, die für sie galt3 Anforderungen
Workloads referenzieren Images per Digest, nicht per verschiebbarem Tag3 Anforderungen
Für jeden Schweregrad ist ein Behebungsfenster festgelegt3 Anforderungen
Workload-Privilegien werden bei der Admission begrenzt3 Anforderungen
Akzeptierte Risiken sind benannt, begründet und laufen ab2 Anforderungen
Nur Images mit nachgewiesener Herkunft dürfen laufen2 Anforderungen
Images, deren Basis-OS keinen Support mehr hat, werden abgelehnt1 Anforderung
Befunde werden mit einem nationalen Katalog ausgenutzter Schwachstellen abgeglichen1 Anforderung
Images kommen nur aus benannten Registries1 Anforderung

Das Paket

Was der Bericht enthält.

Jedes Paket enthält dieselben Abschnitte, unabhängig vom Framework. Markiert sind die, auf die sich die Antworten zu MAS TRM stützen, jeweils mit der Zahl der Anforderungen, die auf sie verweisen.

Mehr zum Paket

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)

Umfang

Geltungsbereich, wörtlich aus dem Bericht (Englisch).

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.

Fragen

Fragen zu MAS TRM

Ist das eine Zertifizierung nach MAS TRM?

Nein. Das Paket ist ein Nachweis aus den clustereigenen Einträgen. Es ist keine Zertifizierung, und kein Auditor muss es anerkennen. Der Absatz zum Geltungsbereich auf dieser Seite ist derselbe, den auch der Bericht enthält.

Warum liegen 11 Anforderungen außerhalb des Umfangs?

Sie fragen nach Dingen, die die Admission- und Scan-Einträge eines einzelnen Clusters nicht zeigen können. Sie werden mit Begründung aufgeführt statt weggelassen, damit jeder Leser des Berichts sieht, dass der Ausschluss bewusst ist.

Welcher Plan enthält MAS TRM?

Jeder Plan kann danach berichten. Community und Team enthalten 1 Framework Ihrer Wahl, Business 3, Enterprise alle. Die Preise stehen auf der Preisseite.

Wie prüft ein Auditor das Paket?

Im Browser unter attestkeep.com/verify.html, wo nichts hochgeladen wird, oder mit dem kurzen Skript auf der Dokumentationsseite. Beides kommt ohne uns aus. Einzelheiten stehen unter Für Auditoren.

Selbst installieren.

Konto anlegen, die E-Mail mit dem zugesandten Code bestätigen, den kostenlosen Community-Schlüssel auf der Seite Licences holen und mit Helm installieren.

Konto anlegen