Pentest Rules of Engagement Template for Crypto and Fintech

Video transcript

Published pentest templates were written for networks and information technology systems. They do not cover mainnet funds, hot wallets or the laptops of multisig signers.

Rules of engagement turn a simulated attack into authorized work. NIST says they answer five questions: scope, who may test, logistics, sensitive data, and incidents.

Custodians, MPC wallet providers, exchanges and RPC providers are third parties. Get their written permission, or test only your side of the integration.

A mainnet transaction is usually irreversible, so prove exploits on a local fork. Move no real value without written approval and a cap. Use test keys only, cap hot wallet tests, and target signers only with written approval.

Halt if production degrades, testers see signs of an intruder, reach a path to funds or keys, touch out-of-scope data, or a step would move mainnet value. Name who can halt and resume.

Keep emergency contacts reachable around the clock, and an out-of-band channel for critical findings. A path to user funds should not wait for the final report.

Each engagement is scoped by what it tests. Guardian's offchain pentests are led by Carlos Polop, Head of Offchain Services.

Read the full article for the copy-ready template, or book a system review: an hour with a Guardian engineer on what you run, who holds the keys and where the risk sits.

Rules of engagement turn a simulated attack into authorized work. They extend what NIST calls an assessment plan, which protects both sides: the organization from accidental disruption, and the testers by showing management agreed to the scope.

Published templates, such as NIST's, were written for networks and IT systems. They do not cover mainnet funds, hot wallets or the laptops of multisig signers.

This template follows NIST SP 800-115 and the Penetration Testing Execution Standard (PTES), then adds those clauses. New to pentesting? Start with what penetration testing is.

What Rules of Engagement Cover

NIST defines rules of engagement as "detailed guidelines and constraints regarding the execution of information security testing."

They are set before testing starts, and give testers authority to carry out defined activities without asking again.

NIST lists five questions the rules should answer:

• What is the scope?
• Who is authorized to test?
• What are the logistics?
• How should sensitive data be handled?
• What happens in an incident?

The rules also authorize what company policy normally forbids, such as attacks meant to compromise systems.

NIST recommends involving legal advisors in intrusive tests such as pentests. They may add indemnity, limitation of liability and nondisclosure terms.

Scope, Targets and Exclusions

List what may be tested by name: domains, IP ranges, apps, APIs, cloud accounts, repositories, chains and contract addresses.

List what may not be tested just as precisely. NIST calls this the "exclude list."

Confirm ownership first. PTES warns of legal consequences if a target turns out to belong to someone else.

Third-party systems

A client cannot authorize testing of systems it does not own. NIST says the owner of a third-party network usually must consent in writing.

Cloud providers set their own rules. Check the current version before each test:

AWS also asks for a Simulated Events form, at least two weeks ahead, before red team exercises and phishing or malware simulations.

Custodians, MPC wallet providers, exchanges and RPC providers are third parties too. Get their written permission, or test only your side of the integration.

Windows and Stop Conditions

Agree test hours before testing starts. NIST suggests testing an operational site in the evening rather than at peak business times.

Add blackout dates for token launches, listings and contract upgrades.

List the source IP addresses testers will use, so your team can tell the test from a real attack.

Then write the stop conditions. NIST asks for criteria for halting the test, and a process for resuming it. For a crypto platform, halt when:

• A test action degrades production, or is about to.
• Testers find signs of a real intruder, past or present.
• Testers reach a path to user funds or production keys.
• Testers touch data outside scope, such as personal data.
• A step would move real value on mainnet.

Name who can stop the test and who can restart it. NIST puts it directly: if testers find an intruder, should testing stop, and by whose authority does it resume?

Clauses for Wallets and Mainnet

A mainnet transaction is public and usually irreversible. Treat mainnet as out of scope unless a clause says otherwise.

• Forks first: prove onchain impact on a local fork. Foundry's Anvil can fork mainnet at a specific block.
• No mainnet value: no transaction moving real funds without written, per-transaction approval and a cap.
• Test keys only: signing services are tested in staging or with test keys, never production keys.
• Hot wallets: withdrawal tests use test accounts and capped amounts, and stop at the signing request.
• Key material: testers who reach a seed or private key record where, never copy it, and call the emergency contact.
• Signers: people and devices are targets only with named, written approval.
• Deployed contracts: no calls to pause, upgrade or role-management functions in production.

Anvil's documentation warns that its default accounts are publicly known. Use a custom mnemonic when forking mainnet.

PTES describes proving access without keeping sensitive data, such as screenshots of database schemas or file permissions.

Testing from a compromised laptop or signer device? See the assumed breach pentest guide.

Contacts, Escalation and Data

PTES asks for an emergency contact list, shared with everyone on it. For each person, record:

• Full name, title and operational responsibility.
• Authority to discuss the test.
• Two ways to reach them immediately, around the clock.
• One secure way to transfer data.

Add an out-of-band channel for Critical findings. A path to user funds should not wait for the final report.

For data, NIST covers storage during and after testing, transmission and removal. Results identify exploitable weaknesses, so treat them as sensitive.

The Template

Copy this, fill in the brackets and attach it to your statement of work.

1. Purpose: tester [firm], client [legal entity], objective [what the test must show].
2. Scope:
   • In scope: [domains, IPs, apps, APIs, cloud accounts, repositories, chains, contracts].
   • Exclude list: [systems, IPs, third-party services].
   • Third-party approvals: [provider, reference].
3. Authorization:
   • Allowed techniques: [list].
   • Prohibited: [DoS, flooding, others].
   • Social engineering: [none, or named targets only].
4. Schedule:
   • Window: [dates, hours, time zone].
   • Blackout dates: [launches, listings, upgrades].
   • Tester source IPs: [list].
5. Wallets and onchain:
   • Exploits proven on: [fork at block N, or testnet].
   • Mainnet transactions: none without written approval; cap [amount].
   • Signing: staging and test keys only.
   • Key material found: not copied, location recorded, [contact] called.
6. Stop conditions:
   • Halt on: production impact, signs of an intruder, a path to funds or keys.
   • Also halt on: out-of-scope data, or any step that moves mainnet value.
   • Halt authority: [name]. Resume authority: [name].
7. Contacts:
   • Per person: [name, title, role, two 24/7 numbers, secure channel].
   • Critical findings: [channel], within [hours].
8. Data handling: storage [encrypted, where], transfer [method], destruction after [days], confirmed in writing.
9. Reporting: status updates [daily], final report [date], retest [window].
10. Signatures: test lead [name, date]; client executive [CISO or CTO, date].

NIST says at a minimum the test team leader and the client's senior management should sign, confirming they understand the scope and boundaries.

How Guardian Runs Pentests

Carlos Polop, Guardian's Head of Offchain Services, co-founded and built HackTricks training. His team runs Guardian's offchain pentests.

Guardian scopes each offchain engagement by what it tests. A web app is scoped by what a user can do, an API by its endpoints and roles, and cloud by the accounts and platforms in play.

Planning a test? Book a system review: an hour with a Guardian engineer on what you run, who holds the keys and where the risk sits.

Frequently Asked Questions

What are rules of engagement in a pentest?

The written terms that authorize a pentest and set its limits: scope, exclusions, timing, contacts, data handling and stop conditions. NIST says they are set before testing, and let testers carry out defined activities without asking again.

Who signs a pentest rules of engagement document?

NIST says at least the test team leader and the client's senior management, such as the CISO, CIO or CSO. Owners of third-party systems in scope give their own written permission.

Do I need permission from AWS, Azure or Google Cloud to pentest?

Usually not for your own resources. AWS allows tests of listed services without prior approval, Azure has not required it since 2017, and Google says you need not contact it. AWS and Microsoft both prohibit denial of service testing.

Can a pentest send transactions on mainnet?

It should not move real value. Prove onchain impact on a local fork or a testnet, and allow mainnet transactions only with written, per-transaction approval and a spending cap.

Sources

• NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment, Appendix B: Rules of Engagement Template (September 2008)
• PTES: Pre-engagement Interactions (mirror of pentest-standard.org)
• AWS: Penetration testing policy
• Microsoft: Microsoft Cloud Unified Penetration Testing Rules of Engagement
• Microsoft Learn: Penetration testing (Azure)
• Google Cloud Help: Penetration testing your Google Cloud infrastructure
• Foundry: Anvil overview
• Guardian: Audits and pentests
• Guardian: System review
• Guardian: Team