最新的CREST Certified Red Team Manager - Scenario - CCRTM-SC免費考試真題
問題1
Background: You are scoping an engagement for Ashcombe Retail Bank, a mid-sized UK bank preparing for its first CBEST engagement. During the scoping workshop, the Head of Digital Channels strongly advocates for an objectives-based ("flag") approach, proposing a single objective: "achieve unauthorised funds transfer capability in the core payments system." The Head of Operational Resilience, in the same meeting, separately advocates for a crown-jewels (asset-based) approach explicitly listing seven named critical systems that must each be individually assessed, arguing the board specifically wants to see coverage confirmation against each one for their operational resilience self-assessment.
Both stakeholders are Control Group members, and neither is aware the other has a different underlying preference until this workshop, where the disagreement becomes evident in real time. The engagement's resourcing (agreed with the Bank of England as broadly appropriate for a first CBEST engagement of this bank's size) is not large enough to comfortably deliver a deep, patient, objectives-based campaign against one target AND a full individual assessment of all seven named systems within the available testing window.
Question: As the Red Team Manager facilitating this scoping workshop, how would you help the Control Group resolve this disagreement, and what would you recommend? Explain your reasoning.
Background: You are scoping an engagement for Ashcombe Retail Bank, a mid-sized UK bank preparing for its first CBEST engagement. During the scoping workshop, the Head of Digital Channels strongly advocates for an objectives-based ("flag") approach, proposing a single objective: "achieve unauthorised funds transfer capability in the core payments system." The Head of Operational Resilience, in the same meeting, separately advocates for a crown-jewels (asset-based) approach explicitly listing seven named critical systems that must each be individually assessed, arguing the board specifically wants to see coverage confirmation against each one for their operational resilience self-assessment.
Both stakeholders are Control Group members, and neither is aware the other has a different underlying preference until this workshop, where the disagreement becomes evident in real time. The engagement's resourcing (agreed with the Bank of England as broadly appropriate for a first CBEST engagement of this bank's size) is not large enough to comfortably deliver a deep, patient, objectives-based campaign against one target AND a full individual assessment of all seven named systems within the available testing window.
Question: As the Red Team Manager facilitating this scoping workshop, how would you help the Control Group resolve this disagreement, and what would you recommend? Explain your reasoning.
正確答案:
See The answer in Explanation part below.
Explanation:
Step 1 - Recognise this as a legitimate scoping methodology disagreement, not a problem to paper over.
Both stakeholders are raising genuinely valid, well-established scoping approaches (objectives-based/flag- based versus crown-jewels/asset-based, both discussed in the syllabus), and both have legitimate underlying business drivers - realistic adversary emulation toward a genuinely damaging objective, versus a board- driven need for explicit assurance coverage across named critical systems. Your role is not to simply pick a side, but to facilitate the Control Group toward a well-reasoned, resourced, and realistic decision.
Step 2 - Make the resourcing constraint explicit and central to the discussion. The most important immediate contribution you can make is to be transparent, per the syllabus principle on budget/scope/objective mismatches, that the currently agreed resourcing genuinely cannot deliver both approaches to a proper, credible standard within the available window - attempting to do so would likely mean shallow, unconvincing coverage of seven systems and an under-resourced, unrealistic attempt at the funds-transfer objective, satisfying neither stakeholder's actual underlying need well. Surfacing this constraint honestly and early is essential before any scope decision is finalised.
Step 3 - Explore whether the two preferences are more reconcilable than they first appear. Rather than treating this as strictly either/or, explore with the Control Group whether a hybrid, prioritised approach could serve both underlying needs: for example, a primary, well-resourced objectives-based scenario targeting unauthorised funds transfer capability (satisfying the realistic-adversary-emulation goal), where the realistic attack paths pursued are deliberately chosen, where feasible, to pass through or touch several of the seven named critical systems along the way - meaning the Head of Operational Resilience's board reporting could legitimately describe those touched systems as having been genuinely, realistically assessed as part of an integrated scenario, even though not every one of the seven was necessarily reached, while remaining honest that the coverage was realistic-path-driven rather than an independent, systematic per-system assessment for every listed system.
Step 4 - Be explicit about what a compromise honestly does and does not deliver. If a hybrid approach is pursued, you must be scrupulously honest with the Control Group that this does not equate to full, independent assurance coverage of all seven systems in the way the Head of Operational Resilience originally wanted - some named systems may end up not meaningfully touched at all if the realistic attack path simply does not lead there, and this must be clearly flagged as an accepted limitation of the chosen approach, not glossed over, so the board's own understanding (via the Head of Operational Resilience) is accurate rather than inadvertently overstated.
Step 5 - Present genuine options to the Control Group rather than deciding for them. Ultimately, this is a Control Group risk and priorities decision, not one for you to make unilaterally. You should present the Control Group with clearly articulated options - for example: (a) a primarily objectives-based scenario as described in Step 3, with honest limitations on per-system coverage; (b) a purely crown-jewels approach systematically but perhaps more superficially covering all seven systems, sacrificing depth and realistic attacker-path continuity; or (c) if the Control Group genuinely believes both are essential and cannot be compromised on, a transparent conversation about whether additional budget/timeline could be sought (echoing the scoping domain's guidance on addressing genuine budget/objective mismatches transparently) - and facilitate a decision, rather than imposing your own preference.
Step 6 - Ensure the final decision and its rationale are properly documented. Whatever the Control Group decides, the choice and its explicit rationale (including the honestly acknowledged trade-offs) should be documented clearly in the scope specification, both so future audit/attestation review understands the reasoning, and so there is a clear record protecting against later disagreement about what was actually promised and delivered.
Conclusion: The correct facilitation approach surfaces the genuine resourcing constraint honestly, explores a hybrid approach that may reasonably serve both stakeholders' underlying needs without pretending it delivers everything either wanted in full, and ultimately presents clear, honest options to the Control Group for their own risk-based decision - rather than the Red Team Manager unilaterally picking one stakeholder's preferred methodology over the other's.
---
Explanation:
Step 1 - Recognise this as a legitimate scoping methodology disagreement, not a problem to paper over.
Both stakeholders are raising genuinely valid, well-established scoping approaches (objectives-based/flag- based versus crown-jewels/asset-based, both discussed in the syllabus), and both have legitimate underlying business drivers - realistic adversary emulation toward a genuinely damaging objective, versus a board- driven need for explicit assurance coverage across named critical systems. Your role is not to simply pick a side, but to facilitate the Control Group toward a well-reasoned, resourced, and realistic decision.
Step 2 - Make the resourcing constraint explicit and central to the discussion. The most important immediate contribution you can make is to be transparent, per the syllabus principle on budget/scope/objective mismatches, that the currently agreed resourcing genuinely cannot deliver both approaches to a proper, credible standard within the available window - attempting to do so would likely mean shallow, unconvincing coverage of seven systems and an under-resourced, unrealistic attempt at the funds-transfer objective, satisfying neither stakeholder's actual underlying need well. Surfacing this constraint honestly and early is essential before any scope decision is finalised.
Step 3 - Explore whether the two preferences are more reconcilable than they first appear. Rather than treating this as strictly either/or, explore with the Control Group whether a hybrid, prioritised approach could serve both underlying needs: for example, a primary, well-resourced objectives-based scenario targeting unauthorised funds transfer capability (satisfying the realistic-adversary-emulation goal), where the realistic attack paths pursued are deliberately chosen, where feasible, to pass through or touch several of the seven named critical systems along the way - meaning the Head of Operational Resilience's board reporting could legitimately describe those touched systems as having been genuinely, realistically assessed as part of an integrated scenario, even though not every one of the seven was necessarily reached, while remaining honest that the coverage was realistic-path-driven rather than an independent, systematic per-system assessment for every listed system.
Step 4 - Be explicit about what a compromise honestly does and does not deliver. If a hybrid approach is pursued, you must be scrupulously honest with the Control Group that this does not equate to full, independent assurance coverage of all seven systems in the way the Head of Operational Resilience originally wanted - some named systems may end up not meaningfully touched at all if the realistic attack path simply does not lead there, and this must be clearly flagged as an accepted limitation of the chosen approach, not glossed over, so the board's own understanding (via the Head of Operational Resilience) is accurate rather than inadvertently overstated.
Step 5 - Present genuine options to the Control Group rather than deciding for them. Ultimately, this is a Control Group risk and priorities decision, not one for you to make unilaterally. You should present the Control Group with clearly articulated options - for example: (a) a primarily objectives-based scenario as described in Step 3, with honest limitations on per-system coverage; (b) a purely crown-jewels approach systematically but perhaps more superficially covering all seven systems, sacrificing depth and realistic attacker-path continuity; or (c) if the Control Group genuinely believes both are essential and cannot be compromised on, a transparent conversation about whether additional budget/timeline could be sought (echoing the scoping domain's guidance on addressing genuine budget/objective mismatches transparently) - and facilitate a decision, rather than imposing your own preference.
Step 6 - Ensure the final decision and its rationale are properly documented. Whatever the Control Group decides, the choice and its explicit rationale (including the honestly acknowledged trade-offs) should be documented clearly in the scope specification, both so future audit/attestation review understands the reasoning, and so there is a clear record protecting against later disagreement about what was actually promised and delivered.
Conclusion: The correct facilitation approach surfaces the genuine resourcing constraint honestly, explores a hybrid approach that may reasonably serve both stakeholders' underlying needs without pretending it delivers everything either wanted in full, and ultimately presents clear, honest options to the Control Group for their own risk-based decision - rather than the Red Team Manager unilaterally picking one stakeholder's preferred methodology over the other's.
---
問題2
Background: Your firm is engaged to deliver a red team engagement for Marchmont Utilities plc, spanning both its UK head office operations and a regional office in a second country where Marchmont has recently acquired a smaller local utility. The engagement contract and authorisation letter were drafted using your firm's standard UK template, reviewed only by Marchmont's UK-based General Counsel, who confirmed "our legal position is the same everywhere we operate, so this should be fine as written." Your firm has never previously delivered an engagement in this second country and has not sought local legal advice.
Three weeks into the engagement, your team plans a physical social engineering exercise (tailgating and a pretext visit) at the newly acquired regional office. Separately, your threat intelligence work has identified that a plausible attack path involves a local telecommunications provider's infrastructure used by the regional office for internet connectivity - infrastructure the regional office does not own but simply subscribes to as a retail customer.
Question: Identify the legal risks created by proceeding as currently planned, and explain the steps that should be taken before the physical exercise proceeds and before any technical activity touches the telecommunications provider's infrastructure.
Background: Your firm is engaged to deliver a red team engagement for Marchmont Utilities plc, spanning both its UK head office operations and a regional office in a second country where Marchmont has recently acquired a smaller local utility. The engagement contract and authorisation letter were drafted using your firm's standard UK template, reviewed only by Marchmont's UK-based General Counsel, who confirmed "our legal position is the same everywhere we operate, so this should be fine as written." Your firm has never previously delivered an engagement in this second country and has not sought local legal advice.
Three weeks into the engagement, your team plans a physical social engineering exercise (tailgating and a pretext visit) at the newly acquired regional office. Separately, your threat intelligence work has identified that a plausible attack path involves a local telecommunications provider's infrastructure used by the regional office for internet connectivity - infrastructure the regional office does not own but simply subscribes to as a retail customer.
Question: Identify the legal risks created by proceeding as currently planned, and explain the steps that should be taken before the physical exercise proceeds and before any technical activity touches the telecommunications provider's infrastructure.
正確答案:
See The answer in Explanation part below.
Explanation:
Step 1 - Challenge the "our legal position is the same everywhere" assumption directly. This is the central issue the scenario is testing: the General Counsel's assurance, however well-intentioned, reflects exactly the dangerous oversimplification the syllabus warns against. Cybercrime, trespass, and data protection law can differ materially between jurisdictions, and relying on a UK-templated authorisation and RoE, reviewed only by UK-qualified counsel, for activity in a second country creates a genuine, material legal risk for both the firm and its individual testers, regardless of the General Counsel's confidence.
Step 2 - Assess the physical social engineering risk specifically. Physical access testing - tailgating and a pretext visit - engages local trespass law and potentially other public order or physical security offences that are jurisdiction-specific and were explicitly flagged in the syllabus as a distinct legal consideration beyond computer misuse law. Proceeding with this activity in a country where your firm has no established legal understanding, based solely on a UK GC's blanket assurance, is professionally unsound and creates real risk to the individual testers physically present (for example, if challenged and a local law enforcement response is triggered, with no locally verified authorisation position or discreet liaison arrangement in place).
Step 3 - Assess the telecommunications infrastructure issue. The local telecommunications provider owns and operates the infrastructure the regional office merely subscribes to as a retail customer - directly analogous to the cloud provider and SaaS vendor authorisation-boundary issues covered elsewhere in this syllabus. Marchmont cannot validly authorise testing of infrastructure it does not own or control; the telecommunications provider's own separate consent (and likely review of relevant local telecommunications regulation, which can carry its own specific restrictions beyond generic computer misuse law) would be required before any technical activity could properly and lawfully touch that infrastructure.
Step 4 - Halt both activities pending proper legal review. Given the gaps identified, the professionally correct action is to pause both the planned physical exercise and any technical activity contemplated against the telecommunications provider's infrastructure, rather than proceeding on the basis of the existing UK- templated documentation and the GC's general assurance.
Step 5 - Commission genuine local legal advice. Consistent with the syllabus principle for first-of-its-kind engagements in an unfamiliar jurisdiction, your firm should commission proper local legal advice specifically covering: relevant local criminal/cybercrime law (including how "authorisation" defences operate locally, which may differ materially from the Computer Misuse Act framework), trespass and any other relevant offences potentially engaged by physical social engineering, local data protection law (which may differ from UK GDPR in scope and specific obligations), and any telecommunications-specific regulation relevant to testing the local provider's infrastructure.
Step 6 - Adapt authorisation and RoE documentation accordingly. Based on that local advice, the authorisation letter and RoE should be specifically adapted for the second country's legal context - not merely reused from the UK template - including explicit, locally accurate coverage of the physical exercise and clear exclusion (pending separate consent) of the telecommunications provider's infrastructure.
Step 7 - Confirm insurance coverage extends to the second jurisdiction. Consistent with the syllabus principle on insurance review when operating in unfamiliar jurisdictions, you should explicitly confirm with your firm's insurers that professional indemnity/cyber liability coverage genuinely extends to activity conducted in this second country before proceeding, rather than assuming this is automatically covered.
Step 8 - Engage the telecommunications provider (or exclude that path) before any technical activity proceeds. For the specific attack path involving the telecommunications provider, the team should either seek the provider's own explicit consent (documented, and informed by the local legal advice above) before including it in active technical scope, or exclude that specific path from live testing and instead document the associated risk for Marchmont's own third-party/supply-chain risk management, consistent with the approach discussed elsewhere in this syllabus for third-party infrastructure discovered during scoping or threat intelligence work.
Conclusion: Both the physical social engineering exercise and any technical activity touching the local telecommunications provider's infrastructure should be paused; genuine local legal advice must be obtained and used to properly adapt authorisation, RoE, and insurance coverage for the second jurisdiction; and the telecommunications infrastructure should not be actively tested without the provider's own separate, properly informed consent.
---
Explanation:
Step 1 - Challenge the "our legal position is the same everywhere" assumption directly. This is the central issue the scenario is testing: the General Counsel's assurance, however well-intentioned, reflects exactly the dangerous oversimplification the syllabus warns against. Cybercrime, trespass, and data protection law can differ materially between jurisdictions, and relying on a UK-templated authorisation and RoE, reviewed only by UK-qualified counsel, for activity in a second country creates a genuine, material legal risk for both the firm and its individual testers, regardless of the General Counsel's confidence.
Step 2 - Assess the physical social engineering risk specifically. Physical access testing - tailgating and a pretext visit - engages local trespass law and potentially other public order or physical security offences that are jurisdiction-specific and were explicitly flagged in the syllabus as a distinct legal consideration beyond computer misuse law. Proceeding with this activity in a country where your firm has no established legal understanding, based solely on a UK GC's blanket assurance, is professionally unsound and creates real risk to the individual testers physically present (for example, if challenged and a local law enforcement response is triggered, with no locally verified authorisation position or discreet liaison arrangement in place).
Step 3 - Assess the telecommunications infrastructure issue. The local telecommunications provider owns and operates the infrastructure the regional office merely subscribes to as a retail customer - directly analogous to the cloud provider and SaaS vendor authorisation-boundary issues covered elsewhere in this syllabus. Marchmont cannot validly authorise testing of infrastructure it does not own or control; the telecommunications provider's own separate consent (and likely review of relevant local telecommunications regulation, which can carry its own specific restrictions beyond generic computer misuse law) would be required before any technical activity could properly and lawfully touch that infrastructure.
Step 4 - Halt both activities pending proper legal review. Given the gaps identified, the professionally correct action is to pause both the planned physical exercise and any technical activity contemplated against the telecommunications provider's infrastructure, rather than proceeding on the basis of the existing UK- templated documentation and the GC's general assurance.
Step 5 - Commission genuine local legal advice. Consistent with the syllabus principle for first-of-its-kind engagements in an unfamiliar jurisdiction, your firm should commission proper local legal advice specifically covering: relevant local criminal/cybercrime law (including how "authorisation" defences operate locally, which may differ materially from the Computer Misuse Act framework), trespass and any other relevant offences potentially engaged by physical social engineering, local data protection law (which may differ from UK GDPR in scope and specific obligations), and any telecommunications-specific regulation relevant to testing the local provider's infrastructure.
Step 6 - Adapt authorisation and RoE documentation accordingly. Based on that local advice, the authorisation letter and RoE should be specifically adapted for the second country's legal context - not merely reused from the UK template - including explicit, locally accurate coverage of the physical exercise and clear exclusion (pending separate consent) of the telecommunications provider's infrastructure.
Step 7 - Confirm insurance coverage extends to the second jurisdiction. Consistent with the syllabus principle on insurance review when operating in unfamiliar jurisdictions, you should explicitly confirm with your firm's insurers that professional indemnity/cyber liability coverage genuinely extends to activity conducted in this second country before proceeding, rather than assuming this is automatically covered.
Step 8 - Engage the telecommunications provider (or exclude that path) before any technical activity proceeds. For the specific attack path involving the telecommunications provider, the team should either seek the provider's own explicit consent (documented, and informed by the local legal advice above) before including it in active technical scope, or exclude that specific path from live testing and instead document the associated risk for Marchmont's own third-party/supply-chain risk management, consistent with the approach discussed elsewhere in this syllabus for third-party infrastructure discovered during scoping or threat intelligence work.
Conclusion: Both the physical social engineering exercise and any technical activity touching the local telecommunications provider's infrastructure should be paused; genuine local legal advice must be obtained and used to properly adapt authorisation, RoE, and insurance coverage for the second jurisdiction; and the telecommunications infrastructure should not be actively tested without the provider's own separate, properly informed consent.
---