MAS Technology Risk Management Guidelines (2021)
Attestkeep rattache ce que l'admission control et le scan d'images de votre cluster ont enregistré sur une période à 30 exigences (source : Monetary Authority of Singapore, 18 janvier 2021). 19 sont évaluées sur ces enregistrements ; 11 sont marquées hors périmètre, chacune avec la raison.
19 exigences à portée de cluster.
Références et titres tels que le rapport les imprime, c'est-à-dire en anglais. Ouvrez une exigence pour lire ce qu'elle demande, reformulé au plus près du texte de l'instrument.
Technology Risk Management Guidelines
Monetary Authority of Singapore, 18 janvier 2021
Sections 3.3 (actifs informationnels), 6.1 et 6.3 (sécurité applicative et DevSecOps), 7.2 à 7.6 (gestion de la configuration, du renouvellement technologique, des correctifs, des changements et des releases logicielles), 11.3 et 11.4 (sécurité des systèmes et de la virtualisation), 12.1 et 12.2 (cyber threat intelligence et surveillance des événements), 13.1 et 13.6 (évaluation et correction des vulnérabilités) et 15 (audit informatique)
| Référence | Exigence | Sections du rapport |
|---|---|---|
| Paragraph 3.3.1 | Information asset management practicesPour avoir une vue exacte et complète de son environnement informatique, l'établissement financier devrait mettre en place des pratiques de gestion des actifs informationnels : identification des actifs qui soutiennent son activité et la fourniture de services financiers, classement de chaque actif selon sa classification de sécurité ou sa criticité, propriété des actifs et rôles et responsabilités du personnel qui les gère, ainsi que politiques, normes et procédures pour gérer les actifs selon ce classement. | CoverageSupply chain |
| Paragraph 3.3.2 | An inventory of information assets, reviewed and kept currentL'établissement financier devrait tenir un inventaire de tous ses actifs informationnels, le réexaminer périodiquement et le mettre à jour à chaque changement. | CoverageSupply chain |
| Paragraph 6.1.4 | Tracking vulnerabilities in third party and open-source componentsPour corriger les vulnérabilités en temps utile, l'établissement financier devrait suivre les mises à jour et les vulnérabilités signalées du code tiers et open source intégré à ses logiciels. | Supply chainCoverage |
| Paragraph 6.1.7 | Issues tracked, and major defects remediated before deploymentTous les problèmes et défauts logiciels découverts lors de la revue du code source et des tests de sécurité applicative devraient être suivis, et les problèmes et défauts majeurs corrigés avant le déploiement en production. | CoverageAdmission decisionsOutcomesControl statement |
| Paragraph 7.2.1 | Configuration management keeps accurate information about each systemL'établissement financier devrait mettre en place un processus de gestion de la configuration qui tienne des informations exactes sur la configuration du matériel et des logiciels de chaque système informatique (modèle, version, spécifications, etc.), afin d'avoir une visibilité et un contrôle effectif de ses systèmes. | CoverageSupply chainControl statement |
| Paragraph 7.2.2 | Configuration information is reviewed and verified regularlyL'établissement financier devrait réexaminer et vérifier régulièrement les informations de configuration de son matériel et de ses logiciels pour qu'elles restent exactes et à jour. | CoverageAdmission decisionsEvidence chain |
| Paragraph 7.3.1 | Outdated and unsupported software is avoided and end-of-support watchedL'établissement financier devrait éviter le matériel et les logiciels obsolètes ou non supportés, qui peuvent accroître son exposition aux risques de sécurité et de stabilité, et surveiller de près les dates de fin de support, car les fournisseurs cessent en général de livrer des correctifs après cette date, y compris pour les vulnérabilités de sécurité découvertes ensuite. | Control statementCoverage |
| Paragraph 7.4.1 | Patches applied within a timeframe set by criticalityUn processus de gestion des correctifs devrait garantir que les correctifs fonctionnels et non fonctionnels applicables, comme les corrections de vulnérabilités de sécurité et de bugs, sont appliqués dans un délai proportionné à la criticité des correctifs et des systèmes de l'établissement. | Control statementCoverageAdmission decisionsOutcomesIssues |
| Paragraph 7.5.1 | Changes are assessed, tested, reviewed and approved before implementationL'établissement financier devrait mettre en place un processus de gestion des changements afin que les changements des actifs informationnels soient évalués, testés, revus et approuvés avant mise en œuvre. | Admission decisionsEvidence chain |
| Paragraph 7.5.7 | The change process is loggedComme les journaux facilitent les investigations et le dépannage, l'établissement financier devrait s'assurer que la journalisation est activée pour enregistrer les activités menées pendant le processus de changement. | Evidence chain |
| Paragraph 7.6.2 | Traceability and integrity for code moved between environmentsDes contrôles devraient maintenir la traçabilité et l'intégrité de tout code logiciel déplacé entre environnements informatiques. | Supply chainControl statementAdmission decisionsEvidence chain |
| Paragraph 11.3.1 | Security standards outline configurations that minimise exposureLes normes de sécurité du matériel et des logiciels de l'établissement, comme les systèmes d'exploitation, bases de données, équipements réseau et terminaux, devraient décrire les configurations qui réduisent au minimum leur exposition aux cybermenaces, et être réexaminées périodiquement pour leur pertinence et leur efficacité. | Control statementAdmission decisions |
| Paragraph 11.3.2 | Standards verified as applied uniformly, and deviations addressedL'établissement financier devrait mettre en place un processus pour vérifier que les normes sont appliquées uniformément aux systèmes et repérer les écarts ; les risques liés aux écarts devraient être traités en temps utile. | Control statementAdmission decisionsTriage decisions |
| Paragraph 11.3.6 | Only authorised software may be installedDes mesures de sécurité, comme une liste blanche d'applications, devraient garantir que seuls les logiciels autorisés peuvent être installés sur les systèmes de l'établissement. | Control statementSupply chain |
| Paragraph 12.1.1 | Cyber-related information is collected, processed and analysedPour une bonne connaissance de la situation cyber, l'établissement financier devrait mettre en place un processus de collecte, de traitement et d'analyse des informations cyber (événements, cyber threat intelligence et informations sur les vulnérabilités des systèmes) selon leur pertinence et leur impact potentiel sur son activité et son environnement informatique. | ClusterCoverageControl statement |
| Paragraph 12.2.2 | System logs are collected, reviewed, retained and protectedUn processus de collecte, de traitement, de revue et de conservation des journaux système devrait soutenir la surveillance de sécurité de l'établissement, et ces journaux devraient être protégés contre l'accès non autorisé. | Evidence chain |
| Paragraph 13.1.1 | Regular vulnerability assessment, with risks addressed in timeL'établissement financier devrait mettre en place un processus d'évaluation régulière des vulnérabilités de ses systèmes pour repérer les failles de sécurité et traiter à temps les risques qui en découlent, à une fréquence proportionnée à la criticité du système et au risque de sécurité auquel il est exposé. | CoverageAdmission decisionsOutcomesControl statementIssues |
| Paragraph 13.1.2 | What a vulnerability assessment must minimally coverUne évaluation des vulnérabilités devrait au minimum couvrir la découverte des vulnérabilités, l'identification des configurations de sécurité faibles et des ports réseau ouverts, et les vulnérabilités applicatives ; pour les systèmes web, elle devrait inclure les vulnérabilités web courantes. | CoverageControl statementAdmission decisions |
| Paragraph 13.6.1 | A remediation process that classifies, times and governs deviationsUn processus complet de correction devrait suivre et résoudre les problèmes identifiés lors d'évaluations ou d'exercices de cybersécurité, avec au minimum l'évaluation et le classement de la gravité, un délai de correction par gravité, et l'évaluation des risques et des stratégies d'atténuation pour gérer les écarts par rapport au framework. | CoverageAdmission decisionsOutcomesControl statementTriage decisionsIssues |
11 exigences hors périmètre, et pourquoi
| Référence | Exigence et raison |
|---|---|
| Paragraph 6.1.3 | Third party and open-source code reviewed before integration La revue et les tests ont lieu avant l'intégration, dans une arborescence de sources et un build ; ce contrôle rencontre le résultat sous forme d'image construite et peut dire ce qu'elle contient, pas ce qu'on lui a fait auparavant. |
| Paragraph 6.1.6 | Application security validation and testing Les tests statiques, dynamiques et interactifs lisent le code source, le bytecode et une application en cours d'exécution ; une décision d'admission lit les composants d'une image et les vulnérabilités qui les visent, c'est une autre mesure, portant sur un autre objet, et elle ne les remplace pas. |
| Paragraph 6.3.1 | DevSecOps aligned with the SDLC and IT service management L'alignement entre un pipeline et un framework dépend de la façon dont l'établissement organise le travail ; ce cluster est l'endroit où arrive la production du pipeline, et il voit l'artefact plutôt que le processus qui l'a produit. |
| Paragraph 6.3.2 | Segregation of duties across development, testing and release La séparation des tâches décrit quelles personnes détiennent quelles permissions dans un système de build et de release, et rien de cela n'est visible dans une décision d'admission prise sur l'artefact que ces personnes ont produit. |
| Paragraph 7.3.3 | Management dispensation for continued use of unsupported software Une dérogation, c'est la direction qui autorise un risque et lui fixe une échéance, enregistrée dans la gouvernance propre de l'établissement ; ce contrôle peut montrer qu'une image dont l'OS de base n'est plus supporté a été admise et que la policy l'autorisait, et les acceptations de risque qu'il enregistre portent sur des vulnérabilités, pas sur une plateforme que plus personne ne corrige. |
| Paragraph 7.4.2 | Patches are tested before production Un correctif est testé dans les environnements propres de l'établissement avant d'être appliqué ; ce contrôle rencontre ensuite l'image reconstruite et peut dire ce qu'elle ne contient plus, pas ce qui a été fait pour s'assurer qu'on pouvait l'appliquer sans risque. |
| Paragraph 7.6.1 | Segregation of duties in the software release process Qui peut construire et qui peut promouvoir dépend des permissions d'un pipeline de release ; ce cluster est le dernier environnement de cette chaîne et enregistre ce qui est arrivé, pas qui avait le droit de l'envoyer. |
| Paragraph 11.4.1 | Security standards for every component of a virtualisation solution Les composants que nomme ce paragraphe sont l'hyperviseur, le système d'exploitation hôte et le système d'exploitation invité, tous situés sous le node où tourne cet operator ; un webhook qui admet un container n'en voit aucun. |
| Paragraph 11.4.3 | Policies and standards governing virtual images and snapshots Les actifs que régit ce paragraphe sont les images de machines virtuelles et leurs snapshots, et les lignes directrices définissent la virtualisation comme la simulation de matériel ; une image de container partage le mot, pas l'artefact, et les contrôles que cet operator exerce sur les images de container sont rapportés sous 7.6.2 et 11.3.6 plutôt qu'empruntés pour une section sur les hyperviseurs. |
| Paragraph 12.1.2 | Intelligence services and threat information sharing Acheter un service et rejoindre un dispositif de partage sont des décisions commerciales et d'adhésion de l'établissement ; le fait que cet operator lise un catalogue public de vulnérabilités exploitées est rapporté sous 12.1.1 et ne remplace ni l'un ni l'autre. |
| Paragraph 15.1.1 | An independent IT audit opinion Ce document est une preuve qu'un audit lit, pas l'audit lui-même ; l'opinion que demande le paragraphe est formée par une fonction qui doit être indépendante des contrôles qu'elle examine, et un contrôle ne peut pas s'auditer lui-même. |
Preuves tirées des journaux que tient déjà le cluster.
Rien n'est rempli à la main. La réponse à chaque exigence porte un statut (satisfaite, partielle, écart ou hors périmètre), une note avec les chiffres de la période et les sections du rapport d'où viennent ces chiffres.
Ce sur quoi s'appuie le mapping
Chaque exigence évaluée reçoit sa réponse d'une ou plusieurs de ces affirmations sur les enregistrements de la période. La même affirmation répond à la même question dans tous les frameworks : deux rapports sur une même période ne peuvent pas diverger.
- Chaque image de l'inventaire a un enregistrement de scan9 exigences
- Un SBOM est conservé pour les images en service5 exigences
- Les images portant des vulnérabilités graves sont refusées4 exigences
- L'admission refuse les workloads non conformes3 exigences
- Chaque décision et chaque action d'administration est enregistrée3 exigences
- Chaque changement d'image est enregistré avec la policy qui le régissait3 exigences
- Les workloads désignent les images par digest, pas par un tag mobile3 exigences
- Un délai de correction est déclaré pour chaque sévérité3 exigences
- Les privilèges des workloads sont limités à l'admission3 exigences
- Les risques acceptés sont nommés, justifiés et expirent2 exigences
- Seules les images de provenance établie peuvent tourner2 exigences
- Les images dont l'OS de base n'est plus supporté sont refusées1 exigence
- Les vulnérabilités trouvées sont croisées avec un catalogue national de vulnérabilités exploitées1 exigence
- Les images n'entrent que depuis des registries désignés1 exigence
Ce que contient le rapport.
Chaque paquet contient les mêmes sections, quel que soit le framework. Les sections signalées sont celles que citent les réponses pour MAS TRM, avec le nombre d'exigences qui renvoient à chacune.
- 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)
Le paragraphe de périmètre, tel que le rapport l'imprime (en anglais).
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.
Sur MAS TRM
Est-ce une certification selon MAS TRM ?
Non. Le paquet est une preuve produite à partir des enregistrements de votre cluster. Ce n'est pas une certification, et aucun auditeur n'est tenu de l'accepter. Le paragraphe de périmètre de cette page est celui que porte le rapport lui-même.
Pourquoi 11 exigences sont-elles hors périmètre ?
Elles portent sur des choses que les enregistrements d'admission et de scan d'un cluster ne peuvent pas montrer. Elles figurent avec la raison au lieu d'être omises, pour que le lecteur du rapport voie que l'exclusion est voulue.
Quel plan inclut MAS TRM ?
Tous les plans peuvent produire un rapport selon ce framework. Community et Team incluent un framework au choix, Business trois, Enterprise tous. Les prix sont sur la page des tarifs.
Comment un auditeur vérifie-t-il le paquet ?
Dans un navigateur, sur attestkeep.com/verify.html, où rien n'est envoyé, ou avec le court script du site de documentation. Aucun des deux n'a besoin de nous. La page Pour les auditeurs donne le détail.
Installez-le vous-même.
Créez un compte, confirmez votre e-mail avec le code envoyé, prenez la clé Community gratuite sur la page Licences et installez avec Helm.
Créer un compte