Resiliency in the Face of High-Profile Breaches and Trendy Threats

This is Recorded Future, inside threat intelligence for cybersecurity.

Dave Bittner

Hello everyone, and thanks for joining us for episode 48 of the Recorded Future podcast. I'm Dave Bittner from the CyberWire. There's a natural tendency, not just in cybersecurity, to be drawn to bright, shiny objects. If you're a security professional, you've likely had to respond to questions from management and your coworkers about the latest high-profile breach or ransomware incident. For sure, that's part of the job, but how do you make sure you're not spending too much time reacting to the latest threat when you could be strengthening your internal resiliency plans?

On today's episode of the Recorded Future podcast, we address the downside of headline chasing and the need for resiliency within security, so that basic, fundamental tasks don't lead to mass chaos within organizations. We've got two guests today, Zak and Ryan. They're both high-level security professionals at a major financial services organization, and in order to minimize the number of hoops they'd have to jump through to get permission from their employer to appear on our show, we're going to respect their request to keep things on a first-name basis. Stay with us.

Zak:

I started working in cybersecurity as a developer coming out of school. I got some experience with vulnerability scanning, dealing with the data, helping create metrics, and that sort of thing.

Dave Bittner:

That's Zak. Again, both he and Ryan have asked us to keep their identities confidential.

Zak:

I quickly realized the power of correlating data and the need to correlate data and information security. From there, I was given an opportunity to move into the space and deal more with threat intelligence, doing similar work — coordinating data, working closely with SIEMs, doing data analysis, and ultimately, correlating it to make threat intelligence.

Dave Bittner:

And Ryan, how about you?

Ryan:

I got my start quite a while ago — about 20 years — in IT, and moved into building and designing monitoring systems on architecting, stuff around that, and then from there, I moved into the security side. I've been working with SIEMs probably for the last 15 years or so.

Dave Bittner:

All right. So let's get into some of the meat of the conversation here. We wanted to talk about some of the pitfalls that come with chasing the headlines. Zak, can I start with you? Can you sort of give us an overview? When we're talking about this, what do people find themselves doing?

Zak:

Yeah, so let's first start with defining what I would call headline chasing. That is, as cybersecurity becomes more and more popular, especially the need for cybersecurity, when you're talking critical infrastructure like financial services, healthcare, energy, defense, that kind of thing, it continues to get more attention in the media, right? Which ultimately leads to more attention, more chatter, and people assuming certain things based on what they read in the media. So obviously, most headlines are meant to capture people's attention, draw them in, and we see this with the cyber headlines as well. However, we all know that typically, headlines only represent a portion of the truth, and it takes some reading, analysis, research, and more to uncover what the media is really trying to portray.

Dave Bittner:

And Ryan, from your point of view, how do you go about prioritizing as these headlines come over the wire? How do you decide what needs your attention?

Ryan:

I think that's where I find this topic kind of interesting. A lot of the work we do with threat intelligence has to do with keeping track of a lot of different signals coming in, so you're going to have kind of trust groups, you're going to have threat intelligence platforms, and you may have products that you subscribe to. You have a large community of folks that's kind of keeping you up to date as to what's going on. And so, what I find is that we're constantly watching that signal, and then you're going to get some spikes in it that come to a media headline. And so, usually, it's going to hit a major news outlet. A vendor is going to start sending an email through the systems, or different people within a few different companies will start sending some information around. And that's where I really see it come into play, is usually, when senior-level management gets hold of a headline, or something hits one of the major news media outlets, it starts getting a lot of focus, really quick. Then you start catching emails from them saying, "Hey, what are we doing on this?" Or you're going to start to see some of that information come out, so that's kind of where I usually see it come up.

Then, from a prioritization point of view, what usually happens is, you're going to get into a position where, as defenders, we're trying to line up our technology in a way to defend a particular asset, a particular entity. And so, there's kind of a process with that. There's a particular set of technologies that we've picked to accomplish that mission.

And so, what's kind of interesting is, in the headline chasing scenario, it's almost distracting from the core mission, right? And that core mission is that defense. And so, you have to have some faith in the mechanisms that you've built, designed, and architected, that they're going to execute and perform well. And so, from a prioritization perspective, to an extent, some of it is just minimizing the turn that can be caused by a senior-level manager approaching somebody and saying, "Hey, what are we doing around this?" Whereas, if you can kind of build systems to communicate to him quickly, or effectively address something and have a quick response on it, you can kind of minimize that turn in the scheme of things.

Dave Bittner:

I mean, it strikes me that obviously, you have a responsibility to answer those questions, particularly if they are coming from higher-up people, from the board of directors, or people up to the chain of command. And yet, like you say, you can't just necessarily drop everything because the CEO got a text message with a news alert.

Ryan:

Yeah, and that's kind of what we see is, in a lot of cases, we may have looked at a vulnerability, or we may have looked at a piece of intel that we got, done an initial assessment, and kind of come to the conclusion that our traditional control should be sufficient to deal with that threat. And then, that's where it's a balancing act that kind of has to be struck. And so, to your point, usually it's, “How quickly can we inform someone about that?” Or do you give them a place to go? A lot of this is just making sure that people are informed, and they kind of build faith in your systems, so I think a part of that is being able to quickly respond to it or give some levels of management visibility into systems where they can go check.

I know the products that you guys provide give us a little … They give us glimpses of that, right? They give us a place to send someone to have them look at an Intel Card. It gives us a place to start deriving, kind of, what is the social media chatter related to this topic? And so, a lot of the tools that are coming out nowadays are very well designed to give us that initial point to point someone to, to kind of give them more comfort with the situation — that we're aware of it, we're tracking it, and something's going on with it.

Dave Bittner:

Zak, do you have anything to add to that one?

Zak:

Yeah. I think it's very similar to Ryan's response. It's using the frameworks that you've already developed, and then basically trusting — or rather, building trust with higher-level management — that threat intel is tracking it. But the challenge is tracking it and communicating it at the same time, right? Because as Ryan mentioned, the second that a CEO, or someone else, sees it on their phone, or their TV, the threat intelligence teams begin to get asked questions, and it distracts from the core mission of researching and analyzing, raising up concerns about the correct threats.

Dave Bittner:

How do you go about evaluating what the various risks are to your systems, to your processes? In other words, when a threat comes in, what's the process for determining how much of your attention it actually deserves?

Zak:

I think some of it is understanding affected systems, right? That's one aspect to it — figuring out your threat landscape, things that are being targeted. Certain industries may not be as much of a concern as if you're in that industry. Rather, you want to pay attention to stuff that's in your threat vertical, or your industry vertical, and from there, you kind of look at your internal systems, your application, and figure out, are the latest threats or the newest item going to impact you? And from there, doing an internal assessment using intelligence and data that you've gathered versus your internal intelligence and system inventory.

Ryan:

It's a combination of taking all of the different teams that play into a security solution. Like, no one person can tackle all of these tasks. We like to think that that's the case. There's always going to be other teams that play, so I think that the key component to that is that initial assessment. And so, a lot of people will have a vulnerability team, or inventories, or a lot of the goods — kind of sound practices that you need, because the industry — or where I see security — it's all about what you know and how you're applying your defenses based on what you know. And so, there's a lot of different data points that you know, and I think some of the most critical ones that are sometimes overlooked initially because they're not as pretty and as flashy as human intelligence, or dark web type finds where you may get some hits off of something like that, would just be internal intelligence. What kind of assets do you have? How are they positioned? What kind of controls do you have in place? Do I know what I have on my network? Do I know if I even run any of those products? Do I know what kind of web code is sitting out there? Some basics like that help with that kind of initial assessment.

And so, usually, everybody's going to try and take an element of data, whether it be phishing, something that you're imagining is going to come against a human asset, or something that's going to come across like the ASA vulnerabilities, or something where they're going to go after a piece of infrastructure hardware that's exposed to the internet. So some of it is knowing positioning, and then looking at the defenses around that.

And then, kind of directing people to the appropriate teams, right? Because I think that's one thing that sometimes we miss, as technical folks, is making sure that we're encouraging the use of the processes and procedures we have in place, which sometimes means you need to redirect managers to the appropriate team that may have a sole function related to that. And so, that's one of those areas that we see that is interesting, where we're talking about some stuff like this.

Dave Bittner:

Yeah. Let's switch gears a little bit and talk about resiliency. To me, this seems like one of those things where people think they have a plan in place. There's that old saying about how, "No plan survives contact with the enemy." When you all are putting resiliency plans in place, what's the process by which you do that?

Ryan:

I completely agree with that statement. No plan is a list of stuff, that'll never ever happen that way. And so, I think it goes back to how you train, how you prepare, how you go about your procedures, right? If you make things overly complicated, they're probably not going to pan out well, so you try to keep stuff as streamlined and as simplistic as possible when you go through these kind of steps, and this different information. And so, I think when it comes to an intel perspective, you try to boil it down to just the basics. What do we know? What don't we know? What do we think the impact is? And keep it fairly simple. What that does is that allows us to take some elements of what we're seeing, distill it as much as possible to its simplest form, and then get it to the teams that we need to take an action on it, right?

And so, I think keeping it simple is where you get the resiliency from. You can have a very elegant, well-thought-out 200-step process, but usually, people aren't going to follow through something that's 200 steps long. So I think by keeping stuff simple, distilling the information down to just the critical components that are needed, and then having details available for when you get a second to breathe, you can look into something a little bit deeper. So that's kind of where I'd go with that.

Dave Bittner:

How about you, Zak?

Zak:

Yeah, very similar. I think part of it is trusting your teams, in addition to keeping it simple, right? Like he mentioned in his previous answer, the coordinating between multiple teams who have your expertise in certain areas will help when everything hits the fan. Keeping everybody on deck, letting everyone do their job, and coordinating a group effort to tackle a very serious issue can certainly help us recover faster and kind of deal with an incident as it arises.

Dave Bittner:

You know, there's that saying in sports, "You practice like you play." I've heard many people say that one of the problems when it comes to resiliency is, it's hard to get people to take time to actually play-act through some of these scenarios, to stick a microphone in someone's face when they have to pretend to be talking to the press when there's a breach, or something like that. For those kinds of things, for convincing the higher-ups that these things are important, how do you approach that?

Ryan:

I think there are a few different ways that are interesting, when it comes to this. There are some practical times when you could use a lesser example to the exercise, the machine, and the mechanisms. A lot of times, you're going to be triaging stuff in, and if it's something that is new, dangerous, unpatched, and you know is a life scenario, you may get these kind of edge cases where it's not necessarily a huge risk. Or you think that for whatever reason, based on your analysis, that you feel the company is in an adequate position, and where I would go with that is that I think there's some value in running some exercises like that where you do it live, you take an edge case, and you just exercise the mechanism. I would consider that training more so than the actual event because when it really counts, you need everything working. And so, you use some of those lesser examples.

And then, we've also done some tabletop exercises, and we're pretty fortunate in some of the management chains that we've had that they do endorse some practices where we do get everybody together. We also get multiple teams, even get into other different elements of the business, so we've been pretty fortunate in that, but I think some other ways to do it are to just use examples that you see day to day.

Zak:

I echo some of those statements and add some as well. Other areas where we've been able to run through simulations, or practices, if you will, have been through some internal competitions, as well as some friendly competitions outside our organization where you take scenarios like the one that you mentioned, where you need to get somebody in front of the press, or you need to run through a scenario on the internal defense side, a new zero-day comes out … What's your next step to ensure that your organization is protected? So, it's interesting to go through those experiences, and you learn different team-building strategies throughout the process, in addition to technical controls, and technical weaknesses, and where you can grow and learn.

The other area is going through the table exercises, as Ryan mentioned, and practicing those procedures, or those different operations that many teams plan, and organizing them and putting them into place on the smaller vulnerabilities, or the smaller threats, so that when that next big WannaCry, or something like that comes up, the teams are prepared. And it's not the first time they run through it, because that's incredibly important, and you kind of learn. It's a personal growing experience for everybody, and it helps organizations grow as a team, as well.

Dave Bittner:

How do you prepare people for uncertainty? I'm thinking about, for example, when Meltdown and Spectre were released, when the information about them became public … I'd say, even now, we're still sort of figuring out what the long-term impact of them is going to be. How do you put people at ease when you don't have all the answers?

Zak:

I think some of it is building the trust like we mentioned earlier, right? So, especially for threat intelligence teams that are constantly watching that signal … whether it's Twitter feeds, trust groups, tools like Recorded Future or other platforms, threat feeds, threat information, or just public news.

If threat intelligence teams can build trust within the organizations, that they're on top of it, in certain scenarios, it's okay to say, "There's still pending analysis.” The entire world doesn't know much about how IT or technology is going to respond to a certain situation, and that's okay when the analysis isn't there. But without that trust, or without that support from an organization, sometimes the answer of, "We don't know right now," is kind of scary. But I think it really boils down to trust, deep analysis, and knowing that if the data is out there, threat intelligence teams are going to find it, and they're going to provide the content that helps people making the business decisions comfortable, right?

Ryan:

There's a lot of interesting components to Meltdown and Spectre, in my opinion. One of the ones is that this is a new type of vulnerability, something that we hadn't typically had to deal with, and so, I think it threw some curveballs that were interesting, and I think they still are interesting, and this is one of few instances where multiple layers of patching was being applied.

When I look at traditional vulnerability systems, most of them are designed around you looking for one particular file being installed, testing one particular method, and you're covered. Whereas, this one had everything from multiple different browsers that were patching for some elements of it — you had the OS patching, and then you had some hardware fixes also being applied to it. And so, I think it was one of those scenarios that really challenged our current thinking of where we sit, what we have to be concerned with, and how we report something as being patched, or saying we're successfully covered for something. I mean, a dynamic that came up often, I know, in our ventures was the cloud element, right?

So, I mean, we all have buzzwords, and cloud is one of those, but there's some virtualized infrastructures that our companies are using. And then, when you start talking about some particular vendors, some large vendors that service a need, you all of a sudden opened yourself up to a risk that existed all along, but I don't think it was understood at the time. And so, I think it goes back to what you're saying. You have to look at management and deal with the reality of the situation that says, "We have limited information. This is what we know right now." It was released ahead of schedule, so everybody was kind of playing catch-up upfront, and I think you tell them what you know. You tell them, and you're kind of firm about what you don't know. And then, you advise them based on what we were saying. In a lot of the cases, I think this came out, and it was rated very low from a scoring mechanism, depending on what vulnerabilities rating system that you were using, and then it kind of worked its way up over time.

And then, there were some more questions being proven, or asked, that required more investigation, and required some elements of the business realizing that the second you decided to deploy some of your infrastructure into a cloud-spaced system, you gave up some control of that infrastructure for the convenience, and the rapid deploy natures of them, or for whatever reasons. And so, that was part of the architecture that you approved, so it gives them some things to think about related to the vulnerabilities. And then, some of it is saying, "You have to have faith in the technical solutions that you have." And then, you have to start to look at, well, what other best practices did you layer on top of your architecture? How are you coding the code that sits on that box? Did you have any data that was sitting at rest?

This one was interesting because there's an element of pulling information out of memory, right? So you may not have been able to cover every angle, but then you had to start weighing that against, "Well, what is it that I'm hosting? Am I hosting static content on that system? What kind of connectivity does it have?"

It was a great exercise, I think, to stretch where companies went and how they looked at vulnerabilities. And so, some of that is just dealing with unknowns, but some of it is also using that as a reflection point to move on. So that's where I think it's a very interesting set of vulnerabilities. It's a very interesting genre of vulnerabilities that I think is going to be exciting over the course of this year, for sure.

Dave Bittner:

Yeah. Let's talk about threat intelligence in general, as it fits into the work that you all do. Let me start with you, Zak. When you think about threat intelligence and the place that it has in the work you do defending your organization, where does it fit in? How do you describe it?

Zak:

I think it fits in with many different areas. One of the big ones is new threat research, so when you talk about these new vulnerabilities such as Spectre, Meltdown, or WannaCry, or the ones that we talk about hitting the headlines … Non-technical people, or non-security people, haven’t even heard about these vulnerabilities. So these are the ones that — not that others aren't — but these are the ones where threat intelligence plays a huge role, whether it's threat intel teams doing some research, automated threat feeds, trust groups, or whatever it may be, being able to dig into that information, and paint a picture of, "Here's what we know. Here's what could be affected." Using some of the internal intelligence we talked about to really lay it out for an organization, and really paint a picture of impact, and determine business decisions based on intelligence we've collected.

I think the other area it really plays into organizations, especially with our work, is SIEM use cases, or developing content to catch badness within an organization. So you can use the threat intelligence and use the data, right? Threat data and threat information that is collected through all those signals that we talked about earlier, and really applying it to internal applications, internal systems, internal logs, and figuring out impact, or potential impact. You can get into all the other buzzwords, or new topics of our interest, where you can apply behavior analytics, machine learning, and those kinds of things to really use the power of machines to catch badness that you'd need a team of 20 to 30 people — if not more — to do without some of that advanced technology and computational power, using threat intelligence.

Dave Bittner:

And Ryan?

Ryan:

So yeah, I mean, threat intelligence is kind of a very broad topic for me. A lot of this stuff, I think, has existed under a different name, so I boil a lot of it down to, you have information and data, and that's what you start with, and it's how you apply what you know. And so, from my perspective, I tend to take a more broad stroke, or broad picture of it that says, "A lot of this stuff is about what we know." So when I look at threat intelligence, it's everything from, what am I seeing on my current network? What do I have coming in for my threat feeds? What are people talking about? What vulnerabilities are coming through the system?

It's when you take all of that and start framing it into pictures to derive an action that becomes actionable intel is where a lot of this stuff starts to find value. And so, some of that is used to just inform folks to make sure they're up to date with the current threats, and that they have what they need to respond to other managers within the company, even, so that's arming a person there with actionable information.

It can also be driving for change. I mean, we talked a minute ago about some major vulnerabilities that are kind of a new variety that we haven't seen before, and so, that's where I would look at threat intelligence and say, part of it was knowing that it was out there early on, trying to keep people informed, trying to keep people apprised of how that's changed over time, and then using that to drive a longer-term result that says, “Maybe we revisit how we deal with vulnerabilities, or maybe we look into our capacities of how quickly we can answer to something.” And so, that's turning the threat intel that we have into longer-term, strategic goals related to that. And then, some of them are going to be operational. Some of them, they're going to kick over to a SIEM and expect you to kind of kick out matches. It's also … Some of our job is to reassure folks that have spent a lot of money on these solutions, that invest a lot of money, time, and labor, that these things are working.

One of the ways I think threat intelligence gets its best press is typically in that role where you show how we're consuming information from multiple sources. It's crossing our infrastructure, and we're taking the appropriate actions. I think those are the ones that get us the most visibility — the day-to-day stuff is just what we do to get by, and it's not necessarily always that exciting. I mean, you may have put in a whole bunch of raw data points that never cross. It doesn't mean that you're not attempting to make actionable intel, it just means that in this scenario, it didn't happen to cross, driving toward an action. You're trying to keep people informed. You're trying to give them the best information and you're trying to position someone for the best win, right?

I mean, we ask a lot of analysts to do a job that most of us don't want to do, day in and day out, and they have the hardest job in the world. You're trying to get them to look at something for a varied point in time, and you want to get them the best information that you can, and you want to aid them in any way that you can, and I think that's where some of that threat intel comes in from that perspective, too. I want to give somebody the best opportunity to make the right call at the right time so that we get the optimal results and it ends in win of the defense, which is what we're after.

Zak:

The other thing that I find interesting is just the need for continual education, right? It doesn't have to be formal education, but just the need for continual learning, or the desire for continual learning, because we talk about things like a new type of vulnerability and new types of analysis, whether it be machine learning, AI, or whatever the new trend is. Continually staying up on different types of analysis techniques, different technical details, or technical systems, to really be able to understand and paint the picture we talk about to make those intelligent decisions.

Dave Bittner:

Our thanks to Zak and Ryan 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.