# WeatherFlow Tactical Security Review
# Classification: Confidential
# Date: 2026-06-09
# Reviewer: Claude Code (drafted); pending Founder approval
# Status: Draft

---

## 1. Vendor / Device Overview

| Field | Value |
|---|---|
| **Name** | WeatherFlow Tactical WEATHERmeter (WeatherFlow-Tempest, Inc.) |
| **Website** | tempest.earth · shop.tempest.earth |
| **Service / purpose** | Handheld BLE atmospheric sensor — wind speed/direction, temperature, humidity, pressure |
| **CBB use case** | Default ScopeDOPE weather sensor. ScopeDOPE reads the sensor **directly over BLE using CBB's own driver (`WeatherFlowTacticalDriver.kt`)** — the vendor's Tempest app and cloud are **not used.** |
| **Data tier(s) accessed** | Tier 1 — anonymous atmospheric readings only. No PII, no account, no cloud. |
| **Access type** | BLE GATT (read/notify) from the ScopeDOPE app; no vendor app, no vendor account, no internet |
| **Proposed onboarding date** | Already integrated — retrospective review |

> **Key distinction:** CBB does **not** use the WeatherFlow Tempest mobile app or WeatherFlow's cloud service. ScopeDOPE talks to the device directly over BLE with a CBB-authored driver. Therefore the vendor's SaaS/cloud data-handling is **out of scope** — this review assesses the **BLE link + the physical device**, not a cloud service.

---

## 2. Data Exposure Assessment

### 2.1 What CBB data will this vendor / device access?

**None flows to the vendor.** The device is a passive sensor. ScopeDOPE reads:

- Wind speed / direction, temperature, humidity, pressure (raw atmospheric values)
- Device battery / status fields

These are **anonymous environmental measurements** — they contain no user identity, no location-as-identity, no ballistic profile. They feed the on-device ballistic computer and never leave the phone (offline-first, no server — SPEC §4.6).

### 2.2 Where will CBB data be stored by this vendor?

**Nowhere.** No vendor app, no vendor cloud, no vendor account is used. Readings are consumed in-app on the phone. WeatherFlow receives nothing from CBB's integration.

### 2.3 Is any Highly Confidential data (Tier 4) involved?

- [ ] Yes
- [x] **No** — atmospheric readings only; no SPEC/engine material. (How those readings are *used* by the engine is Tier-4, but that logic is on-device and is not transmitted to or accessible by the device/vendor.)

---

## 3. Vendor Security Posture (Software vendors only)

**Largely N/A** — CBB uses no WeatherFlow cloud service or app, so vendor SaaS compliance (SOC 2 etc.) is not in the trust path. The only vendor-side dependency is the **device firmware supply chain**, assessed in §4.

---

## 4. Hardware Security Assessment (Hardware / BLE devices only)

### 4.1 Communication protocol

- **BLE GATT**, CBB-authored driver (`WeatherFlowTacticalDriver.kt`).
- Confirmed protocol (project memory / reverse-engineering): service `961f0001`, notify characteristic `961f0005`, `WFPSM`-framed packets, 16-byte payloads; wind value = raw/1024; **no density-altitude field on the wire** (derived on-device).
- Open protocol items tracked separately (#102 compass semantics, battery low-alert).
- Pairing is **read/notify of broadcast sensor data** — no CBB data is written to the device.

### 4.2 Firmware update mechanism

- Per WeatherFlow's published device-security posture: firmware is **encrypted with a per-device key, validated before install**; firmware must be downloaded from WeatherFlow servers over a secure channel; malicious/foreign firmware is rejected by the device.
- Devices run a **purpose-built embedded OS** — no open ports, no login, no general-purpose OS attack surface; all network comms are device-initiated.
- **CBB does not perform firmware updates** through its integration; updates (if any) occur via the vendor's own tooling, outside ScopeDOPE.

### 4.3 Data transmission security

- [x] Device does **not** transmit CBB data to any external server (CBB integration is BLE-only, offline)
- [~] BLE link encryption: the sensor broadcasts atmospheric data; readings are **non-sensitive** (anonymous environment). Even if a nearby device sniffed the BLE advertisement, it would learn only ambient weather — no CBB/user data. (Confirm whether the link uses BLE bonding/encryption; **low impact either way** given non-sensitive payload.)
- [x] Pairing exposure is limited — no CBB data is written to or stored on the device

### 4.4 Physical security

- If the device is lost/stolen, it exposes **no CBB data** — it stores none. It is a commodity sensor. Replacement is the only impact (cost, not data).

---

## 5. Integration Security

### 5.1 Credential management

- **No credentials** — BLE read/notify of public sensor data requires no key, token, or account. Nothing to store in Key Vault.

### 5.2 Network exposure

- **None.** No inbound rule, no webhook, no public IP, no internet path. Entirely on-device + local BLE radio.

### 5.3 Offboarding plan

- Remove/disable the `weatherflow_tactical` driver via the `SensorRouter` (`sensor_driver_id` DataStore preference). No data deletion needed — none is held by the vendor or device.

---

## 6. Risk Summary

| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| BLE sniffing of sensor readings | L | **Negligible** | Payload is anonymous ambient weather; no CBB/user data on the link |
| Malicious firmware on device | L | L | Vendor per-device-key signed firmware; CBB doesn't flash firmware; device can't reach CBB data |
| Lost/stolen device | L | Negligible | Device stores no CBB data; replacement cost only |
| Spoofed sensor feeding bad readings | L | M | A spoofed BLE device could feed false atmospherics → wrong DOPE; user-visible implausible values; consider sanity bounds on ingested readings |

**Overall risk rating:** **Low** (arguably the lowest-risk integration in the estate — no data, no account, no cloud, no credentials).

**Recommendation:** **Approve with conditions** — pending Founder sign-off.

**Conditions:**
1. Confirm whether the BLE link uses bonding/encryption (document the finding; low impact regardless).
2. Consider sanity-bounds validation on ingested atmospheric readings (guards against a spoofed/faulty sensor producing wrong DOPE).
3. Add WeatherFlow Tactical to the "CBB Risk Register" SharePoint List (hardware entry).

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (`03_-_Confidential/`) |
| **Location** | `OneDrive/ScopeDOPE/03_-_Confidential/Hardware/WeatherFlow_Tactical_Security_Review.md` |
| **Cross-references** | `Security_Review_Template.md`; `scopedope-shared` BLE driver docs; "CBB Risk Register" SharePoint List |
| **Created** | 2026-06-09 |
| **Last updated** | 2026-06-09 |
| **Next full review due** | 2027-06-09 |

---

## Revision Control Block

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| DRAFT | 2026-06-09 | Claude Code | — | — | Initial draft. Framed around CBB's own `WeatherFlowTacticalDriver` (no vendor app/cloud/account). Device firmware posture verified against WeatherFlow's published device-security page (per-device-key signed firmware, embedded OS, device-initiated comms). Assessed BLE link + physical device only; recommends Approve with conditions. Version number to be assigned by Founder. |
