Security engineering at trading firms and investment managers

Security at a trading firm is not generic enterprise security with a finance logo on it. The assets are unusual, and so are the constraints on how you defend them.

This guide sets out what the function covers, how the constraints differ from a typical enterprise, a published example of security-data engineering at one firm, and how to prepare. It is a path of its own - not a specialism of infrastructure engineering, even though the two work together daily.

Two assets, two different threat models

Research intellectual property. Signals, datasets, model code and the institutional knowledge around them. The dominant concerns are exfiltration and insider risk, and the controls people reach for - data-loss prevention, egress controls, tight access boundaries, monitoring of bulk reads - collide directly with the working habits of researchers who need broad access to data to do their jobs. Most of the real work is negotiating that boundary without making research unworkable or the control theatrical.

The trading path. Here confidentiality is rarely the first concern. Availability and integrity are. A control that fails closed on a market-data path is an outage with a P&L number attached, and an agent that adds jitter to a latency-sensitive host is not acceptable simply because it is standard elsewhere. Security engineering on this side is mostly about designing controls that are observable rather than intrusive, and about knowing which decisions must be made before the market opens rather than during.

A third, quieter area matters at firms managing outside money: the regulatory and client-assurance surface - due-diligence questionnaires, audits and regulatory expectations around resilience. It is real work and it needs an engineer who can answer accurately rather than aspirationally.

Detection and security-data engineering

The part of the function that looks most like engineering is the security data platform: getting logs and telemetry from many sources into a normalised, enriched form, and turning detection ideas into rules that fire usefully.

G-Research published Siembol, describing it as a scalable, advanced security analytics framework based on open-source big data technologies that normalises, enriches and alerts on data from a wide variety of sources. The post presents it as a user-friendly alternative to Apache Metron following Metron's retirement, describes an advanced parsing framework for building fault-tolerant parsers - Metron's parsing being, in their account, brittle and sensitive to minor syntax issues - and notes correlation rules combining multiple data sources and UI support for translating Sigma rule specifications into Siembol alerting rules (G-Research, Introducing Siembol, 8 April 2021).

Three things in that account are worth carrying into an interview, and they are about engineering judgement rather than about the product:

1. Parsing is where a security pipeline actually breaks. Sources change format without notice; a parser that fails hard takes the detection with it. "Fault-tolerant parsing" is not a feature bullet, it is an admission about the real failure mode. 2. Detections are portable artefacts. Sigma is a generic signature format; supporting it is a choice to keep detection logic from being locked to one engine. Being able to argue about detection-as-code, review and testing is more valuable than knowing one vendor's console. 3. Enrichment is what makes an alert actionable. An alert without asset, owner and context is a ticket, not a detection.

This is one firm's published project from 2021, not a description of how security teams at trading firms generally work. Check the project's current state before citing it as live practice.

A worked scenario: the researcher who downloaded everything

Illustrative, not an account of any real incident.

A detection fires: a researcher pulled an unusually large volume from a research data store at 23:40, to a host that is not their usual workstation. Four readings, all plausible:

1. A legitimate backfill. They are re-running a study and the store's client fetches in bulk by design. 2. Automation running as a person. A scheduled job inherited a human identity years ago - common, and the reason so many insider-risk detections are noisy. 3. A compromised credential. Someone else is using the account. 4. Genuine exfiltration ahead of a resignation.

The engineering questions are the same in all four cases, which is why the platform matters more than the rule: can you resolve the identity to a person or a service *reliably*; do you know what the normal volume for that dataset is, per user, rather than firm-wide; can you tell the destination host's role; and can you answer all three before escalating to a conversation that, handled badly, damages a working relationship with a research team you need on your side.

The right first fix is usually not a stricter rule. It is separating service identities from human ones so the detection stops being 90 per cent noise. Volume thresholds tuned on a population that includes robots will always be wrong.

Comparison: where security engineering sits

Readiness checks

• Explain a detection you wrote, how you tested it, and how you measured its false-positive rate.
• Describe a control you chose *not* to apply because the operational cost outweighed the risk, and how you justified that.
• Walk through how you would distinguish a service identity from a human one in log data you have never seen before.
• Explain how you would secure a host where an intrusive agent is not acceptable.
• Describe an investigation you ran that involved a colleague rather than an external attacker, and what you did about the human side of it.

Questions to ask the team

• Which of the four seats above is this, and who owns the others?
• Does security here own tooling it builds, or configure tooling it buys?
• What is the relationship with the research teams, and when was a control last changed because research pushed back?
• What is the on-call arrangement, and who is the first responder on a trading-hours event?
• How are detections reviewed and retired?

What this guide does not claim

Siembol is one published project from one firm. This guide makes no claim about how most firms staff or tool their security functions, and no claim about a pay premium for security work at trading firms relative to elsewhere; advertised and modelled pay are reported separately in the salary index.