Okay, so next stock is by Gerald Combs and Nigel Douglas, and they're here to tell us all
about a stratashock applying the power of Washock to system calls and logs help me give them
a roll-on-one.
Come, please.
Thank you.
Well, good afternoon, everyone.
Can you hear me okay?
Great.
Good.
As the slide says, I'm Gerald Combs, I am the creator of Washock.
I'm also involved with the Washock Foundation, and if you want to learn more about that,
we have a stand over and building age, and we can tell you all about that.
I also work for a company called CISDIG, and I'm here with one of my co-workers and I'll
take this, who good news for you.
He's a much better presenter than I am, and he'll be talking a little bit about FACO and about
stratashock.
So, quick overview of what we're going to talk about.
First I'm going to cover a little bit about Washock and what it does and how it relates
to stratashock, and then we're going to talk about FACO and how it relates to stratashock
as well, and Nigel's going to give a quick demo, and then we're going to wrap up with
some more information and have some time for questions if you have any.
Now, I thought I'd start off, I thought I'd start off where I left off last time, which
was 20 years ago when I was here at Fauston, giving a talk, and at that time, I was talking
about a project called the Thereal, and I thought I'd give a status update on the
big news is we changed the name to Washock.
We got a new name, the project grew, in fact, it grew enough such that we now have conferences
for Washock, one in the US, and one in the EU each year.
We went ahead and started a foundation called the Washock Foundation, again, if you want
to learn more about that, we'd be happy to talk to you over at the Washock stand, and
fill you in on that.
So, as more of a Washock status update, Washock actually has grown to be a pretty good sized
application, and we're up to, depending on how you measure code, we're up to either 3.5
million lines of code, or 6 million lines of code, whether or not you can automatically
generate a code, and that's been generated and created by about 2,300 contributors so far,
and that bottom number is something that I really love, I really love the fact that so many
people have contributed to the project and are involved, it's really great to be part of something
like that, but we have a lot of users as well, we get about on the servers that I manage
and the servers I have insight into, we have about, sorry, back up one, we have about a million
and a half-down loads per month, and most of those for Windows and Mac OS, I don't really have a
lot of insight into how many Linux users we have, because I just don't have access to those
statistics, but I'm assuming that it's kind of the line with the Windows and the Mac OS users.
We have a pretty active user community, we have an active question and answer side, an active
discord server, mainly, this aren't really active, but we still have them, and that's also
kind of an indication that we have a pretty large and popular project. Next slide, now,
this is a carry, we support 3,000 protocols, that's a pretty obvious thing, there's these things
called network protocols, which are standardized and where shark supports about 3,000 of them,
but that second number, we support 250,000 display filter fields, and that's an indication
of how large and useful our shark is, but it's not really obvious what fields are, so maybe
I actually explain what those are and how they make our shark useful. The core of our shark is
its dissection engine, and by that I mean, when you click on a packet in a wire shark, it takes
that packet and breaks it down into its constituent fields, and it shows you everything about
every bit and bite in that packet that it can, and so it'll take each field and give it a name,
it'll tell you where it is, and how large it is, what kind of data you're looking at, whether it's
a number, an IP address, or a string, or what, have you, and the thing about the detection
and it makes it so useful is that you can filter on those fields, and the big and obvious thing
is that this little text area at the top of the application that lets you type in these filters
and drill down to the traffic that they're really interested in, for instance, at the top,
you can see a filter for ICMP, and any frame that has a string, ABCDF, blah, blah, blah. But there are
all sorts of other features and more shark that make use of this dissection engine, and these
display filter fields, for instance, if you look at the packet list, it's usually drawn in a
bunch of different colors, and that's driven by display filters. You can pull up an IO graph,
and graph either field values, or say how many times they occur over time, interval, you know,
things like that, and a bunch of other features, for instance, if you use wire sharks configuration
profile feature, and you should, if you're a wire shark user, it's really useful. You can set
up a filter that automatically applies a configuration profile. If it matches the first thousand
packets in a capture file, when you open it, for instance, you know, if you have a Wi-Fi profile,
you can look for a specific Wi-Fi filter and have that automatically applied when you open that
file. It's pretty useful. The other thing to know about Wi-Shark is that we're a part of a larger
ecosystem, and if you're not familiar with the logos at the top, we have Kismit and Snort,
C, T, C, Dump, and Top, and Map, and Ceracotta, and those are all based on around a library called
libpecap, and on Windows, you know, we used to have onepecap, and now we have npecap, but
the next slide, the cool thing about libpecap is, as an application developer, libpecap,
lets me not care. It lets me not care about the intricacies of capturing on Linux or Mac OS or Windows.
I don't have to reach down into those OS's, and figure out how to pull those packets out,
libpecap takes care of that for me. It makes things very convenient. I remember when I was very
first developing ethereal, one of the very first things I did was to write this little minimum
viable bit of code that captured packets using libpecap, and prove myself, okay, we can build
an analyzer and top of this, and so it started there and kind of proceeded from there. The other
cool thing about libpecap is that it has a couple of file formats associated with libpecap and
g, and if he back up one slide, the useful thing there is that it lets you pivot between all
these applications. For instance, something I do all the time is, you know, I have a bunch of servers
up in the cloud, and if I need to do a packet capture, it's, you know, typically, like AWS or wherever,
those instances will have, these have been installed already, so it's really easy to just
grab the packet capture, pull it down, and load it into wireshark, or you pass it through
some order, whatever. It's time. So this is really cool, this is really great, it's useful.
A useful question to ask is where we might take these two nice things, this dissection engine,
and this ecosystem, and see where else we might apply that, and the thing that I've been focusing
on is that taking those things and applying them to system calls and the log messages. As it turns
up, any other time series database that you might be dealing with, and that's what we're going
to talk about next, and the thing that, well, just to make sure everybody's on the same page here,
the reason that it's useful to be able to capture system calls is that system calls, they're
kind of the boundary layer between the programs that run on your operating system and the operating
system itself, and so, you know, if you have a web browser, a shell, or a wireshark, what have
you, any time they do anything interesting on your operating system, they're going to go through
the Cisco interface, you know, whether it's reading a file, or playing a sound, or connecting
to something in the network, they're going to use system calls. The nice thing from an application
development point of view is that this is a standard interface, and it lets me, again, not
worry about things, if I write a program that just, you know, reads a file from the TIMP directory,
ultimately going to call open, or when it is associated with system calls, and then read,
you know, several times until I get the contents of the file followed by close, and the cool thing is,
I don't have to worry about whether that's file is on an SSD, or USB stick, or spinning rust,
or on a network share, you know, that the system calls behave the same either way, and on the
operating system side, this is pretty cool because I can enforce security boundaries. If I don't have
access to that file, the operating system, you just say no. But the thing is, like I said,
anytime your, the program's on your system do anything, it's going to go through that system call
interface. So as someone who has written a protocol analyzer, a really useful question would be,
you know, what if we can capture that, and what if we can analyze that? That's what my boss and
my co-workers at SystemDong. They have developed a couple of libraries, LibsGap, and LibsSense,
LibsGapSense for library for system capture, and it can pull a system calls out of your OS through,
using a couple of methods. One is either kernel module, or an EPPF probe,
LibsGap also supports a plugin interface, and there are a bunch of different plugins out there for it.
For instance, you can pull in cloud trail logs, or Kubernetes audit logs, or DCP out at logs,
and things like that. But like I said, if you have a system where you work, or that you do with
that generates custom logs, you can write a plugin for this and pull them in that way. On top of
LibsGap, there's LibsSense with Sense for library for system inspection, and it takes that data
in and enriches it. For instance, with System calls that'll associate user IDs with user names,
and file names, and socket pairs with network connections, and things like that.
On top of that, we have the System OSS command line tool, which works a lot like TCBDum.
You run it, and it'll print System calls, and information on your terminal interface.
We also have FACO, which works a lot like an IDS. They'll continuously read System calls,
and match them against filters, and alert you if anything weird is happening.
The thing that I've been working on is Stratofshark, which takes what I talked about earlier,
which is where Sharks is a section engine, and it's user interface, and it lets you apply that
to System calls, and so that's what we're going to be showing off today.
Right now I'm going to hand things over to Nigel.
Thank you very much. I'm going to keep this nice and short, so we have time for the demonstration.
I work on a project called FACO, and FACO is basically doing a lot of what we just talked about there,
which is System call and inspection. We use those same libraries that we mentioned there.
Second go, Lips inspection, and the Lips Capture. The differentiator here is that FACO is a
rule engine, so we take those System call logic. We build these YAML-based rules, and you can detect
anomalous behavior in your environment, so for those who are familiar with Kubernetes,
the CNCF ecosystem that we probably quite familiar with this project of FACO.
FACO is great, it's probably the tool to use, and I would recommend if you are looking for unusual
behavior in Kubernetes, because you're not just looking at System calls, but then you can also,
as we mentioned there's a technique in Richard again, context from the Kubernetes Autologue
for instance, and even go further and then take the Cloud Provider Autologues as well for additional
context on that Cloud Provider. Where FACO doesn't cover something is where we're talking
about the inspection piece. It's designed so that we're not looking at every single system
call that goes through instead we're kind of streaming it, so we build a set of rules,
and they will look for fine-grained context, so we have all this context that we're stripping
from the metadata of those System calls, and we say if we match that arbitrary context,
then you get a detection which tells you we know something's happening in your environment.
But let's say you're doing troubleshooting forensics, and you need more than just a detection.
Maybe detections are good piece, because it tells you something's happening in your environment.
But the capture file itself, the S-CAP, so think of an S-CAP the same way as a P-CAP in Warshark.
And the S-CAP will show us just about everything, and they can be rather large in size.
So think of this as the relationship where we're at today, and it's definitely a funny looking image.
So Warshark has been around since the 90s, so it's been around for quite some time,
and it was a protocol in Alice's tool, and you were holding these files in P-CAP format.
S-CAP came along, and it was trying to be effectively Warshark, in sense that it's closer to TCP dump,
as a general put it at a second ago, so you could run these, you know, cystic.wn right to a file,
and it will be written to an S-CAP. So instead of P-CAP, sure, over a wire, you're looking at
system calls from the kernel. As I mentioned there a second ago, Falco then is a CNCF project.
So we donated that project to the cloud native computing foundation, and the CNCF then oversight
or overlook the project of Falco. But as I mentioned, it's got a focus being on
detection of system call activity. So then we go in this kind of reverse path backwards,
where we've done projects like S-Stick, which created those Lips, CAP, and Lips and Spection
Libraries. We use those same libraries in Falco, and now today we're working those libraries
again into StratoShark. So what we're trying to do is go back to our grassroots and say,
look, what did Warshark do? That was fantastic, which was that uniformal design, the most
people are familiar with in the user interface, where you can go into that dissection view,
and you can rise a query, and you can really get that deep visibility into packet captures.
So we want to have that exact same experience for StratoShark, but using what we did
fantastic with Falco, and with S-Stick, which is those libraries, so we're reusing those again.
So it's a continuous OSS of involvement. For context, you know, on the left side view,
that is what we are going to see in a second in the terminal. So that's the S-Stick inspect view,
or sorry, S-Stick CLI. There's different names for S-Stick OSS, whatever name you want to use for it.
But as you say, you just run a kind of a S-Stick, and I'll go through the process in the
second view of how you're going to filter that view down, or you can just look at quite literally
every system called coming through. Whereas Falco, on the right side view, same libraries,
but it's that rule engine, so we mentioned it's written in YAML manifest, and you can say,
what is the rule that we're detecting, you define the context in Macros, and this we can talk
about this later, but effectively, that is the unique problem is trying to solve a Falco.
So I'm just going to jump into a demo, because I think that's the best way of doing this.
Where do I put the microphone while I'm demoing? I think we'll just...
Okay, fantastic. So I'm going to close out this view, and we'll come back to in a second,
and everyone should be, can you see my screen? Or how does that work? Because the money presenting
the slide deck, they're a way to stop presenting the slides.
So I'm right now, it's only showing, let me check.
Not even showing down the slide deck, sorry, yeah, maybe you can see. I'm a Linux guy, so you don't need to...
No, yes.
While they're doing that, any questions so far? I mean, we probably have time for one question.
I don't see any hands.
Hey, yep. So I wonder, you know, of course, we were a shock, and we'll pick a packet,
capture over all of the things we've got a pretty good understanding on Linux and the way,
what kind of privileges you can operate with, you know, the version off to run everything,
as a super user. So if you guys work this out, some of the equivalent fashion on the system
calls level, or is this still at the moment that just run as a rule then?
Did we get it?
Yeah, I got it.
Okay.
Just answer your question real quick.
The question you had to do with what privileges you need for for capturing system calls, because
on wire-shark typically on Linux, let's back up here. First of all,
how many of you knew that wire-shark doesn't? The wire-shark application does not capture packets. How many
of you knew that?
Okay, I have you.
The thing that actually captures packets is this is a little tiny utility called dumpcap,
and that's the thing that you have to get privileges to whether it's a super user or
special access to, well, a cabinet admin on Linux and whatever, you know, WPF on macOS and whatever.
There's a similar situation capturing system calls. If you capture from a kernel module,
it's from a device under slash dev, and you just need permissions that device.
The WPF probe, I don't recall lots of them ahead, but permissions need there, but it's,
I'm sure it's pretty standardized, and typically you just need permission to a group to capture.
Then, sirs your question.
Okay, perfect.
Yeah, with that, so at the moment, I'm currently just looking for anything that matches hash,
basically reading a file. So if I was go over here, and I'm in the same box, so I can close that view,
and if I'm just going to say the cat on this Nginx.eml file, you'll see on the left side view,
I'm showing the output of the cat on the Nginx. Now, unless I did something wrong, let's go to
pseudo-system, just to make sure a system is working correctly, and it is, so to our point,
there is a second ago, there's a large volume of system calls being generated directly in the kernel,
all of the time, and it's pretty hard to understand what we're looking at right now.
So for context, I'm on a single of the N2 machines. If you say Qtl, get nodes to show
why, we can see that it's, yeah, just a standard of the N2 machine. I put container D on it,
so we are running Kubernetes. So if I say Qtl, get pods to say, you can see that it's just the
bare minimum Kubernetes cluster. There's nothing special going on here. I have
Sillium as my CNI, and other than that, it's just default stuff that's coming with it.
So let's say I want to monitor a specific process. So what we're going to do is quit this,
if it will quit, and it should, okay, I want, oh, it's quit finally, okay. So what we're going to do
is I'm going to say pseudo-system, and this is the two we're using for collecting these system
called into the S-cut file. So I'm going to say pseudo-system, I'm going to say process,
prok.name equals, let's say, Nginx. Now naturally, there is no workload or there's no process
running inside my environment called Nginx. Now we had that manifest, I mentioned there a second
ago, so if I said Qtl, apply dash f on the Nginx, Nginx, Nginx, and if we watch on the left side panel,
you will see this quite literally in real time coming through. So unless it's like,
they were seeing, okay, so it is coming through. So I'm filtering just for that specific process.
What's interesting to note here is if we say Qtl, get pods, and maybe even just pod-w to watch it for
changes, this was a specifically designed manifest that it would cause a crash loop back,
so it's not designed to work properly. So it's going to go into this running state error,
and then it's going to crash, and it's going to recycle through that. I think the important
thing to spot here is when we're talking about services like solutions like urban eddies,
most people are focusing on the API side of things. So you see those high-level abstractions,
and you can really understand, okay, just by using Qtl, I understand it's going into a crashing state.
But let's say anything lower level than the abstractions of Kubernetes itself, let's say there's
latency or something on those lines, or it's a dependency issue. System calls quite literally show
everything as we mentioned earlier, so if you want to see, for instance, I want to look at
the process activity for engine X, but I also want to see, for instance, the event type activity
of, I don't know, process X, it's every time it leaves, you can quite literally do that just by
pardoning in PROC, exit, and then it will show you every time it's dropping out of that state.
Now, what we want to do is pretty much just write a generic file, so let's say pseudo-sistering,
and this is going to show us quite literally everything in the environment, so we're going to say
pseudo-sistering, and we're going to write it to a file and before I do that, I'm actually going to
put a time out on this as well, so we're going to say time out of 15 seconds, so this is going
to be a 15 second capture, so I'm going to say SISDIG right to a file, and I'm going to call it
phasedom2025.scap, so that's going to be our file. Now, I think one of the things I just
wanted to do here is I have two manifests, or actually a three manifests, so let's say if I say
I'm going to capture this for 15 seconds, and then I want to say QCTL, apply
apply dash f, and we're going to do this a rogue workload. That should just be enough time
that we actually get it in the capture file, and then it should drop out of this in about 15
second capture. So now we have the new file called phasedom2025 capture, and I think this is what you
all want to see now, it's how this shows up in straddleshark, so I'm just going to go back to
this overview here, and I'm going to move a file called because I was playing around with
different files earlier, so if we say phasedom2025.scap, and I'm going to move it to my local directory,
because as we mentioned there, while I go, I'm on a MacBook, so I just want to move that out
of my Linux box to my local directory. So with that, if I was to go to, we'll give it a few seconds,
we can see, hopefully it's not too big capture file. I took for granted how long 15 seconds,
or it is, but if we just go to straddleshark there, a second go out did something more or less
identical, right? So you can go into my engine x-vacor.scap, and you can see in the view, how many events
are actually loading up, so we can see, like it's hundreds and hundreds, sometimes even billions
of events, or generated not only few seconds in that capture file, so it is quite loud. Now,
if I show this as full-screen, many of you be quite familiar with this view, it looks almost identical
to wire-shark. It has that, the try view, I don't know if you describe it as anything else, but you
have your hexadecimal output in the bottom right corner, you tend to have the meat of the information
that you're looking at in the bottom left corner, and then on the top is just all the event view.
Now, what's the daunting part here for users is, I'd barely understood what I saw come out of
assistig, why would I understand what I'm seeing here at the moment? Well, what we've done is try to put
these pre-filtered views, so for instance, if I was to look at all command executions, you would see
that means event dot-type equals x-z-v. Doing that, clicking into it, it shows me all of the
filters for it. Now, if I knew what I was doing, I could say, and proc.name is equal to, let's say,
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,
and of course it will return every case where there was an interactive command, and it was coming
from q-c-t-t-l, of which there's only two instance of that. Clicking into it, you can then see
all of the event view, and then we can pull this up a bit higher, just so we can see all of the
surrounding context. As I mentioned, this is a single moment in time, so we can see, for instance,
q-c-t-l was run, but the actual thing that was run was me saying, apply a file, and that manifest is
posted on my GitHub repository. Now, in itself, that's not that interesting, because above
by the found that the command was run, but how can I use this in a real world, or let's say,
I don't know how to use these queries. There's a few approaches we can take here. You can grab
something that's in the output of CIS and call, and you could use that as the basis for further searches.
So let's say, okay, let's say, every time q-c-t-l is the executable path, you can actually just
grab that context, throw that into the search view, and if I didn't do that wrong, did I do that wrong?
No, let's see. So at this point, it should show plus, and then I think it's selected, right?
Okay, perfect. So in this case, every time there's a system called, that will have the executable
path of basically q-c-t-l, then you can go through those examples here, or where Gerald and
team amated a lot easier is if you want to say, for instance, I want to look at read write activity,
because again, I'm just learning the basics right now. You can go into examples of, let's say,
read write activity, file deletion, and then it will show you what was the basis for creating that query.
You can, of course, just like in Wireshark, write your own queries, and then save them.
Examples being looking at in band-up and connections. Again, every time you write to a file,
you open a file, an network connection is established, or something is deletion, we see that activity
in system calls. So it's important to understand how we're refiltering through that context,
and naturally when we do get to that context, let's say the case of the read write activity,
then you can just drill down into the individual event. I'm conscious of time. Do you want
to go back to the deck? There, Gerald, are you okay?
Let's do this.
That's when I was down in third.
The water sharks stand earlier today.
We had a bunch of stratter shark stickers and people
kept asking about what was going on there.
What that was.
And the reason, none of you maybe knew what
stratter shark was, is because we just announced it last week.
And so to kind of set some expectations, please
know that the current released number of scatter sharks
were 0.9.0.
And that does reflect the kind of that done this at it.
It's still a work in progress.
We're still early days.
It's a really weird mixture because on the one hand,
we have all this established code that we're using
from wire shark that gives you a really nice, really rich,
and future, full user interface.
But at the same time, as far as being a system
colonelizer goes, we're really still early days.
There's an analysis menu you can pull down that has a few
features.
But as an application developer, I see that.
And what I see is what's going to happen to the future.
If stratter shark is in the, I'm sorry.
If wire shark is in any indication, stratter shark
is going to get a lot of features that will be added.
That are very clever and have been contributed
by the user community.
That's what happened with wire shark somebody would come
along and say, hey, I want to add this feature.
And it would never have occurred to me.
It's just a reflection of the fact
that we have a really clever and really talented community
that dominates all these features.
And I expect that to happen with stratter shark.
The user expander, user experiences roughening
a few places.
And hopefully we can kind of get things straight
not before one does.
It was released.
And just to keep in mind that this is still early days
in the project.
Another question that kept popping up when we did the announcement
was, OK, if I go to stratter shark.org,
I see installers for Windows.
And I see them for Mac OS.
I don't see anything for Linux.
What's going on here?
And part of that is just, like I said, the fact
that we're still early days in the project.
And they're just aren't Linux packages yet.
Part of that is my fault.
Right now, if you want to build a stratter shark package,
you, of course, have to have a few lip scents and lip scents.
Debian has a package for those libraries.
I don't know if any of the RPN-based distributions
do or if RRF-ARCH do, as far as I can tell they don't.
Another problem here is that right now,
stratter shark releases were being done
in a much more rapid cadence than wire shark releases.
So if you're doing that packaging,
it's kind of difficult to package that up.
What I hope to do sometime this summer
is to start matching wire shark releases
and stratter shark releases and doing them at the same time.
But even then, the version numbers are going to be different
because, like I said, right now, or version 0.9,
I want to have a one dot or release just to signal to everybody
that, hey, maybe you should start using this now.
And maybe at some point later, we'll actually
synchronize the wire shark and stratter shark version numbers.
But that's kind of a minor thing right now.
If you want to help, I know the thing that's missing
is local capture on Windows and Mac OS
that would be really useful.
That's each of those platforms has their own mechanism.
For doing that, like on Windows, there's
a TW Mac OS has, sorry, Jetlag.
I can't remember the name of the library.
Anyway, there's a way to do that.
But it's just not implemented yet.
And that's something I hope will pop up over time.
Maybe that's something I'll be able to work on.
Maybe somebody else can help out without.
We do need Linux packaging, but we'll get there.
If you have any questions, like I said,
we have a stand-down building age.
We'll be glad to answer any questions.
We also have stratter shark stickers.
So if you want one of those, this is the first one
of the stickers.
Nobody else has these stickers, so you better get them now.
A few useful links.
If you want to get stratter shark, you can get it
at stratter shark.org.
You can also get, if there is a future that you need that's
not in the installers, you can get latest,
bleeding edge installers from our continuing
sendigration system at the second URL,
there's also this thing here, which is,
it's a Lewiscript.
It's a plug-in for stratter shark code event extras.
And it draws little up and down arrows in your packet
with it or your event list for data IO.
And it's just an example.
Script that shows you how to extend the system called
the center.
There's also this really cool resource.
For the people that sort of has this really great page,
it lists all the Linux system calls,
and if you're interested in that, that's
like I said, really great resource.
Finally, well, actually, we're going to open up
the for-for-question sooner or second.
But at first, I wanted to just say thank you.
Why are shark and now stratter shark are great
and wonderful things?
And it's not because of me, it's because of all of you.
It's because of our community, our users,
our developers, and our educators, and our sponsors.
I love working on these applications,
and it's been the thrill of a lifetime,
and I can't thank you all enough.
I don't know if you would have anything you want to say.
No, absolutely.
We have a bunch of resources we've tried to put together
in the last week, I guess.
So it's a short period of time.
But if you have questions about any of the tools
you mentioned, a system call capture
how to use stratter shark and best practices,
we try to best to document that on strattershark.org,
and I think that's on the next slide, correct?
Yes.
So you can scan the above QR codes,
and that should provide some of the helpful resources,
such as, well, why did we take this approach today?
Why didn't we do this in the past?
Where does all this tieback to cystic?
But also, those articles I mentioned,
they should all be under strattershark.org,
which is easy to find.
And yeah, you can just scan that.
But yeah, we'll leave it open to the Q&A.
Thank you.
Whenever a capturing sees calls,
can it capture the name of the container
in which the process did this call?
Yeah, it's a really good question,
because I probably could have shown it there
in this system call itself.
It actually does contain some context-like container ID.
Do you want to answer that, actually?
Yeah, like you said, the information is captured by a lipscap.
However, on Windows and Mac OS, the library right now
doesn't, there's basically a bug that doesn't show
the information correctly.
And we're open to get that fixed
before the one that I release.
Yeah, hi.
We use support of the architectures,
other than XATCX or 64, we use support ARM, for example.
I didn't quite catch the capture.
Also, will you support other architectures
like ARM, for example?
We already do.
If you go to the start of the Charter Charter Door,
you can download and download for Windows and Mac OS
on both X86 and ARM.
And it's the same with Linux.
I mean, the distribution's just packaged up
for each platform they support.
Oh.
Hi.
Thank you for the talk.
I was wondering, now that Strader Charter
or the entire ecosystem is coming from this container
and monitoring and threat detection background.
Can you see it being useful for debugging some low-level
but user space tools?
Like, I would be thinking, like, system-d for instance.
Is that a use case you anticipate,
or is that just too far off in the future?
A little of a system tool is like what?
Like, I was thinking system-d for instance,
which just uses space tools that would be hard
or annoying to debug with regular means.
Like, that's the nice thing about the system inspection
tool that we just mentioned there,
that you are running in use space.
I think that's what you're asking, correct?
So you can run it within the user space.
You can just put one little flag at the end.
You can say modern BPS probe, if you want to do that.
And then, of course, that would do the collection
from this low as the kernel.
So it shouldn't really hamper your normal operations.
It's not like your new paradigm shift.
You continue working in user space,
but you get the deep kernel activity.
Does that answer the question?
Or is there anything else on that?
Have a question here?
Why did it took so long?
It's like 20 years ago.
Why?
Why now?
Well, I mean, the system tool has been around for a while now.
I think Laura's my boss developed that in what, 20, 15, or 2016.
I've been working on Strider Shark for the last few,
well, I think about two or three years.
One of the reasons has been taken so long
is because at the same time I've been working on Strider Shark,
we've been trying to launch a non-profit foundation
for Wireshark, and that takes time as well.
But it's a good question that you know why it took so long.
Because in retrospect, this is a really obvious and useful thing.
Why didn't we do it, sir, sir?
There's it.
Yeah.
Hi.
I just a quick one.
We are used to use tools like the esterase and things like that.
Are you going to support those as well?
Or just CISD for a cantering?
That's a very good question.
On the Linux side, esterase would be a great candidate for this.
In order to support that, esterase would need to log out something
that would be contained all the information that we needed.
I don't know if esterase has a binary log format or anything like that.
But if it does, we can certainly use that.
Another question along several lines is if we support
Procmon on Windows, because I do know that Procmon,
it's a log file contains all the information that we're going to need.
It's just a matter of developing a file parser that reads that information.
Thank you.
There's any idea about four worst steps to mock-up
by using QR records, mock-up system calls for the application for QA and so on.
For, I'm sorry, for what now?
If you have the records of CISD calls,
you can use them in addition to your application to simulate the work load
and how to house the application is working.
For instance, if you record something from out in the cloud
and then replace your locally the same.
Is it possible in the idea?
You're talking about injecting system calls or...
I think replaying system calls.
So you record and then later in a test environment can play the same?
We don't really do that.
But I mean, like I said, we have a really clever and talented community,
so maybe that would be something somebody could develop.
When you mentioned system calls and logs in any time series database,
so I think the jump from dumps, packet capture dumps
to system calls and capturing those makes a lot of sense,
like refining live data of what's occurring right now,
but I didn't get the gist of how you can jump to from that to logs,
because for me, logs is more like, well, there's a text of data that goes into a database
and you aggregate and query it later.
And in the examples, also, you showed more system calls than logs and how to use...
Yeah.
No, no, it's a good question and it's not something I actually showed in the demo.
I could throw it on my screen really quick, but if we have struttershark open
and I go back onto the home page, this is what you're talking about.
So, we were in a machine and on that machine, we did the capture and we put in an S-cup,
and yes, that is purely system calls.
However, Falco has this plug-in architecture, which means you can stream
events from other arbitrary endpoints.
So, in the case of this example here, we have CloudTrail, AWS,
and of course these are in system calls.
These are the audit service is CloudTrail,
and you can just kind of point to, I think today it's an SNS-Q or S3 bucket,
am I right in saying they're the only options?
Yeah, and obviously they're storing those events that are generated.
So, it's a different paradigm.
You're looking at something that is in system calls, you're looking at all the logs.
However, I mean, it's one of these powerful use cases where you have a EC2 instance, a machine,
and that's the underlying gene for your Kubernetes cluster,
but it's running in a Cloud provider.
So, you have three different sources that you need to look at,
which is the system calls to understand, well, why is that process,
for instance, behaving the way it is?
I want to tie it to that abstraction layer, which is the Kubernetes audit logs to understand,
okay, in which network namespace, or how does this relate back to the abstractions of Kubernetes?
But then I also want to see the context of the Cloud provider,
because then I want to know, well, in which region is this running,
and how does this apply back to AWS?
So, I think that answers your question, correct?
Correct.
Yeah, I also have a question.
So, for network-tuned traffic, it's kind of a subset of system calls, right?
All the system calls to make networking connections are also system calls,
and we could already see that the files get pretty big.
Is wire-grab-shark going to be fast enough to analyze like real-world traces?
It's a good question.
Do you want to take these?
Oh, sure.
That's always been a problem with the application, and not only wire-shark,
I remember years ago when I very first started out analyzing networks,
I had, I used this thing called a Sniffer.
It was this hardware device about this big.
It cost as much as a luxury car, but even back then, in the early 90s,
that was one of the things you had to deal with, dealing with the back-than-10 mix,
was a really fast network, and the Sniffer just could barely keep up with that.
And that's just a continuous thing that we always have to deal with.
Just whether or not your analyzer can keep up with whatever fast is at the current time.
And to be more specific about the answer,
one of the things I'm not really happy with, wire-shark right now,
is that I made a mistake early on, and the design didn't really allow
for multiple cores to be used when analyzing it.
And for network traffic, that's actually a very hard thing to do.
But maybe that is something we can add later on,
and be more much, much more efficient about processing packets,
and utilizing all the resources on your system to do that.
And that would alleviate the amount of days that we're dealing with.
Do you?
Do we have any other questions?
But actually, I just thought of something that I wanted to add on.
Something that's continuously amazed me is the amount of data that people are actually able to
pull into wire-shark. I forget how many rows, you know, Microsoft Excel will handle in their spreadsheet,
but it's some comparatively small number.
We recently, a couple of years ago, fixed a bug, you know,
somebody complained that they couldn't load more than 53 million packets into wire-shark,
and they were upset about that, and we found the bug and fixed it.
You can actually load more than that.
So, you know, that capabilities there in the application,
it's just, you know, the matter of making it fast and more efficient in dealing with.
Very cool.
If not, then yeah, please give another one plus through the speakers.