Field mapping

If your file uses column names Beacon doesn't recognize, you'll land on the mapping screen. Tell Beacon which column is which, once, and it remembers for every future upload from that same source.

Why this happens

Every security vendor uses slightly different column names. Palo Alto might call the source IP src, SentinelOne might call it srcIp, your in-house SIEM might call it originating_host. Beacon knows hundreds of common aliases, but if yours is new to us, we ask you once, save your answer as a mapping profile, and auto-apply it every time you upload from that vendor going forward.

Required fields (you must map these)

Beacon can't score anything without these three. They're the minimum definition of “a connection happened.”

• src_ip: the source IP address, i.e. the computer that initiated the connection. Looks like 192.168.1.50 or an IPv6 address.
• dst_ip: the destination IP address, i.e. the computer or server being contacted.
• timestamp: when it happened. Beacon accepts ISO 8601 (e.g. 2026-04-18T14:22:31Z) or Unix epoch time (seconds or milliseconds since 1970). Text dates like “April 17, 2026 10:42 AM” are not supported. See the tips section if you're stuck on this.

Strongly recommended fields

Beacon can still score without these, but the score quality drops noticeably. Map them if your file has them:

• dst_port: the destination port number (443 for HTTPS, 80 for HTTP, etc.). Must be a number.
• bytes_out: how many bytes the source computer sent.
• bytes_in: how many bytes the source computer received back.
• duration: how long the connection stayed open, in seconds.

The bytes_out / bytes_in asymmetry is one of Beacon's strongest signals: malware beacons tend to send tiny check-ins and receive larger command bursts, which is invisible if you only have a combined “total bytes” column. Keep them separate if you can.

Optional enrichment fields

If your vendor already computes these, mapping them saves Beacon the work of recomputing:

• ja3, ja4, ja4h, ja4x: precomputed fingerprints. See Fingerprinting for what these are.
• http_user_agent: the User-Agent string from HTTP requests (identifies the client software, e.g. Mozilla/5.0 ...).
• sni: the TLS Server Name Indication, which is the hostname the client was trying to reach over HTTPS. (Example: if you browse to https://example.com, the SNI is example.com.)
• dns_query: the domain name queried in a DNS request.

Saving a mapping profile

After you've dragged every one of your columns to the right Beacon field:

1. Check the Save profile box at the bottom of the mapping screen.
2. Give it a descriptive name, e.g. Palo Alto firewall or SentinelOne export.
3. Click Continue.

Next time you upload a file with the same column structure from the same vendor, Beacon recognizes it automatically and skips the mapping screen entirely. Profiles are saved per workspace, so your teammates get the benefit too.

Profile limits by plan:

• Recon (free): 1 saved profile.
• Hunter: 3 saved profiles.
• Operator and Partner: unlimited.

Tips and common gotchas

• If your file has both client_ip and server_ip, the client_ip is almost always the source. Map it to src_ip.
• If your only byte field is a combined total (no separate “in” vs “out”), pick one of bytes_out or bytes_in. Either is better than nothing. Scoring quality still drops.
• Timestamp parse errors are the most common problem. Open one row of your file and confirm the timestamp is either ISO 8601 (2026-04-18T14:22:31Z) or a plain number (like 1713456000). Anything else, fix it in a spreadsheet first by adding a formula that converts to ISO 8601 and save as a new CSV.
• If you get a parse error even after mapping everything, the timestamp column is the culprit 95% of the time.