There are many nuances in developing actionable threat intelligence. Tags, references, descriptions and sharing restrictions usually top off the list, but none holds a candle to the elusive timestamp. In the world of action- timestamps are one of the most important attributes an indicator has. Without a timestamp there is no past or present, there is no context.
If I made the statement, "drug dealer" and "123 apple road" in the same context, you might consider "ok- you mean recently?". Without a point of reference, you have no idea if I mean "recently", "last month" or "in the 1920s". Yet we see this in many popular threat intelligence feeds. A list of URLs, or IPs with maybe an inferred set of tags, zero timestamps.
There's only one thing worse than intelligence lacking timestamps, one whose timestamps are poorly crafted and/or lack universally accepted standardization. It's well understood that not all cultures recognize dates, times or even calendars the same way. Some of us read "5pm" as "1700", others think the "first of the year" is not "January 1st". Some even write their dates "backwards"...
When I first learned that "not all dates and time is universally perceived", it helped me better understand, time isn't always an exact science. One might argue it's math, there's a clear history of politicians making things up as they go too. I am astonished by the current "datetime" tools available to us as CSIRT operators. Many of them are extremely useful- to a point. They usually try to "do the correct thing" rather than "the right thing".
Python's Arrow library is by far one of the most popular tools in dealing with timestamps, followed closely by Pendulum. Arrow is setup to do most of the correct things you'd need to do as an operator. With the exception, you have to understand the library end to end to do something like:
Pendulum claims to "do the correct thing more often", but with what I've experienced as a glut of dependencies (failing at times). Combined with the lack-luster motivation to improve the library based on community feedback.
As operators, we're often caught between three rocks- two popular libraries that "almost" do what we need them to, and our own hacked up code that wraps them. In an ideal world, we'd contribute patches to the popular tools in an effort to offload that technical debt. However most tool authors are authoritarian by nature, rejecting pull requests "because you missed a tab" somewhere. Or worse- let them hang out in the wind, for months and years at a time.
I'm starting to realize why- everyone just copy paste's code into their own frameworks, creating more technical debt along the way.
Whether you use this library or not- isn't the point. It's an example template in how to wrap some existing timestamp based tools to enhance your operations. It illustrates the point that context is important and your tools should bend to you- not you to them.
We merge pull requests too. =)
