I’ve been fortunate these last few years to meet with dozens, perhaps hundreds, of security teams of all shapes and sizes, with maturity ranging from a couple smart but embattled analysts all the way up to massive cyber fusion centers with an intelligence capability that likely rivals that of most small nations.
In my quest to understand what makes these teams effective, I started to develop a hypothesis: if you want to do security correctly, at some point, you must write code.
I first realized the importance of what we now call “automation and orchestration” about four years ago, when long-time users of our domain name research products started asking for API access to our data. The most interesting requirements came from security teams at companies in the defense industrial base and, later, in the financial sector. The use cases ranged from “hey, I’ve got a set of domains, I need a bunch of Whois records” to “can I get your brand and registrant alerts via API so I can block the domains proactively?”
As I dug deeper, I discovered these teams were writing scripts that acted as glue between various pieces of their security infrastructure, and that persisted in some system the intelligence gathered externally, or revealed interactively by their analysts.
It was fascinating, and it began to inform the ways we built our products. We knew we wanted to bring as much of that capability as possible to teams early in their maturity. We built our Iris investigative platform to help with interactive investigations on domains, the actors that control them, and the infrastructure they are using, and it’s been very effective for that kind of human-driven research. But as powerful as Iris is, it’s only part of the story; it is most effective when paired with programmatic access to our data for enrichment and automation.
Our list of integration partners is growing all the time, but that can only address pre-defined use cases. Each security environment is unique, with it’s own special blend of tech, targets, and teams, and you very likely need some custom code to put DomainTools data to best use in all the right places.
My “you must write code” hypothesis was further strengthened when I spoke to the cyber security lead at a huge multi-national manufacturing company. He said it was important for him that his analysts were comfortable at a Linux command line. He expected them to be proficient at writing Python scripts that would automate their investigations and, more importantly, document successful workflows the entire team could use.
And then in June of this year, at the FIRST conference in Seoul, I listened as Christopher Clark, Managing Director of Palo Alto Network’s Global Security Response Team, said in his keynote that one of his earliest hires in the new team he built was a programmer. He knew he’d need a dedicated resource to create tooling for his analysts, and he wanted to automate his team’s hunting activities and investigative workflows. He went on to say that the ability to code at a basic level was a fundamental requirement he had of everyone on his team, including himself.
We all laughed when Christopher explained how bad his coding skills were, but I also sensed a certain resignation in the room, as leaders who were trying to build their own teams realized good analysts with coding skills would be very hard to find. Even if they agreed that it was an important requirement, they knew that for their team, Christopher was describing a capability that was entirely out of reach.
I’ve worried about the same thing, because if my hypothesis is true, if you must have code in your security practice to be truly effective, a lot of teams are going to struggle to get the most value out of their technology investments and threat intelligence sources, unless they can find a way to benefit from code without actually having to write it.
What if it was possible, just by drawing a flow diagram, to block a domain name in your web filter based on the Reputation Score DomainTools assigns to it, without either DomainTools or the web filter knowing how to work together?
Or what if you could take a proven investigative pathway for phishing domains, one that reveals related domains by owner or infrastructure, and have it run every time someone in your team investigates a domain name? What if you could make it smart enough to decide what to pivot on, without having to remember if this particular language expects curly braces around its conditional blocks?
All of that, and indeed much more, is possible with the incredible product Phantom has built and the DomainTools app available now in the Phantom platform. The code is still there – it’s just built for you, at the right level of abstraction, with dozens of tidy interfaces to other products, and with the option to edit the code directly if you must. The code is even packaged as playbooks you can share among peers or receive from vendors like DomainTools that enables immediate re-use of proven workflows. You don’t even need to get very fancy with it – just run a quick “domain whois” action and you’ll get the results directly, though Phantom is smart enough to stick those results in a container so you (and your peers) can find it again.
I’ll admit I was skeptical when I first heard Phantom’s claims, but now that I’ve had a chance to run actions and create playbooks with the DomainTools API, it’s made a believer out of me. I simply love how easy it is to get incredibly powerful results with minimal effort, and I can’t wait to show you what’s possible.
Please join Rob Truesdell, Director, Product Management at Phantom and me this Friday NOON ET / 9 AM PT as we walk through the actions and playbooks made possible with the DomainTools app for Phantom.
