# Threat Intelligence Procedure & Threat Assessment Methodology

**SyncMate — WYHEN Pty Ltd (ABN 57 688 078 999)**
Version 1.0 · Effective 31 August 2026 · Owner: Founder/Technical Operator · Review: annually

---

# Part A — Threat Intelligence Procedure

## A.1 Purpose

To maintain current awareness of threats relevant to a multi-tenant financial document platform serving accounting firms, and to convert that awareness into tracked, remediated action.

## A.2 Sources monitored

| Source | What it tells us | Cadence |
|---|---|---|
| ACSC alerts and advisories (cyber.gov.au) | Australian threat landscape, active campaigns against businesses | Weekly |
| OAIC notifiable data breach notices and guidance | What is causing breaches in Australia, regulator expectations | Quarterly, plus on publication |
| Xero developer and security advisories | API changes, token handling, OAuth security guidance | Weekly |
| Supabase, Cloudflare, Stripe security bulletins and status | Platform vulnerabilities and incidents affecting us directly | Weekly |
| OpenAI and Google API/security announcements | Changes to data handling, retention or training terms | Weekly |
| CVE feeds filtered to our dependency set | Vulnerable libraries we actually ship | Continuous (automated) plus weekly review |
| OWASP publications (Top 10, ASVS updates) | Application security practice changes | On publication |
| Accounting-sector threat reporting and peer incidents | Phishing and fraud patterns targeting bookkeepers and their clients | Monthly |

## A.3 Weekly triage

Once per week the Founder reviews new items from the sources above and, for each, records one of:
- **Not applicable** — with the reason (component not used, configuration not present).
- **Applicable — track** — raised into the vulnerability register (A6) with a CVSS-based severity and due date.
- **Applicable — monitor** — no action available yet; re-reviewed the following week.

Anything assessed as Critical is escalated immediately and does not wait for the weekly cycle; triage begins the same day and the A6 24-hour Critical remediation clock applies.

## A.4 Outputs

- Findings into the vulnerability register (A6).
- New or re-scored risks into the risk register (A4).
- Content for the quarterly security awareness update (A2 §2.3).
- Where a threat materially affects customers, a customer advisory.

## A.5 Records

Triage decisions are recorded with date, source, item, decision and rationale, and retained for at least 3 years.

---

# Part B — Threat Assessment Methodology

## B.1 Approach

We use **STRIDE** applied to the system data-flow. The assessment is re-run when the data-flow changes and at least annually.

## B.2 The data-flow assessed

```text
User browser (Mazars staff)
  -> Cloudflare edge (TLS termination, routing)
    -> Application server functions (authorisation, business logic)
      -> Supabase Postgres (customer data, RLS-enforced)
      -> Supabase object storage (uploaded source documents)
      -> Xero API (OAuth 2.0, tenant-scoped read/write)
      -> OpenAI / Google APIs (transient OCR and extraction)
      -> Stripe (billing)
```

## B.3 Threat actors modelled

1. **Primary — the authenticated cross-tenant adversary.** A legitimate user of one workspace attempting to read or modify another workspace's data. This is our highest-consequence actor because a single flaw exposes another accounting firm's clients' financial records. Every isolation control is designed against this actor.
2. **Secondary — credential theft against a customer user.** Phishing or session theft targeting a Mazars staff member. Mitigated primarily by Xero-only authentication with provider-enforced two-step verification, meaning there is no password for us to lose and no password-only path into the product.
3. **Secondary — subprocessor compromise.** Compromise of a hosting, AI or payment provider. Mitigated by provider selection on certification, contractual data-protection terms, minimal data sent to AI providers, and the ability to revoke and rotate.
4. **Tertiary — unauthenticated external attacker.** Standard internet-facing attack surface: injection, enumeration, denial of service.
5. **Tertiary — insider (operator).** Mitigated by least privilege, audit logging of administrative actions, and signed confidentiality obligations.

## B.4 STRIDE analysis per flow

| Flow | Threat | Scenario | Control |
|---|---|---|---|
| Browser → edge | Spoofing | Impersonating a user | Xero OAuth identity with mandatory two-step verification at the identity provider; no password credentials held |
| Browser → edge | Tampering | Modifying requests in transit | TLS 1.2+ enforced end to end |
| Browser → edge | Denial of service | Volumetric attack | Edge provider DDoS protection |
| Edge → server functions | Elevation of privilege | Calling a server function without authorisation | Every server entry point verifies caller identity and workspace membership before acting; route guards are not relied on as the boundary |
| Server → database | Information disclosure | Reading another tenant's rows | Row-Level Security enforced by the database on every table; membership resolved via security-definer function; privileged client never reachable from the browser |
| Server → database | Tampering | Writing to another tenant's records | Same RLS write policies; authorisation check before mutation; audit trail |
| Server → object storage | Information disclosure | Retrieving another tenant's documents | Per-workspace isolated paths, no public object URLs, access mediated by authorised server code |
| Upload path | Tampering | Malicious file uploaded | Type and size restriction; objects stored inert and never executed; rendered in-browser only; risk recorded as R5 in A4 |
| Server → Xero | Spoofing / Information disclosure | Token misuse or leakage | Tokens stored server-side encrypted, scoped per user and tenant, never returned to the browser, revoked on disconnect |
| Server → AI providers | Information disclosure | Customer documents used for training or retained | Enterprise API tiers with contractual no-training and no-retention terms; only the document content needed for extraction is sent; results written back only into the originating workspace |
| Server → Stripe | Information disclosure | Card data exposure | Card data never touches our systems; handled entirely by Stripe (PCI DSS Level 1) |
| All flows | Repudiation | Disputed action | Audit trail records who did what and when for administrative and data-affecting actions |
| All flows | Denial of service | Resource exhaustion via extraction queue | Queue with bounded concurrency and retry; degradation is to slower processing, not data loss |

## B.5 Outputs

Scenarios without an adequate control become entries in the risk register (A4) with a treatment plan. Scenarios with adequate controls become test cases for penetration testing scope and for the code-review checklist (A3 §5).