What is this CHRIME thing anyway?

CHRIME header large


If you work in any intense environment where large volumes of information are processed, you figure out how to be efficient and agile or you don’t last long.  CHRIME came into being as the output of late night brainstorming sessions about how to do things better.  It was borne in the struggle to balance intelligence tradecraft with operational requirements, specifically security operations requirements.  Pushing to complete tasks within service level agreement (SLA) restrictions, without gaming the system to buy the time needed meant the longer, traditional cycle of intelligence development needed to be shortened, but in a way that didn’t sacrifice quality.  Its’ conception started in the fertile field of documentation, not that any of us sat down with a happy face to churn out documentation.  Everyone knows the value and need for documentation, but very little of us like to do it.  Breaking off that time means not spending the time in coding, reversing or investigating.  The fact we had an audit probably pushed that effort to document into being more than anything.  The outcome of the effort to document and standardize operational actions among different analysts and researchers led to realizing that while we all looked at the process differently and felt it was a rather artistic endeavor, reality was demonstrating eight out of the ten actions we took were nearly identical, though widely dispersed in order.  Identification alone meant we could standardize, not just in our approach, but in our results.  Oh, and that audit?  While everyone was happy that we had documented, it also got misused and misunderstood, as these outcomes tend to be.  Thankfully, we had written in a functional deviation from standard process.  Some people just don’t get that there is more than one way to do things…but I digress.


Was it really enough to stop there…

Operationally, we had compiled a commonality of actions that were hitting the mark, but a core group of us still felt the process could be better.  That thought led to numerous bull sessions, usually with appropriate amounts of liquids to imbibe, to hash it out.  While we focused heavily on the process and steps, really it came down to patterns of data, and equally, patterns of how to think.  Everyone rattled on about indicators and depth of detail, but we found after continued scrutiny that the patterns, habits, and relationships were more durable.   Especially in the context of mapping threat intelligence to functional outcomes.  Using data in isolation was a trek towards the mountain of frustration.  Knowing how that data intersected and influenced each other was crucial.  After all, significant resources were being expended to collect and refine data.  The outcome of that collection and processing wasn’t always a rich and useful one.  It was very much a hit and miss environment when it came to putting the right data in the right context to make it useful.  We didn’t lack for data.  The industry around threat intel is rife with disconnected data fragments.  From online exchanges to feeds of atomic data, putting your hands on information wasn’t difficult, and in fact, so overly encouraged it rapidly inundated users and the security appliances that were consuming it.  Noodling on what to collect and in what order led to many more sessions over defining that process.  Some pretty fractious brainstorming, too.  Everyone one of us had a favorite or two that seemed we could not do without in the decision making process.


Hashing it out

Diagraming is an important technique to understanding data.  Once we compiled the “must-haves” it was a matter of mapping the forest of connections and dependencies.  We started with operational process schematics and quickly evolved to pulling it all into a comprehensive mind map to show relationships.  Each step was a process of competing those elements we thought crucial against each other to evaluate their need at that specific step.  Remember, we were driving to find the right order and seeing how each operation, each step connected to the next was critical.  To cast that in a way that might make more sense, given an investigation into a phishing event, one of us would start with the email, another analyst would ignore the email to focus on the DNS, a third would look for malware, a fourth would examine the event to understand the execution, and so on.  Everyone’s starting point was different and their decision point was equally variable.  The point of “knowing enough” to make a decision was very driven by past experience, which made it difficult to standardize.  The argument of sufficiency of information was pretty rancorous.

1 before 2, 3 before 4

Eventually, though, we got there.  As the concepts were agreed upon, their order naturally fell into place.  The previous diagrams and procedure flows identified what the most optimum concepts to perform were and at which step.  Once the steps fell into place, it was a matter of finding the right labels to express the concepts belonging to each step.  That’s where CHRIME came in.  Diagraming was such a powerful technique that after enough discussion, everyone agreed it constituted the first, most important step.  Outlining links, especially those 1st tier links was undefeatable.  The act along put the answer into view greater than 50% of the time, especially when contrasted against a storehouse of knowledge.  A couple of us were astronomy geeks and few others recalled all the orienteering we had done in the military.  Diagraming just didn’t sound right and since we were drawing simple clusters and links and nodes of data, the idea of a constellation being built seemed only appropriate.  After all, we were navigating the sky of information by using a pattern of highlighted data stars.  Knowing the history came next.  The past came into focus when history was outlined and was the next step in the chain.  History defined reputation—what are we, but the culmination of all our past actions?  Out of knowing the first three came the hints and signals of intention.  From that point, it was only a matter of determining whether malware was present or connected and lastly, the execution process.


Forwards, Backwards and even the Middle

Conceptually, CHRIME flows from Constellation to Execution as the optimum path but can just as easily be flipped to run from Execution to Constellation given the right use case.  Those circumstances very frequently lead to malware, e.g., execution via exploit that allowed the download of a dropped file that was malicious or social engineering that led to a compromise of credentials that ended in malicious activity.  In those instances where the execution of something is most telling, beginning with Constellation was counterproductive.  CHRIME was meant to be flipped and even curtailed to one or two letters.  The discovery of malware on an endpoint, rapidly meant chasing down its Intent, Reputation and History well before defining its Constellation and Execution.


 Time for Action!

Once we had it defined, it was time to put it in action.  Updating our intelligence and operations processes was the first step.  Next, and most critical, was ensuring we could store and recall the intelligence to really drive home its value.  Once in play, it started showing we were on the right path.  It didn’t replace our current steps in most instances, but instead supplemented most of our existing processes to make them function at heightened efficiency.  That alone paid dividends.


As a technique to fast-type data, CHRIME really steals the show when it comes to security operations and threat intelligence.  I really wanted to highlight where it came from in this article and introduce it a bit more widely than our own organization.  It’s a great technique and over the next couple of articles, I’ll introduce each letter of the acronym and showcase the works.


We also use CHRIME in our daily work and you can find me talking about it at ISSA and conferences pretty much year around.  In fact, CyberDefenses believes in this technique so much that we have a full-day dedicated training course to it.  You can find about our offerings on CHRIME and other topics via this link:  www.cyberdefenses.wpengine.com/academy/.


This is the introduction to a linked series of articles on CHRIME.  What will follow is a breakdown of each letter in the acronym, tied to an example so you can see the technique in full swing.

About the author

Monty St John

Monty is a security professional with more than two decades of experience in threat intelligence, digital forensics, malware analytics, quality services, software engineering, development, IT/informatics, project management and training. He is an ISO 17025 laboratory auditor and assessor, reviewing and auditing 40+ laboratories. Monty is also a game designer and publisher who has authored more than 24 products and 35 editorial works.