Security Data Science Teams: A Guide to Prestige Classes

Erick Galinkin opens by arguing that security data science is not an entry-level specialty. He uses a role-playing game metaphor: you need prerequisite experience and skills before you can move into the specialized class. A malware classifier that scored near-perfectly on its test set, but mostly keyed on system language and compiler, shows why domain knowledge matters alongside statistical skill.

The middle of the talk covers the job titles that have multiplied across the industry, including data scientist, ML engineer, data engineer, data analyst and MLOps engineer. Galinkin notes that these roles overlap unevenly and that many organizations collapse them under one title, which he jokingly suggests dropping. He describes the work of a security data team as presenting findings to stakeholders, building task-specific data models, and making large volumes of alerts usable for analysts. He also walks through the model lifecycle, stressing that models drift and need ongoing testing and monitoring. Team building, he says, should combine complementary strengths, much like a party in a game, with visualization and infrastructure gaps covered deliberately.

In the audience questions, he explained one way to use language models for analysts: lookups of indicators of compromise and vulnerabilities go to trusted structured data sources instead of the model, which reduces hallucination. He recommended probability, statistics and information theory as foundations, and noted that decision trees often suit tabular security data better than neural networks. His takeaway for practitioners working with data science teams is to state clearly what inputs the team has and what outputs the security side needs.