Treasury ops

docs/pages/config/contributors.json

@@ -188,7 +188,31 @@
     "twitter": "https://x.com/_SEAL_Org",
     "website": "https://securityalliance.org",
     "company": "SEAL",
-    "job_title": "Frameworks Contributors",
-    "description": "Frameworks Contributors"
+    "job_title": "Frameworks Contributor",
+    "description": "Frameworks Contributor"
+  },
+  "bsamuels453": {
+    "slug": "bsamuels453",
+    "name": "Ben S",
+    "role": "contributor",
+    "avatar": "https://avatars.githubusercontent.com/bsamuels453",
+    "github": "https://github.com/bsamuels453",
+    "twitter": "https://x.com/thebensams",
+    "website": "https://bsamuels.net/",
+    "company": "Trail of Bits",
+    "job_title": "Director of Engineering for Blockchain",
+    "description": "Frameworks Contributor"
+  },
+  "ElliotFriedman": {
+    "slug": "ElliotFriedman",
+    "name": "Elliot",
+    "role": "contributor",
+    "avatar": "https://avatars.githubusercontent.com/ElliotFriedman",
+    "github": "https://github.com/ElliotFriedman",
+    "twitter": "https://x.com/Elliot0x",
+    "website": "https://kleidi.io/",
+    "company": "Solidity Labs",
+    "job_title": "Founder & Engineer",
+    "description": "Frameworks Contributor"
   }
 }

docs/pages/treasury-operations/classification.mdx

@@ -0,0 +1,142 @@
+---
+title: "Custodial Treasury Security: Classification Framework"
+tags:
+  - Treasury Ops
+  - Operations
+  - Risk Management
+contributors:
+  - role: wrote
+    users: [dickson]
+  - role: reviewed
+    users: [relotnek, bsamuels453, ElliotFriedman]
+---
+
+import {
+  TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+<TagProvider>
+<TagFilter />
+
+# Custodial Treasury Security: Classification Framework
+
+<TagList tags={frontmatter.tags} />
+<AttributionList contributors={frontmatter.contributors} />
+
+Proper documentation and classification of custodial accounts is essential for institutional treasury security. This guide focuses on the security assessment and classification framework for crypto assets held with third-party custodians.
+
+> See also: [Registration Documents](./registration-documents) and [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+## Classification Process
+
+Use this dual classification to determine appropriate security controls for each custodial account.
+
+### Step 1: Impact Assessment
+
+Evaluate the consequences if this account is compromised or unavailable.
+
+#### Financial Impact
+
+Calculate the total value at risk in this account:
+
+- Current market value of all assets held
+- Include value of any active positions (e.g., staked assets, DeFi deposits)
+- What is the financial impact if unavailable for 7 days?
+
+#### Operational Impact
+
+Assess the consequences if this account becomes unavailable:
+
+- What specific operations require this account?
+- Do you have a secondary custody account that can handle these operations?
+- What is the reputational impact if this account is compromised or unavailable?
+
+#### Regulatory Impact
+
+Evaluate regulatory and compliance consequences:
+
+- Are assets in this account subject to regulatory reporting requirements (SEC filings, audit requirements)?
+- Does this account hold regulated assets (e.g., stablecoins subject to reserves reporting)?
+- What are the regulatory deadlines that could be missed if this account is unavailable?
+
+#### Impact Classification
+
+| Level        | Financial Exposure (% of Total Assets) | Operational Dependency                       | Regulatory Impact                                    |
+| ------------ | -------------------------------------- | -------------------------------------------- | ---------------------------------------------------- |
+| **Low**      | \<1%                                   | No critical operations depend on it          | No regulatory reporting tied to this account         |
+| **Medium**   | 1% - 10%                               | Important but alternative funding available  | Periodic reporting; delays manageable                |
+| **High**     | 10% - 25%                              | Critical operations, limited alternatives    | Regular regulatory filings; delays cause violations  |
+| **Critical** | \>25%                                  | Business-critical, no alternatives for weeks | Real-time reporting requirements; SEC filings; audit |
+
+### Step 2: Operational Assessment
+
+Evaluate how frequently and urgently this account must be accessed.
+
+#### Transaction Frequency
+
+Document typical transaction patterns:
+
+- Transactions per month
+- Typical transaction sizes
+- Predictability of transaction timing
+
+#### Access Urgency
+
+Define response time requirements:
+
+- What is the maximum acceptable delay for routine transactions?
+- Are there scenarios requiring same-day execution?
+- What are the consequences of 24-hour, 72-hour, or 7-day delays?
+
+#### Coordination Requirements
+
+Assess how transactions are executed:
+
+- How many approvers are needed for typical transactions?
+- Are transactions handled manually or through automated systems?
+- Do approvers need to coordinate across timezones?
+
+Note: Single-approver configurations should only be used for low-value operational accounts (\<0.1%) with additional compensating controls like strict spending limits and daily reconciliation.
+
+#### Operational Classification
+
+| Type                  | Frequency     | Response Window | Example Use Cases                                  |
+| --------------------- | ------------- | --------------- | -------------------------------------------------- |
+| **Cold Vault**        | \<5 tx/month  | 48-72 hours     | Long-term reserves, infrequent rebalancing         |
+| **Warm Storage**      | 5-50 tx/month | 4-24 hours      | Scheduled payments, planned operations             |
+| **Active Operations** | \>50 tx/month | \<4 hours       | Trading capital, frequent operational expenses     |
+| **Time-Critical**     | Unpredictable | \<2 hours       | Collateral management, market-sensitive operations |
+
+### Step 3: Security Control Matrix
+
+Combine impact and operational assessments to determine required controls.
+
+| Use Case                      | Impact      | Operational   | Approvers | MFA Requirement    | Whitelist Delay | Additional Controls                         |
+| ----------------------------- | ----------- | ------------- | --------- | ------------------ | --------------- | ------------------------------------------- |
+| Payments                      | Low         | Active Ops    | 2         | Standard TOTP      | 6 hours         | **Baseline (all accounts):** Dedicated devices for custody access, address whitelisting enabled, test small amount to new addresses before full transaction, transaction simulation. **Low-specific:** Per-transaction cap, monthly aggregate limit         |
+| Operational Wallet            | Medium      | Active Ops    | 2         | Hardware required  | 12 hours        | All Low controls + daily transaction caps, weekly reconciliation, monthly audit                    |
+| Liquidation Protection        | Medium-High | Time-Critical | 2         | Hardware required  | None            | All Low/Medium controls + automated alerts for position health, real-time monitoring |
+| DeFi Positions                | Medium-High | Warm Storage  | 3         | Hardware mandatory | 24 hours        | All Low/Medium controls + smart contract whitelist, position monitoring, daily reconciliation     |
+| Trading Capital (variable)    | High        | Active Ops    | 3         | Hardware mandatory | 6 hours         | All Low/Medium controls + smart contract whitelist, real-time monitoring, daily reconciliation   |
+| Active Treasury (5-10%)       | High        | Warm Storage  | 3-4       | Hardware mandatory | 24 hours        | All Low/Medium controls + transaction velocity limits, SIEM monitoring， multi-channel confirmation       |
+| Secondary Reserve (10-25%)    | Critical    | Cold Vault    | 4-5       | Hardware mandatory | 48 hours        | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended    |
+| Primary Reserve (>25% assets) | Critical    | Cold Vault    | 5-7       | Hardware mandatory | 72 hours        | All Low/Medium/High controls + geographic distribution of approvers, MPC recommended    |
+
+### Step 4: Document Your Decision
+
+
+
+- Record impact level and operational type with justification
+- Capture approver thresholds and required controls
+- Store links to relevant custody accounts and addresses
+
+Proceed to: [Registration Documents](./registration-documents)
+
+For Critical/High accounts, ensure you also review: [Enhanced Controls for High-Risk Accounts](./enhanced-controls)
+
+</TagProvider>
+<ContributeFooter />

docs/pages/treasury-operations/enhanced-controls.mdx

@@ -0,0 +1,151 @@
+---
+title: "Enhanced Controls for High-Risk Custodial Accounts"
+tags:
+  - Treasury Ops
+  - Operations
+  - Risk Management
+contributors:
+  - role: wrote
+    users: [dickson]
+  - role: reviewed
+    users: [relotnek, bsamuels453, ElliotFriedman]
+---
+
+import {
+  TagList,
+  AttributionList,
+  TagProvider,
+  TagFilter,
+  ContributeFooter,
+} from "../../../components";
+
+<TagProvider>
+<TagFilter />
+
+# Enhanced Controls for High-Risk Accounts
+
+<TagList tags={frontmatter.tags} />
+<AttributionList contributors={frontmatter.contributors} />
+
+For Critical and High impact custodial accounts, implement the following controls in addition to baseline measures.
+
+---
+
+## Transaction Verification
+
+- Test transactions: Send maximum $100 to new addresses before executing full transaction
+- Multi-channel confirmation: Request via one channel, approve via separate channel
+- Simulation requirement: All transactions must be simulated before execution
+- Address verification: Verify new addresses against three independent sources
+
+For DeFi interactions: refer to the [DeFi Risk Assessment Guide](https://entethalliance.org/specs/defi-risks/v1/) for recommended procedures.
+
+## Access Security
+
+- Hardware security keys (FIDO2/WebAuthn) mandatory for all approvers
+  - Secure fallback: Each approver must register minimum 2 hardware keys stored in separate secure locations
+  - Key loss procedure: Temporary access via backup key + additional approver verification via multiple channels + mandatory key replacement within 48 hours
+- IP whitelisting with 24-hour change approval delay - if treasury software supports application-level IP whitelisting, restrict to VPN IP range only
+- Device fingerprinting with new device approval process
+- Session timeout and re-authentication for sensitive operations
+- Dedicated credentials: Use separate email addresses and passwords exclusively for custody access, not shared with other corporate systems
+
+## Device Security
+
+- Dedicated secure workstations and mobile devices for custody access only (no general browsing, email, or other corporate activities)
+- Network isolation on separate VLAN/segment
+- VPN mandatory for all platform access; if treasury platform supports it, configure IP whitelisting to only allow access from VPN IP addresses
+- Full disk encryption with automatic screen lock
+- MDM-enforced security baseline with remote wipe capability
+- Mobile endpoint security monitoring (e.g., iVerify) for devices used as second factors or keystores, without requiring full MDM admin control
+
+## MPC for Large Holdings
+
+For organizations managing >10% of total assets or >$10M equivalent in a single custodial account consider using MPC:
+
+- Evaluate MPC (Multi-Party Computation) custody solutions that distribute key material across multiple parties
+- Consider threshold signature schemes (e.g., 3-of-5 or 5-of-9) where no single party controls sufficient key shares
+- Implement geographic distribution of key share holders across multiple jurisdictions
+- Establish clear key refresh and rotation procedures
+- Document recovery procedures and test annually
+
+### Custody/MPC Policy Thresholds for Treasury Operations
+
+- Minimum of 3 distinct approvers across roles (e.g., Treasury, Security, Finance)
+- Target majority approval (≥50% of designated approver group; e.g., 3/5, 4/7)
+- Scale quorum size with assets-at-risk and operational blast radius
+- Enforce separation of duties: requester cannot be an approver; admins cannot unilaterally execute withdrawals
+
+Policy scope definitions (examples):
+
+- Emergency Freeze: Temporarily block withdrawals/policy changes across workspaces
+- Protocol Parameters: Custody/policy engine settings, risk rules, policy changes
+- Capital Allocation: Movements between accounts, exchanges, or strategies
+- Treasury – Large: Routine treasury transfers above internal threshold or rate limit
+- Treasury – Small: Routine operational transfers below internal threshold or rate limit
+- Constrained DeFi: Time-sensitive interactions with pre-approved protocols/contracts
+
+Suggested approver thresholds (treasury contexts):
+
+| Operation            | Impact   | Urgency        | Approver Threshold            |
+| -------------------- | -------- | -------------- | ----------------------------- |
+| Emergency Freeze     | Critical | Emergency      | 2/4                           |
+| Protocol Parameters  | High     | Routine        | 4/7 (7/9+ for upgrades)       |
+| Capital Allocation   | High     | Time-Sensitive | 3/5                           |
+| Treasury - Large     | High     | Routine        | 4/7                           |
+| Treasury - Small     | Medium   | Routine        | 3/5                           |
+| Constrained DeFi     | Medium   | Time-Sensitive | 2/3                           |
+
+## Custody Policy Engine Rules
+
+Most custody/MPC platforms provide a policy engine that evaluates transaction rules and takes one of three actions: allow, block, or require additional approvals.
+
+Core rule elements:
+
+- Action: allow | block | escalate (require more approvers)
+- Asset selector: all assets or specific assets/tokens
+- Amount limits: per-transaction limit and optional rolling window aggregation
+- Source and destination selectors: account/wallet groups, internal vs external addresses, exchanges
+- Transaction type: transfers, contract interactions, approvals/signing
+- Initiators and approvers: who can initiate and who must authorize (with thresholds)
+- Rule identity and ordering: each rule has an ID; engines typically evaluate rules in order (first-match wins)
+
+## Zero Trust Architecture Alternative
+
+A Zero Trust architecture involves continuous verification of user, device, and context, rather than reliance on a single perimeter or network location. Centralizing access through a secure environment (such as a bastion host or isolated cloud workspace) can support Zero Trust principles when combined with strong identity and device posture enforcement.
+
+- Bastion Host Approach: Deploy a hardened jump server that acts as the sole gateway to custody platforms.
+  - All custody sessions route through the bastion with full session recording
+  - Bastion enforces MFA, device posture checks, and approved software versions
+  - No direct custody access from employee devices
+  - Centralized patch management and security configuration
+
+- Cloud Workspace Isolation: Use browser-isolated or virtual workspace environments (e.g., Citrix, AWS WorkSpaces, Azure Virtual Desktop)
+  - Custody access occurs only within a controlled virtual environment
+  - Copy/paste and download restrictions prevent data exfiltration
+  - Session timeout and automatic workspace destruction after use
+  - Significantly reduces risk from compromised employee devices
+
+## Security Monitoring & Logging
+
+For Critical and High impact accounts, implement centralized security monitoring:
+
+- SIEM Deployment: Deploy SIEM to centralize logs from custody platforms, authentication systems, and access devices. Create real-time correlation rules for suspicious patterns (failed authentication, geographic anomalies, policy changes).
+
+- Internal Incident Response: Build dedicated incident response capability for custody-related security events. Define clear escalation procedures, maintain 24/7 on-call rotation for Critical accounts, and establish playbooks for custody compromise scenarios.
+
+- Essential Log Sources: Authentication events, transaction attempts, policy modifications, access changes, whitelist updates, IP address changes, new device enrollments, and approval workflows.
+
+For Medium and Low impact accounts, leverage custodian's native audit logs with weekly manual review and automated alerting for critical events (new device enrollment, policy changes, transactions above threshold).
+
+---
+
+### See also
+
+- Classification: [Custodial Treasury Security: Classification Framework](./classification)
+- Templates: [Registration Documents](./registration-documents)
+
+</TagProvider>
+<ContributeFooter />
+
+