SecDataOps Careers: A Space Fan’s Route Into Security Data

Maya spent her first year at a small satellite operator convinced that the glamorous work happened in the control room, where people watched passes and issued commands. Then a quiet Tuesday changed her mind. A downlink had been dropping a handful of housekeeping fields for nine days, and nobody noticed because every dashboard still looked green. The engineers who finally caught it were not orbital mechanics specialists. They were the people who looked after the evidence trail. That corner of the profession now has a name in security circles, SecDataOps, and it makes for a surprisingly good career lane for anyone who loves space systems and data.

If you read astronomy news, you already know the spacecraft is only half the story. The other half is the stream of numbers that comes home, gets decoded, stored, and eventually trusted. SecDataOps applies the same mindset to security logs: someone has to make sure the records defenders rely on are complete, readable and affordable to keep. This post follows Maya’s path to show what the work looks like and which skills a space-minded person already has.

What SecDataOps means, in a space-flavoured sentence

The Ops Atlas frames SecDataOps as the craft of engineering and governing the telemetry that defenders depend on, and it uses the phrase “data engineering for defenders” as a shorthand. You can read that framing yourself in the Ops Atlas entry on SecDataOps, which also admits the name is new, pushed mostly by vendors, and has no official standard behind it. Governments describe the same chores under older names such as log management and event logging.

Translate that to a mission. A satellite has sensors, an onboard computer, a radio, ground stations, a decoding pipeline and an archive. Each link can silently fail. Security telemetry has the same shape: sources produce events, collectors gather them, a pipeline parses and enriches them, storage tiers hold them, and analysts or auditors read them at the end. The Atlas calls this chain the evidence supply chain, and SecDataOps is the job of owning every link.

Why the story starts with a gap nobody saw

Back to Maya. The missing housekeeping fields did no harm on their own, but they taught her team a lesson that the Atlas makes in security terms: a source that stops talking looks identical to a source with nothing to say. The discipline answers with something it calls a silence test. Once a month a lab source gets unplugged deliberately and someone times the alert. If the honest answer is “days”, that is your real monitoring gap.

Operators of orbiting hardware will recognise the instinct. Nobody trusts a heartbeat they have never watched fail. In a ground segment you rehearse a lost carrier signal; in a telemetry pipeline you rehearse a lost log source. Same habit, different antenna.

The skills you already have

People who come to this work from physics, astronomy clubs or aerospace coursework tend to bring four things that matter more than any product certificate.

  • Comfort with units, time and clocks. The Atlas insists on keeping both the event time and the processing time, written in UTC with millisecond precision. Anyone who has reconciled spacecraft clock offsets will nod.
  • Respect for raw data. Astronomers never throw away raw frames after calibration, because calibration code improves. The Atlas gives the same advice for logs: keep the raw copy in the cheapest tier and normalise forward from it.
  • Interface thinking. Mission engineers live by interface control documents. The security equivalent is a telemetry contract for each source.
  • Patience with tedious verification. Replaying archived data against a changed pipeline is the unglamorous heart of the job.

What a telemetry contract looks like

Maya’s first real deliverable was a one-page contract for each log source. The Atlas suggests a short list of fields, and she copied the spirit of it onto a template: who owns the source, what schema it follows, which fields are required, how fresh the data must be, which storage tier it lands in, how long it is kept, which canary event proves it is alive, what it costs, and which gaps are already known. It reads like an interface document because it is one.

The Atlas offers example targets so a contract is measurable rather than aspirational. Data arriving within five minutes for 95 percent of events, a parse success rate of at least 99.5 percent, field completeness of at least 98 percent, and a page after fifteen minutes of silence. Treat those as starting numbers to tune, not universal law. The point is that every contract carries numbers someone can alarm on.

A career ladder you can actually climb

Because the field is emerging, job titles vary. You will see “security data engineer”, “detection data engineer”, “telemetry engineer” or simply “logging engineer”. The Atlas offers its own five-step maturity ladder, which doubles as a way to describe what each stage of your own growth looks like.

  1. Reactive. You find out about gaps when someone complains. Entry-level work here is mostly cleaning up after surprises.
  2. Inventoried. You keep a register of sources and score each on a zero-to-five scale for device completeness, field completeness, timeliness, consistency and retention.
  3. Contracted. Every important source has an owner and a written agreement.
  4. Measured. Health monitors, fixtures and automated checks run continuously.
  5. Optimising. You re-tier streams, trim cost and prove with replay tests that nothing you rely on broke.

For beginners the Atlas sketches a 30-60-90 day plan, and it makes a handy portfolio project. Month one is about a register of sources, scores, a retention policy and health monitors on your top ten. Month two adds contracts, parser fixtures and canaries for that same ten, plus a price tag on every stream. Month three moves the three largest streams to cheaper tiers, proves the move by replay, and ends with a first silence drill and a baseline report. A volunteer or student could run a scaled-down version on a home lab and have something concrete to show.

Parsers as code, like flight software

Space software teams would never push an untested change to a satellite. The Atlas applies the same restraint to log parsers. Treat each parser as code, keep sample events as fixtures, and run contract tests in your build pipeline so that a vendor changing a field name fails a test rather than quietly emptying a column. One of the caveats it lists is a good teaching example: in one popular pipeline tool, converting a null value to an integer yields zero, so malformed input can turn into a fake connection to port zero. The recommended fix is to quarantine anything that fails a strict pattern instead of coercing it.

That kind of story is gold for interviews. It shows you understand that data pipelines fail quietly and politely, which is the most dangerous way to fail.

Retention: the long orbit of evidence

Space enthusiasts understand slow timescales. A spacecraft anomaly may only make sense once you compare today’s readings with data from months ago. Security investigations are similar. The Atlas cites a recent breach-response consultancy’s 2025 casework review that puts the global median dwell time at 14 days, but 122 days for espionage-style cases, and one long-running campaign near 400 days. Against that, a default 90-day log retention leaves investigators blind to how an intrusion started.

The Atlas also points to public guidance on how long to keep records, including an Australian-led 2024 and 2025 paper suggesting a starting point of one year for administrative and security logs and ninety days for informational ones, and a US memo with a 12-month active plus 18-month cold minimum. If you want to be useful on day one, learn how those figures differ and why jurisdictions disagree. India’s CERT-In directions from 2022, for example, call for 180 days.

Cost thinking is a career skill too

Satellite budgets are brutal about bandwidth, and so are SIEM bills. The Atlas gives a worked illustration: shipping 400 gigabytes a day of firewall flow records straight into hot storage costs about 400 units a day, while keeping 8 gigabytes a day of summaries hot and sending raw data to a 400-day lake costs about 164, and raw retention actually rises from 90 to 400 days. Learning to build that kind of comparison, and to defend it with replay checks, makes you valuable fast.

Where to go next

If you want a gentle on-ramp, start with concepts you can practise on this site. Our newcomer-friendly tour of low Earth orbit is a nice place to build the physical intuition about why links drop and clocks drift, and the plain explanation of geostationary orbit shows how coverage and latency trade off, the same trade-off you will weigh between hot and cold log tiers. Then pick a small data source of your own, write its contract, and run a silence test.

Maya now teaches a monthly session to new hires. Her opening slide is not about tools. It says: keep the raw data, name an owner for every link, and never trust a quiet channel. Those three lines fit a spacecraft, and they fit a security pipeline just as well.