Intelligence Sharing to Protect Ourselves and Each Other

October 15, 2018 • Amanda McKeon

Our guest today is Paul Kurtz. He’s the co-founder and CEO of TruSTAR Technology, a company that develops collaborative intelligence-sharing platforms with the goal of streamlining the distribution of actionable information for cybersecurity professionals.

Paul Kurtz began working in cybersecurity at the White House in the late 1990s, and later served in senior positions related to critical infrastructure and counterterrorism on the White House’s National Security and Homeland Security Councils under Presidents Clinton and Bush.

We’ll hear his views on information sharing and threat intelligence, and we’ll find out why he thinks that we may not be able to count on the government to protect us in the cyber realm.

This podcast was produced in partnership with the CyberWire.

For those of you who’d prefer to read, here’s the transcript:

This is Recorded Future, inside threat intelligence for cybersecurity.

Dave Bittner:

Hello everyone, and welcome to episode 78 of the Recorded Future podcast. I’m Dave Bittner from the CyberWire.

Our guest today is Paul Kurtz. He’s the co-founder and CEO of TruSTAR Technology, a company that develops collaborative intelligence-sharing platforms with the goal of streamlining the distribution of actionable information for cybersecurity professionals. Paul Kurtz began working in cybersecurity at the White House in the late 1990s, and later served in senior positions related to critical infrastructure and counterterrorism on the White House’s National Security and Homeland Security Councils under Presidents Clinton and Bush.

We’ll hear his views on information sharing and threat intelligence, and we’ll find out why he thinks that we may not be able to count on the government to protect us in the cyber realm. Stay with us.

Paul Kurtz:

I spent a fair share of my career working on intelligence analysis. In other words, fusing data around national security problems. I spent some time looking at weapons of mass destruction, non-proliferation, looking at countries like Iraq, Iran, North Korea, and fusing data that we have from intelligence agencies and other countries to try to put together a picture of what was going on, looking at each one of those countries, regarding their weapons programs.

Then, I moved on to counterterrorism and was on the White House staff and NSC as a director of counterterrorism leading up to the events around 9/11, and there I was, once again, fusing data as to what we knew about terrorist activities — in particular, Al Qaeda and Osama Bin Laden.

This fusion challenge that we had in 9/11 was open wide to me when I started looking at cybersecurity, and I picked cybersecurity up probably right around 2000, right after Y2K, leading into … Up to around 2003 or 2004, and I became very fixated on the idea that we needed to develop a platform from the ground up that would allow us to manage cyber intelligence, share cyber intelligence views and intelligence, and be able to do that in real time. In other words, to be able to say, “Oh, today we have Facebook. We discovered a breach.” Or being able to say, “I’m going to wait for my attorney to come back to me,” and say, “Yeah, I had a problem.’” We needed to do something in real time. So I started building TruSTAR about four years ago, and today we have an active exchange of data underway.

Dave Bittner:

So, before we get to the stuff that you’re doing there at TruSTAR, can you dig in a little bit and describe to us, what was the state of things, in terms of sharing information, before you started to take this on?

Paul Kurtz:

Yeah, well, if you turn back the clock and look at a document called PDD 63, that was a document signed actually by President Clinton, in 1998. President Clinton advocated that each sector should set up an organization in order to share information, and many sectors stepped forward. Obviously, the financial sector was the first one to step forward, and what we’ve found since then is that people want to, so to speak, share information, but the value rendered back to those to share is not necessarily high, for a wide variety of reasons. One is, often, it’s just not timely. Two is, it may be interesting but it doesn’t have context associated with it. Then, three is, often they get the data, and they can’t easily integrate it in terms of defenses.

So in other words, a list service is sent out, and you see a myriad of indicators and you’re like, “Oh, great. Now what?” It sits in my email inbox — what do I do with that now? Or, even if you look at the threat intelligence world, where you have good data that is potentially very useful, a lot of companies still have a hard time ingesting that information. So sharing has always struggled, and we’ve focused so much on the idea of sharing and never unpacked it and said, “Okay, what are the steps we need to do in order to make this happen from a technology point of view, from a value-add point of view, to all those entities that might want to participate in such an exchange?”

And we found a lot of pretty interesting surprises. The one that was probably the most interesting was that in most every company you go into today, they have a hard time managing their own data. In other words, their own cyber intelligence. They may be using a SIEM, they may be using a ticketing system or a case management system, they may be using an orchestration platform. That’s great, but at the end of the day, often, they can’t manage all of that awesome data they have and leverage that against data that might be available from the FS-ISAC, or the IT-ISAC, or the retail-ISAC, or proprietary feeds, or government feeds. And so, sorting out that problem inside of a company, was a big surprise to us. So we spent a lot of time working on that problem.

Dave Bittner:

Tell me, describe to us, what did you come up with as a solution?

Paul Kurtz:

Well, what we did is figured … Much like we’ve seen other areas, say, for example, GitHub, where you have a wide variety of players who might want to contribute to developing code, to basically a repository of information. The way we solved that problem was to basically give the enterprise a private repository to put all their information in. And in that repository, the data is automatically correlated, and then they can begin to see patterns in their own data. Setting aside any data they may have from anywhere else, they can understand their own data more effectively. They develop a canon, or chronology, of everything that’s happened inside their enterprise. That becomes immensely valuable to an analyst who’s playing whack-a-mole every day, and then they can literally point, click, and select the external data feeds that they find of interest.

That is automatically correlated with their own data, so that at the end of the day, Dave, sharing is not just to share. We drive toward sharing because we’re trying to drive down the mean time to respond and investigate events — bottom line. That’s what we’re all after. We’re trying to reduce the tasks and the time associated with getting to the bottom of the problem. And so you have to have that mechanism, that repository, that scalable system, in order to help you grapple with all the data you have. So this has randomly become an intelligence management problem, at the end of the day.

Dave Bittner:

Now, how do you deal with what I would imagine are a number of roadblocks within any organization? I’m thinking specifically of the folks in the legal department, who might … I can see going to them and saying, “Hey, we want to share this stuff with other people,” and them saying, “Have you lost your mind? No.” You know, the easiest thing for them to say is, “No.”

Paul Kurtz:

Well, a couple of things have happened. The first thing we think about is, when you say, “Hey, I want to share information that I’ve been breached,” that does very much become a challenge for the legal office, for the council, to look at. But that’s when you’re starting to look at the problem way too late.

What is far more interesting for everybody is to ingest all of that data about suspicious events. In other words, your SIEM fires off an alert, and says, “Hey, according to the rulesets you’ve given me, you should be looking at this,” so the analyst looks at the data, and often they automatically create a ticket in one of the many ticketing systems that are out there today, and then they begin to try and put two and two together. They may not necessarily have remediated the problem yet or gotten to the bottom of the problem, and you take that data and all of that in real time goes into a repository. So it’s suspicious event data, in other words — it’s not a confirmed breach.

They’re starting to look at data much earlier in the “left of bang,” so to speak. Not right of bang — if you look left of bang, we all have a much better chance of aggregating suspicious event data, discerning patterns, and taking action. And it’s leveraging all of the great tools that are out there today. I mean, there’s great SIEMs in the marketplace. There are great ticketing systems in the marketplace. There are awesome analysts in the marketplace, and all of those analysts are populating tickets, and those are ingested inside of each single enterprise, and so the enterprise does a much better job grabbing hold of interesting data for themselves, and so we come to the legal issues at the end of the day. A lot of the data that’s being exchanged is not that company X had a problem, it’s just that company X, without saying the name of the company, is seeing similar problems to what you’re looking at.

And the other thing that is quite interesting, that has happened along on a separate track, is we’ve been continuing to migrate to the cloud. And so, I remember one of the first companies that we spoke to, they were very intrigued, and they were like, “This looks good. I would like an on-premise solution.” And I said, “Well, that’s not going to happen right now, because we’re a SaaS platform.”

And as the discussion went forward, I quickly learned that they were actually using a cloud-based email platform in order to record all of their investigations. In other words, basically email. But it was a cloud-based email platform. And I said, “Wait a minute. You’re putting all of your super-sensitive information about your investigations in the cloud, but you won’t use a SaaS platform to correlate your own events?”

And we got around that, because it was actually that eye-opening event, because the council said, “You know what? You’re right.” And so, when you step into a lot of different enterprises, they are leaning heavily on the cloud for a wide variety of reasons, so the legal challenges we had when bringing companies together or individually have been not nearly as significant as we thought four years ago.

Dave Bittner:

Now, you mentioned being able to share without sharing names and so forth, so there’s a certain amount of anonymity that goes along with this.

Paul Kurtz:

Oh, absolutely. So if you’re a company and you use the platform, you know all your data is ingested and it’s not redacted. It’s sitting there for you to look at, or it’s correlated, because obviously, it’s very interesting. If you’re ingesting data and you’re looking at internal events, internal investigations, and events that are coming from your SIEM, or in-house that’s been put together by your analyst, you want to see that all un-redacted, but if you begin to want to exchange that data with others, you can easily redact, so to speak, the PII, or the corporate proprietary information. Through natural language processing, we are able to redact that information for you, and then you can send it on to another party.

And you have other companies that … For example, in the retail sector, there are companies that have joined together several years ago, and now they’re getting more sophisticated, and they’re using repositories in order to pull certain information from, let’s say, a school, or other companies in the retail sector, and that data is curated and it drops into another enclave, and then everybody else in the retail community can, so to speak, feed off of that data.

Of course, it’s all anonymized, but they know it’s gone through a vetting process, and much of this data, by the way, is staged via API. It’s exchanged in near real time, so when you think about analysts spending lots of time manually putting data into the system, those days are gone. It simply won’t work. So that’s why a workflow on understanding exactly what SIEM you are using, what case management system you are using, what orchestration platform you are using, what threat feed is of great interest to you is important. Are you using Department of Online Securities AIS data? Are you using SISP data? Are you a member of the FS-ISAC, are you a member of the IT-ISAC, are you using one of the other awesome proprietary feeds that are out there today? I’m not going to name names, but there are a lot of good intelligence feeds out there today.

And then, you grapple with all that, and the individual company can take all that data, feed it into their own repository, and then they can begin to make decisions about what they want to share. But only then are they sharing … They’re sharing only their data. They’re not able to share the data that’s coming from all those, if you will, third parties.

Dave Bittner:

Now, I want to touch on threat intelligence with you, and specifically where you feel it fits in. When companies are aiming to defend themselves, what’s the part that threat intelligence plays?

Paul Kurtz:

Yeah, so, the first point is, “Know thyself.” You have to know what’s going on inside your own four walls. You have to know … You have to be able to have the data from your SIEM, you have to be able to understand what your critical assets are, and you want to be able to understand the vulnerabilities that you have. That’s good, and if you bring that together in one place, it makes the problem much easier.

But then the question becomes, “Okay, what’s going on around me?” And that is where an intelligence-driven approach to security becomes exceptionally valuable, because if you have additional insight from other parties that can give you really rich content, and you can see that directly against your own data, that becomes hugely powerful to you. Once again, what’s the bottom line? We’re ultimately trying to drive down the time it takes to investigate an event and to remediate an event. And so, if you can leverage that type of threat information from other parties, it becomes exceptionally useful.

And you know, there’s a lot of awesome intelligence that is out there today, but you talk to many companies, and you’re like, “Jeez, I just … I can’t use it effectively.” In other words, I know this is super interesting content, but how does it measure up against what’s going on inside my company? I could go to each of these individual platforms, or these threat feeds, and I can look and see, hey, this is important.

They can do that, and there’s great insight to be found. All that takes time. And so, if you’re going to drive down time, you put your data in one place and you see other relevant threat feeds correlated against your data. It becomes immensely powerful, and frankly, takes a lot of the repetition out of the problem for the individual analyst, and also helps managers and CFOs understand what the value of these open source feeds is, what the value of these proprietary feeds is, what the value of a feed coming from the U.S. government, or USERD, or whatever it might be.

Dave Bittner:

How do you recommend that companies dial in when they’re shopping for threat intelligence, trying to figure out what is the best fit, what is the best … Like you say, there are lots of platforms out there — how do I shop around from an informed point of view?

Paul Kurtz:

Yeah, well, one of the first things I would consider looking at is … Cloud Security Alliance released a paper around RSA this year, which lays out some pretty practical guidance on how to go about a more intelligence-driven approach, including the selection of threat feeds. And their point — stated far more clearly than I have here today — is to start from the inside out.
Look at your own data, aggregate your own data, and then understand what your particular needs are, or what your use case is.

So, for example, there are some threat feeds out there that are particularly focused on fraud.
And if, obviously, you’re trying to address fraud, you’re going to be far more interested in those than a feed that is more focused on a particular actor, or an actor set in the more traditional cybersecurity sense. So you want to make sure you’re discussing with whoever, in selecting whatever threat provider you’re turning to, you want to have that, “Okay, what are the problems I’m seeking to solve? Am I addressing traditional cybersecurity issues? Am I addressing insider threats? Am I assessing broader business risk?”

To what degree is physical security important to you? Remember that everybody is walking around with cards around their necks, and ID tags that grant them access to particular buildings, access to computers. You know, all those kind of things add up, so you have to look and understand what your own challenges are, and then find those sources that are of great value, or can be of maximum value to you.

And that’s one of the places where we’ve tried to be helpful, where we integrate with a lot of really valuable producers of threat intelligence. When we look at how … With this platform that we’ve set up, we don’t generate threat intelligence, what we do is correlate and infuse all the intelligence data that’s out there, with whatever is going on inside your system. And so, I’m careful to tell people to understand the problems that they’re seeking to solve, and there are some providers out there that cover the whole waterfront. I mean, they can handle fraud, they can handle cyber. They can handle the more traditional business risks. They can handle physical. But there are some that are boutique and focus on a particular problem.

I also think you want to understand the sourcing. Where’s the data coming from? Is it timely, is it recent? Or the other big, big issue — what context is associated with it? And Dave, I haven’t talked about that enough, because often, when people think about threat intelligence, or even sharing, it’s far too much of a discussion around indicators, and not enough of a discussion about the context around those indicators. And understanding, when did this occur? What else was going on at the same time? Is this associated with other problems that people, or that research, has previously identified? All those things become important.

Now, at the end of the day, there may be some level of … You say, “Hey, these are a hundred really hot indicators that are exceptionally valuable today,” and you obviously want to ingest those, but that’s the ephemeral nature of cyber intelligence. And that is one of the big problems that everybody has to deal with every day is. As you know, Dave, an IP address today could be super hot and bad, but two weeks from now, it could be benign.

Dave Bittner:

Yeah, I’m curious … When you look back at the time you spent in government, and you slowly wind that clock forward, what has that been like? How have you seen our capabilities evolve to where we are today, and where do you think we’re headed?

Paul Kurtz:

Well, I think we’ve seen fits and starts. I think every time we have a big breach, we talk in terms of working together more, and the reality is, at the end of the day, that usually passes pretty fast.

And I also think, at the same time, that we are 20, 25 years into this battle, and we are conditioned, unfortunately, to buy a better mousetrap, or what we think is going to do a better job catching the mice and catching the rats, or a better firewall to keep the bad actors out. And at the end of the day, as we all know, it only takes one way in. It takes one vulnerability. And so, our idea about digging a deeper moat, building a higher silo in order to protect ourselves really doesn’t work, and culturally, I think we’re having a hard time getting out of that mindset. I think within the last couple of years, I’ve started to see a change, largely because four, five years ago, the budgets for cybersecurity started going up substantially in enterprises. And boards of directors started to figure it out and CSOs finally got the attention they needed.

But now that we’re four years in, they’re starting to say, “Okay, well, this budget can’t continue to go up. And CISOs are also being smart too, saying, “Wait a minute, I’m buying this new widget or that widget that is supposed to help me, but ultimately, it’s failing.” And it’s not because there’s, you know, a bunch of trash on the market. It’s just because we are not collaborating or working with each other. Until we start building the capability to exchange and collaborate, in real time, and understand intelligence in real time, we’re going to get whacked.

And I think a new mindset is starting to take hold, and so if you go back in time, going back to your question, Dave, if I look prior to 9/11, and see FBI, CIA, NSA, DIA, you name the three letter agency, trying to exchange data about what they knew, about what Osama Bin Laden was up to, and Al Qaeda’s plans … It was big silos with a nod to each other that they were going to help each other and exchange data, and we all know what happened. We also learned, inside individual organizations — they couldn’t fuse data. This is all documented in the 9/11 report that came out.

Dave, the very same thing has been happening in cybersecurity since 9/11, but in cyberspace. And I think that now people are understanding, especially the potential risk associated with critical infrastructure, and candidly, activity by Russia in 2016 in undermining our election process, that has kicked people in the gut, and now we’re like, “We cannot continue to work on this as an individual, company-by-company basis, or as an agency-by-agency basis. We have to be able to fuse data in real time.” And I think that’s starting to make a difference, but we have a long way to go.

Well, one other point I would add is, I think there are those out there who might say that this follows a traditional national security track, in that government will be able to provide for the common defense. In a sense, the Cold War days, or even the counterterrorism days, WMD non-proliferation activities, the idea that Uncle Sam and our allies and friends, we can work together and solve those problems. And the challenge with cyberspace is, I really do think it fundamentally alters our approach to how we secure ourselves, in that government is not well positioned to defend us. They’re not well positioned because of privacy issues, the authorities that they have, the budget that is available, but most importantly, the attacks are happening at lightspeed. Literal lightspeed. And the ability of the government to step in and say … To stop something that is directed at certain parts of our critical infrastructure — in other words, not directed at government assets — that becomes an exceptional challenge.

And so, the net is that the private sector is probably going to be the leader here. The private sector, if they’re able to continue to build on the progress to date, to exchange cyber intelligence in real time with each other, I think we’ll have a much better chance. But if we’re waiting for government to lead, we’re going to fail. And it’s not because government is bad, it’s just because when you look at the complexities of the problem, and how the private sector leans on these systems … Our critical infrastructure, at least in the United States, is driven by the private sector. Government is not going to be able to provide for the common defense. We are going to have to do, in the private sector, the lion’s share of the work.

Dave Bittner:

Our thanks to Paul Kurtz from TruSTAR for joining us.

Don’t forget to sign up for the Recorded Future Cyber Daily email, where every day you’ll receive the top results for trending technical indicators that are crossing the web, cyber news, targeted industries, threat actors, exploited vulnerabilities, malware, suspicious IP addresses, and much more. You can find that at recordedfuture.com/intel.

We hope you’ve enjoyed the show and that you’ll subscribe and help spread the word among your colleagues and online. The Recorded Future podcast team includes Coordinating Producer Amanda McKeon, Executive Producer Greg Barrette. The show is produced by Pratt Street Media, with Editor John Petrik, Executive Producer Peter Kilpe, and I’m Dave Bittner.

Thanks for listening.