Building and Operationalising an Empowered CTI Team

To learn more about the Threat Intelligence practitioners utilizing Recorded Future, we sat down with Jasmina Zito and Bianca Forbes, who run the Cyber Threat Intelligence team at Canva.

This wide-ranging discussion talks through how they got into their current roles, recommendations for getting buy-in for a CTI program, and how to showcase value to the rest of the organization.

Meet the Canva Cyber Threat Intelligence Team:

Jasmina Zito, Senior Cyber Threat Intelligence Specialist

Bianca Forbes, Senior Cyber Threat Intelligence Specialist

(Recorded Future) How did you find yourself in a cybersecurity role?

(Jasmina Zito) I started out as a digital artist and a games developer. Then I decided that I wanted a more secure – pun intended – career path that didn’t hinge on my creative output. I sub-majored in network security in university and took a chance on a cybersecurity graduate position, which I really ended up liking. I’ve kind of been doing both ever since.

What’s your role at Canva?

(Zito) I lead the Cyber Threat Intelligence (CTI) team. Since starting in this industry, I have tried a little bit of everything – incident response, security engineering, vulnerability management. Eventually, I settled on specializing in CTI and have been doing that ever since.

When I joined Canva, the role was actually to help build out the detection and response capability. While interviewing, I had some candid discussions with the head of security at the time, and we both agreed it didn’t make sense for there to be any dedicated CTI capability without a mature detection and response team first. There’s honestly no point in threat intelligence if there’s no way to action it, and to do that you need a solid incident response team as your foundation. Imagine flipping over all these rocks and there’s no-one around to deal with the spiders!

After a year or two, we felt we were ready to build out a CTI program, which we’ve done from scratch. While we’ve made a huge amount of progress, we’re still a very lean team and I’m still on a “bit of everything” train: I engineer our collections, automation and intelligence sharing infrastructure; maintain intelligence requirements and alerting use cases; still tag-team on incidents where intelligence analysis can benefit; and design ways for strategic threat intelligence to make its way to the right areas of the business.

(To Bianca Forbes) How did you get started in cybersecurity? And what is your role at Canva?

(Bianca Forbes) I actually started out in penetration testing, which I did for three years, before moving into cyber threat intelligence. When I first got into CTI, I didn’t know much about it. After getting thrown in the deep end, I came to really enjoy researching and tracking adversaries as well as the contacts in the intelligence community that I made. I’ve been doing it ever since.

At Canva, I help run the CTI program with Jasmina. I focus primarily on intelligence operations: tracking adversaries, reporting on trends in the threat landscape, providing analysis expertise in investigations, and crafting threat hunting packages.

How did you get buy-in for building a Cyber Threat Intelligence (CTI) program? Why should other companies consider investing in threat intelligence?

(Zito) To use an industry buzzword – CTI really helps security teams shift left. Traditionally, without CTI, you may be detecting and responding to threats using only the information you have from within your own network. You’re looking for something bad but you’re not always sure what, how, or when.

In my mind, once you detect a threat, you've already got it in your environment. It’s too late. It's already happened.

I think what really helped me get buy-in was to actually start producing CTI products to showcase their value. At the heart of it, the value of threat intelligence is influencing: you use your deliverables to convince the business to do something, whether it’s investing in a capability, changing the way something is done, or paying more attention to an identified risk.

You obviously have to start small and be very curated when you don’t have dedicated resources. I’ve seen it go wrong when emerging teams simply rehash the news or flick on all the threat feeds, which causes a lot of frustration for the people who have to do extra work as a result of the onslaught of new, incoming information. You have to start somewhere but you also have to know what you want out of it all. This is where threat modeling can help. Understanding your organization’s crown jewels and what the risks are (your intelligence requirements) helps you be more strategic about where to start.

In my talk at Recorded Future Predict23 in Singapore, I mentioned a few tips based on lessons learned over time.

Tip #1: Instead of sending out daily security news summaries to a mailing list, try referencing a security report in an action item sent directly to the team who can remediate a specific security risk.

Being that filter between all the sensationalized articles and what your organization actually needs to action helped us build rapport and trust between teams. If you meet your peers halfway, actually read the report and try to make a call on what needs to be done and by whom, you’ve reduced a lot of mental labor for everyone involved. An added bonus is that you subconsciously train folks to pay attention to when you send them something, otherwise I wager pretty strongly that those daily digests are going to end up in the junk pile a lot of the time.

Tip #2: Instead of turning on “threat intelligence” modules and data feeds in all of your security tools, try only ingesting high-fidelity observables that directly map to a threat you’re concerned about.

That doesn’t mean you need to intentionally miss out on a bunch of data during collections. Something Bianca and I have built out is kind of like a tier-based system. All of the observables from our commercial and open source come into the threat intelligence platform (TIP), and they actually all go to the SIEM as well, but that doesn’t mean they all are treated the same way. The bulk, “raw” data is used for enrichment and historical referencing. Then, as part of our usual operational cadence, we will research and validate a subset of observables that meet our intelligence requirements.

Based on our research, we’ll add extra context and metadata to those observables and intentionally mark them as curated so that they become “active” in our security tools and can be used in detection or prevention rules. This way, we combat the perception that CTI is just a stream of low-fidelity observables that cause a lot of noise and alert fatigue.

Once we had that foundation of trust and confidence in the value and fidelity of the curated data, we could then weigh in on the detection engineering process by providing expertise on what metadata can be used – out of the remaining uncurated observable data – to satisfy specific detection use cases.

As you're putting together your Cyber Threat Intelligence function, what kind of information is needed?

(Zito) Once you've got your intelligence requirements – pick three to start off with and then work back from there –you could ask yourself:

• What information do I need to answer those questions?
• Is it open source information? Is it commercial intelligence? A mixture of both?
• What data do I need? How will I then consume that data?
• Do I have a threat intelligence platform?

You need to figure out where you're going to put all of that information, and understand whether you have the technical capability to actually manage all of that infrastructure yourself. If you're a small team and you don't have a lot of engineering resources, maybe you'll actually start off with something commercial and ‘buy’ instead of ‘build’ so you don’t have to think about managing infrastructure and can instead focus on actual analysis.

It can be tempting to get started using open source tooling. I love that there’s passionate people out there collectively building free tools to help with CTI operations. I would be cautious here about the time and skills needed to maintain some of these systems, as they can require a bit of TLC and jerry-rigging. Again, starting small and being intentional about your desired outcome is your best shot at incremental success.

When it comes to people, there are a lot of varying skills among CTI practitioners. For example, because of Bianca's pentesting background, she’s very technically proficient and good at researching how adversary TTPs evolve; and there are other folks who specialize in what I would call more traditional intelligence analysis. It really just depends on your organization and what's going to work best to satisfy your intelligence requirements.

If, like Canva, your organization is tech and software-centric, maybe it’s important you have people with the technical ability to understand how the latest obscure exploit could actually impact you, if at all. Whereas, if you are in critical infrastructure, maybe you need a bit more of that geopolitical background to help you understand which APT groups are a threat to your organization by understanding why somebody would try to come after critical infrastructure in the first place.

How do you think about connecting your people, tools and workflows?

(Zito) If you think about the teams consuming your intelligence products as customers, you need to understand their ways of working, their pain points, and what they need from you to support them. I usually pick one customer at a time, and pilot a workflow end-to-end based after sitting down with them and understanding their requirements.

If you’re into games, pretend this is a role-playing game (RPG) and you’re the support class. Your job is throwing heals and buffs. You’re likely not on the front lines in the heat of the battle, so it’s not really fair if you insist on calling all the shots.

If you use your blue team / SOC as an example first customer, they very likely have their own tooling for detections, their own case management system to house investigations and incidents, and their own internal comms channels. Nobody wants to receive an email with an attached report that has a bunch of random observables listed at the end in no particular format, that they then have to manually put into a system. What a waste of time!

When you talk to your blue team, you may learn that if they could have anything they wanted, it would be for someone to do all that for them and to not have to think about it. There’s no real reason they need to read a report for the threat to be blocked. If they need context, they’ll be able to find it if an alert ever triggers.

Unfortunately, we (CTI) really don’t want to be copy-paste robots either. So we automate. In cases where the analysis has already been done and all we need to do is block some hashes or C2 IPs, why does anyone have to be involved in the process? CTI should be able to click a button to validate an observable, and based on metadata, it goes where it needs to go. That’s essentially what we ended up building.

And that actually means now that when an intelligence report is published, it’s much more likely to be read, because the last one wasn’t just a day ago. We want people to feel confident that silence from us equals no threat to worry about.

(Forbes) A good example of an integrated workflow with Recorded Future is how we develop threat hunting packages. Our team is continually tracking trends in the threat landscape and we have processes to help us identify what is relevant to us. Reflecting back on the idea behind the tier-based system we have for observables, we consume all of the threat hunting packages Recorded Future publishes. Once we identify a threat trend we want to hunt for, we can use the relevant ingested packages as a building block for the final deliverable. It’s especially helpful considering they come with YARA rules and TTPs, so it reduces some of the manual work we have to do.

Once a hunting package is developed, we’ve built an automated message that sends all the relevant information to the threat hunting team, again, integrating with their workflow and tooling. Another benefit of working closely with our customers when designing integrations is we can get valuable feedback about the outcomes of our intelligence products.

Another example workflow is how we mitigate risks associated with our supply chain vendors. By populating our suppliers watch list within Recorded Future, we can then look for things like who's attacking our suppliers. An example would be if one of our critical vendors has been posted on a ransomware blog site. Oftentimes we'll learn about that through Recorded Future before the vendor even reaches out and says, “Hey, we've had an incident”. Yeah, we know we've been watching. Recorded Future allows us to get on the front foot in those types of situations.

How do you showcase the value that you’re bringing to the rest of the security organization? And to the rest of the company?

(Zito) We track the fidelity of our deliverables by showing how much information and data we consume and how much of that turned into some kind of action.

For example, if we pulled in 100 threat reports; shortlisted 20 based on the topic meeting our intelligence requirements; and only 3 turned into an internal threat bulletin with recommended actions –- that’s actually a good thing. It shows that we filtered and curated information really well before it got on anyone’s to-do list.

It doesn’t stop at recommendations or information shared, though. We also want to know how much of the work we have generated for other teams resulted in something useful. If we published a threat hunting package and no malicious activity was uncovered, that’s great. But what else did we discover? Were there any new detection ideas as a result? Is there any additional telemetry that we could monitor?

When we're talking about showing value to the broader organization, it's really about taking the macro trends from all of those metrics and surfacing it into high level insights. Imagine if you started out thinking malware was your biggest threat because that’s what your industry’s threat landscape is telling you.

Once you start collecting data about the outcomes of your intelligence products – What category of observables triggered the most alerts? How many threat bulletins resulted in a security investigation and subsequent uplift, and in what areas?

You may learn your biggest threat is something entirely different. Or, if you don’t, at least the data validates your current assessment. Either way, this can help you drive your overall security strategy by supporting continued investment into existing focus areas or highlighting areas that may need more attention.