WEBVTT 00:00.000 --> 00:11.840 Okay, so next stock is by Gerald Combs and Nigel Douglas, and they're here to tell us all 00:11.840 --> 00:17.640 about a stratashock applying the power of Washock to system calls and logs help me give them 00:17.640 --> 00:18.640 a roll-on-one. 00:18.640 --> 00:19.640 Come, please. 00:19.640 --> 00:20.640 Thank you. 00:20.640 --> 00:29.440 Well, good afternoon, everyone. 00:29.440 --> 00:30.680 Can you hear me okay? 00:30.680 --> 00:31.680 Great. 00:31.680 --> 00:32.680 Good. 00:32.680 --> 00:38.480 As the slide says, I'm Gerald Combs, I am the creator of Washock. 00:38.480 --> 00:44.880 I'm also involved with the Washock Foundation, and if you want to learn more about that, 00:44.880 --> 00:49.320 we have a stand over and building age, and we can tell you all about that. 00:49.320 --> 00:54.080 I also work for a company called CISDIG, and I'm here with one of my co-workers and I'll 00:54.080 --> 00:55.640 take this, who good news for you. 00:55.640 --> 01:00.000 He's a much better presenter than I am, and he'll be talking a little bit about FACO and about 01:00.000 --> 01:02.000 stratashock. 01:02.000 --> 01:09.000 So, quick overview of what we're going to talk about. 01:09.000 --> 01:12.240 First I'm going to cover a little bit about Washock and what it does and how it relates 01:12.240 --> 01:18.760 to stratashock, and then we're going to talk about FACO and how it relates to stratashock 01:18.760 --> 01:22.280 as well, and Nigel's going to give a quick demo, and then we're going to wrap up with 01:22.280 --> 01:30.040 some more information and have some time for questions if you have any. 01:30.040 --> 01:36.520 Now, I thought I'd start off, I thought I'd start off where I left off last time, which 01:36.520 --> 01:43.960 was 20 years ago when I was here at Fauston, giving a talk, and at that time, I was talking 01:43.960 --> 01:47.800 about a project called the Thereal, and I thought I'd give a status update on the 01:48.280 --> 01:53.880 big news is we changed the name to Washock. 01:53.880 --> 02:01.160 We got a new name, the project grew, in fact, it grew enough such that we now have conferences 02:01.160 --> 02:05.920 for Washock, one in the US, and one in the EU each year. 02:05.920 --> 02:09.480 We went ahead and started a foundation called the Washock Foundation, again, if you want 02:09.480 --> 02:14.920 to learn more about that, we'd be happy to talk to you over at the Washock stand, and 02:14.920 --> 02:20.920 fill you in on that. 02:20.920 --> 02:28.760 So, as more of a Washock status update, Washock actually has grown to be a pretty good sized 02:28.760 --> 02:34.760 application, and we're up to, depending on how you measure code, we're up to either 3.5 02:34.760 --> 02:39.240 million lines of code, or 6 million lines of code, whether or not you can automatically 02:39.240 --> 02:45.720 generate a code, and that's been generated and created by about 2,300 contributors so far, 02:45.720 --> 02:50.760 and that bottom number is something that I really love, I really love the fact that so many 02:50.760 --> 02:55.800 people have contributed to the project and are involved, it's really great to be part of something 02:55.800 --> 03:06.040 like that, but we have a lot of users as well, we get about on the servers that I manage 03:06.040 --> 03:11.480 and the servers I have insight into, we have about, sorry, back up one, we have about a million 03:11.480 --> 03:17.720 and a half-down loads per month, and most of those for Windows and Mac OS, I don't really have a 03:17.720 --> 03:22.440 lot of insight into how many Linux users we have, because I just don't have access to those 03:22.440 --> 03:27.720 statistics, but I'm assuming that it's kind of the line with the Windows and the Mac OS users. 03:27.720 --> 03:33.400 We have a pretty active user community, we have an active question and answer side, an active 03:33.400 --> 03:42.280 discord server, mainly, this aren't really active, but we still have them, and that's also 03:42.280 --> 03:49.960 kind of an indication that we have a pretty large and popular project. Next slide, now, 03:51.800 --> 03:57.560 this is a carry, we support 3,000 protocols, that's a pretty obvious thing, there's these things 03:57.560 --> 04:02.600 called network protocols, which are standardized and where shark supports about 3,000 of them, 04:02.600 --> 04:10.600 but that second number, we support 250,000 display filter fields, and that's an indication 04:10.600 --> 04:17.320 of how large and useful our shark is, but it's not really obvious what fields are, so maybe 04:17.320 --> 04:26.760 I actually explain what those are and how they make our shark useful. The core of our shark is 04:26.760 --> 04:32.840 its dissection engine, and by that I mean, when you click on a packet in a wire shark, it takes 04:32.840 --> 04:37.880 that packet and breaks it down into its constituent fields, and it shows you everything about 04:37.880 --> 04:43.400 every bit and bite in that packet that it can, and so it'll take each field and give it a name, 04:43.400 --> 04:47.560 it'll tell you where it is, and how large it is, what kind of data you're looking at, whether it's 04:47.560 --> 04:54.040 a number, an IP address, or a string, or what, have you, and the thing about the detection 04:54.040 --> 05:01.560 and it makes it so useful is that you can filter on those fields, and the big and obvious thing 05:01.560 --> 05:06.440 is that this little text area at the top of the application that lets you type in these filters 05:06.440 --> 05:11.560 and drill down to the traffic that they're really interested in, for instance, at the top, 05:11.560 --> 05:20.280 you can see a filter for ICMP, and any frame that has a string, ABCDF, blah, blah, blah. But there are 05:20.360 --> 05:25.640 all sorts of other features and more shark that make use of this dissection engine, and these 05:25.640 --> 05:30.040 display filter fields, for instance, if you look at the packet list, it's usually drawn in a 05:30.040 --> 05:35.320 bunch of different colors, and that's driven by display filters. You can pull up an IO graph, 05:35.320 --> 05:41.560 and graph either field values, or say how many times they occur over time, interval, you know, 05:41.560 --> 05:48.520 things like that, and a bunch of other features, for instance, if you use wire sharks configuration 05:48.600 --> 05:53.640 profile feature, and you should, if you're a wire shark user, it's really useful. You can set 05:53.640 --> 05:59.720 up a filter that automatically applies a configuration profile. If it matches the first thousand 05:59.720 --> 06:06.600 packets in a capture file, when you open it, for instance, you know, if you have a Wi-Fi profile, 06:06.600 --> 06:12.200 you can look for a specific Wi-Fi filter and have that automatically applied when you open that 06:12.200 --> 06:19.800 file. It's pretty useful. The other thing to know about Wi-Shark is that we're a part of a larger 06:19.800 --> 06:25.240 ecosystem, and if you're not familiar with the logos at the top, we have Kismit and Snort, 06:25.240 --> 06:32.200 C, T, C, Dump, and Top, and Map, and Ceracotta, and those are all based on around a library called 06:32.200 --> 06:37.560 libpecap, and on Windows, you know, we used to have onepecap, and now we have npecap, but 06:38.520 --> 06:45.240 the next slide, the cool thing about libpecap is, as an application developer, libpecap, 06:45.240 --> 06:52.360 lets me not care. It lets me not care about the intricacies of capturing on Linux or Mac OS or Windows. 06:52.360 --> 06:57.080 I don't have to reach down into those OS's, and figure out how to pull those packets out, 06:57.080 --> 07:03.320 libpecap takes care of that for me. It makes things very convenient. I remember when I was very 07:03.400 --> 07:08.760 first developing ethereal, one of the very first things I did was to write this little minimum 07:08.760 --> 07:15.000 viable bit of code that captured packets using libpecap, and prove myself, okay, we can build 07:15.000 --> 07:21.640 an analyzer and top of this, and so it started there and kind of proceeded from there. The other 07:21.640 --> 07:27.720 cool thing about libpecap is that it has a couple of file formats associated with libpecap and 07:27.960 --> 07:35.400 g, and if he back up one slide, the useful thing there is that it lets you pivot between all 07:35.400 --> 07:40.280 these applications. For instance, something I do all the time is, you know, I have a bunch of servers 07:40.280 --> 07:46.760 up in the cloud, and if I need to do a packet capture, it's, you know, typically, like AWS or wherever, 07:47.720 --> 07:51.960 those instances will have, these have been installed already, so it's really easy to just 07:51.960 --> 07:55.960 grab the packet capture, pull it down, and load it into wireshark, or you pass it through 07:55.960 --> 08:05.400 some order, whatever. It's time. So this is really cool, this is really great, it's useful. 08:05.400 --> 08:12.760 A useful question to ask is where we might take these two nice things, this dissection engine, 08:12.760 --> 08:21.320 and this ecosystem, and see where else we might apply that, and the thing that I've been focusing 08:21.320 --> 08:28.360 on is that taking those things and applying them to system calls and the log messages. As it turns 08:28.360 --> 08:35.960 up, any other time series database that you might be dealing with, and that's what we're going 08:35.960 --> 08:43.960 to talk about next, and the thing that, well, just to make sure everybody's on the same page here, 08:43.960 --> 08:52.200 the reason that it's useful to be able to capture system calls is that system calls, they're 08:52.200 --> 08:57.240 kind of the boundary layer between the programs that run on your operating system and the operating 08:57.240 --> 09:02.360 system itself, and so, you know, if you have a web browser, a shell, or a wireshark, what have 09:02.360 --> 09:06.280 you, any time they do anything interesting on your operating system, they're going to go through 09:06.280 --> 09:11.160 the Cisco interface, you know, whether it's reading a file, or playing a sound, or connecting 09:11.160 --> 09:20.200 to something in the network, they're going to use system calls. The nice thing from an application 09:20.200 --> 09:26.760 development point of view is that this is a standard interface, and it lets me, again, not 09:26.760 --> 09:31.160 worry about things, if I write a program that just, you know, reads a file from the TIMP directory, 09:33.320 --> 09:37.320 ultimately going to call open, or when it is associated with system calls, and then read, 09:38.200 --> 09:44.040 you know, several times until I get the contents of the file followed by close, and the cool thing is, 09:45.480 --> 09:51.240 I don't have to worry about whether that's file is on an SSD, or USB stick, or spinning rust, 09:51.240 --> 09:56.680 or on a network share, you know, that the system calls behave the same either way, and on the 09:56.680 --> 10:01.960 operating system side, this is pretty cool because I can enforce security boundaries. If I don't have 10:02.040 --> 10:10.040 access to that file, the operating system, you just say no. But the thing is, like I said, 10:10.040 --> 10:14.600 anytime your, the program's on your system do anything, it's going to go through that system call 10:14.600 --> 10:24.040 interface. So as someone who has written a protocol analyzer, a really useful question would be, 10:24.040 --> 10:31.000 you know, what if we can capture that, and what if we can analyze that? That's what my boss and 10:31.000 --> 10:36.840 my co-workers at SystemDong. They have developed a couple of libraries, LibsGap, and LibsSense, 10:36.840 --> 10:42.920 LibsGapSense for library for system capture, and it can pull a system calls out of your OS through, 10:42.920 --> 10:47.640 using a couple of methods. One is either kernel module, or an EPPF probe, 10:49.320 --> 10:54.040 LibsGap also supports a plugin interface, and there are a bunch of different plugins out there for it. 10:54.040 --> 10:59.960 For instance, you can pull in cloud trail logs, or Kubernetes audit logs, or DCP out at logs, 10:59.960 --> 11:07.160 and things like that. But like I said, if you have a system where you work, or that you do with 11:07.160 --> 11:12.280 that generates custom logs, you can write a plugin for this and pull them in that way. On top of 11:12.280 --> 11:17.480 LibsGap, there's LibsSense with Sense for library for system inspection, and it takes that data 11:17.480 --> 11:23.320 in and enriches it. For instance, with System calls that'll associate user IDs with user names, 11:23.320 --> 11:29.400 and file names, and socket pairs with network connections, and things like that. 11:31.800 --> 11:36.840 On top of that, we have the System OSS command line tool, which works a lot like TCBDum. 11:37.640 --> 11:40.600 You run it, and it'll print System calls, and information on your terminal interface. 11:41.800 --> 11:48.280 We also have FACO, which works a lot like an IDS. They'll continuously read System calls, 11:48.280 --> 11:51.720 and match them against filters, and alert you if anything weird is happening. 11:53.400 --> 11:58.120 The thing that I've been working on is Stratofshark, which takes what I talked about earlier, 11:58.120 --> 12:03.480 which is where Sharks is a section engine, and it's user interface, and it lets you apply that 12:03.480 --> 12:07.560 to System calls, and so that's what we're going to be showing off today. 12:09.400 --> 12:11.000 Right now I'm going to hand things over to Nigel. 12:12.280 --> 12:17.320 Thank you very much. I'm going to keep this nice and short, so we have time for the demonstration. 12:17.640 --> 12:24.200 I work on a project called FACO, and FACO is basically doing a lot of what we just talked about there, 12:24.200 --> 12:28.040 which is System call and inspection. We use those same libraries that we mentioned there. 12:28.040 --> 12:34.520 Second go, Lips inspection, and the Lips Capture. The differentiator here is that FACO is a 12:34.520 --> 12:40.680 rule engine, so we take those System call logic. We build these YAML-based rules, and you can detect 12:41.240 --> 12:45.320 anomalous behavior in your environment, so for those who are familiar with Kubernetes, 12:45.880 --> 12:50.120 the CNCF ecosystem that we probably quite familiar with this project of FACO. 12:51.400 --> 12:57.240 FACO is great, it's probably the tool to use, and I would recommend if you are looking for unusual 12:57.240 --> 13:01.400 behavior in Kubernetes, because you're not just looking at System calls, but then you can also, 13:01.400 --> 13:05.960 as we mentioned there's a technique in Richard again, context from the Kubernetes Autologue 13:05.960 --> 13:10.920 for instance, and even go further and then take the Cloud Provider Autologues as well for additional 13:10.920 --> 13:17.560 context on that Cloud Provider. Where FACO doesn't cover something is where we're talking 13:17.560 --> 13:22.200 about the inspection piece. It's designed so that we're not looking at every single system 13:22.200 --> 13:27.560 call that goes through instead we're kind of streaming it, so we build a set of rules, 13:27.560 --> 13:32.920 and they will look for fine-grained context, so we have all this context that we're stripping 13:32.920 --> 13:39.560 from the metadata of those System calls, and we say if we match that arbitrary context, 13:39.560 --> 13:43.880 then you get a detection which tells you we know something's happening in your environment. 13:43.880 --> 13:48.120 But let's say you're doing troubleshooting forensics, and you need more than just a detection. 13:48.120 --> 13:51.880 Maybe detections are good piece, because it tells you something's happening in your environment. 13:51.880 --> 13:57.080 But the capture file itself, the S-CAP, so think of an S-CAP the same way as a P-CAP in Warshark. 13:57.080 --> 14:01.320 And the S-CAP will show us just about everything, and they can be rather large in size. 14:02.760 --> 14:08.120 So think of this as the relationship where we're at today, and it's definitely a funny looking image. 14:08.760 --> 14:14.440 So Warshark has been around since the 90s, so it's been around for quite some time, 14:14.440 --> 14:20.280 and it was a protocol in Alice's tool, and you were holding these files in P-CAP format. 14:21.000 --> 14:28.760 S-CAP came along, and it was trying to be effectively Warshark, in sense that it's closer to TCP dump, 14:28.760 --> 14:35.960 as a general put it at a second ago, so you could run these, you know, cystic.wn right to a file, 14:35.960 --> 14:41.400 and it will be written to an S-CAP. So instead of P-CAP, sure, over a wire, you're looking at 14:41.400 --> 14:47.000 system calls from the kernel. As I mentioned there a second ago, Falco then is a CNCF project. 14:47.000 --> 14:53.000 So we donated that project to the cloud native computing foundation, and the CNCF then oversight 14:53.000 --> 14:57.880 or overlook the project of Falco. But as I mentioned, it's got a focus being on 14:58.600 --> 15:04.200 detection of system call activity. So then we go in this kind of reverse path backwards, 15:04.200 --> 15:09.080 where we've done projects like S-Stick, which created those Lips, CAP, and Lips and Spection 15:09.080 --> 15:15.160 Libraries. We use those same libraries in Falco, and now today we're working those libraries 15:15.160 --> 15:19.880 again into StratoShark. So what we're trying to do is go back to our grassroots and say, 15:19.880 --> 15:25.720 look, what did Warshark do? That was fantastic, which was that uniformal design, the most 15:25.800 --> 15:30.360 people are familiar with in the user interface, where you can go into that dissection view, 15:30.360 --> 15:35.800 and you can rise a query, and you can really get that deep visibility into packet captures. 15:35.800 --> 15:39.960 So we want to have that exact same experience for StratoShark, but using what we did 15:39.960 --> 15:45.240 fantastic with Falco, and with S-Stick, which is those libraries, so we're reusing those again. 15:45.240 --> 15:51.000 So it's a continuous OSS of involvement. For context, you know, on the left side view, 15:51.000 --> 15:55.800 that is what we are going to see in a second in the terminal. So that's the S-Stick inspect view, 15:55.800 --> 16:00.920 or sorry, S-Stick CLI. There's different names for S-Stick OSS, whatever name you want to use for it. 16:00.920 --> 16:04.680 But as you say, you just run a kind of a S-Stick, and I'll go through the process in the 16:04.680 --> 16:08.520 second view of how you're going to filter that view down, or you can just look at quite literally 16:08.520 --> 16:13.240 every system called coming through. Whereas Falco, on the right side view, same libraries, 16:13.240 --> 16:17.720 but it's that rule engine, so we mentioned it's written in YAML manifest, and you can say, 16:17.800 --> 16:22.440 what is the rule that we're detecting, you define the context in Macros, and this we can talk 16:22.440 --> 16:26.600 about this later, but effectively, that is the unique problem is trying to solve a Falco. 16:27.400 --> 16:30.920 So I'm just going to jump into a demo, because I think that's the best way of doing this. 16:31.800 --> 16:35.320 Where do I put the microphone while I'm demoing? I think we'll just... 16:37.880 --> 16:42.920 Okay, fantastic. So I'm going to close out this view, and we'll come back to in a second, 16:42.920 --> 16:47.480 and everyone should be, can you see my screen? Or how does that work? Because the money presenting 16:47.480 --> 16:54.680 the slide deck, they're a way to stop presenting the slides. 16:58.440 --> 17:05.080 So I'm right now, it's only showing, let me check. 17:12.920 --> 17:31.080 Not even showing down the slide deck, sorry, yeah, maybe you can see. I'm a Linux guy, so you don't need to... 17:31.240 --> 17:32.440 No, yes. 17:37.320 --> 17:42.680 While they're doing that, any questions so far? I mean, we probably have time for one question. 17:44.760 --> 17:45.800 I don't see any hands. 17:48.360 --> 17:54.040 Hey, yep. So I wonder, you know, of course, we were a shock, and we'll pick a packet, 17:54.040 --> 17:58.040 capture over all of the things we've got a pretty good understanding on Linux and the way, 17:58.040 --> 18:02.600 what kind of privileges you can operate with, you know, the version off to run everything, 18:02.600 --> 18:09.320 as a super user. So if you guys work this out, some of the equivalent fashion on the system 18:09.320 --> 18:12.520 calls level, or is this still at the moment that just run as a rule then? 18:18.360 --> 18:19.240 Did we get it? 18:19.240 --> 18:20.440 Yeah, I got it. 18:20.440 --> 18:21.240 Okay. 18:25.240 --> 18:26.840 Just answer your question real quick. 18:27.000 --> 18:32.520 The question you had to do with what privileges you need for for capturing system calls, because 18:33.560 --> 18:39.800 on wire-shark typically on Linux, let's back up here. First of all, 18:39.800 --> 18:44.840 how many of you knew that wire-shark doesn't? The wire-shark application does not capture packets. How many 18:44.840 --> 18:45.240 of you knew that? 18:47.800 --> 18:49.320 Okay, I have you. 18:50.120 --> 18:54.280 The thing that actually captures packets is this is a little tiny utility called dumpcap, 18:54.280 --> 18:59.080 and that's the thing that you have to get privileges to whether it's a super user or 18:59.080 --> 19:06.760 special access to, well, a cabinet admin on Linux and whatever, you know, WPF on macOS and whatever. 19:07.560 --> 19:11.880 There's a similar situation capturing system calls. If you capture from a kernel module, 19:11.880 --> 19:15.640 it's from a device under slash dev, and you just need permissions that device. 19:16.360 --> 19:21.720 The WPF probe, I don't recall lots of them ahead, but permissions need there, but it's, 19:21.720 --> 19:27.080 I'm sure it's pretty standardized, and typically you just need permission to a group to capture. 19:27.080 --> 19:28.200 Then, sirs your question. 19:29.320 --> 19:30.200 Okay, perfect. 19:31.880 --> 19:36.920 Yeah, with that, so at the moment, I'm currently just looking for anything that matches hash, 19:36.920 --> 19:43.400 basically reading a file. So if I was go over here, and I'm in the same box, so I can close that view, 19:43.400 --> 19:50.360 and if I'm just going to say the cat on this Nginx.eml file, you'll see on the left side view, 19:50.520 --> 19:55.320 I'm showing the output of the cat on the Nginx. Now, unless I did something wrong, let's go to 19:55.320 --> 20:01.560 pseudo-system, just to make sure a system is working correctly, and it is, so to our point, 20:01.560 --> 20:06.200 there is a second ago, there's a large volume of system calls being generated directly in the kernel, 20:06.200 --> 20:10.600 all of the time, and it's pretty hard to understand what we're looking at right now. 20:10.760 --> 20:20.200 So for context, I'm on a single of the N2 machines. If you say Qtl, get nodes to show 20:20.200 --> 20:25.720 why, we can see that it's, yeah, just a standard of the N2 machine. I put container D on it, 20:25.720 --> 20:32.600 so we are running Kubernetes. So if I say Qtl, get pods to say, you can see that it's just the 20:32.600 --> 20:36.840 bare minimum Kubernetes cluster. There's nothing special going on here. I have 20:36.920 --> 20:42.920 Sillium as my CNI, and other than that, it's just default stuff that's coming with it. 20:42.920 --> 20:51.160 So let's say I want to monitor a specific process. So what we're going to do is quit this, 20:51.160 --> 20:58.040 if it will quit, and it should, okay, I want, oh, it's quit finally, okay. So what we're going to do 20:58.040 --> 21:03.960 is I'm going to say pseudo-system, and this is the two we're using for collecting these system 21:03.960 --> 21:09.640 called into the S-cut file. So I'm going to say pseudo-system, I'm going to say process, 21:09.640 --> 21:16.760 prok.name equals, let's say, Nginx. Now naturally, there is no workload or there's no process 21:16.760 --> 21:22.280 running inside my environment called Nginx. Now we had that manifest, I mentioned there a second 21:22.280 --> 21:31.800 ago, so if I said Qtl, apply dash f on the Nginx, Nginx, Nginx, and if we watch on the left side panel, 21:31.880 --> 21:36.200 you will see this quite literally in real time coming through. So unless it's like, 21:37.480 --> 21:42.840 they were seeing, okay, so it is coming through. So I'm filtering just for that specific process. 21:43.720 --> 21:51.400 What's interesting to note here is if we say Qtl, get pods, and maybe even just pod-w to watch it for 21:51.400 --> 21:57.480 changes, this was a specifically designed manifest that it would cause a crash loop back, 21:57.480 --> 22:01.640 so it's not designed to work properly. So it's going to go into this running state error, 22:01.640 --> 22:05.240 and then it's going to crash, and it's going to recycle through that. I think the important 22:05.240 --> 22:10.200 thing to spot here is when we're talking about services like solutions like urban eddies, 22:11.080 --> 22:15.560 most people are focusing on the API side of things. So you see those high-level abstractions, 22:15.560 --> 22:22.360 and you can really understand, okay, just by using Qtl, I understand it's going into a crashing state. 22:23.240 --> 22:28.680 But let's say anything lower level than the abstractions of Kubernetes itself, let's say there's 22:28.680 --> 22:36.120 latency or something on those lines, or it's a dependency issue. System calls quite literally show 22:36.120 --> 22:40.440 everything as we mentioned earlier, so if you want to see, for instance, I want to look at 22:41.160 --> 22:50.200 the process activity for engine X, but I also want to see, for instance, the event type activity 22:50.280 --> 22:56.200 of, I don't know, process X, it's every time it leaves, you can quite literally do that just by 22:56.200 --> 23:01.400 pardoning in PROC, exit, and then it will show you every time it's dropping out of that state. 23:02.040 --> 23:08.040 Now, what we want to do is pretty much just write a generic file, so let's say pseudo-sistering, 23:08.040 --> 23:12.200 and this is going to show us quite literally everything in the environment, so we're going to say 23:12.200 --> 23:16.120 pseudo-sistering, and we're going to write it to a file and before I do that, I'm actually going to 23:16.120 --> 23:22.120 put a time out on this as well, so we're going to say time out of 15 seconds, so this is going 23:22.120 --> 23:27.000 to be a 15 second capture, so I'm going to say SISDIG right to a file, and I'm going to call it 23:28.040 --> 23:35.160 phasedom2025.scap, so that's going to be our file. Now, I think one of the things I just 23:35.160 --> 23:40.920 wanted to do here is I have two manifests, or actually a three manifests, so let's say if I say 23:41.080 --> 23:49.080 I'm going to capture this for 15 seconds, and then I want to say QCTL, apply 23:50.120 --> 23:56.360 apply dash f, and we're going to do this a rogue workload. That should just be enough time 23:56.360 --> 24:00.440 that we actually get it in the capture file, and then it should drop out of this in about 15 24:00.440 --> 24:06.600 second capture. So now we have the new file called phasedom2025 capture, and I think this is what you 24:06.680 --> 24:11.480 all want to see now, it's how this shows up in straddleshark, so I'm just going to go back to 24:11.480 --> 24:17.640 this overview here, and I'm going to move a file called because I was playing around with 24:17.640 --> 24:25.480 different files earlier, so if we say phasedom2025.scap, and I'm going to move it to my local directory, 24:26.280 --> 24:30.360 because as we mentioned there, while I go, I'm on a MacBook, so I just want to move that out 24:30.360 --> 24:36.520 of my Linux box to my local directory. So with that, if I was to go to, we'll give it a few seconds, 24:36.520 --> 24:45.160 we can see, hopefully it's not too big capture file. I took for granted how long 15 seconds, 24:45.160 --> 24:51.320 or it is, but if we just go to straddleshark there, a second go out did something more or less 24:51.320 --> 24:58.440 identical, right? So you can go into my engine x-vacor.scap, and you can see in the view, how many events 24:58.520 --> 25:03.800 are actually loading up, so we can see, like it's hundreds and hundreds, sometimes even billions 25:03.800 --> 25:08.760 of events, or generated not only few seconds in that capture file, so it is quite loud. Now, 25:08.760 --> 25:15.640 if I show this as full-screen, many of you be quite familiar with this view, it looks almost identical 25:15.640 --> 25:21.000 to wire-shark. It has that, the try view, I don't know if you describe it as anything else, but you 25:21.000 --> 25:26.360 have your hexadecimal output in the bottom right corner, you tend to have the meat of the information 25:26.440 --> 25:30.680 that you're looking at in the bottom left corner, and then on the top is just all the event view. 25:31.320 --> 25:36.600 Now, what's the daunting part here for users is, I'd barely understood what I saw come out of 25:36.600 --> 25:41.800 assistig, why would I understand what I'm seeing here at the moment? Well, what we've done is try to put 25:41.800 --> 25:47.320 these pre-filtered views, so for instance, if I was to look at all command executions, you would see 25:47.320 --> 25:53.960 that means event dot-type equals x-z-v. Doing that, clicking into it, it shows me all of the 25:54.520 --> 26:04.520 filters for it. Now, if I knew what I was doing, I could say, and proc.name is equal to, let's say, 26:04.520 --> 26:11.320 by its equals equals, so it's going to have space equals equals q-c-t-l, as the tool that we're using here, 26:11.320 --> 26:15.640 and of course it will return every case where there was an interactive command, and it was coming 26:15.640 --> 26:22.120 from q-c-t-t-l, of which there's only two instance of that. Clicking into it, you can then see 26:22.120 --> 26:27.000 all of the event view, and then we can pull this up a bit higher, just so we can see all of the 26:27.000 --> 26:31.800 surrounding context. As I mentioned, this is a single moment in time, so we can see, for instance, 26:31.800 --> 26:38.680 q-c-t-l was run, but the actual thing that was run was me saying, apply a file, and that manifest is 26:38.680 --> 26:43.560 posted on my GitHub repository. Now, in itself, that's not that interesting, because above 26:43.560 --> 26:48.360 by the found that the command was run, but how can I use this in a real world, or let's say, 26:48.360 --> 26:52.760 I don't know how to use these queries. There's a few approaches we can take here. You can grab 26:52.760 --> 26:58.040 something that's in the output of CIS and call, and you could use that as the basis for further searches. 26:58.040 --> 27:04.280 So let's say, okay, let's say, every time q-c-t-l is the executable path, you can actually just 27:04.280 --> 27:10.280 grab that context, throw that into the search view, and if I didn't do that wrong, did I do that wrong? 27:10.280 --> 27:16.920 No, let's see. So at this point, it should show plus, and then I think it's selected, right? 27:17.480 --> 27:22.920 Okay, perfect. So in this case, every time there's a system called, that will have the executable 27:22.920 --> 27:29.000 path of basically q-c-t-l, then you can go through those examples here, or where Gerald and 27:29.000 --> 27:33.640 team amated a lot easier is if you want to say, for instance, I want to look at read write activity, 27:33.640 --> 27:38.920 because again, I'm just learning the basics right now. You can go into examples of, let's say, 27:38.920 --> 27:44.440 read write activity, file deletion, and then it will show you what was the basis for creating that query. 27:44.440 --> 27:48.840 You can, of course, just like in Wireshark, write your own queries, and then save them. 27:49.800 --> 27:55.160 Examples being looking at in band-up and connections. Again, every time you write to a file, 27:55.160 --> 28:02.440 you open a file, an network connection is established, or something is deletion, we see that activity 28:02.440 --> 28:07.000 in system calls. So it's important to understand how we're refiltering through that context, 28:07.000 --> 28:13.240 and naturally when we do get to that context, let's say the case of the read write activity, 28:13.240 --> 28:18.680 then you can just drill down into the individual event. I'm conscious of time. Do you want 28:18.680 --> 28:23.240 to go back to the deck? There, Gerald, are you okay? 28:43.240 --> 28:58.840 Let's do this. 29:07.400 --> 29:12.360 That's when I was down in third. 29:13.240 --> 29:16.080 The water sharks stand earlier today. 29:16.080 --> 29:18.760 We had a bunch of stratter shark stickers and people 29:18.760 --> 29:21.880 kept asking about what was going on there. 29:21.880 --> 29:23.160 What that was. 29:23.160 --> 29:27.260 And the reason, none of you maybe knew what 29:27.260 --> 29:30.600 stratter shark was, is because we just announced it last week. 29:30.600 --> 29:37.600 And so to kind of set some expectations, please 29:37.600 --> 29:41.680 know that the current released number of scatter sharks 29:41.680 --> 29:43.600 were 0.9.0. 29:43.600 --> 29:47.600 And that does reflect the kind of that done this at it. 29:47.600 --> 29:48.720 It's still a work in progress. 29:48.720 --> 29:52.040 We're still early days. 29:52.040 --> 29:58.600 It's a really weird mixture because on the one hand, 29:58.600 --> 30:01.400 we have all this established code that we're using 30:01.400 --> 30:05.440 from wire shark that gives you a really nice, really rich, 30:05.440 --> 30:07.240 and future, full user interface. 30:07.240 --> 30:11.320 But at the same time, as far as being a system 30:11.320 --> 30:15.160 colonelizer goes, we're really still early days. 30:15.160 --> 30:19.200 There's an analysis menu you can pull down that has a few 30:19.200 --> 30:19.760 features. 30:19.760 --> 30:23.560 But as an application developer, I see that. 30:23.560 --> 30:28.360 And what I see is what's going to happen to the future. 30:28.360 --> 30:30.800 If stratter shark is in the, I'm sorry. 30:30.800 --> 30:33.680 If wire shark is in any indication, stratter shark 30:33.680 --> 30:36.680 is going to get a lot of features that will be added. 30:36.680 --> 30:39.120 That are very clever and have been contributed 30:39.120 --> 30:40.360 by the user community. 30:40.360 --> 30:42.400 That's what happened with wire shark somebody would come 30:42.400 --> 30:44.960 along and say, hey, I want to add this feature. 30:44.960 --> 30:46.840 And it would never have occurred to me. 30:46.840 --> 30:48.400 It's just a reflection of the fact 30:48.400 --> 30:52.400 that we have a really clever and really talented community 30:52.400 --> 30:55.400 that dominates all these features. 30:55.400 --> 30:58.440 And I expect that to happen with stratter shark. 30:58.440 --> 31:01.840 The user expander, user experiences roughening 31:01.840 --> 31:04.760 a few places. 31:04.760 --> 31:07.360 And hopefully we can kind of get things straight 31:07.360 --> 31:08.360 not before one does. 31:08.360 --> 31:09.200 It was released. 31:09.200 --> 31:12.080 And just to keep in mind that this is still early days 31:12.080 --> 31:12.680 in the project. 31:17.160 --> 31:20.040 Another question that kept popping up when we did the announcement 31:20.040 --> 31:23.480 was, OK, if I go to stratter shark.org, 31:23.480 --> 31:25.160 I see installers for Windows. 31:25.160 --> 31:27.080 And I see them for Mac OS. 31:27.080 --> 31:28.760 I don't see anything for Linux. 31:28.760 --> 31:29.840 What's going on here? 31:29.840 --> 31:33.320 And part of that is just, like I said, the fact 31:33.320 --> 31:35.360 that we're still early days in the project. 31:35.360 --> 31:37.800 And they're just aren't Linux packages yet. 31:37.800 --> 31:39.520 Part of that is my fault. 31:42.400 --> 31:45.360 Right now, if you want to build a stratter shark package, 31:45.360 --> 31:50.880 you, of course, have to have a few lip scents and lip scents. 31:50.880 --> 31:54.280 Debian has a package for those libraries. 31:54.280 --> 31:58.240 I don't know if any of the RPN-based distributions 31:58.240 --> 32:01.960 do or if RRF-ARCH do, as far as I can tell they don't. 32:01.960 --> 32:05.800 Another problem here is that right now, 32:05.800 --> 32:07.480 stratter shark releases were being done 32:07.480 --> 32:11.080 in a much more rapid cadence than wire shark releases. 32:11.080 --> 32:14.280 So if you're doing that packaging, 32:14.280 --> 32:17.160 it's kind of difficult to package that up. 32:17.160 --> 32:19.880 What I hope to do sometime this summer 32:19.880 --> 32:23.680 is to start matching wire shark releases 32:23.680 --> 32:26.600 and stratter shark releases and doing them at the same time. 32:26.600 --> 32:28.640 But even then, the version numbers are going to be different 32:28.640 --> 32:31.560 because, like I said, right now, or version 0.9, 32:31.560 --> 32:34.200 I want to have a one dot or release just to signal to everybody 32:34.200 --> 32:37.120 that, hey, maybe you should start using this now. 32:37.120 --> 32:39.480 And maybe at some point later, we'll actually 32:39.480 --> 32:42.920 synchronize the wire shark and stratter shark version numbers. 32:42.920 --> 32:47.600 But that's kind of a minor thing right now. 32:47.600 --> 32:52.080 If you want to help, I know the thing that's missing 32:52.080 --> 32:54.640 is local capture on Windows and Mac OS 32:54.640 --> 32:56.440 that would be really useful. 32:56.440 --> 33:01.040 That's each of those platforms has their own mechanism. 33:01.040 --> 33:02.640 For doing that, like on Windows, there's 33:02.640 --> 33:06.560 a TW Mac OS has, sorry, Jetlag. 33:06.560 --> 33:08.200 I can't remember the name of the library. 33:08.200 --> 33:10.200 Anyway, there's a way to do that. 33:10.200 --> 33:12.160 But it's just not implemented yet. 33:12.160 --> 33:16.120 And that's something I hope will pop up over time. 33:16.120 --> 33:17.760 Maybe that's something I'll be able to work on. 33:17.760 --> 33:20.640 Maybe somebody else can help out without. 33:20.640 --> 33:24.600 We do need Linux packaging, but we'll get there. 33:24.600 --> 33:29.560 If you have any questions, like I said, 33:29.560 --> 33:31.160 we have a stand-down building age. 33:31.160 --> 33:33.880 We'll be glad to answer any questions. 33:33.880 --> 33:38.720 We also have stratter shark stickers. 33:41.720 --> 33:43.720 So if you want one of those, this is the first one 33:43.720 --> 33:44.400 of the stickers. 33:44.400 --> 33:46.760 Nobody else has these stickers, so you better get them now. 33:50.760 --> 33:51.840 A few useful links. 33:51.840 --> 33:53.360 If you want to get stratter shark, you can get it 33:53.360 --> 33:55.880 at stratter shark.org. 33:55.880 --> 34:00.560 You can also get, if there is a future that you need that's 34:00.560 --> 34:03.480 not in the installers, you can get latest, 34:03.480 --> 34:06.680 bleeding edge installers from our continuing 34:06.680 --> 34:10.240 sendigration system at the second URL, 34:10.240 --> 34:14.080 there's also this thing here, which is, 34:14.080 --> 34:15.040 it's a Lewiscript. 34:15.040 --> 34:18.920 It's a plug-in for stratter shark code event extras. 34:18.920 --> 34:23.600 And it draws little up and down arrows in your packet 34:23.600 --> 34:28.280 with it or your event list for data IO. 34:28.280 --> 34:29.600 And it's just an example. 34:29.600 --> 34:32.680 Script that shows you how to extend the system called 34:32.680 --> 34:33.840 the center. 34:33.840 --> 34:36.040 There's also this really cool resource. 34:36.040 --> 34:38.920 For the people that sort of has this really great page, 34:38.920 --> 34:40.960 it lists all the Linux system calls, 34:40.960 --> 34:43.360 and if you're interested in that, that's 34:43.360 --> 34:46.520 like I said, really great resource. 34:46.520 --> 34:50.000 Finally, well, actually, we're going to open up 34:50.000 --> 34:51.400 the for-for-question sooner or second. 34:51.400 --> 34:55.480 But at first, I wanted to just say thank you. 34:55.480 --> 34:57.480 Why are shark and now stratter shark are great 34:57.480 --> 34:59.000 and wonderful things? 34:59.000 --> 35:02.000 And it's not because of me, it's because of all of you. 35:02.000 --> 35:04.320 It's because of our community, our users, 35:04.320 --> 35:10.560 our developers, and our educators, and our sponsors. 35:10.560 --> 35:13.160 I love working on these applications, 35:13.160 --> 35:16.600 and it's been the thrill of a lifetime, 35:16.600 --> 35:17.960 and I can't thank you all enough. 35:17.960 --> 35:21.320 I don't know if you would have anything you want to say. 35:21.320 --> 35:23.200 No, absolutely. 35:23.200 --> 35:26.000 We have a bunch of resources we've tried to put together 35:26.000 --> 35:29.120 in the last week, I guess. 35:29.120 --> 35:31.400 So it's a short period of time. 35:31.400 --> 35:34.440 But if you have questions about any of the tools 35:34.440 --> 35:37.160 you mentioned, a system call capture 35:37.160 --> 35:40.360 how to use stratter shark and best practices, 35:40.360 --> 35:44.280 we try to best to document that on strattershark.org, 35:44.280 --> 35:46.880 and I think that's on the next slide, correct? 35:46.880 --> 35:48.200 Yes. 35:48.200 --> 35:51.600 So you can scan the above QR codes, 35:51.600 --> 35:55.600 and that should provide some of the helpful resources, 35:55.600 --> 35:59.080 such as, well, why did we take this approach today? 35:59.080 --> 36:01.320 Why didn't we do this in the past? 36:01.320 --> 36:03.960 Where does all this tieback to cystic? 36:03.960 --> 36:05.840 But also, those articles I mentioned, 36:05.840 --> 36:08.480 they should all be under strattershark.org, 36:08.480 --> 36:10.360 which is easy to find. 36:10.360 --> 36:13.120 And yeah, you can just scan that. 36:13.120 --> 36:15.360 But yeah, we'll leave it open to the Q&A. 36:17.560 --> 36:20.040 Thank you. 36:20.040 --> 36:35.200 Whenever a capturing sees calls, 36:35.200 --> 36:37.600 can it capture the name of the container 36:37.600 --> 36:41.720 in which the process did this call? 36:41.720 --> 36:44.840 Yeah, it's a really good question, 36:44.840 --> 36:47.160 because I probably could have shown it there 36:47.160 --> 36:48.880 in this system call itself. 36:48.880 --> 36:53.320 It actually does contain some context-like container ID. 36:53.320 --> 36:55.520 Do you want to answer that, actually? 36:55.520 --> 37:01.360 Yeah, like you said, the information is captured by a lipscap. 37:01.360 --> 37:04.280 However, on Windows and Mac OS, the library right now 37:04.280 --> 37:07.040 doesn't, there's basically a bug that doesn't show 37:07.040 --> 37:08.160 the information correctly. 37:08.160 --> 37:09.520 And we're open to get that fixed 37:09.520 --> 37:10.840 before the one that I release. 37:17.400 --> 37:19.360 Yeah, hi. 37:19.360 --> 37:21.560 We use support of the architectures, 37:21.560 --> 37:25.960 other than XATCX or 64, we use support ARM, for example. 37:28.400 --> 37:29.840 I didn't quite catch the capture. 37:29.840 --> 37:32.720 Also, will you support other architectures 37:32.720 --> 37:35.200 like ARM, for example? 37:35.200 --> 37:36.800 We already do. 37:36.800 --> 37:38.400 If you go to the start of the Charter Charter Door, 37:38.400 --> 37:41.320 you can download and download for Windows and Mac OS 37:41.320 --> 37:44.200 on both X86 and ARM. 37:44.200 --> 37:45.200 And it's the same with Linux. 37:45.200 --> 37:46.800 I mean, the distribution's just packaged up 37:46.800 --> 37:48.120 for each platform they support. 37:57.240 --> 37:58.080 Oh. 38:02.720 --> 38:06.200 Hi. 38:06.200 --> 38:07.920 Thank you for the talk. 38:07.920 --> 38:10.160 I was wondering, now that Strader Charter 38:10.160 --> 38:14.160 or the entire ecosystem is coming from this container 38:14.160 --> 38:17.960 and monitoring and threat detection background. 38:17.960 --> 38:22.080 Can you see it being useful for debugging some low-level 38:22.080 --> 38:23.400 but user space tools? 38:23.400 --> 38:28.040 Like, I would be thinking, like, system-d for instance. 38:28.040 --> 38:30.960 Is that a use case you anticipate, 38:30.960 --> 38:33.640 or is that just too far off in the future? 38:33.640 --> 38:35.720 A little of a system tool is like what? 38:35.720 --> 38:38.080 Like, I was thinking system-d for instance, 38:38.080 --> 38:41.560 which just uses space tools that would be hard 38:41.560 --> 38:44.200 or annoying to debug with regular means. 38:47.120 --> 38:50.240 Like, that's the nice thing about the system inspection 38:50.240 --> 38:51.680 tool that we just mentioned there, 38:51.680 --> 38:53.360 that you are running in use space. 38:53.360 --> 38:55.200 I think that's what you're asking, correct? 38:55.200 --> 38:57.760 So you can run it within the user space. 38:57.760 --> 38:59.200 You can just put one little flag at the end. 38:59.200 --> 39:02.480 You can say modern BPS probe, if you want to do that. 39:02.480 --> 39:04.480 And then, of course, that would do the collection 39:04.480 --> 39:06.000 from this low as the kernel. 39:06.000 --> 39:09.040 So it shouldn't really hamper your normal operations. 39:09.040 --> 39:11.840 It's not like your new paradigm shift. 39:11.840 --> 39:14.000 You continue working in user space, 39:14.000 --> 39:16.960 but you get the deep kernel activity. 39:16.960 --> 39:18.000 Does that answer the question? 39:18.000 --> 39:19.120 Or is there anything else on that? 39:23.600 --> 39:26.280 Have a question here? 39:27.240 --> 39:29.800 Why did it took so long? 39:29.800 --> 39:33.600 It's like 20 years ago. 39:33.600 --> 39:34.240 Why? 39:34.240 --> 39:35.080 Why now? 39:39.080 --> 39:42.080 Well, I mean, the system tool has been around for a while now. 39:42.080 --> 39:47.760 I think Laura's my boss developed that in what, 20, 15, or 2016. 39:52.360 --> 39:55.880 I've been working on Strider Shark for the last few, 39:55.960 --> 39:58.200 well, I think about two or three years. 39:58.200 --> 40:00.440 One of the reasons has been taken so long 40:00.440 --> 40:03.320 is because at the same time I've been working on Strider Shark, 40:03.320 --> 40:05.800 we've been trying to launch a non-profit foundation 40:05.800 --> 40:08.920 for Wireshark, and that takes time as well. 40:08.920 --> 40:13.800 But it's a good question that you know why it took so long. 40:13.800 --> 40:16.840 Because in retrospect, this is a really obvious and useful thing. 40:16.840 --> 40:19.080 Why didn't we do it, sir, sir? 40:20.200 --> 40:20.680 There's it. 40:20.680 --> 40:22.200 Yeah. 40:22.200 --> 40:23.000 Hi. 40:23.000 --> 40:24.440 I just a quick one. 40:26.440 --> 40:29.240 We are used to use tools like the esterase and things like that. 40:29.240 --> 40:30.760 Are you going to support those as well? 40:30.760 --> 40:33.480 Or just CISD for a cantering? 40:33.480 --> 40:34.840 That's a very good question. 40:34.840 --> 40:39.240 On the Linux side, esterase would be a great candidate for this. 40:39.240 --> 40:42.760 In order to support that, esterase would need to log out something 40:42.760 --> 40:47.640 that would be contained all the information that we needed. 40:47.640 --> 40:50.840 I don't know if esterase has a binary log format or anything like that. 40:50.840 --> 40:52.360 But if it does, we can certainly use that. 40:53.400 --> 40:57.400 Another question along several lines is if we support 40:57.400 --> 40:59.960 Procmon on Windows, because I do know that Procmon, 40:59.960 --> 41:02.600 it's a log file contains all the information that we're going to need. 41:02.600 --> 41:06.840 It's just a matter of developing a file parser that reads that information. 41:08.280 --> 41:09.800 Thank you. 41:09.800 --> 41:16.680 There's any idea about four worst steps to mock-up 41:16.680 --> 41:22.840 by using QR records, mock-up system calls for the application for QA and so on. 41:23.880 --> 41:25.880 For, I'm sorry, for what now? 41:25.880 --> 41:28.680 If you have the records of CISD calls, 41:28.680 --> 41:35.560 you can use them in addition to your application to simulate the work load 41:35.560 --> 41:38.200 and how to house the application is working. 41:38.200 --> 41:42.600 For instance, if you record something from out in the cloud 41:42.600 --> 41:46.120 and then replace your locally the same. 41:46.760 --> 41:50.040 Is it possible in the idea? 41:50.040 --> 41:52.920 You're talking about injecting system calls or... 41:52.920 --> 41:55.080 I think replaying system calls. 41:55.080 --> 41:58.760 So you record and then later in a test environment can play the same? 41:58.760 --> 42:00.440 We don't really do that. 42:00.440 --> 42:05.560 But I mean, like I said, we have a really clever and talented community, 42:05.560 --> 42:08.280 so maybe that would be something somebody could develop. 42:08.280 --> 42:23.160 When you mentioned system calls and logs in any time series database, 42:23.160 --> 42:30.680 so I think the jump from dumps, packet capture dumps 42:31.720 --> 42:37.000 to system calls and capturing those makes a lot of sense, 42:37.000 --> 42:43.880 like refining live data of what's occurring right now, 42:43.880 --> 42:51.240 but I didn't get the gist of how you can jump to from that to logs, 42:51.240 --> 42:58.760 because for me, logs is more like, well, there's a text of data that goes into a database 42:58.760 --> 43:01.880 and you aggregate and query it later. 43:02.200 --> 43:13.320 And in the examples, also, you showed more system calls than logs and how to use... 43:13.320 --> 43:14.520 Yeah. 43:14.520 --> 43:18.360 No, no, it's a good question and it's not something I actually showed in the demo. 43:18.360 --> 43:23.080 I could throw it on my screen really quick, but if we have struttershark open 43:23.080 --> 43:28.200 and I go back onto the home page, this is what you're talking about. 43:28.200 --> 43:33.800 So, we were in a machine and on that machine, we did the capture and we put in an S-cup, 43:33.800 --> 43:36.200 and yes, that is purely system calls. 43:36.200 --> 43:40.760 However, Falco has this plug-in architecture, which means you can stream 43:42.040 --> 43:45.080 events from other arbitrary endpoints. 43:45.080 --> 43:49.480 So, in the case of this example here, we have CloudTrail, AWS, 43:49.480 --> 43:51.000 and of course these are in system calls. 43:51.000 --> 43:54.280 These are the audit service is CloudTrail, 43:54.280 --> 44:01.000 and you can just kind of point to, I think today it's an SNS-Q or S3 bucket, 44:01.000 --> 44:02.680 am I right in saying they're the only options? 44:02.680 --> 44:06.600 Yeah, and obviously they're storing those events that are generated. 44:06.600 --> 44:08.840 So, it's a different paradigm. 44:08.840 --> 44:12.040 You're looking at something that is in system calls, you're looking at all the logs. 44:12.040 --> 44:17.800 However, I mean, it's one of these powerful use cases where you have a EC2 instance, a machine, 44:18.600 --> 44:22.040 and that's the underlying gene for your Kubernetes cluster, 44:22.040 --> 44:23.720 but it's running in a Cloud provider. 44:23.720 --> 44:27.400 So, you have three different sources that you need to look at, 44:27.400 --> 44:30.440 which is the system calls to understand, well, why is that process, 44:30.440 --> 44:32.360 for instance, behaving the way it is? 44:32.360 --> 44:36.840 I want to tie it to that abstraction layer, which is the Kubernetes audit logs to understand, 44:36.840 --> 44:41.880 okay, in which network namespace, or how does this relate back to the abstractions of Kubernetes? 44:41.880 --> 44:44.920 But then I also want to see the context of the Cloud provider, 44:44.920 --> 44:47.880 because then I want to know, well, in which region is this running, 44:47.880 --> 44:50.360 and how does this apply back to AWS? 44:50.360 --> 44:53.560 So, I think that answers your question, correct? 44:53.640 --> 44:54.600 Correct. 44:58.600 --> 45:00.280 Yeah, I also have a question. 45:01.480 --> 45:06.520 So, for network-tuned traffic, it's kind of a subset of system calls, right? 45:06.520 --> 45:11.160 All the system calls to make networking connections are also system calls, 45:11.880 --> 45:15.160 and we could already see that the files get pretty big. 45:15.160 --> 45:21.160 Is wire-grab-shark going to be fast enough to analyze like real-world traces? 45:22.120 --> 45:23.240 It's a good question. 45:23.240 --> 45:24.120 Do you want to take these? 45:25.320 --> 45:26.120 Oh, sure. 45:27.480 --> 45:32.600 That's always been a problem with the application, and not only wire-shark, 45:32.600 --> 45:36.840 I remember years ago when I very first started out analyzing networks, 45:36.840 --> 45:39.000 I had, I used this thing called a Sniffer. 45:39.000 --> 45:41.000 It was this hardware device about this big. 45:41.000 --> 45:44.760 It cost as much as a luxury car, but even back then, in the early 90s, 45:44.760 --> 45:50.040 that was one of the things you had to deal with, dealing with the back-than-10 mix, 45:50.040 --> 45:54.120 was a really fast network, and the Sniffer just could barely keep up with that. 45:54.120 --> 45:57.640 And that's just a continuous thing that we always have to deal with. 45:57.640 --> 46:03.800 Just whether or not your analyzer can keep up with whatever fast is at the current time. 46:03.800 --> 46:10.040 And to be more specific about the answer, 46:10.040 --> 46:12.520 one of the things I'm not really happy with, wire-shark right now, 46:12.520 --> 46:18.600 is that I made a mistake early on, and the design didn't really allow 46:18.600 --> 46:21.480 for multiple cores to be used when analyzing it. 46:21.480 --> 46:25.080 And for network traffic, that's actually a very hard thing to do. 46:25.080 --> 46:28.280 But maybe that is something we can add later on, 46:28.280 --> 46:31.320 and be more much, much more efficient about processing packets, 46:31.320 --> 46:34.520 and utilizing all the resources on your system to do that. 46:34.520 --> 46:38.680 And that would alleviate the amount of days that we're dealing with. 46:41.240 --> 46:41.720 Do you? 46:45.560 --> 46:46.920 Do we have any other questions? 46:49.560 --> 46:52.680 But actually, I just thought of something that I wanted to add on. 46:56.120 --> 47:00.440 Something that's continuously amazed me is the amount of data that people are actually able to 47:00.440 --> 47:07.320 pull into wire-shark. I forget how many rows, you know, Microsoft Excel will handle in their spreadsheet, 47:07.320 --> 47:10.440 but it's some comparatively small number. 47:10.440 --> 47:13.320 We recently, a couple of years ago, fixed a bug, you know, 47:13.320 --> 47:17.640 somebody complained that they couldn't load more than 53 million packets into wire-shark, 47:17.720 --> 47:20.040 and they were upset about that, and we found the bug and fixed it. 47:20.040 --> 47:21.560 You can actually load more than that. 47:21.560 --> 47:24.840 So, you know, that capabilities there in the application, 47:24.840 --> 47:28.040 it's just, you know, the matter of making it fast and more efficient in dealing with. 47:30.920 --> 47:32.200 Very cool. 47:32.200 --> 47:36.840 If not, then yeah, please give another one plus through the speakers.