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

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

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.
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.
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.
Tertiary — unauthenticated external attacker. Standard internet-facing attack surface: injection, enumeration, denial of service.
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).