Use Python to inspect security data, not to hide reasoning

Start with the data contract

Before choosing a model, define what one row represents, where it came from, which time window it covers, how labels were produced, and which fields may contain sensitive information. Security datasets often combine systems with different clocks, sampling rates, and retention rules.

A clean dataframe does not guarantee trustworthy data. Look for duplicated events, impossible timestamps, missing labels, post-incident fields that leak the answer, and class distributions that differ from production.

• Grain: one login, one flow, one alert, or one user-day.
• Provenance: sensor, query, export time, and owner.
• Label: rule, analyst judgment, incident outcome, or synthetic tag.
• Leakage: fields created after the event that reveal the class.
• Privacy: identifiers that should be removed, hashed, or aggregated.

Features express a security hypothesis

A feature is not merely a column. It encodes a belief about behavior: login hour may indicate unusual timing; destination diversity may indicate scanning; a ratio may reveal asymmetry. Document the hypothesis and the conditions under which it fails.

Avoid identifiers that let the model memorize a user, host, or campaign. Split train and test data by time or entity when random rows would place nearly identical events on both sides.

If you cannot explain why a feature should generalize, it may be a shortcut rather than a signal.

Keep notebooks exploratory

Notebooks are useful for seeing data and testing ideas. They are weak places for hidden state, credentials, unpinned dependencies, and steps executed out of order. When an experiment matters, move the data contract, transformations, and evaluation into small versioned functions with tests.

Record dataset hashes, code revision, parameters, random seed, and results. Without these, a promising model can become impossible to reproduce after an incident or audit.