Indicators of Compromise: What’s Interesting, What’s Not and What Else Is Needed

Presenters: Brandon Dunlap, Managing Director of Research, Brightfly; Ismael Valenzuela, IR Technical Practice Mgr, Foundstone; Mat Gangwer, Information Security Analyst, Rook Security








Join the forum discussion here.
View the webinar on YouTube here.
Read a full transcript of the webinar here.



Transcript

Brandon Dunlap: Good morning, good afternoon, or good evening, and welcome to today’s ISC2 Security Leadership Roundtable ThinkTank. Today’s event is sponsored by Intel Security, and we’re going to be talking about ‘Indicators of Compromise: What’s interesting, what’s not, and what else is needed’. Many of you have heard of indicators of compromise or IOCs, as they are known, and they can be very helpful in gaining some additional visibility into what’s going on in your environment, from the good, the bad, and the ugly, and today we’re going to talk about what makes them interesting, which ones are interesting, and where we can best make use of them in our own enterprise operations, be it from the kind of hunt-and-destroy activities up to and including incident response and incident management.

As always, we’ve got assembled with us today a great panel to take your questions live. And we’re joined first and foremost by Ismael Valenzuela. He’s the IR and Forensics Technical Practice Manager from Intel Security. We also have an addition to the panel today [that you’ve probably heard and seen] before, Mat Ganger, he’s the Head of Security Operations from Rook Consulting, has some good hands-on experience as well. And last but not least we’ve got Jack Walsh, the Mobility Program Manager from ICSA Labs. My name is Brandon Dunlap, and as always, I’ll be your host here for about the next 58 minutes or so.

I want to remind you to please make liberal use of that question console there. Shoot your questions over to me, I’ll be posing those to the panel that I mentioned live. I also want to remind you that today’s event does qualify for one CPE, which will be submitted automatically on your behalf. That CPE is also good with our archive, which will be available shortly after this event concludes today. So feel free to share that link with your colleagues who couldn’t make it to the live event.

I also wanted to let you know we’ve got an attachments section that is chockfull of tons of great material here, [indecipherable] constitutes an indicator of compromise or attack through some incident response and incident management best practices and tips. So feel free to grab those elements as well. Again, share them, pass them along. Definitely some interesting reading material to be had.

So as I mentioned, we’re going to talk today about hunting down [indecipherable] those indicators of compromise. Ismael, I want to lead off with you, because I know this is near and dear to your heart. [First up] – finding these indicators – what are some kind of the low-hanging fruit, the easy ones to suss out?

Ismael Valenzuela: Thanks for the introduction. It’s really a pleasure to be here.

Yeah, so usually [… so I was looking] this morning, for instance, on one of the latest [indecipherable] that is being now delivered by the, again, [angler exploit kit]. And usually, one of the first things that you get is IP addresses. People out there might be [indecipherable] the machines are getting compromised because of visiting this IP address that is related to the [angler exploit kit]. One of the first things that you usually start with is the IP addresses or hashes, although those can be a bit more tricky to search in your network. Let’s say IP addresses, you have a [indecipherable] is usually what you start with, you have [indecipherable] a terminal, a dashboard, and start looking for connections to those IP addresses.

Brandon: So it sounds like you’ve got to kind of know what you’re looking for here first. Mat, I know in the operations group that you head up there, you guys are monitoring a lot of different sources for some of this information. What are some open-source feeds or areas where people can start to gain some familiarity and start to look for some of the easier-to-find items, like IP addresses and such that Ismael mentioned.

Mat Granger: Yeah, over the last year, it seems, there’s been a lot of frameworks that people have released or at least started projects on. You know you have TAXII and STIX and OpenIOC and projects like [Yara]. Their main goal is to take the information that people have either found on their network or have done research, and put it in a format that’s easily digestible and usable, and some kind of application or code that can then transpose those either into IDF signatures, IPF signatures or other tool formats that allow kind of the easily searchable language, to see if those IOCs are present on your network or host.

Brandon: We’ll come back, Mat, to some of that, the automated components of that, because I think that’s going to be very hopeful to people on today’s call, simply because any opportunity to automate is a force multiplier. I just posted up some additional information on STIX and TAXII that you mentioned, so people can grab that link and run on with that on their own time here. But Jack, the labs, I know Mat mentioned some of the technologies and such, but you guys have watched also these frameworks that he mentioned evolve. We’ve got STIX, we’ve got TAXII, as he mentioned, there’s CybOX as well. These are still in kind of, shall we say, the expert-friendly phase, or are these becoming a little more mature and easier to consume at this point?

Jack Walsh: Well, I think that they are a little complicated, and it’s going to depend on your level of understanding of the technologies and things like that, whether or not you can be able to make use of them. But I think that it’s increasingly the case that folks are becoming familiar with STIX and TAXII for sure. So I think that they become more and more prevalent if they’re not already so in your enterprise or organization. And in the labs, where we’re doing testing of advanced threats and solutions, which is really where we come at this problem from, we make use of them as well.

Brandon: When you say ‘advanced’ … what was that? Advanced threat, solutions… give us an idea of what those defense solutions look like. Like is it traditional firewalls, next-generation stuff? What kind of tools are in that category?

Jack: Right. So I guess advanced threat defense means different things to different folks. So we’re testing vendor solutions, commercial vendor solutions, for how well they detect new and unknown threats, or even little-known threats, that are just a few hours old, that perhaps AV vendors might recognize. So the solution might be multiple components or a single component – in other words, you could have a PC running some kind of software that… you know, [a mobile or PC], throughout the enterprise, they’re all running this particular software, and it’s sending information to a [indecipherable] somewhere, and it’s saying, “Hey, this stuff here that we just detected is a malicious threat.”

So that would be one example. Another example would be, like you said, it could be a [perimeter] device that acts alone, and perhaps even something that has multiple components where there’s an endpoint piece of software that talks to a [perimeter] device like an IPS or a firewall, and perhaps would send questionable samples to a local or in the cloud type of a sandbox.

So there’s really different solutions that vendors have to handle these advanced threats. And the way I look at it is that I don’t care whether it’s one component, whether the vendor has one component or whether they have multiple components. What matters to me is how effective are these solutions at detecting new and unknown threats that traditional security products are missing.

Brandon: That’s a good way of putting it. Ismael, from your perspective, as we’ve talked of just a moment ago with regard to the low-hanging fruit… we heard Mat take that into some of these [indecipherable] structured formats and such, Jack talking about where the advanced defense technologies may or may not sit in your enterprise. Is there kind of a best place to look, or where should people in their enterprises start to investigate and hunt for these things? Is this going to be in the endpoint environments, the server environment? Should we be looking beyond maybe, into the partner ecosystem with regard to cloud services, even perhaps into our own joint ventures and suppliers, for example, as well?

Ismael: Yeah, that’s a very good question. One [indecipherable] for 15 years, and [indecipherable] [response in particular] for the last seven, kind of full-time. And in the past, we would look more at the network – network indicators. We would focus on those, trying to find traffic to, as I mentioned, specific IP addresses or domains, certain kinds of traffic that doesn’t adhere to [RFCs] or to normal traffic [indecipherable] in the network. And that’s still very valuable. But towards the last few years, we’ve seen also a focus on the endpoint. And I think that both are really necessary. You need to [indecipherable] compromise in both the network and the endpoints. Because the main thing in the end is the [context].

Sometimes, we think that we’re going to get this [feed] from whoever the source it is – it could be a vendor, it could be a [indecipherable] sources, as you mentioned before. One of the solutions I actually like is a CIF, collective intelligence framework, which is an interesting project maybe some of our research [guys] are familiar with. But whatever the tools are, sometimes we tend to think that we’re going to get this [feed], these IP addresses, these domains, these hashes, and we’re going to find stuff immediately. And sometimes you find stuff, but the problem is that you do not have enough context.

We did a survey earlier this year, and we were asking the respondents where do they spend most of their time, in doing which tasks, and we found out that most of the time is spent in actually scoping the [internet]. So that’s one of the challenges – you find something, and you try and find out what it is. Is this just [indecipherable]? Is it maybe something more advanced? So in order to have a full picture of what’s going on, in order to scope the whole of the internet, you can’t just look only at the endpoints or only at the network. You have to look at all these different pieces, so that you can put the pieces of the puzzle together.

Brandon: Now, when you say that they’re spending most of their time scoping [indecipherable] do you mean that they’re just trying to identify what the breadth of the attack activity is or that they’re trying to scope where they’re looking for these things?

Ismael: Trying to scope what’s the impact. In the past, we would have incidents every now and then. And it was even kind of a romantic thing. “Oh, we have hackers, we have incidents! We have someone attacking us. Let’s try and find out.” I guess, as everyone agrees these days, it’s just like you have so many incidents every single day that it’s not fun anymore.
[laughter]
Ismael: The challenge becomes with: what seems really important for my organization? I think that [indecipherable] we have come to this agreement that we cannot prevent compromise. And that’s why we’re talking about indicators of compromise, that’s why we’re talking about hunting – because we have to assume that at any given point in time there’s going to be at least one machine that is compromised. So the challenge for the [incident] responder is finding out how… what the context, who is… not so much who is the attacker, but what’s the motivation of the attacker. How much time do we have to spend chasing this? [indecipherable] incidents…

And I can remember some of the [indecipherable] incidents we had in December of 2012, in the [Middle East], where 30,000 machines were destroyed, completely wiped out. We have heard of similar incidents recently, like the [Sony] incident, and many others that haven’t been public, but where attackers are actually [burning] the place down like [indecipherable]. And it’s not [indecipherable] things that we are finding on the field. How can you determine early enough in the cyber attack [indecipherable] or the [indecipherable] cyber attack what the motivation of the attacker? I guess that’s [the most] difficult thing when you do [IR].

Brandon: Well, you know, you mentioned incident response, and I was talking to some colleagues over dinner actually, just two nights ago, and one of them said that as we start to go through this process of identifying indicators of compromise and constantly kind of roaming the halls, if you will, of our network, looking for things, that it has become less of an incident response activity, and more incident management, that this becomes an ongoing, repeatable, cyclical activity.

Mat, I know you get to work with a bunch of different customers, and you guys are providing a lot of support in this realm. Are you finding that customers are becoming more receptive to this kind of ongoing, almost beat cop model, or are they still looking at it as, “Oh, I finally discovered something. Call everybody,” and it’s crisis management time?

Ismael: [indecipherable] So usually, it’s [indecipherable] [reflective abilities], [going] more into a reactive mode, where they do incident response. Whenever they find something, firstly, someone from [a more mature organization] will have [not just an] incident response plan in place, but something that is actionable, something that is proactive, and then they are looking into… some people call it hunting, some people call it just [incident] monitoring, or [indecipherable] incident management – it’s trying to have a proactive posture, knowing that there is something bad going on in your network, and now you have to search for that, searching for those indicators of compromise or indicators of attack, trying to understand what’s the context, what’s the motivation of the attacker, and how important is that for my business.

Brandon: That kind of filtering, if you will, I think is important. Mat, with the work at Rook that you guys do with your customer base, are you taking this kind of hunting model, where you’re just kind of… or continuous monitoring, as the audit community puts it, or are you finding that the lion’s share of your customers are driving more towards that, “Oh god, here’s the problem! Crisis!” kind of…

Mat: Yeah. I think historically – and that’s been changing here recently – it mostly has been kind of a reactive model, where there’s an IDS alert or something triggers on the network, and it’s response mode, and trying to figure out what happened, and follow the lifecycle of the incident through to the end. We do have dedicated teams here that are more in that proactive role, hunting and digging through the information that we have available through the different [sims] that we manage, looking for what we would consider anomalous activity.

And I think that one thing that the industry in general may not do well is how does that lifecycle circle back around on itself – so you go through all of this research and identifying what the threat is, and you’ve settled on your standards, whether that’s the CIF framework or STIX or TAXII. How do you take that information that you’re gathering, and your instant response or your continuous monitoring and hunting, and put that back in the [hopper] for the next time that it comes around. So taking the information that you’re gathering, and going through the lessons learned phase, and making sure that goes through the cyclical process of getting back into the tools, so if it happens again, you’re already… you have the identifications in place or you have the protections to stop it.

And then the other part of that… go ahead.

Brandon: So you’re talking about… you’re building and compiling this kind of ever-growing list in that regard, is that what you’re saying?

Mat: Yeah, correct. So IOCs aren’t necessarily a one-size-fits-all thing. So the open-source community is great – there’s information out there of common attack vectors that we can leverage, and import, and get into the tools that we’re using on site, but at the same time, each organization has their own set of challenges or their own things that they’re specifically looking out for. So kind of taking the feed from the [indecipherable] community and matching that up with a private feed that you’re managing for the organization, and making sure that that lifecycle makes sense.

Brandon: That’s great, because I think putting it in that context is what Ismael was saying earlier, is critical, and there is a lot coming at this, but [indecipherable] build these kind of cables of IOCs and these kind of compounded volumes of information that we feel are relevant. Jack, I can’t help but think about the work that you guys have done there at the Labs with anti-virus – it sounds an awful lot like signature-based methodology, which, I think we’re rapidly coming to realize, isn’t necessarily sustainable, right?

Jack: Right. I mean, [indecipherable] sustainable, it’s something that’s going to be helpful for known threats. But for unknown and little-known and new threats, obviously, a signature-based solution, traditional solution that’s signature-based, isn’t going to be sufficient. So I don’t think at ICSA Labs… we’re not saying cast out your AV solutions. What we’re saying – complement, supplement your antimalware solutions with something else. So that’s where we see these advanced threat defense solutions, where we really think they sort of fit.

Brandon: Interesting.

[crosstalk]
Jack: And you should also know that there’s a lot of newer vendors in that space, so you do have the traditional antimalware vendors that are in that space, and actually even traditional perimeter defense vendors, who are starting to get into this space, but you also have newer vendors as well. So there’s a lot of good competition going on right now.

Brandon: Well, I’m sure it’s just going to heat up too. We’re starting to see some acquisitions and funding and such hitting this space. I know this one in particular is getting pretty exciting at this point in time.

I’m curious as to a couple of slightly more technical questions that we’ve had coming in here. Ismael, you opened up talking about some of the low-hanging fruit, as we discussed, and you mentioned known bad actors, bad IP address ranges, things of that nature. Where should people go to find this stuff? Should they just be trawling through their firewall logs or maybe looking at their endpoint firewall data? Where’s a good place to start poking around for those known bad actors?

Ismael: I think the best place, naturally, would be the [sync]. [indecipherable] as you mentioned, logs from the firewall, from your IDS, from your proxy definitely, and logs from your endpoint as well. looking for IP addresses, usually, you want to see what your users are [indecipherable]. Most of the [incidents] these days, [where the] compromise happens based on client-side attacks, or a user browses through [… could be a legitimate site], and maybe that [legitimate site] has been compromised or there is some kind of malicious code, like JavaScript or something [indecipherable] in the background that is compromising the machine.

So [the proxy logs are] a huge source for these things, firewall logs for sure, and… sometimes, we tend to think that most of the sources could be external, and you have to struggle with something like that. But I would say also, focus on what is normal behavior in your network. Try to understand how users behave in your network, so you can look for deviations from what is normal. That’s usually very, very powerful.

Brandon: Well, we had… a lot of people, I think, over the years, have… we’re coming in kind of the later generations of some technologies, and I think folks, in many cases, have gone through their second or even third iterations on those. I’ll be curious to see how some of those technologies and capabilities come through as these products continue to evolve.

Mat, I’m curious, again, because of the breadth of customers that you’ve got there. Coming back to that context that you described – obviously, you’re going to know their IP address ranges, their net blocks that they, you’re going to have some visibility into their technologies and such. How much do you have to understand the business side of their organization to add that context and choose the right IOCs, and validate that they are going to be useful for that context?

Mat: Yeah, that’s a really, really good question. Like we’ve said before, there is very low-hanging fruit when it comes to IOCs, and I feel like historically that’s been a lot of networking information – the IP addresses, the domain names, URLs, and things like that, that are easily identifiable. Where it gets tough is when you get down to host-based logs and determining what type of tooling is being used in the environment or could be leveraged, and then, the toughest of them all, the tactics, techniques, and procedures of these [militia factors] and, especially when we’re…

Our objective, as responders, or analysts, is to try to cut off those threats from kind of the tip of the iceberg, and the further down we can do that, the less risk we have as an organization.

The conceptual awareness of the business is pretty critical, because especially if you’re dealing with manufacturing or critical infrastructure, the types of threats and attacks for those industries are going to be a lot different than, say, advertising or financial or healthcare data. I’m not saying that the threats aren’t similar, but the types of targeted attacks and information that people are after, that’s going to be different. And you can kind of tune your [IDF] and [IPS] and your IOC database to specifically look for information that’s relevant to the business function.

Brandon: I’ve heard both you and Ismael talk a little bit about the threat [actors] because you talked about the tools, tactics, and procedures that they use. I think part and parcel with understanding your business and how your company operates is critical to teasing out the types of threat actors that you may be most susceptible to or that are going to find you to be more of a juicier target, shall we say. There’s been a lot of growth, and even some consolidation, as it relates to the threat intelligence data that’s available in the marketplace today, be it open-source intelligence or some for-fee feeds. Where do you see that kind of threat actor intelligence getting married up with the IOC data coming from other sources, to drive that kind of attacker context that Mat was describing.

Ismael: I feel when you do that, when you are [circulating] your own threat intelligence, and that internal threat intelligence you are creating based on the incidents that you have investigated, or adding these extra sources from third parties, from other vendors, that’s when it becomes valuable and relevant to the organization. As I mentioned before, it’s a matter of maturity. This is something that is going to benefit mature organizations that have already some incident response and some hunting [indecipherable] [monitoring] capabilities. Because otherwise, it’s just going to add noise.

You understand your business when you know – so I’m in the financial services business, so who’s after me? And it’s not that much about who, but about their motivation and their tactics, the [TTPs]. Then you can start focusing on those techniques, those tactics, those tools that you know these guys are going to use. And it’s not about mentioning countries or [gang] names or things like that. But we know that certain threat actors, they’re looking after intellectual property, some others are after financial gain. And they will act in different ways. Some of them…

I’ve been working on a case recently where these actors have been, for more than five years, in a financial services organization, looking at documents and spreadsheets, all of that, to try to get some financial gain. And it’s very difficult to detect them, because they’re very silent, they do not leave a lot of traces. So unless you know what you’re looking for, it’s going to be difficult to detect them.

So it’s a combination of things. And as I said before, it’s not [indecipherable] you’re going to get a feed with certain indicators of compromise from a third party, and automatically or magically you can [add that] into your [indecipherable]
    or your [indecipherable] and just press a button and search and everything is going to light up and you can see absolutely everything. I think that it’s more about maturity, and it’s having these capabilities also within the organization, so you can connect that context and know what matters to you. Brandon: I keep coming back to this contextual element – you bring up something interesting there, Ismael, and that is, in your example, you say that they were in the organization for five years, looking at things and being rather quiet. It seems to me like if something’s in there for five years, you might just look at it as normal business. You might not recognize that as an indicator… or that you are actually compromised, because to you, it’s been going on for so long it looks normal, to some degree. I’m curious, as we approach the halfway mark in our time here together… I want to shift gears just a little bit on this, and start to talk a little bit about the operation aspects of this. Coming back again to that compromise between knowing about your own organization, that kind of self-awareness, and then what the rest of the community is doing, and kind of what that signal-to-noise ratio looks like. Mat, you had mentioned picking and choosing things from these various feeds and sources in the open-source community and such. Can you give me an idea, and the folks listening today, what kind of a percentage do you leave on the table versus what kind of percentage you find, “Okay, that’s going to be useful in a given context”? Mat: Yeah. I’m not sure if I have a percentage right off the top of my head. Obviously, we would like to be able to use all of it, or as much of it as we could, just to have that layer of protection. If I had to go with my gut, I’d probably say 60-70% would be something that we would keep, and that might be a strong answer. Obviously, the more signatures or the more IOCs that we have available to us, the more comfortable we’re going to feel that we have protection. But as you’re stating, it’s all about managing that signal-to-noise. So how frequently are these things triggering, is it useful, is it actually an incident or a problem that the security team is going to need to deal with. I’ve always seen, when we deploy tools or when organizations deploy tools, there’s always that initial month or so where it’s just a flood of information. You get the tool set up, and all of the signatures are lighting up, and it’s kind of a mess, to start with. But as it runs, and as people start filtering through that data, you’re kind of learning what is normal, building that baseline, as “This is expected,” or following up to find out if it is expected, and then tuning back those signatures or events that may not be as critical, or putting constraints on them – “If I see five of these in an hour, then I want to be alerted.” So setting up those correlations – correlations help you, for your organization. Brandon: Yeah, I think with any technology, Mat, once we start looking around and first get up, we find a lot of things we didn’t know about. I think that first month that you mentioned, of things being a mess, is absolutely true, just about anything that gives us new eyes on our environment. Jack, there at the labs, you guys get to play with some of the latest and greatest and most interesting things, but more importantly though, the technologies may be leading edge, but, to Mat’s comments there, you got to be ready for some of the deluge of things you’re going to find. As you talk to customers using some of these technologies, Jack, are there any particular [“gotchas”], either from a skill set base that maybe they didn’t realize they needed, or even head count, or any of the operational elements that jump out at you when people start digging into these things? Jack: I think that organizations, enterprises are frustrated – find [indecipherable], figure out what they need to do, to protect themselves. When I was working on the network [indecipherable] prevention side of things, I did a lot of interaction with organizations, with enterprises, and they were all saying… not all of them, but many of them were saying that they wanted to have… they wanted to turn these signatures on, but they were worried about the throughput [indecipherable] their networks. They were worried about that sort of an issue. “Okay, yeah, we’ll turn on these protections, but if we turn on these protections, what’s going to happen? Are we going to be in big trouble, and is the CEO going to be able to read [indecipherable] and stuff like that?” So we found that, at the time at least, that there was a lot of frustration there in that regard. So you get frustration with the enterprises, they don’t… you know how it is in security, or I think you do, that it’s hard to make the case… organizations have trouble making the case for why they need [indecipherable], and they say [indecipherable] [if they are able to] convince someone that they need things, and if they do indeed, and if in a situation like Mat was explaining, where it’s 30 days, things are a mess for 30 days and maybe even more, depending on the organization, it frustrates everybody, and so it makes the security person’s life that much more difficult. So [we’ve run into] that sort of frustration working with enterprises. Brandon: That kind of reminds me, Jack, of when people started to really ratchet and dial down their [IDSs], because [indecipherable] they’re noisy, right? But again, you got to come back and say, “Okay, what am I getting out of this?” And hopefully stem some of that frustration by properly tuning as well. But that also begs the question, I think, of organizational maturity, to some degree. And Ismael, I want to… with your work in incident response and forensic efforts, with a variety of customers, I expect that there are certain stages in a security program’s maturity where this makes sense, and there’s probably a break point where they should be focusing on some of the more basics. Can you give us an idea of when this sort of IOC funding activity should be undertaken and maybe where people should, say, focus on those basic blocking and tackling elements first? Ismael: Sure. [crosstalk] Brandon: We’ll take you first, Ismael. Ismael: Oh, okay. Sorry, Yeah. So security maturity is something that we’ve been talking about in this industry for a while. And some people use [CMMI] or older models. Whatever you’re using, what I think is important is to move from a compliant to a practice capacity. So, for me, the main difference is when you want to just try to be compliant, organizations just want to be compliant, [indecipherable] the standards, they just do the minimum that the standard requires, and are mostly reactive.

    But when you have at least an incident response plan in place, some kind of capabilities to do hunting… you don’t even have to assign people to this IOC hunting like a unique role, but you can have some people working out of your [SOC], some people doing [monitoring], some people doing incident response, some people doing even [system administration], doing some kind of hunting with those indicators of compromise that are most familiar with. One of the key things here, from a financial perspective, is trying to hunt for things that you understand. And it’s the same with any security products – sometimes we see people just sending all kinds of logs [indecipherable] and things that they do not understand. It’s very difficult to make analysis of something that you are not familiar with.

    So that will be my advice, and also: do not hunt on a Friday evening, Friday afternoon, 4 AM, because it’s likely you’re going to spend the rest of the weekend in incident response mode. So that’s [chuckles] the only advice I would give.

    Brandon: [laughs] Oh, that’s [pretty funny]. Jack, was it you that had something that you were going to add in there?

    Jack: I was just trying to make it difficult for Ismael to talk. [laughter]
    Jack: I’m kidding, I’m kidding.

    So the thing is I just wanted to make sure that you weren’t directing the question at me because I don’t think I had a good enough answer. So I think Ismael’s is way better than what I would say.

    Brandon: [laughs] Yeah, no problem. So Mat, kind of going off on what Ismael said with regard to not hunting for things on a Friday – which I think is fabulous advice – are there particular days of the week? Because I know you guys get to see this across multiple customers in your operations there. Are there particular cycles, that you start to see things pick up, either end of the year or maybe end of the week, maybe it is Friday that you’re seeing the lion’s share of these things? Is there any particular… I hesitate to use the term ‘schedule’, but we’ll call it season, to this?

    Mat: Yeah, so your normal, day-to-day blocking and tackling events, those seem to happen pretty regularly. I haven’t noticed any schedule. But in all honesty, for those events or incidents that get escalated up and are needing like a dedicated IR team or forensics done, it always seems to happen on Friday afternoon. Aside from that, there may be some peaks at the end of quarters and things like that, but it’s hard to put a number on it when there’s just so much … the breadth of all the information that we’re taking, and it just seems like it’s a pretty constant attack going on, and there’s not really any peaks or troughs that I’ve observed over the years.

    Brandon: Well, it sounds like this is becoming the low-level hum of background noise for all of us, as you said, Mat. The world is a cruel and brutal place there, and the attack cadence is pretty constant.

    Ismael, you mentioned this, not doing this hunting, shall we say, on a Friday. But what about as part of the other duties, in the SOC or in the network administration, that you talked about? A friend of mine kind of refers to this sort of stuff as what he calls grout work. The big piles he lays down are the daily job duties and his core functions. But when he’s got ten or fifteen minutes to kill, he’ll go and poke around and hunt for little things. Is that maybe an effective way to get started for this, do some searching, do some tweaking, dig into some logs if you’ve got a few spare moments? Or does this take a concerted and well thought-out program to truly be effective?

    Ismael: Well, it depends on the [concerned] organization, the resources that you have available. [Sometimes on the floor,] if you have more resources, you have a way more mature organization, you might have people who are dedicated to this hunting. But in my opinion, what works well is, in the context of a SOC, you can have people doing monitoring for maybe an hour, a couple of hours, and then move into some hunting. And that, as you mentioned, should be tweaking the [indecipherable] [correlation rules], in my [entire] [indecipherable] for logging additional things.

    And I’ll give you an example – right now, I think everyone is talking about PowerShell attacking techniques. So the bad guys leveraging the use of PowerShell, so if that kind of activity is blended in the normal activity of the organization, [because system] administrators and everyone else uses PowerShell, so it becomes more difficult for the defenders of the SOC to find that activity.

    [indecipherable] definitely those frameworks [we deployed] entire [office] tools that may PowerShell attack techniques, read all these [blogs] and try to recreate that into kind of a [indecipherable], and see if you can actual find that activity, if you need additional login, or if there is some kind of artifact left behind. And I use that for hunting. And I think that doing that on a regular basis, on a daily basis, and sharing that information internally, that goes a long way and it’s very beneficial.

    Brandon: That’s great. I think that we’ve covered a lot of ground, gentlemen. We’ve got about 15 minutes left, and the questions have been coming in fast and furious here. I’m curious also, Jack, if we could get your insight as we approach the end of the hour – with everything that we’ve talked about, from incident response and management to hunting these particular issues to the frameworks coming in to the ecosystem of tools and the skill sets that we need to be cultivating in our organizations… I know you guys have some research that’s going to be coming out soon. I won’t hold you to naming dates or anything, but can you give us an indicator of what’s in the pipeline and some of the more, perhaps, telling things, if you want to gaze into your crystal ball a little bit, about where you think some of this stuff is going based on the work you’ve been doing there?

    Jack: Okay. Well, I will spill the beans a little bit, since there’s only about a few hundred of us on the phone. [laughs]

    [crosstalk]
    Jack: Our little secret, between us few hundred people. And that is that you know, in about a month, like you said, we will be releasing the first round of testing results for this advanced [indecipherable] defense solution. So there are a handful of folks that were able to meet the criteria and pass… basically they were able to detect… detection effectiveness to a certain degree, and timeliness of that detection, and not alert us to many false positives, and [due logging] of all these sort of new threats. So we will be able to share that with you guys, because… with everyone – it’s publicly available information. That’s how we do it, everything is available to everyone. So it’s not private, for the vendors and that sort of thing…

    So anyway, that’s in about a month, just over a month from now. So we’re looking… what we have, in terms of [indecipherable] compromise, they’re basically a side effect of all this testing that we’re doing. We see… we end up producing a whole bunch of them or finding a whole bunch of them. So things like [caches], most examples that… I think Ismael mentioned that earlier today, the IP addresses of course, you mentioned that. Those are things that… the easy ones perhaps, but those are things that we’re seeing in our testing as well.

    One of the more interesting ones that we’re seeing is the IP addresses that [you use] for malware, [command and] control traffic. So we’re seeing a further subset of the things, [they were using SSL] with self-signed certificates. We believe that the certificate data is following patterns that indicate that they’re not legitimate. And we’re seeing stuff like that. And this is… that’s interesting, and just another thing that we’re running across in the Labs during this testing.

    Brandon: That’s some interesting stuff, command and control activity has been one that also piqued my interest, and I’ve been seeing some interesting stuff come out of the market. It seems to be everybody making this race to get their hands on DNS data, for example, as a way to do some of this command and control kind of capture stuff.

    Ismael, I know, obviously, from our sponsor here today, you bring a wealth of information from that point of view. To go on with what Jack mentioned, is there anything particularly compelling or interesting that you see coming from the marketplace to either improve our incident management capabilities or improve our detection capabilities? Where do you see some of this stuff going, from your perspective?

    Ismael: I think we’re going towards [automation], and now the industry is focusing more on detection. As I mentioned earlier, I think that everyone now understands that you can prevent compromise. So you still have to keep working on prevention, but now the focus is… and it’s going to keep going on to detection, how to reduce detection time, how to use effective indicators of compromise, or indicators of attack, that can shorten your response time. And automation is very important. There are special [indecipherable] everyone agrees there is a shortage of skills in this industry that is huge. So how can you do more with limited resources?

    It has to go down to automation, and [that ties into the ATD] conversation that we had before, how do you correlate all these things, how you automatically analyze artifacts, and tell your endpoints to [block] those. That’s where I can see the industry going, and that’s what we see today from many vendors as well.

    Brandon: Now, great point – I think we’ve seen a lot of that in security over the years, that automation becomes crucial, especially in shortening our response time, not just making our workloads easier, but also closing the window, if you will, on the bad activity as it’s happening.

    Well, guys, we’ve just got about 10 minutes or so left here, and I want to briefly take a moment here, and kind of recap a little bit what I’ve heard, and then I want to go around the table with each one of you and get some closing remarks. Maybe it’s something that we didn’t get a chance to talk about in the short time we’ve had together, or perhaps that we did touch on but you want to further reinforce or add some more information to.

    So I’ll start off going through the closing remarks here, about what I’ve heard, and it sounds like there has been a lot of technological advancement here. We are seeing older technologies adopt some capabilities to identify some of these indicators of compromise, which is great. That’s again taking that automation and perhaps improving our own visibility, but with that visibility obviously comes a need to respond or clean up or otherwise mitigate or manage what we have found.

    You can sleep well at night in a hotel room if you just turn the lights on, but if you turn the black light on, maybe not so much. And this is kind of that same scenario, where we’re changing the wavelength of light and we’re seeing new things. And that’s going to cause new demands on our security teams, or our outsources, our service providers, as we start to uncover these things. And [from] that point, that first month gets a little messy. You might dial this thing up, and turn it on, and boom, you’re suddenly crushed, and no other work is getting done.

    So there needs to be some contextualization of this, not just around your own business operations and such, but also to take the time to understand who and how you might be targeted, and use that as another mechanism for adding context and adding some degree of, I guess, filtration, on the types of things that you go looking for.

    We’ve also heard that there are some low-hanging fruit, a couple of times mentioned known command-and-control services and sites that are dropping [out of] nowhere, IP addresses being very easy to detect – there’s a lot of places in the network that you can find those – but it [does] sound like a lot of this is going to be dependent upon getting that data in one spot, so that you can start looking for this. And that, in and of itself, may take a degree of expertise and perhaps even some investment, both in time, tools, and capital, and other efforts there.

    So that’s what I think I’ve captured out of the day so far. And I want to, like I said, go around the table, get some closing remarks from each of you. Jack, I’d like to start off with you if I could – something perhaps that you wish we would have had more time to talk about, or perhaps that we missed altogether.

    Jack: Okay. Well, actually, this is something that we did talk about, but I don’t know what [indecipherable] cover it fully, just wanted to go back to it real quick. And that is the STIX and TAXII and CybOX type tools and [indecipherable] using and stuff like that. Before we began the advanced threat defense testing program, about a year ago, we did a pretty large pilot test for a Fortune 50 enterprise organization that had come to us, and during that pilot test, one of the things that we looked at was indicators of compromise and whether or not they did import threat data, whether or not these solutions are able to import threat data using STIX and TAXII or CybOX or something like that.

    So we found that at the time – again, this is about a year ago, so the information is a little bit old – that about a little bit less than 20% of them, that we tested for that particular pilot, were able to import/export that data via STIX and TAXII, and pretty much all of them were doing stuff with [CSV], that type of thing. I just thought that was interesting. It might be of interest to enterprises.

    Brandon: Absolutely, I think it speaks to the continued evolution and maturation of the marketplace.

    [crosstalk]
    Jack: Things have to evolve still, and they continue to evolve, and I’m sure that that will change very soon.

    Brandon: And also, I think, begs the fact that they say it takes an entire village to raise a child, but it takes us, as buyers too, to move the needle and to start to ask for these types of capabilities from our vendors, which I think is critical to ensuring that the toolsets that we need today and tomorrow are actually going to meet our needs. So good point there.

    Mat, just a few moments here to give us your kind of closings thoughts, any words of wisdom from someone who’s done it.

    Mat: Yeah, I think the main thing to take into consideration is the whole IOC market isn’t a one-size-fits-all, so what’s important to one organization isn’t going to be necessarily as important to someone else. And just based on maturity, there’s a lot of information that can be gathered in some of these frameworks for these open IOC formats. Maybe you don’t have the tools or the capabilities to implement all of this, so start with some of the information that you can – if you can pull IP addresses and get that integrated in with your perimeter detection, to start blocking these known malicious IPs or domains, start there, implement it, and then, piece by piece, keep adding in some of that data. Maybe move into DNS or URL, and then maybe from there go into endpoint detection and start pulling some of that information, if you have a sim, out of there, and building the reports to supplement that.

    I guess the other thing that I would hit on is it’s great to have all of these tools and this information at our disposal, but it’s also very, very important to have the process and procedure around using that information and data and those tools, specifically with the IOC information. How is it going to get leveraged in the normal, day-to-day, instant response? As Ismael said, how does the automation work? Can I leverage this IOC data to immediately write a [snork] rule or some other kind of signature that can immediately be effective at the perimeter?

    So I agree with him, I think we’re going to see a lot of uptick in that kind of realm, with the automation of taking all of these feeds, this IOC information, and it kind of being a end-to-end process where the… your endpoints are talking with your perimeter, your perimeter is talking with your endpoints. So it should be pretty fun, 2016.

    Brandon: [laughs] Most definitely. I know I’m looking forward to it. But I think that’s very good advice. You can take a step-wise approach to this. You don’t have to drink from the fire hose all at once. So definitely words of wisdom in there.

    Well, Ismael, thanks again for Intel’s continued support of the program and your time as well. What would you like to send us out on here, for a high note?

    Ismael: Well, I think [indecipherable] but what I would say is we have to fight a lot of noise. So focus on what matters to your business, your organization. Try to determine how to best build some context around your [continuous] monitoring or your incident response program, and try to do some practice hunting, even if it’s just a little bit, a few minutes a day. It can go a long way in improving your capabilities, your skills, and you’re going to learn a lot. But again, as we said before, do not do that on a Friday [indecipherable].

    Brandon: [laughs]
    Ismael: And the rest of the weekend. [laughs]
    [crosstalk]
    Brandon: … advice. I think that’s fabulous, and if there’s nothing else anybody takes away from this, don’t go looking for problems at close of business on Friday. You’ll just be there all weekend. Well, it’s been great having all of you on, as always. I learned a lot as well. I want to remind everybody listening either live or on the archive that there is a bunch of material over on the attachments tab. We’ve also thrown up a number of URLs regarding STIX, TAXII, CybOX as well as the collective intelligence framework and a few other items for you. Definitely want to google around for some of those, very interesting information out there, and a lot of work being done in the open-source community on this too, which I think is always fantastic. It shows definitely the passion for our industry.

    Gentlemen, unfortunately though, we are out of time. So I’m going to have to let you go back to your daily work. And for those of you listening to us live or on the archives, please take a minute and bounce over to the rating tab before you go. Let us know how we did, give us some comments, tell us what you thought of our panelists, tell me what you think of me and the questions that I asked. Do we need to go deeper? Do we need to stay a higher level? Let me know, and we’ll try to improve this in every episode that we have. But until then, I want to thank you all, and I look forward to continuing the conversation.

    End of Transcript

Leave a Comment