OpenNSM (Applied Detection and Flow Analysis - Chris Sanders Jason Smith)

Okay, let's go ahead and group update. So we've been talking about to have a VM lab and I put up a XenProject server and we're gonna do a Ganeti cluster with LUGs, XenProject system. However, I had some problems with it. I did get it to run with KVM, but the two systems that I have, they do not support the virtual machine extensions. So what I went ahead and did was just scrap the Ganeti idea for now. And went ahead and passed the system over to ACM, which will have a rack soon. So there's that. Go ahead and get into some of the news. So Bro 2.3.2 was released today. It's just a bug fix release. There were two CVEs that were requested. And did both of them get fulfilled? Yep, both of them got fulfilled. And one was an issue with Binpack and something to do with the improper validation of the data. And then, what was the other one?

DMP3.

Oh yeah, the DMP3 analyzer, okay. So Sourcefire announced Snort 3.0. It's an alpha that was released in December. You can download that. It's basically a, it looks like there's a lot of user friendliness additions. They added like built-in documentation and such. And another thing was they added, they're adding multi-threaded support. So you can actually download that and test it out. It is an alpha. Phase, but it'll eventually become Snort 3. And Suricata 2.0.5 got released in— which is another bug fix release— in December. And then Vlad just let me know today that 2.0.6 is out, which is just patching more bugs. And Security Onion now has packages— or a package for 2.5. I don't know if it'll be for 2.6 yet. There was— There's the Havix remote access tool Trojan that we talked about at one point. There was an article released from NetRestSec where it infects industrial control systems and they did an analysis of that. You can follow that link to get more information on that. Ars Technica was owned and they had actually a very nice responsible disclosure to put it out right away, giving the details and what they don't know and what they did, which is really nice to see. Wireshark announced that they have a personal package archive, so you can actually add that to Ubuntu if you want to get the latest Wireshark packages. And then, it also has packages now that parses out the country code in conn.log. And finally, Dustin Weber of Snorby and Liam Randall of Critical Stack released a free intel service you can go online and grab. It has an API and you can use it to pull pull down feeds and it's catered toward Bro. So you can use that to feed it directly into Bro's intel framework. Yes. How are they making money off of that? They're not right now. It's completely free. I don't want to speak for any— I don't want to speak, but yeah, it's free right now. I imagine there's going to be a paid service for it. Okay, I was going to ask, would you be willing to speculate about their model going forward? No. Okay. But I'm hoping to have Liam or Dustin on to talk about how to utilize it. Alright, next section is the tool tray. This is where we talk about any new tools that we might come across. I'm gonna talk about, I'm gonna quickly advertise them. So I came across this FireShark over Christmas break. I don't actually remember what it did, but let's go look real quick. It's a Firefox plugin that— Oh, it does analysis of HTTP requests and stuff. So you can do redirect chaining, de-obfuscation. Hey, again.

So now I'm not on video anymore.

Not on video anymore?

We can hear you though. Okay, and then we got Surwire was the other tool, and this was a tool that enables you to take what's output of Suricata and Wireshark and take a look at the alerts inside of Wireshark. So that was really neat and actually shows it at the bottom. You can see there's the signature identifier and then the actual message and so on and so forth. So you can actually look at your Suricata alerts in there. And then we have the challenge corner, which I only got one result in from my boss, actually. But we're not going to have time to take a look at that. I didn't have time to look at it and see, to go through it. But we'll actually save that for next week. We'll go ahead and turn it over to Chris and Jason. You can see there's a huge bio on these guys. They've been doing this stuff for a long time. They're pretty well known in the industry. And they're going to be talking about applied detection analysis using flow data. And they've developed a set of tools. One's called FlowBat, one's called FlowPlotter, which we'll touch upon toward the end of their presentation after they introduce us to the idea of flows. How to perform analysis with them. And they had a book.

Jon, can you up your font a little bit?

Oh yeah, sorry. We had a request to up the font size. So you can just read all that. Actually, I'll skip down to their bios right there. And they actually came out with a really cool book recently called Applied Network Security Monitoring, which is actually very good. I've read this and I've reviewed it and it's very detailed and it covers a lot of interesting tools like Bro and so on. So it's all— I'll pass this around if anybody wants to look at it. I'll start over here if anybody wants to check it out. I highly recommend it. It's got a lot of practical examples on how to get started in NSM. All right, Chris, you ready? Pass it to you first.

I am ready.

Excellent. So let's see here, out of script.

All right, do y'all have, uh, y'all have my PowerPoint?

Um, can you kill your mic? I'm sorry, can you kill your— well, something's causing feedback. It might be your output volume or your output source. Sorry.

Can y'all hear me all right?

Yeah, I can hear you. Great, it sounds good now. Unless that was someone else in the audience, I'm not quite sure.

Yeah, I'm not sure if there's a function to mute all, but maybe that might be warranted. I'm getting a little feedback on my end still.

Okay, let me do a quick look for that.

Test, manage participants.

Thank you. Mute all.

Jon Schipp. Mute all and then you can unmute.

Okay, mute all and then— Which one?

Let's see what numbers. Did you see what Darjeans is in?

8, 7, 415 is the number we called in on, but that's not showing up there. One second, let's try that.

Looks like everyone is unmuted now.

Okay, great.

You see on the chat that D.

Hargens can't hear us? No. Deharkins, are you good now?

Yeah, and Chris, I guess.

All right, Chris, did that work?

Yeah, I think so. I'm not getting any feedback anymore.

Okay, great.

Y'all have my slides full screen over there?

Yep.

Yes, sir.

Okay.

Sorry about that. All right, well, no worries. Well, thank y'all for having myself and Jason out. We're always excited to come out and talk about flow data and talk about some of the tools we worked on as well. This is not the exact same presentation we gave at MEERCON last year, but it's pretty similar. Generally kind of a gentle introduction into flow data and then some of these tools like FlowPlotter and FlowBadger that we'll demo. Jon told you a little bit about myself and Jason. My background is mostly Department of Defense type work. I spent quite a while working in the DOD and helping build out a few different security operation centers. I worked in an enclave of the Army Research Lab for a while and then went to Spaywar, which is what brought me to South Carolina, where I helped build out a security operation center that they had there. After that, I made a stop at Enguardians for a while, and now I'm at Mandiant, which was, as most of you know, probably recently, about a year ago, acquired by FireEye. Within that group, I lead a small team that includes Jason on the call with me. We're tasked with taking intelligence data and using it to build effective detection to catch bad guys, which is always a fun job. I used to put pictures of myself on my About Me slide, but then I realized that if it were me, I would much rather look at barbecue than myself, so I decided to put pictures of ribs on here.

Thank you.

We're all hungry.

You're welcome. Is Jason, are you still muted?

Oh, I'm sorry, I have to unmute him. Give me just a minute.

Okay, I'm Jason Smith. I'm probably what you think of when you think of Kentuckians. I like to throw stuff together. I like cars, and the difference, I like to throw Raspberry Pis in them a lot of times. You kind of get what you see at the right there, which is a war-driving dune buggy. But worked for several government agencies, the state of Kentucky most recently, and now I'm over at FireEye. I'm not really an expert at making food, but I am an expert at eating food.

As Jon mentioned earlier, we did write a book called Applied Network Security Monitoring. Basically, if you're interested in anything you hear today, there's a whole couple of chapters in the book focused on flow data and making effective use of it. If you like what you hear today, consider taking a look at that. All the author royalties from the book go to support a few different charities, which is something we're pretty proud to say. Today we're going to talk a little bit about flow data, specifically why it's important and what you can do with it. I like to give— anytime I give one of these talks, I try to give just a sentence or two that says what I'm hoping that you can take away. In this case, it's really why you would want to use flow data in network security monitoring and incident response or really how to do so. This is an open NSM group, so I'm not going to spend a lot of time on describing NSM because I feel like we're already at that point, but I do want to talk a little bit about how I approach it. I approach it in a manner with 3 real steps. We call this the NSM cycle. Collection, detection, and analysis. Collection is focused on getting data, more or less, right? That's generally going to be a function of hardware or software. So that's collecting full packet capture data off the wire. It's generating flow data from full packet capture data or off the wire itself. Basically gathering data you need to do security analysis and detection. Detection is taking that data and looking for anomalies. This can be signature-based, it can be anomaly-based, whatever, it doesn't really matter there. But this is generally gonna be a function of either software, like an intrusion detection system, or of hunting. When I say hunting, I mean manual digging through data by a human analyst. And then the last step of that is the analysis phase. That's when you take that data you've collected, you found an anomaly, and then you kind of build a case, an investigation. On that data, and you're basically trying to determine if something bad has occurred. Analysis, while certain aspects of it can be a little automated, I'm a firm believer in that the analysis phase of this is a human-centric process, and because of the number of data sources you have to parse and the decisions you have to make and all the nuance that goes with that, analysis is always best done by a human, and humans should really never be taken out of the loop there, in my opinion. So that's a human-centric function. I intro the NSM cycle there because I think the evolution of them is kind of interesting. On the previous slide you saw that it was indeed a cycle, right? One feeds into the other, and even at the end of the cycle, an investigation in that analysis process can feed back into your collection strategy and what data you collect in there. While it does take a distinct set of steps there, it's not really how it's evolved over time. I've not been around as long as some of the forefathers of this industry, but I've been around long enough that I've seen a little bit of an evolution in the emphasis of NSM technologies and focus. In the past, really, the big thing we saw is kind of the rise of the detection era, and this is kind of spawned off the success of antivirus, right? That's when we had things like Snort come along where you can write signatures and detect bad things on the wire. Really the only limit you had in front of you at that point was how much data you needed. The idea was get all the data you can, everything from your network edge, and throw it through your IDS and you'll be able to detect everything, detect all the things. This worked back then, right? As time progressed into what I'm calling the present, that didn't work so well. The main reason being because our networks got faster and our networks got larger. At that point, it didn't make sense to collect everything because it was just data overload. First of all, the hardware and software doesn't scale, so it's just not an easy thing to do and it's expensive. Beyond that, it's just not feasible to look through that much data. I think that gets us to where we really are now, and that's the collection era where folks are really starting to take a deep hard look at all the data sources they have coming into their network security monitoring infrastructure and picking and choosing what makes the most sense. Where the risk lies. I always tell people to ask yourself from a business perspective, what's your greatest fear? And then translate technical risk from that. And you make decisions based upon that to determine where you want to collect your data and how you want to do things with it. I think most people are generally in this phase right now. Some folks are just getting into it. Some folks are right in the middle, but I think probably 90% of folks from my industry experience are in the collection area right now. I think we're moving towards an era where we're gonna be in the analysis era where folks are starting to look inward at their own internal analysis processes, examine their own biases, think about case management and things like that and stuff that the industry really hasn't gotten to as much. So some people are really getting into that now. I know that's a research area of mine, the application of kind of cognitive processes to security investigations. I think that's where we're going. All that to say that we're obviously— I think most people are in the present now, so that's what we're going to focus on here a little bit. Some of the challenges of the present. I think most people know that we all want to get full packet capture when it's available. Full packet capture is really the end-all be-all of network data because it's everything that happened. It's like a recording of a phone call, right? You know who was talking for how long and everything they said, which is great. Beyond that, from a collection standpoint, it's really easy to capture the data and filter it. A lot of tools exist for this, your NetSniffNGs and things like that. From a detection standpoint, most major detection tools are PCAP-oriented, so Snort, Suricata, Bro, they can all read PCAP and that makes that easier. And then again, from the analysis perspective, it gives us the who, where, when, and what, which is all the good stuff we really need. Now the downside of this is capturing full packets for everything is not entirely feasible, right? I've already hit on this a little bit, but from a collection standpoint, it's not exactly scalable and you don't see a lot of extended retention. Most organizations of scale that I see that are collecting PCAP data can only afford to do it for really sometimes minutes or hours, in some occasions days, maybe a couple weeks, but really that's becoming more and more rare. You don't really see as many folks nowadays collecting full packet data for months at a time or especially not years. From a detection standpoint, full PCAP is not exactly the ideal thing for hunting, so going in and manually digging through data. And that kind of goes hand in hand with analysis. It's not the greatest starting point. Generally, full PCAP, you have a whole lot of data and you have to start whittling it away to get at what you really want to look at. And again, having the data is nice, but if you're spending all of your time digging through it, then you're not really getting the job done. When you compare full PCAP and flow data, which I'm about to talk about, the big difference I want you to keep in mind as far as level of context is kind of the analogy of the recording of a phone call versus the phone bill, right? And I think— I don't know if any of us look at our cell phone bills anymore, but back when, you know, you had 100 minutes a month and you had to be cognizant of that, everybody would always look at their phone bills and they look like something on the right where you had Who called who, how long, and when, right? Pretty basic. So that's kind of what flow data is to PCAP, whereas PCAP is like the recording of the conversation where you also have that context. Flow data is kind of just the summary of it. That's kind of the important analogy to keep in mind. From a storage requirement perspective, certainly that summary data, storing that compared to full PCAP data, it's mountain and molehill. It's very dramatic. Whereas some folks can only store PCAP for a matter of minutes or hours. The majority of organizations I see that store flow data efficiently do it in terms of months, years, or permanently. I've been in many organizations, including very large ones, that are able to reasonably afford to store flow data permanently from some network segments, and that's a pretty good thing, especially when you consider the— I think the statistic is that the average amount of time when a breach is discovered until it is detected is over 200 days. If you have a year of peak flow data, that's really helpful in that scenario. What is flow data? It has a couple different names. Some folks will call it session data. I know in most of Richard Bejtlík's books, he refers to the broader class of flow data as session data. Others will call it just straight NetFlow. I myself generally call it NetFlow just because that's what I've been used to. NetFlow is actually a Cisco term. It's a proprietary version of NetFlow that they have. There are a few different versions of flow data, but most people kind of call flow data just NetFlow all the time. It's kind of like calling a picture a Polaroid. It's just one of those things. But more or less, it's a summary of network communications. You have a process listening on the wire, examining packets going by, and it aggregates those into single records, so a flow record. It gives us the who, where, and when. It just doesn't give us the what. And of course, nothing gives you the why. That's the purpose of the analyst to determine the why, but it certainly gives us the who, where, and when. And it's based on what we call the 5-tuple, which is when you see these two tables at the bottom of the screen here, it's that upper table of source IP, source port, destination IP, and destination port and protocol. So those five things are the 5-tuple. So that is the flow record, and that usually comes with a little bit of metadata. What you see at the bottom there, which is the start time, the end time, and the number of bytes. This would constitute an example of a flow record, is this bit of information. Obviously, there's a lot of things you can derive from this just based upon what you see here. I mean, you see something like destination port 53 and protocol UDP, so you can assume this is DNS. You can look up the IP addresses and get intelligence on those. 8.8.8.8 is a DNS server, so that makes sense. And you can look at the bytes and figure this is maybe a DNS request based on that. Now, if it was an outbound connection to a DNS server and it was 600 bytes, then maybe, maybe that's a little more there that's worth looking at. But generally, there's a little bit of data to be examined here. This is an example of several flow records on the screen at once. As you can see, this is not the easiest to to read holistically, especially if you're going through this stuff nonstop in a terminal window. It takes a little bit of getting used to, especially if you're not used to looking at command line-based data. So building flow records. Again, I mentioned you have a process generally. You can build them from reading PCAPs, but a lot of times you're gonna be just listening off a monitor port on a sensor or off of a router or something like that. Just something that sees packets at the choke point you want to look at. And the way it does this is by examining that 5-tuple. And I kind of imagine this like a guy sitting on a conveyor belt, like a factory assembly line. This is the part, if you could see me, you'd see me waving my hands around and demonstrating this, but you'll just have to imagine for this purpose. But more or less, you have this guy sitting on this assembly line and he's watching packets as they go through. He'll take a look at the first packet, he'll look at that 5-tuple, which again, source IP, source port, destination IP, destination port, protocol. He'll look at that and he'll essentially make a hash of that. He'll look for unique occurrence of that. He'll look at that 5-tuple and say, "Oh, I've not seen this one before." He'll take it, put it in a can, and label that can. Then another packet comes through. If it's got that same 5-tuple, that same hash of that 5-tuple, he'll notice, "Hey, I've already got a can open for this," and he'll throw it in there. For every packet that comes through for a certain amount of time, he's going to take it and aggregate it with the existing can that's open, and that can represents the flow record. If something comes through and it doesn't match that 5-tuple, he would at that point throw it in a different can and label it. The concept being that multiple flow records could be open, so to speak, at any time. And this guy's just rapidly throwing these into these different bins. So that's essentially what the process is doing. The big thing here is when those bins get closed, right? Because obviously, if the guy continually threw the packet aggregation data into the same bin forever, you can do that for a long time, right? Like we constantly communicate between certain hosts and so on. So the thing that causes those CAMs to actually be closed are what are called termination conditions. And there are 3 main ones that we look at here, and there can be different ones for different implementations, but the 3 main ones you'll generally find are the natural timeout, idle timeout, and active timeout. The natural timeout is kind of what you would expect for the natural end of a communication sequence. Protocols like TCP are session-aware, so they have to set up a session and then later on tear down the session. They can do that a couple of ways with a series of FINs and ACKs or reset, something like that. These applications are aware of these natural timeouts.. And when they see those, they'll know this flow record's closed. So when I see a series of SYNs and ACKs from a TCP connection, as per RFC spec, when I see that, I would then close that flow record and it would be kind of done there at that point. And then if I saw another SYN between those same two hosts and even the same protocols— protocol and ports— then I would open up a new one. And so that's as you would expect. Of course, not every protocol is like that. Not every protocol has formal session teardown and things like that. So the idle timeout and the active timeout come into play there. For idle timeout, if no data is received for 30 seconds— so I receive one packet and 31 seconds later another one comes in— that second one that came in would then be part of its own flow record. There. The other is the active timeout. This is a 30-minute max. If I'm getting a packet a second from the same the same set of hosts on the same protocols and ports for 30 minutes. When 30 minutes and 1 second happens, I'm going to go ahead and close that flow record and open up another one. Obviously, we have many processes that would last for a long time—downloads, backups, things of that nature—that will go well longer than 30 minutes. So it's just a way to break up those flow records and make them kind of easier to analyze. That last one, the active timeout, 30 minutes is normally the standard, but it's configurable. It's important that your analyst, when you're working with flow data, it's important that they understand that this exists. There have been many times in my investigative career where someone has come to me and said, "Hey Chris, I think there is something weird going on because I'm looking at these flow records and they all terminate at exactly 30 minutes. It looks like a beacon of some sort or something of that nature." That's not always fun. It's just something your analysts definitely want to be aware of when they're looking at these termination conditions. But that's more or less how flow records are built and how that termination condition exists. At this point, I'll turn it over to Jason and let him talk a little bit about collection with flow data.

So what I'm going to talk about is more to do with how do organizations typically collect flow data, what do they use to look at flow data, and I guess more importantly, how can you collect flow data and really get to playing around with it. To the point of making it in your head that this is a thing that should be in every organization or every network security monitoring platform that there is because it is, as Chris is saying, such low overhead and there's really no reason to not have it when every tool involved is free. But the big general idea is that you basically need some sort of routers to send data that are already collecting NetFlow data, or you need to generate it yourself. There are many different fields of thought on which is better, but we usually lean on generating it yourself so that you're kind of in control of it. There's no outside source. Let's say your network operations team they may have sample data. You want to get every record. You want unsampled flow data. And when it comes to what type of flow data do you want, there are a number of those. For generators, I say Fprobe and YAP, there are many more. Like for instance, Argus, which I'll talk about in a minute. But these tools are basically— they sit on the wire and they listen to traffic that are coming across and they will generate flow flow records from those, and depending on the tool, they can send those to another listener that will actually collect everything, or actually I should say bin everything in a way that you can analyze. Different flow types, IPFIX, again Chris is talking about NetFlow in general, they're all very different in that they have different field sets, but some of them are very much the same as well. Some of the popular platforms, which you're going to hear me say Carnegie Mellon quite a bit here in the next few slides, but Argus is kind of one of the older flow solutions. I don't mean it's old as in it's not good anymore. In fact, you know, I really like Argus for, you know, by-flow analysis. You know, however, you know, it's not incredibly well documented by comparison to tools like SILK. But it is very reliable and it's very fast. And when you want to set it up, it is included with Security Onion at this moment right off the bat, and it's useful immediately. Also, Argus, again, it goes back to 1990 when it was really being used. Carter Bullard first made Argus to do a lot of their analysis of some very, very old vulnerabilities that they were seeing in traffic, and it became kind of the most reliable tool to actually look at everything. So it's a really good history. You know, Argus itself has a really good history of the internet protocol as it was originated and how vulnerabilities first started or first recognized. A pretty good presentation was given in FlowCon 2014 called Network Flows: Past, Present, and Future. Carter himself was giving that presentation. It's very good if you want to look that up. It's actually still hosted by Carnegie Mellon. And I guess nf-dump is used by quite a few people as well. It's really easy to set up and really easy to use, and it also has nf-syn, which is a frontend but it's not in huge use like Argus or SILK is. SILK has a ton of analysis tools, a ton of ways to deploy it, a ton of ways to send data around, which is why it is going to be the thing that we're going to talk about more here. SILK and Argus 2.0 in 2008 became available, and so when you think of the history of really usable flow solutions, it really goes back to 2008 when you had really reliable things that we can use and deploy very easily, you know, with just a little bit of knowledge, but they'll be reliable once they're stood up. So SILK is the System for Internet Level Knowledge, and again, Carnegie Mellon's Network Situational Awareness Team, you know, made it. It's basically just two major components. There's a packing suite and there's an analysis suite. Whereas the packing suite, again, it goes about collecting data, not necessarily generating the flows, but it will collect the flows that are sent to it. And then there's the analysis suite that will do basically everything you can think of when it comes to looking at the actual data. And there's the link for some of the documentation and the, the community. And again, it's a huge community and the documentation is second to none. Your typical SILK architecture, which, you know, look directly in the middle, that's your SILK server, which will have the collection and the analysis tools on it. However, you'll be sending it data from, you know, F-Probe or YAF or router, as I mentioned earlier. You know, here in this case we have— this should be sensor, but we call it senor F-Probe because it never gets changed on these slides. But it goes to the analysis or the SILK server and then that's queried by the analyst workstation. So in total to get SILK stood up you basically just need to download YAF or Fprobe and have some sort of mirror or a tap or something to work off of. Basically if you have some sort of sensor stood up you probably already have everything you need. You just download this and tell it to look at your interface that's that is your tapped interface or something like that. And then you'll send data to the SILC server, which can also by chance be that box that's actually generating the data. RWflowpack listens to that. It packs everything into bins such that the analysis suite can actually look at it. And then the analyst workstation will be where all the analysis tools are on, which can also be the same thing. That your flow source is generating from and your SILK server, or you can have everything on separate boxes and there are plenty of tools that are also within these, the collection set for SILK that will allow you to push flows around. The analysis suite, at least for the purpose of today, is made up of a ton of different tools, but there are 4 main ones we're going to talk about, which R2B Filter is, as it says, it filters out all the data based on whatever conditions you give it. You may give it, you know, tell it to look for certain ports or certain hosts, and it's going to filter down to just those. Or you can say, I don't want to look at those, and say that you can filter those out. Cut, RWcut will actually take that and it'll make it a human-readable thing. You know, it can dump everything to you, or it can tell it certain fields to show. RWstats, guess what, it generates stats from data that you filtered. And RWcount summarizes all the traffic that you have into packets, records, and bytes over bend time. Here's an output, very ugly output, of just rdbcut as it is. This is kind of what you're looking at if you don't know how to sort things down even more. Here we're showing all traffic as far as for all inbound and outbound traffic of all protocol. We're passing this to standard out and then we're taking the binary and converting it with rdbcut into human-readable form, and you get this big blob of data. Here is a sorted version of something similar where we've also went ahead and thrown in a start date and an end date to look between a week of last year, you know, the first week of August, and we're looking at this 192.168.1 range where any country code is CN. Obviously none of those 192.168 addresses will be CN, so it's basically looking for anything destination or source that came from a Chinese address. Here RWcut sorts down to just source time, SIP dip, source port, dest port, and the actual type of if it was in or out or in-web or out-web. A lot of different types. Here's an example of RWStats, and what you'll see here is that we have 7 protocols listed here. And, you know, how did these come about? We literally just fed in— again, you see the all data kind of RWFilter, which is essentially saying don't filter at all. It says give us all type equals all and all protocols and filter that down or do statistics based on the --top count=10 fields protocol=bytes. And it really reads like that in RWStats. It's a top 10 protocols by bytes there. And another example is looking at the top 10 SIP-DIP pairs for valid conversations. And valid conversations here being defined as things that have flow records that have more than 4 packets and they, you know, kind of large— not so much large communications, but communications that have actually been verified. That could be extended to say, you know, you want to show that there's a flag, you know, an ACK flag set somewhere in there as well. But here we're looking again at top 10 and fields where there's SIP dip by bytes, and so it's binning up every flow record that had a source IP and a dest IP of certain types, and then it's only picking us the top 10 by bytes. Here's another example looking at the top 10 outbound destination country codes by records. Here we only look at --type=OUT and OUTWEB. There are also a few more you can do like OUTICMP and stuff like that, but we're looking at OUT and OUTWEB, any protocol, and we're doing again top 10 DCC, so it's your top 10 destination country codes. Here's a real-world example, which isn't perfect, but it's pretty accurate as far as you put this in a large environment, you're going to find some zero-access victims almost without a doubt. You know, here, this is just based on some sample data. But we did that, you know, -type=all to look for any type of data. And then we did destination ports that are usually used or usually seen in zero-access communications. We also could have done protocol=17 because usually it's UDP traffic, but we also run a top source IPs by distinct destination country codes. Where there are more than 3. Now I say that because Zero Access is very loud and usually it's talking out to a lot of different country codes, and here we want to find any sort of source IPs that have talked to at least 3 or more on those destination ports. Another good example, discovering outbound data to applications using non-standard ports. Here we leverage one of SILK's plugins that comes with SILK. It's @mismatch.so. It basically looks for, you know, so with YAF, which is a flow generator, you can also tell it to go ahead and tag applications that it sees. So it's not just looking at source ports and desk ports, it's actually looking at some of the payload itself, some of the headers and things like that, and trying to determine what applications are actually here. Not just trusting the ports. And so here it's basically looking for wherever an application was mismatched to the source or destination ports. Here we're looking for things where source ports are over 1024, where there are more than 4 packets, and trying to narrow down on flags to make it seem like these are actually legit communications, and then sending that to look for the top 100, where our top 100 applications where the— by destination, or sorry, where there are distinct destination ports, are pretty high. And here we're also looking where it's the application and destination port together to kind of narrow that down. It's basically a good way to look to see what your ports are that you're actually looking at, so you don't have to double up the searches.

That hit pretty well, I think, on collecting NetFlow data and SILK data itself. One thing I want to talk about in the vein of collection is collecting intelligence data. Everybody wants to talk about threat intelligence right now. That's the new thing, but the form of intelligence that people often forget about is what we call friendly intelligence. That's intelligence about your own internal network devices. Security folks, we all know that generally the security folks and the guys working in the SOC often know more about the network than the guys who are actually managing the network. Apologies to any network admins in the room, but it's really true. With that, we can do a lot of unique things and identify a lot of friendly intelligence with NetFlow data. Services on the network are a good example. Look for things listening on specific ports or communicating to things on specific ports. Identify normal behaviors of hosts. Obviously, a lot of server hosts and things of that nature communicate on pretty predictable patterns. That's not necessarily the case with user activity, although there are some patterns to be derived there. You can spot deviations from normalcy there, and that's certainly worth investigation and good for NSM hunting and things like that. Also the identification of friends and family. When we're talking at a device level, a device's friend is someone it communicates with outside of your network, and its family is a host it communicates with inside the network. Again, baselining normal communication so you can look for odd things. It's okay if this machine communicates to this other machine all day, every day, but all of a sudden it talked to this other machine that it's never talked to before and it transferred a large amount of data out over SMB protocol or something like that. Maybe that's a worth looking for. So there's some room to do some detection in there as well, which is pretty nice. A couple queries here just to show you how to identify SSH servers and web servers. I'll make these slides public. I'm not going to go through these now in the sake of time. And a couple to identify friends and family based upon a network of 192.168.0/24 there. So different ways to identify friends and family there, just some queries to help you get started. When we talk about detection with flow data, flow data gives us something that is kind of hard to get in a lot of other ways. When you think about how younger organizations evolve in their level of detection, most generally are going to start with signature-based detection, something like Snort or Suricata. They're writing basic signatures or downloading signatures from elsewhere, applying those to network data, and they're getting some value there. Reputation-based detection often comes pretty early too, so that's subscribing to any number of intelligence feeds or public reputation feeds. This IP address once did something bad, so I want to detect it on my network to see if it does something bad on it. That's reputation-based detection, more or less. As organizations mature, they move towards behavioral-based detection, so that's again kind of behaviors that are deviations from normal. You know, different tools there, that's a lot of manual hunting. Bro's really good a really good tool that supports behavior-based detection just because of the way it normalizes that and gives you a lot of flexibility there. Really great stuff. And then there's statistics-based detection. So that's kind of what we typically see as the more peak of maturity is actually doing detection and operationalizing detection for statistics-based things. As we've shown already, flow data really lends itself well to performing statistical calculations, and it does it at scale really well. So all the queries we just showed you They'll take a little bit longer at scale, but they're certainly doable. You're not waiting hours or days, right? It's still minutes at this point. That's certainly what you want in these types of things. You can automate these things, and that's always exciting too. One of the tools that Jason really worked hard to develop was a tool called FlowPlotter, which is— you can do statistics-based detection just looking at numbers, which is fine, but sometimes visuals help as well. He made FlowPlotter help with that. I'll let him talk a little bit about that.

Yes, the flow plotter, it kind of does two different things, and I'm going to kind of burn through some of these graphs here in a minute just for the sake of time. But, you know, it's basically made so that, you know, you can get a better idea instead of looking at tables and lines of data all day long. You know, sometimes it's easier to actually look at a good picture of what's actually going on, and it's also made so that you can actually, you know, take some data and throw it into a report or show a manager or show another analyst what you're looking at without having to fully explain where you came from when you've made this data. It works the same way as all the other flow or all the other SILK features. It basically works directly off of any RWFilter piped output. So just like you pipe data to RWCut, you can pipe data to FlowPlotter. It's written in Bash, and so it's really easily tweakable. It's very flexible. It's up on GitHub. You can take it and do whatever you want to with it, and it works in every browser I've tried it in. I've tried it in a lot of them. Here's a good example of things that you can throw in a dashboard. It's a GeoMap showing some stuff that is not US or China because of my data. It was overwhelming, but it will show you. You can mouse over and see all the bytes for every country. A line chart to give you a good representation of situational awareness. Kind of, you know, when you come in and you want to run a report or set this up on a cron job to send it to you and just open this up, you know, first thing when you come in in a day or check it every hour. And a lot of times you'll see some very interesting things just through this. And, you know, this is just an example of all data, but you can easily narrow down to certain data for certain hosts, for instance.. And it'll really show you, give you a good idea of a representation of, you know, over time, how are they acting. Here's a tree map. Chris loves tree maps. They show a pretty good representation of differences between different things on, you know, without having to worry about axes and things like that. It has mouseover features as well to show you a lot of different details for any given dataset. I do love treemaps.

This is normally the part where Jason insults me for loving treemaps so much, but if he didn't, I'll consider myself lucky.

It's 2015, it's a new year. So here's your basic pie charts, bar charts, column charts. These are all representing the same thing. Here's a bubble chart, which is actually pretty unique because it shows the It's definitely a multi-axis thing. Based on the size of these bubbles, based on our inner representation of records versus bytes versus packets, you can really get a good representation of, you know, is a host really just hitting another host really hard? But maybe these, you know, the packet count is very high, but the actual record durations are low or anything like that. You can get a pretty good idea, but it takes some massaging to get exactly what you want. Here's the timeline, which really works off of, you know, actual data itself, you know, sorting by just, you know, the times themselves. You know, here is an example of just a ton of data that happened over the course of a single hour, but you can see just kind of how everything is communicating. This is for one major host, which in the image right now you can see is stepping up this 172.189.124.188. This is actually just a beaconing communication that you're seeing over the course of a day. And then here's a force-directed chart. You've probably seen them in various applications, but it's basically a great way to represent kind of what you're showing to a manager or another coworker when you say that some hosts have communicated or here are some ports, odd ports or something like that between different hosts or even country code representations. This is a really quick way to throw that together as well as offering some features to turn some things green and red and make some nodes sticky so they're not bouncing around making everybody sick. And in this case, we're looking at kind of some unique stuff where we're also thresholding based on distinct dead ports.

Yeah, and I'll add with this one, I enjoy the force-directed graph, but the problem most people have with it is the first thing they do is take every bit of flow data they have and send it to a force-directed link graph. And then of course it's just a big mesh of everything and you can't really make sense of it. It's not entirely useful. I'll be the first to say that I hate visualizations that are not useful. Some are not, right? Like the thing earlier where we showed the country code thing. I mean, there's only so much value to looking at what country codes things came from. And if you put too much reliance on that, then that's not a useful visualization. This is one that can be useful, but it requires drilling down to where you don't have a ton of data, getting to a specific dataset you're concerned about, and then feeding it into a force-directed graph., and it becomes a point at which you can really start to identify relationships, which that's ultimately when you talk about security investigations, that's all a security investigation is, is the identification of relationships to kind of determine what the ground truth is.

So this is a useful tool for that. Yeah, very good point about not having too much data in there. And you know, there's a few tools that are great for translating, you know, the data. You know, you may know exactly what's going on, but you need to show a coworker and Force-directed charts really do a pretty good job without being able to actually highlight things. They wouldn't be as nice, but I've tried to make it to where they're actually usable. Here's a tool that kind of works differently because it doesn't do— it doesn't actually work just off of the standard output. It's taking in any amount of filtered data and running that against a lot of other filters and doing automatic asset discovery. So if you have a large amount of data at like a university or something like that, you know, throw an hour's worth of data into this asset discovery tool and you'll discover, you know, quite a bit of what your assets actually are that are sitting out there. It also offers as an option a lot of thresholding so that if you have, you know, a ton of servers that just wouldn't even fit on this page and be readable, you can threshold to just, you know, the top or the bottom of those servers.

I'm going to skip just a couple slides here for the sake of time so we can get to this last demo. We talked a lot about flow data and it's, Jason and I have worked at a lot of places that obviously specialize in detection with Mandiant and the DoD and we've had a lot of success with flow data. We've caught a lot of bad guys and that's kind of really the ultimate goal there. We advocate for flow data anywhere we go because it is so easy to collect. And so easy to use. But that's not to say it's not without its own barriers to entry. Obviously, we've shown a lot of line-based text data, and not everybody can do that. Some people just can't handle that as well, and we accept that. And it's also not the most welcoming thing to folks who are new at this job, new at being a data analyst. It just doesn't mesh well with everybody. And it's certainly not fun to look at, even for guys like me and Jason who look at a lot of it. It's not fun to look at all day. Case in point, this is not the most worthwhile screen to look at all the time. For the most part of our careers, when we're looking at flow data, this is what we've been looking at. We ultimately decided we wanted to do a little something about that. We decided instead of looking at this, it would be a lot better to be able to look at this. This is a tool we created called FlowBAT, and that stands for Flow Basic Analysis Tool. It's essentially a graphical front end to SILK. With the SILK back end, you plug this in in front of it, the idea being that you can plug it into an existing SILK installation or as part of a new one, and then begin graphically analyzing flow data. So we've designed it to be incredibly easy to install. There's actually, if you go to flowbat.com, there's two install scripts. If you don't have SILK installed, there's a script there that you just run inside of a bash shell, and it asks you a couple questions and then does all the work for you. And then a second one that will actually install Flowback for you as well. This is kind of a one-click or one-command thing, so that makes it quite a bit easier. We tested on a couple operating systems and so far we've had really good results with that and making it easier. I know the worst thing ever is when you want to try a new tool and it's ridiculously complicated setup, right? I think we all try to avoid that where we can. Ultimately, I think the biggest takeaway we want to get across with Flowback is that Jason and I are analysts at heart. That's what we do. We're investigators. We enjoy nothing more than digging through data and hunting for bad guys and getting them out of our networks. FlowBats is ultimately a tool that's really by analysts for analysts. That's the big takeaway here. With that said, I'm going to attempt to pass this over to— I'm going to stop my screen share and attempt to pass this over to Jason here so he can do this demo. Do y'all have, do y'all have Jason's screen there? FlowBats, the dashboard? The dashboard. Yep. Good deal. Thank you. Go for it, Jason.

So here is FlowBats basic dashboard, which I've pre-populated with just some data. That you make in some queries. They can be either queries that are command line-esque, or you can have a query builder, which I'll show that here in just a minute. But the principle of this is I set this up with— here's a graph of all your data over the course of a given day. It's a trailing day where this is repeatedly executing every 60 minutes, so that this will be a new graph every 60 minutes. And you'll see things there. As the day goes by, everything moves to the left, as you would expect. I have a little too much data in here, so it's kind of jumbling up some of these days. But these are just some bins. It'll bin itself. You can decide that you want 60-second bins per dataset. Basically anything you want. Anything you can do in Sylk, you can do here. Your top protocols for the last 24 hours, sorting by records. But then adding on pipe and packets as well, just for your information. Top inbound IP addresses for the past 24 hours. This is kind of using the type, leveraging type to say that you're only looking at in-web and inbound traffic, and then going with RWStats to knock that down and look at the source IPs, top 10. And then here's top inbound communications ranked by application for the past 24 hours by bytes. And so it basically lists all applications where the, the top 10 by bytes communicating. And so you have, you'll notice that these are translating into their actual names instead of, you know, in Sylph where they would just show up as 2253443. You know, this tries to tell you what they actually are. Now breaking down into one of these, you know, if I click edit here, it will break down into the actual saved query. You can also look at any amount of queries, even if they're not on the dashboard, that you save here. So let's go to all data for past 24 hours. Here I use the query builder to look at a rolling offset, which Sylk doesn't offer, but it's all calculated in on the web app itself. So it's actually going through and calculating the active time and the start date, end date for everything that you want it to do without you having to calculate all that. So you'll notice it's a pretty specific time based on whenever I first executed that, and I said I wanted to go back 24 hours. And then here I've chosen a chart instead of table. If I wanted the same output, I could go to a table, and it's going to show me an RW count output. Where there are 10 per page, but there are really going to be a lot of these because we're looking at 10-minute intervals here, so 600, 600 seconds. And so there are going to be quite a few pages here. However, that's the basic idea of the query builder. I mean, you can specify any host, any protocol, port. If you only wanted to look at records for the certain filter, which in this case the filter is everything, I can look at the, the records here And you know, you can— let's say you want to pivot off something. Something is of interest. If I want to look at source ports of 123, I can add that. You'll notice it added it up here, and I can re-execute that, and then we'll have source ports that are 123. Well, hypothetically, let's say we wanted to say, "I want to search Rocktex for this guy." Well, it will open up the information for this particular IP. You can do a number of different things, you know, getting more information on the port itself through SANS, and you can do different pivoting. The app also allows for— it's not built in yet for the addition of other lookup sources, which we're going to add in the future. But you can also go to Quick Query. Let's say you're already a SILK veteran and you're not really trying to learn things. In Query Builder, you'll notice that it did leave this filter. If I was to run that in the command line right now at terminal, this would give me the same kind of output. It's basically the idea of it so that junior analysts can actually learn SILK through this front end if they decide to make their own tools, for instance, like FlowPlotter was. FlowPlotter, it obviously leverages the command line. However, anyone can make any tool they wanted to. To really pivot from this data. So this kind of allows them to do that if they need. However, if they're just looking for, you know, use the flows themselves and leveraging just Flowback instead of having to go through the documentation, you know, to kind of figure out what these terms are. You know, say any port, for instance, if I want to look at source port or dest port of 123, you know, I want to look at, you know, all data. You'll notice it's autofilling down here at the bottom. It offers you every option that you could possibly have for SILC. I'll say 0 to 255, and then, you know, I don't know if it's A or any, but once I start typing this out, I see that, okay, you know, there's any address, any all this, but it's not any port, which you clearly see there. I go back. Well, there is A port. We'll look at 123 and execute that, and it's looking where anything source port or dest port is 123. Here is, you know, obviously one outlier. If I wanted to go ahead and add that and say, I want to look at that as a source port, it adds that up here in the query that I can change that easily. Earlier when you saw that added to the final query, it also added it to the query builder where you could go and say, I want to look at, you know, hosts or ports and then you could change it there. So I want to change and remove a port. It's going to refresh, and here's the only flow record that we have for this.

Hey, Jason. Will you— oh, yeah, go ahead. Will you show them the two things, the swapping the columns and the time switcher?

Oh, absolutely. Yeah. So let's say that you're— actually making— I'll just do a quick query using the query builder this time, looking at just today. Actually, let's look at yesterday. I want to look at all the— not yesterday at all. It is yesterday. I'm losing track of time. So I want to look at yesterday, and it's going to look at any host and kind of anything on the query builder because junior analysts are more likely to use it. We go ahead and fill out --type=all and all protocols and allow you to go ahead and change that if you need to in additional options. However, I'm going to go ahead and narrow down some of these results here. And let's say that I only want to look at certain things. I want to get rid of duration. I'll get rid of end time. Sensor, they're all going to be the same on this particular box. I'll go ahead and get rid of TCP flags as well. But I'm really interested in start time as the first thing. I can move that over here and it goes ahead and refreshes everything. I can also sort by start time, which is a pretty unique thing as well. You can do this all in Sylk as well, but it requires a lot of different tools to do this, like rdif2sort, which you'll see. When I did sorting, it automatically changed this output to go ahead and sort as it needs to sort by fields at the time.

Yeah, the big reason I'll add for the— the thing we realized as Jason and I were doing this, ironically, was that we both like different fields in different orders, and that was kind of the impetus for this feature, was Jason liked looking at his data a different way than I like looking at mine, and then we kind of realized that everybody is kind of their own special snowflake in that regard, and like likes looking at it their own way, so we did it this way. And it's also such that the order of the columns is persistent with your user profile. So if you have starting time first and you configure it that way, the next time you run a query, it will also be saved that way. So that way you don't have to reconfigure it every time. Right.

And if you wanted to throw this in a dashboard, it's also going to show up in the dashboard how you want it to show up, not as how it was executed previously. You can also download— let's say if you want to actually share this output with someone else, you can download the RWF, which is an RW Filtered File, and go ahead and send this to someone else. And if they have— they can open it up in Terminal and look at that there. You can also download it as a CSV. Also notice the changing time. You can use your local time or you can use UTC time, which is really beneficial for analysts because it's a pain in the butt to go ahead and change between those all the time manually. I think that's about it for the demo. Yeah.

Yeah, so that's pretty much the demo. And so I want to say just a little bit, I'll open up for questions here in a second. I just want to speak a little bit about the future of FlowBad and what we've got planned. Obviously we've got a lot of features in here. I think I saw somebody in the chat mentioned how they enjoy when developers actually use the tools because they're a little more refined. And we certainly hope that's the case because we use FlowBad all the time. Ultimately, while this is a tool for everybody else, it was also a tool for us. And we get a lot of use out of it, so we're hoping other folks do too. We're— we've got a couple things in the works for this. You saw FlowPlotter, and we've obviously got some features of FlowPlotter in here already, but ultimately we're going to have full integration where you can generate any of those FlowPlotter graphs on the fly with just a couple clicks from FlowBack. We've got intentions of doing alerting, so you can set up specific conditions, and if a query returns a certain amount of data, then it will alert you somehow, or if you have a statistic output and a certain threshold is met, it'll alert you in that way, which can be pretty useful for doing kind of rudimentary detection from flow data. So we're doing that, a couple of other things as well, but those are a couple of the big things on the horizon that we're really looking forward to.

We definitely reiterate, go to flowbat.com and definitely try these scripts. And I mean, it's literally like a 10-minute install for both Sylk and FlowBat to get those running. On a clean Ubuntu 14.04 instance. So testing it out is really easy.

Yeah. So that said, I had a final slide, but I mean, it's nothing big on it. Just our contact info, which I can share out later. And really, flowbat.com is the website you'll want to visit to get all the information. We've got really thorough installation documentation. Actual usage documentation is a little light right now. We're working on that. Feel free to take a look. It's in GitHub, so you can look at it, clone it, play with it. We're always looking for, you know, if you find bugs, let us know, and we're always looking for feature suggestions. So certainly play around with it, and we really appreciate the opportunity to get to talk to you guys. So we'll open it up for questions.

Excellent. I'm going to go ahead and try to unmute. Anybody that's joined remotely, they will be able to to ask questions. Well, how about— You mute, you can let them unmute themselves.

Say again?

So when you just did the mute all, there's an option to let them unmute themselves. Oh, OK. That's a good idea.

Oh, and that noise is gone. Unmute me. Okay, so if you— can everybody hear me? I can. I guess, um, Chris and Jason. Okay, Chris, Jason, can you hear me? Yes, sir. Okay, so anyone in the audience, you can— you should be able to unmute yourself if you want to ask a question, and then when you're done, do press mute again, please.

Tim Yardley would like to know why you didn't mention N-probe. He can't ask himself because he's feeding his daughter.

Okay, we didn't mention N-probe just because we just don't use it a lot, haven't had as much experience, and we were kind of aware of it, but as far as massive use. I mean, we try to focus first of all on kind of free open source when we can because it's more accessible. So that fact, I mean, that just— the 3 ones we see used the most by far are the ones we mentioned: Argus, SILK, and the other one that just escaped my mind for some reason right now. So that's why.

Yeah, there are definitely a lot of other solutions for both generation and analysis. So, I mean, don't think what we've mentioned here is the only thing that there is. There are a lot of solutions out there, and again, no reason for someone not to be using flow data. There's literally anything you want.

I saw that Flow Plotter was a shell script. What are you using in there? What programs are you calling to generate those graphs?

So a lot of them use Google Visualizations, which, you know, some people say aren't really trustworthy because they kind of change those so quickly. But Google Visualizations only go so far. You know, for instance, they used to have force-directed graphs, but they don't really support those anymore. So for like the force-directed graphs and the asset discovery, I went ahead and used D3 to generate those instead. Okay, cool. And all the data itself is kind of just parsed out with a lot of sed, awk, and grep.

So I have another question. I know that Argus, you can actually, when you run in the daemon, there's an option to listen on an interface and actually take the packets and then generate the appropriate or the corresponding Argus files. So you don't actually have to have a router to send flow records. Do you know if you can do that with SILK?

Yes. So basically, I mean, well, I'll say that SILK itself is kind of the collection and packing suite, but if you use it in conjunction with like fprobe or YAP, basically that's what all those utilities do is they'll listen on the wire and then they'll send that over to SILK, and then at that point SILK will create files and store it in its kind of own proprietary file format there. That's generally what we do most of the time. We actually ironically do less of the generation directly from routers and more directly from NSM sensors and sending that data back.

It's probably worth noting you can also generate from PCAP.

Okay, that's good to know. Anyone else have any questions?

I've got one question.

I guess in the— oh, go ahead. All right. You— so you talked about the full PCAPs being a very limiting factor and that you don't find people storing it for very long periods of time.

Can you speak to what the limiting factor there is? Sure. It's really cost of hardware. Just because it's a lot of space. You know, you can do things to selectively filter that down, you know, get rid of maybe your encrypted data if you're not doing anything with that, for instance. But really, it's just a matter of the more that you store, it just takes up a whole lot of space. And then, you know, folks can't really afford to store it en masse because at that point it's not just storing it, but you also have to have the ability to query through it quickly and then move it around for analysis. And all those things kind of compound and it gets very hairy.

So I guess there are a couple things in group chat as well, namely, you know, the talk of scalability. You know, just to jump into that as well, like, you know, YAF was made kind of, you know, in the support of, you know, a lot of different tools. YAF is a by-flow meter of generating flow data, but, you know, YAF also, you know, sends data directly to Silken and directly supports support SILC. When it comes down to, you know, how quickly and, you know, what kind of networks can these things actually operate on, you know, we've been told directly by the CERT guys themselves that they've seen networks where they were gathering flows, 12 billion flows a day. SILC itself can handle a 20 gigabit per second network, and that's of unsampled flows, not anything sampled at all. So, you know, these days even, you know, YAF and Argus both, you know, they can generate and handle networks of almost any size, any size I've ever seen at least where they've been deployed. And I guess—

Go ahead.

There was a— I was going to go— there's another question here about NetFlow v5 versus v9 and IPFIX. I don't really want to get into all that right now because that's There's a lot to all that. I mean, there are some big differences. V5 is obviously an older version than V9. It's a little bit simpler. V9 is a little more customizable. You can define some custom fields and things, but I don't really— I'll be honest, I probably can't do that justice in the amount of time we have here. There's some information on that in the book, but there are also some good resources out there that you can find that will talk a little bit about that.

Yeah, the book goes in pretty good detail, but Plixer also has a few different blog posts especially for v9 versus ipfix. You know, like, you know, the big difference is being field sets between all of these. v5 has, you know, very few and only what is necessary. And then, you know, like version 9 goes to 79, and I think ipfix goes like 238 field sets that are usable.

There was a question here about how to use NetFlow in combination with something like Bro. Bro has its own version, I guess, of NetFlow. I don't know if you would call it that. I gotta be careful because I see Vlad's on the call here and I don't want him to hurt me. But it basically has its conn log is kind of like a version of flow data. It kind of gives you the same basic thing. So that gives you some rudimentary flow data there. I'm of the opinion it's not the easiest to parse through. Most of the time, I mean, I run Bro, I love Bro, but I also have NetFlow solutions that run along with it. So, you know, it's all about correlating data between data sources. So as far as, you know, how to use it in combination, I guess definitely I recommend doing it in combination. You know, it's all kind of— all the same rules apply as far as syncing data sources, right? You want to make sure they're synced to the same time source so you can quickly go from one to the other. A lot of the times I'll start with NetFlow data and finding what I want to find, narrowing down to a particular time range. And then once I've narrowed down to that time range, I'll switch over to Bro data and start looking at, you know, HTTP logs or file logs or things like that. I usually want to start with the simplest, most uniform, and fastest to analyze data source first to narrow down to my specific things I want to look at, and then pivot over to other things, which would include Bro. At that point, it would also include things like like full packet capture if I do have that available and I've narrowed it down to a specific time window, or proxy logs or host logs or things like that. But I know for me, Flow is my generally kind of my first starting place for network data. I know that's going to be a little different for everybody, but that's generally where I'll start and then pivot to Bro.

Okay, do you guys want to say anything else? You started whenever I was speaking, or is that good?

I think we're good. We appreciate the opportunity to talk to y'all.

Yeah, it was an excellent talk. I really appreciate it, and I encourage everyone to check out FlowPlot and FlowBats, or FlowPlotter, excuse me, and FlowBats. You guys did a really good job of touching on flow data in general and the concepts around it. Yeah, thank you for graciously donating your time and coming to join the call. It was really good. Thank you. I also want to say thanks.

We're kind of a weird group because we're a mix of students just finding out about a lot of this stuff and industry professionals. I thought that your guys' talk was a really good overview of a lot of the basic flow concepts and brief introduction to a lot of different useful tools that— I'm amazed at how much information you guys gave us in such a short period of time. Yeah. Thank you for that.

Thank you. I recommend everyone who's more interested in this, that does not have the experience with these tools, to purchase their book, the Applied Never secure mining, but it's really good.

Jon passed it around at the beginning of the meeting, so— Good.

All right, guys, thank you very much. Take care. Take care, you too. All right, that concludes this, uh, open NSM meeting. We will continue next week as well on Monday. Uh, we do not have a speaker scheduled though, so it's still up in the air if anybody wants to— if anybody has a topic they'd like to present or a tool they'd like to talk about, let me know. Otherwise, I'll try to fill in for something. All right, meeting adjourned. Thank you, guys. Thank you, Jon.