MAS TRM penetration testing requirements — what section 13 of the Technology Risk Management Guidelines expects

The Technology Risk Management Guidelines were revised in January 2021 and are addressed to financial institutions (FIs) supervised by the Monetary Authority of Singapore. Section 2 explains how they work:

• Paragraph 2.2: the extent and degree to which an FI implements the Guidelines should be commensurate with the level of risk and complexity of its financial services and the technologies that support them, and the degree of observance with the spirit of the Guidelines is an area of consideration by MAS when it supervises the FI.
• Paragraph 2.3: the Guidelines provide general guidance and do not replace legislation; they are read together with the relevant acts, subsidiary legislation, and the directions, notices and codes that MAS issues.

So nothing in section 13 is a statutory duty on its own, and the text uses “should” and “is expected to”. In practice, a supervisor who finds that internet-facing systems have not been penetration tested for two years will read that against paragraph 13.2.4, and it is up to the FI to explain why its approach still meets the spirit of the Guidelines.

The binding layer is in MAS notices. For banks, Notice FSM-N06 on Cyber Hygiene, issued on 9 May 2024 under section 29(1) of the Financial Services and Markets Act 2022, took effect on 10 May 2024; Notice 655, which it replaces, was cancelled from the same date. FSM-N06 uses “must” and covers six practices: securing administrative accounts, applying security patches within a timeframe commensurate with the risk posed by each vulnerability (with compensating controls where no patch exists), a written set of security standards for every system, network perimeter controls, malware protection, and multi-factor authentication for administrative accounts on critical systems and for accounts used to access customer information over the internet.

FSM-N06 does not mention penetration testing. It does require patch timeframes that follow the risk of each vulnerability, which is hard to justify without knowing which vulnerabilities are exploitable in your environment. If you hold a different MAS licence, check which cyber hygiene notice applies to it.

Section 13, Cyber Security Assessment, has six parts.

• 13.1.1 Vulnerability assessment: a process to conduct regular VA on IT systems, to identify security vulnerabilities and address the resulting risk in a timely manner. The frequency should be commensurate with the criticality of the system and the security risk it is exposed to.
• 13.1.2 VA scope: at a minimum, vulnerability discovery, identification of weak security configurations, open network ports and application vulnerabilities; for web-based systems, checks on common web-based vulnerabilities.
• 13.2.1 Penetration testing: PT to obtain an in-depth evaluation of the FI's cyber security defences, with a combination of blackbox and greybox testing for online financial services. The footnote defines blackbox as testing with no prior knowledge except IP address ranges and known URLs, and greybox as testing with credentials, where the assessor is authenticated with the same rights as a normal customer.
• 13.2.2 Bug bounty: an FI may consider a bug bounty programme to complement its PT.
• 13.2.3 Production: PT should be conducted on the production environment for a more accurate assessment, with proper safeguards in place.
• 13.2.4 Frequency: set by factors such as system criticality and exposure to cyber risk. For systems directly accessible from the Internet, the FI is expected to conduct PT at least once annually or whenever these systems undergo major changes or updates.
• 13.3 Cyber exercises: regular scenario-based exercises, such as social engineering, table-top or cyber range exercises, to validate response, recovery and communication plans, involving senior management, business functions, service providers and technical staff as relevant.
• 13.4 Adversarial attack simulation exercise: an exercise to test and validate the effectiveness of cyber defence and response against prevalent threats. Objectives, scope and rules of engagement are defined before it starts, and it runs in a controlled manner under close supervision so that the red team does not disrupt production systems.
• 13.5 Intelligence-based scenario design: scenarios based on challenging but plausible threats, optionally designed with threat intelligence on the actors and the tactics, techniques and procedures most likely to be used against the FI.
• 13.6 Remediation management: a process to track and resolve issues from assessments and exercises that includes, at a minimum, severity assessment and classification, a timeframe to remediate issues of each severity, and a risk assessment and mitigation strategy for deviations.

The footnotes adapt the definitions of PT and red teaming from the Association of Banks in Singapore (ABS) Penetration Testing Guidelines of 2015 and its Red Team Adversarial Attack Simulation Exercise guidelines of 2018. Section 6.1 adds a separate stream: application security testing of the FI's own software, using a mix of static, dynamic and interactive methods.

Written in the Guidelines:

• A VA process with a defined minimum scope, at a risk-based frequency.
• PT on production with safeguards, and black-box plus grey-box testing for online financial services.
• PT at least once a year, and after major changes or updates, for systems directly accessible from the Internet.
• Cyber exercises and adversarial attack simulation exercises with rules of engagement.
• A remediation process with severity-based timeframes and a documented way to handle deviations.

Not written in section 13:

• A frequency for VA, for PT of internal systems, or for red teaming. These follow from criticality and exposure, and you must be able to explain the choice.
• A requirement that PT be performed by an external firm or a certified tester. The Guidelines ask for an IT audit that gives the board an independent and objective opinion, with auditors who have the requisite competency (15.1.1 and 15.1.4); for testing they ask for an in-depth evaluation, not for a particular kind of tester. Whether an internal team or an external firm runs the test is your decision, and the report has to show the depth 13.2.1 asks for.
• A specific methodology or scoring system.

Note what grey-box means here. For online financial services the Guidelines define it as testing with the rights of a normal customer, so the authenticated test 13.2.1 asks for is the one a fraudster with a stolen or newly opened account would run. A test from an employee workstation answers a different question, and a reasonable one to add for internal critical systems; see black-box vs gray-box testing.

1. List everything directly accessible from the Internet, including the APIs behind mobile and web channels. These systems carry the one explicit floor in section 13, so the list is what an examiner will compare your PT dates against.
2. Define “major change” in change management so that a release, a new integration or an infrastructure move on an internet-facing system triggers a test automatically, instead of waiting for the next annual cycle.
3. Set VA frequency by tier (for example internet-facing, internal critical, other) and write down why each tier gets its interval, with reference to 13.1.1.
4. Test online services both ways: black-box from outside and grey-box with customer credentials. For internal critical systems add a test with the access of a standard employee.
5. Write the production safeguards down: approved windows, rollback plans, stop conditions and named contacts. 13.2.3 asks for PT on production, and the safeguards are what make that acceptable to operations.
6. Plan the exercises: which scenario-based cyber exercises and which adversarial attack simulation you will run, with threat-based scenarios and rules of engagement agreed before they start.
7. Close the loop under 13.6: severity classes, a remediation timeframe per class, a deviation process with risk assessment, and a re-test that confirms each fix.

• VA records showing the scope 13.1.2 lists: vulnerability discovery, weak configurations, open ports, application vulnerabilities and, for web systems, common web vulnerabilities.
• PT reports with date, scope, test type (black-box or grey-box), the environment tested and the safeguards applied on production.
• The inventory of internet-facing systems with the date of the last PT and of each change-triggered PT.
• Exercise records: scenarios, rules of engagement, participants and outcomes of cyber exercises and adversarial attack simulations.
• The remediation register: severity, target timeframe, owner, closure evidence and re-test result, plus each approved deviation with its risk assessment and mitigation.
• For banks, patch records under FSM-N06 that show the timeframe for each vulnerability followed from the risk it posed, and the compensating controls where no patch existed.

An autonomous AI red team for networks and infrastructure does not run your adversarial attack simulation exercise, does not supply threat intelligence, and does not replace the in-depth test that your board, your auditors or MAS expect from qualified testers. What it adds is coverage between those tests. For an overview of the category, see automated penetration testing.

• Black-box and gray-box on a schedule. Campaigns from outside with no prior knowledge and authenticated campaigns with standard-user access, run on a schedule and after changes, so the “whenever these systems undergo major changes” part of 13.2.4 does not depend on booking an engagement.
• Exploitability as an input to remediation. Findings say whether they were proven exploitable in your environment, which is what severity classification under 13.6 and risk-based patch timeframes under FSM-N06 need.
• Safeguards for production. 13.2.3 asks for proper safeguards when testing production. Scope validation, an emergency stop and five autonomy levels define what the agents may do alone and what waits for an operator, and exploit proofs of concept can be held for review. See human in the loop.
• Framework mapping. MAS TRM is one of the 34 frameworks the engine maps findings to, with exportable compliance reports. Check the mapping against the paragraph numbers in this guide before you show it to a supervisor; tying each report to 13.1, 13.2 and 13.6 stays in your documentation.
• Records and data location. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain per campaign, verifiable offline, and no customer data leaves the appliance: the models run on it, with no external AI service. See on-premise AI red team and the on-premise pentest platform buyer's guide.

• MAS: Technology Risk Management Guidelines (mas.gov.sg)
• MAS Technology Risk Management Guidelines, January 2021, paragraphs 2, 6.1, 13 and 15 (PDF, mas.gov.sg)
• MAS Notice FSM-N06 on Cyber Hygiene (mas.gov.sg)
• MAS Notice 655 on Cyber Hygiene, cancelled with effect from 10 May 2024 (mas.gov.sg)