Prior to leaving home for college, I spent a summer working as a software engineering intern at Omya, an industrial company that produces calcium carbonate, a chemical commonly found in toothpaste, tissue paper, and paint. Omya’s entire plant was orchestrated and managed by a custom-written factory management system. It was and still remains some of the most impressive and sophisticated software systems I’ve seen. I was tasked with working through some bugs involving the system’s integration with various programming logic controllers (PLCs).

A bird's-eye view of the Florence, Vermont Omya Plant.

Everything in the plant was interconnected; measurement devices, pumps, barrels, conveyor belts, and train cars. All of these physical entities were programmatically represented as objects with attributes that described them and methods that represented their interactivity. During this time, I learned an important lesson in how to apply object-oriented design in software systems.

This knowledge and mindset nicely carried over into the field of detection and response and threat detection engineering. It’s true, the only tangible objects in threat detection exist as physical hardware and the humans controlling them. Everything else is abstracted as logical entities. Luckily, this is where object-orientation design shines. It helps us strip away the deep layers of abstraction and connect logical entities to our physical world. Everything involved in a threat detection engineering system can and should be represented by objects.

Many frameworks and projects exist that attempt to standardize the use of objects in detection and response but are highly disjointed from one another:

  • Security events and data sources: Splunk Common Information Model (CIM), Elastic Common Schema (ECS), Open Cybersecurity Schema Framework (OCSF)
  • Detection Content (rules, signatures, etc.): Sigma, Splunk ESCU, Elastic Rules
  • Atomic indicators, techniques, tools, campaigns, actors: STIX
  • Vulnerabilities: CVE
  • Incidents: VERIS

Threat detection engineering teams should seek to use or borrow the concepts created in these projects in an effort to create a highly connected system of objects that represent every component of an attack kill chain. It’s important that each object’s relationship with one another is well defined.

A simplified representation of the relationship between objects in an attack kill chain.

A highly optimized threat detection program strives to successfully attribute security events, atomic, behavioral, and correlated activity to indicators, techniques, tools, campaigns, threat actors, and most importantly, their motives. At the surface of all of this abstraction, a cyber attack and defensive effort involves two people (or groups) at separate ends of the keyboard. Achieving this level of attribution ultimately arms a cyber defense team with the knowledge and data needed to successfully sever a threat actor’s kill chain and prevent future attacks.

If you’d like to spend more time learning about and practicing object-oriented design, I recommend getting acquainted with object-oriented programming and how it’s applied to most modern programming languages like Python, JavaScript, Rust, or Go. Get familiar with the frameworks and object schemas for the projects I listed above. Spend more time representing your data in a consistent and standardized manner by using data serialization formats like JSON, YAML, or even TOML. This mindset will arm you with the knowledge required to design and build out a threat detection system capable of achieving a high level of attribution.