[00:00.000 --> 00:10.880]  All right, thanks for having me, folks.
[00:10.880 --> 00:18.280]  So let's have a quick chat about Surikara, open source, ideas, network security monitoring
[00:18.280 --> 00:21.080]  and all those sorts of things.
[00:21.080 --> 00:25.960]  And what it used to look like before and what it looks like now, at least from our perspective
[00:25.960 --> 00:32.360]  and all the things that we need to take care of and the things that we have still challenges
[00:32.360 --> 00:34.560]  with.
[00:34.560 --> 00:39.040]  So a quick overview of the agenda.
[00:39.040 --> 00:43.280]  We're going to talk about what is Surikara, how it started, how it evolved, challenges
[00:43.280 --> 00:50.240]  when we're monitoring the traffic and how to get involved basically and help out.
[00:50.240 --> 00:54.680]  First of all, I'll introduce Eric, he's my colleague, he was supposed to be here today,
[00:54.680 --> 00:59.400]  he fled, got cancelled and he couldn't make it, but we did the presentation together.
[00:59.400 --> 01:04.000]  So apologies, he actually just touched down at the Brussels airport.
[01:04.000 --> 01:10.200]  So Eric is the city of Stamels Network, he's part of the OSF team, that's where I met him
[01:10.200 --> 01:14.240]  during the Surikara, developing Q&A during the Surikara project.
[01:14.240 --> 01:22.560]  He's also a member of the board of directors, a Linux kernel, let's go developer, he maintains
[01:22.560 --> 01:26.480]  also Sirius and Selk's and that's the Twitter handle in there.
[01:26.480 --> 01:30.040]  So apologies, Eric could not make it and that's why I'm making the introduction with him,
[01:30.040 --> 01:34.200]  he's a great open source colleague and a friend.
[01:34.200 --> 01:41.040]  My name is Peter Manev, I am 13, almost 14 years with Surikara, I'm part of the OSF
[01:41.040 --> 01:48.600]  exec team and where I usually do a lot of things around Surikara Q&A and trainings.
[01:48.600 --> 01:52.720]  I'm also a chief strategy officer of Stamels Networks, I'm one of the maintainers for the
[01:52.720 --> 01:57.000]  open source distribution, Selk's, I really like thread hunting and lots of open source
[01:57.000 --> 02:03.240]  around it, I'm guessing lots of people here in the conference too.
[02:03.240 --> 02:07.840]  So what is actually Surikara?
[02:07.840 --> 02:14.360]  So basically a high performance network security monitoring engine that can do active or passive
[02:14.360 --> 02:20.520]  monitoring and also produces a lot of application and protocol metadata.
[02:20.520 --> 02:28.400]  Open source, GPL2, code is available on GitHub of course and basically produces when you
[02:28.400 --> 02:31.720]  plug Surikara in the network, it just gives you this high level situational awareness
[02:31.720 --> 02:34.560]  of what's happening on the network, what's going on, something you should be aware of
[02:34.560 --> 02:39.040]  or something you didn't know or to confirm things, for example, you know we have these
[02:39.040 --> 02:44.320]  a lot of angles like trust but verify to use the famous quote, you know we have zero trust
[02:44.320 --> 02:47.600]  architectures, you want to confirm that they're actually implemented.
[02:47.600 --> 02:52.120]  It's one thing to implement, it's another thing to confirm that it's there.
[02:52.120 --> 02:57.200]  And actually Surikara is used by a lot of organizations, a lot of people, it's awesome
[02:57.200 --> 03:03.880]  to see it and really, really thankful for that and all the feedback and sometimes organizations
[03:03.880 --> 03:09.960]  before use it even without knowing because it's embedded in a lot of vendor appliances
[03:09.960 --> 03:11.440]  and similar.
[03:11.440 --> 03:16.280]  So what can Surikara do?
[03:16.280 --> 03:20.040]  Basically it's a few options there.
[03:20.040 --> 03:25.980]  It's an idea system, so intrusion detection system, it could be in passive mode, right?
[03:25.980 --> 03:30.360]  So it could be in line, intrusion prevention system where it actually actively stops or
[03:30.360 --> 03:32.920]  enables a connection to pass through or not.
[03:32.920 --> 03:37.360]  It can also be just purely network security monitoring perspective, you know it works
[03:37.360 --> 03:43.320]  without rules, it can just generate all sorts of protocol, flow data, file extraction and
[03:43.320 --> 03:44.320]  similar.
[03:44.320 --> 03:49.800]  It can also store everything it sees on disk, so it can also do full packet capture.
[03:49.800 --> 03:55.920]  And very often you see users of Surikara in combinations like this, so for example IDS
[03:55.920 --> 04:02.000]  plus NSM mode with all the network protocol data and full packet capture and similar.
[04:02.000 --> 04:11.920]  There is also something new coming up in Surikara 7, Surikara 7 RC was just released this week.
[04:11.920 --> 04:21.720]  And it's called conditional pick up capture which is actually code introduced and developed
[04:21.720 --> 04:24.040]  and donated by Eric.
[04:24.040 --> 04:28.040]  What it allows you to do is, so for example if you have an alert it will save that whole
[04:28.040 --> 04:30.360]  session, so not just the packet but the full session.
[04:30.360 --> 04:35.000]  So in that way you actually have the full sessions for all alerts stored in pick up
[04:35.000 --> 04:41.480]  as opposed to having to do full packet capture which in a lot of cases might be prohibitive.
[04:41.480 --> 04:49.440]  So basically use the network to defend ourselves, observe, protect, adapt, that's what we do,
[04:49.440 --> 04:52.200]  that's what we try to excel at every day.
[04:52.200 --> 04:57.080]  And this is a quick snapshot from actually our website.
[04:57.080 --> 04:58.600]  So some major features.
[04:58.600 --> 05:05.560]  To name a few, yeah more from configuration, JSON for output, multi-threaded, there's hardware
[05:05.560 --> 05:09.680]  acceleration and that becomes more and more relevant these days because the speeds are
[05:09.680 --> 05:12.480]  going up and up all the time.
[05:12.480 --> 05:18.280]  Network metadata logging by a lot of protocols, we are going to name all of them here, some
[05:18.280 --> 05:24.960]  of the main ones are here, more advanced parsing and automatic detection of HTTP DNS, SMB,
[05:25.720 --> 05:30.000]  SMTP TLS, all those guys and more.
[05:30.000 --> 05:40.840]  One thing that Surigata does very well is file extraction, SMB, FTP, HTTP, FTP2, SMTP,
[05:40.840 --> 05:47.520]  all that and the cool feature about that is actually it automatically de-duplicates when
[05:47.520 --> 05:48.520]  it's extracted.
[05:48.520 --> 05:53.320]  So if the same file is seen 10 times it will only be saved or extracted once to disk.
[05:53.320 --> 05:58.640]  So in other words saving a lot of space, really a lot.
[05:58.640 --> 06:03.520]  And of course support for SCADA, that's upcoming and we need more and more of that but it's
[06:03.520 --> 06:06.360]  also very relevant these days.
[06:06.360 --> 06:07.640]  So why the network?
[06:07.640 --> 06:12.320]  Well, because everything happens from the network.
[06:12.320 --> 06:18.480]  Everything from social media to finance to to name it, everything is on the network.
[06:18.480 --> 06:22.480]  So the good people are there, the bad people are there.
[06:22.480 --> 06:33.920]  So even if you have malicious actors getting in, even to get in is actually 99% of the
[06:33.920 --> 06:35.600]  cases it's over the network.
[06:35.600 --> 06:41.000]  And once they get in they need to either exfiltrate or move laterally or do some other part, that's
[06:41.000 --> 06:42.280]  still happening on the network.
[06:42.280 --> 06:45.600]  So you have to double to observe that.
[06:45.600 --> 06:48.800]  It's not the only place where you need to observe from security perspective, there's
[06:48.800 --> 06:54.680]  others of course but the network is one of the major ones.
[06:54.680 --> 06:59.600]  And while you're doing all that, while you're confirming if things are configured as expected
[06:59.600 --> 07:04.800]  or not or if all the connections are correct or there's no some anomaly and all things
[07:04.800 --> 07:10.560]  like that, you have to be able to identify and stop this activity.
[07:10.560 --> 07:12.840]  Granted there are differences, right?
[07:12.840 --> 07:18.240]  So a university network is totally different from a bank corporate network, there's totally
[07:18.240 --> 07:21.960]  different things, believe me.
[07:21.960 --> 07:32.200]  So network metadata logging, so we actually provide a lot of metadata around any alert
[07:32.200 --> 07:36.360]  event or metadata just on its own, you don't need to have an alert.
[07:36.360 --> 07:42.760]  So default output format is JSON, right, JavaScript object notation.
[07:42.760 --> 07:47.360]  And on the right hand side here you can see actually a picture, a small snippet actually
[07:47.360 --> 07:51.960]  of an event type, HTTP or an HTTP protocol.
[07:51.960 --> 07:55.840]  So all the different protocols have their own event type and they're logged in like that
[07:55.840 --> 08:00.120]  and then next to that you also have alerts.
[08:00.120 --> 08:05.080]  So file identification and extraction.
[08:05.080 --> 08:11.200]  One thing to mention is that file identification is done on the fly and it's automatic regardless
[08:11.200 --> 08:18.280]  of extensions and similar things like that, it's just using lib magic and those tools
[08:18.280 --> 08:19.760]  to be able to identify a file.
[08:19.760 --> 08:24.320]  So if it's like an executable, it's a PDF or if it's a PDF but with an extension TXT
[08:24.320 --> 08:29.320]  we'll still be able to match an extract if you want to that file.
[08:29.320 --> 08:38.320]  You can also match on SHA sums and other attributes of the file info events.
[08:38.320 --> 08:46.280]  So as I mentioned extract is sort of system deduplicated that really saves a lot of conversations
[08:46.280 --> 08:50.560]  with finance about sizing.
[08:50.560 --> 08:54.040]  So we have some pick up capabilities.
[08:54.040 --> 09:00.640]  Now what I mean by that, besides the fact that Suricada can actually store everything
[09:00.640 --> 09:04.960]  on disk and do full packet captures, Suricada can also read pickups.
[09:04.960 --> 09:12.080]  It's actually that part is also used a lot in a lot of sandboxes including, so for example,
[09:12.080 --> 09:16.680]  there is a few out there if you Google sandbox for example, there is a few that even offer
[09:16.680 --> 09:23.000]  free public services but to name one any run is like that actually automatically when a
[09:23.000 --> 09:30.520]  sample is detonated they also save the network traffic and that's also run by Suricada just
[09:30.520 --> 09:36.240]  to see what network protocol data and alerts are in there.
[09:36.240 --> 09:41.440]  So Suricada can read a single pick up, you can actually spin up a unique socket let's
[09:41.440 --> 09:46.600]  say and just feed pickups to it and every now and then you can point it to a folder
[09:46.600 --> 09:52.200]  and it will keep reading from that folder until it reads all the pickups or if there
[09:52.200 --> 09:55.880]  is nothing there it will pause and it will stop and when you throw a pick up in the folder
[09:55.880 --> 10:02.840]  it will continue really automatically, it's really automated in that part and of course
[10:02.840 --> 10:07.040]  you need to have multiple instances just to be on the safe side with that new chain that
[10:07.040 --> 10:10.360]  you did in QA you want to move it into Prod.
[10:10.360 --> 10:16.160]  So passive monitoring, how does it actually work?
[10:16.160 --> 10:21.280]  Here's an example basically we hooked up to a tap or a mirror port on switch and we just
[10:21.280 --> 10:22.280]  nipped the traffic.
[10:22.280 --> 10:26.880]  When you place that you're going to need probably multiple sensors in different scenarios you
[10:26.880 --> 10:32.080]  know it depends where you have on-prem cloud, virtual infrastructure and all that so you
[10:32.080 --> 10:36.840]  have to probably have multiple things but in general this is basically where it sits
[10:36.840 --> 10:43.000]  in passive mode so it logs all the alerts, the protocol metadata, any file, instruction
[10:43.000 --> 10:50.720]  events, pickups and all those things based on the monitoring that it does for that network.
[10:50.720 --> 10:56.000]  Now active monitoring, this is a little bit different, we stay in line so we allow or
[10:56.000 --> 10:57.640]  not traffic to pass.
[10:57.640 --> 11:02.360]  This is a bit more business critical, well not a bit more, it's much more business critical
[11:02.360 --> 11:09.320]  because you know it's actually able to stop effectively traffic so a lot more testing
[11:09.320 --> 11:13.760]  and due diligence in QA is needed there but basically how does it work?
[11:13.760 --> 11:20.400]  So basically you have this setup here, you have a user employee that receives a malicious
[11:20.400 --> 11:26.600]  document usually in a lot of cases it all starts with some sort of link or attachment
[11:26.600 --> 11:33.040]  that is being without intention opened by user or clicked by user so you have a network
[11:33.040 --> 11:39.440]  request and usually there is some sort of a signature or a rule that vets the traffic
[11:39.440 --> 11:43.040]  or inspects the traffic and says yes you can pass, no you cannot pass and this is a very
[11:43.040 --> 11:47.600]  basic example here for example a PowerShell script and then based on that there is a
[11:47.600 --> 11:54.880]  verdict, yes you can go or no you cannot go, either way and that's the inline mode right
[11:54.880 --> 12:00.560]  so there you actually actively making decisions of what can and cannot pass and similar.
[12:00.560 --> 12:07.320]  So one is much more acute, the other one is much easier because in the passive mode you
[12:07.320 --> 12:09.360]  are just monitoring traffic.
[12:09.360 --> 12:17.920]  So a little bit about our history and how we get there, how did we get here.
[12:17.920 --> 12:25.120]  So first lines of code 2007 by Victor Julien, he is the lead developer of Suricada, first
[12:25.120 --> 12:35.120]  release was in 2009, I joined the project 2010 April May somewhere around there so we
[12:35.120 --> 12:41.920]  are open source GPL and we actually have actively contributors and people contributing
[12:41.920 --> 12:49.360]  code, test donations from 23 different countries at the moment, well at least that was the
[12:49.360 --> 12:56.200]  last statistics but basically all continents and Suricada is owned by a non-profit foundation,
[12:56.200 --> 13:01.080]  the Suricada code it's open source and it's on GitHub but it's owned by a non-profit
[13:01.080 --> 13:10.240]  foundation on purpose and the purpose is actually so that it could never be sold, that's it.
[13:10.240 --> 13:17.040]  And this is basically how we started, OASFnet you'll find a little bit more info.
[13:17.040 --> 13:22.840]  So as I mentioned a little bit of a visual representation in there, so our first Suricada
[13:22.840 --> 13:34.000]  training believe it was in 2013 and our first Suricada was in 2015 and those were a lot
[13:34.000 --> 13:39.840]  of fun events and we learned a lot just by talking and interacting with the community.
[13:39.840 --> 13:52.560]  So big help there from the community and how did it used to work and look back in the day.
[13:52.560 --> 13:57.720]  So I had to generate that, this is basically an alert that what it looked like 14 years
[13:57.720 --> 14:00.080]  ago, what it looked like 20 years ago as well.
[14:00.080 --> 14:12.360]  So I had to generate that manually to look at what it produces but so basically that's
[14:12.360 --> 14:17.960]  an alert from 14, 15, 20 years ago, things like that.
[14:17.960 --> 14:20.920]  Not much to see there, not much to say there, right?
[14:20.920 --> 14:26.280]  So you have an IP and a port and a message, what are you going to do with it?
[14:26.280 --> 14:32.640]  Now you need to go find other tools, other protocol logs, you need to go to different
[14:32.640 --> 14:36.640]  machines to figure out what this IP is, what's that for, what's happened before, what happened
[14:36.640 --> 14:41.560]  after, is it a server, is it a laptop, is it guess whatever it is.
[14:41.560 --> 14:48.040]  So you needed to do a lot of work, this was just like a message.
[14:48.160 --> 14:52.360]  But back then it was one of the few things that were there, right?
[14:52.360 --> 14:54.720]  So there was nothing more than that.
[14:54.720 --> 14:57.960]  So fast forward to today.
[14:57.960 --> 15:02.520]  So this is an example for an alert but in a graphical interface anyway.
[15:02.520 --> 15:08.320]  So you have the alert, you have the signature metadata, you have in this case is HCP protocol
[15:08.320 --> 15:12.520]  and a lot of things do happen over clear text by the way because it's not vetted that much,
[15:12.520 --> 15:20.280]  especially in some environments and you also have the flow record, you know, packets, bytes
[15:20.280 --> 15:23.560]  to clients to server, similar things, durations and all those things.
[15:23.560 --> 15:29.560]  So you have a much better understanding when you look at an alert now, okay, so this is
[15:29.560 --> 15:33.160]  the status code, this is the request, this is the file and all those things, so you can
[15:33.160 --> 15:35.640]  actually judge much more.
[15:35.640 --> 15:43.360]  And one thing that actually came with time in Suricata is something called FlowID.
[15:43.360 --> 15:50.240]  What FlowID allows you, this was natively introduced in Suricata in 2014, what FlowID
[15:50.240 --> 15:56.800]  allows you to achieve is basically to correlate the specific alert to any and other protocol
[15:56.800 --> 15:58.600]  data from the same flow and session.
[15:58.600 --> 16:03.200]  So if you have an alert over SMB or something like that, you have all the SMB protocol records,
[16:03.200 --> 16:08.760]  the extracted files, you know, pick up, save, if you need to pick up, you have all that
[16:08.760 --> 16:10.320]  in the package.
[16:10.320 --> 16:14.680]  So much bigger evolution than what you saw in the previous screenshot.
[16:14.680 --> 16:18.920]  So how it works, this is a screenshot for example from e-box, it's a tool developed
[16:18.920 --> 16:27.440]  by Jason Nish, he's our colleague from the Suricata team and here's a quick example.
[16:28.440 --> 16:30.720]  Yeah, every session has a FlowID, right?
[16:30.720 --> 16:36.080]  So here is an alert with a FlowID and that translates to, in this case, that FlowID correlates
[16:36.080 --> 16:41.880]  the alerts to the Flow record, to the HTTP record, to the file info, which is actually
[16:41.880 --> 16:47.800]  the file metadata for that file transaction.
[16:47.800 --> 16:53.560]  So much bigger, much better visibility and you can actually make a decision much faster
[16:53.560 --> 16:58.440]  than needing to go look in other tools.
[16:58.440 --> 17:03.400]  This is actually a showcase of FlowID by Sirius, which is an open source web interface as part
[17:03.400 --> 17:06.000]  of CELX that they help maintain.
[17:06.000 --> 17:10.600]  But in any way, here is the file info on the bottom that is highlighted.
[17:10.600 --> 17:18.000]  You have the SHA, the file magic and everything is correlated between alerts, file info, Flow,
[17:18.000 --> 17:24.280]  logs by the help of that FlowID, which helps glue everything together.
[17:24.280 --> 17:26.960]  So really, really powerful.
[17:26.960 --> 17:31.600]  If I need, often enough I need to explain Suricata in one slide today.
[17:31.600 --> 17:33.440]  This is what Suricata does today.
[17:33.440 --> 17:35.480]  One IDS plus an assembly.
[17:35.480 --> 17:39.800]  So you have the alerts, you have the protocol data, you have the network flows, the file
[17:39.800 --> 17:43.800]  transactions, you do any file transactions and the pickup recordings, right?
[17:43.800 --> 17:46.000]  So you have everything in a package.
[17:46.000 --> 17:50.360]  It's much different when I started at least.
[17:50.360 --> 17:56.000]  So we have evolved and here is another run that is possible.
[17:56.000 --> 18:02.280]  So you could actually, it's a little known fact that Suricata alerts are only about 5-10%
[18:02.280 --> 18:04.480]  of all the data that it produces.
[18:04.480 --> 18:08.720]  The rest of the data is all protocols, data, metadata and things like that.
[18:08.720 --> 18:14.800]  The alerts are very, very small part and alerts, now at least I look at them as just context.
[18:14.800 --> 18:15.800]  It gives me something.
[18:15.800 --> 18:18.280]  It gives me an idea of what's happening.
[18:18.280 --> 18:19.280]  That's it.
[18:19.280 --> 18:20.280]  And that's all.
[18:20.280 --> 18:22.080]  I don't necessarily look at it as true or false positives.
[18:22.080 --> 18:27.200]  It's just like, okay, so that's what happened and I need the context around it.
[18:27.200 --> 18:33.800]  So we got a canned function without signature rules too, although it's not recommended
[18:33.800 --> 18:37.000]  because they help highlight certain events.
[18:37.000 --> 18:38.840]  So what challenges do we have?
[18:38.840 --> 18:42.400]  Well, all those years we need to keep the pace, right?
[18:42.400 --> 18:43.400]  We need to adapt.
[18:43.400 --> 18:44.400]  We need to adapt.
[18:44.400 --> 18:47.080]  We need to move forward.
[18:47.080 --> 18:51.040]  Signatures have evolved at least in Suricata, but back in the day it used to be a pattern
[18:51.040 --> 18:59.600]  match, a buffer overflow, some content triggering in the payload and it was very bounded with
[18:59.600 --> 19:00.920]  the IPS mindset.
[19:00.920 --> 19:01.920]  So you have to stop it.
[19:01.920 --> 19:05.400]  You have to look for something specific and it's expensive.
[19:05.400 --> 19:11.440]  It's CPU intensive actually to look on the fly at the 100 gigabit a second, for example,
[19:11.440 --> 19:12.440]  or pattern.
[19:12.440 --> 19:20.240]  You need to, for example, in IPS, you need to block, stop, protect the asset and similar.
[19:20.240 --> 19:26.640]  So we need to evolve from that to actually a bit more behavior analytics and including
[19:26.640 --> 19:28.880]  from the perspective of infrastructure, right?
[19:28.880 --> 19:33.320]  So you can say, hey, how many proxies they have on the network, right?
[19:33.320 --> 19:34.320]  That's interesting.
[19:34.320 --> 19:37.440]  Do you have proxies somewhere that NGINX, for example, proxies that somewhere in the
[19:37.440 --> 19:40.320]  network that they don't expect them to be?
[19:40.320 --> 19:43.320]  That sort of visibility, you know, that kind of difference.
[19:43.320 --> 19:50.960]  So TLS, okay, TLS is encrypted, sure, but the handshake is in clear text and during the
[19:50.960 --> 19:55.240]  handshake you can see a lot of things, including ciphers and things like that.
[19:55.240 --> 19:56.240]  What do you care about the cipher?
[19:56.240 --> 19:57.240]  Of course you do.
[19:57.240 --> 19:58.240]  Is it secure?
[19:58.240 --> 19:59.240]  Is it degraded?
[19:59.240 --> 20:00.240]  Is it recommended?
[20:00.240 --> 20:03.960]  You know, do you have applications that are using degraded ciphers?
[20:03.960 --> 20:04.960]  How do you know?
[20:05.440 --> 20:06.440]  Network security monitoring.
[20:06.440 --> 20:12.240]  That's the easiest way to do it, actually, or one, much easier than the other way.
[20:12.240 --> 20:16.280]  Put it that way.
[20:16.280 --> 20:27.520]  So you have system updates, you know, who's updating Debian, who's updating Ubuntu, things
[20:27.520 --> 20:28.520]  like that.
[20:28.520 --> 20:31.680]  They're very visible on the network, you know, and it's not about the actual system
[20:31.680 --> 20:36.280]  update, it's about actually do you expect it to happen, where it happens, and where
[20:36.280 --> 20:39.200]  it happens.
[20:39.200 --> 20:45.040]  So yeah, we have to evolve towards that direction and we have managed actually to do a huge
[20:45.040 --> 20:47.920]  leap there.
[20:47.920 --> 20:50.720]  More protocol implementation, right, so we need more and more protocols.
[20:50.720 --> 20:56.200]  Of course we do, but, you know, as it says here, it's no longer a network grip, so you
[20:56.200 --> 20:57.440]  have different protocols.
[20:57.440 --> 21:04.520]  You need application layer identification regardless of the port, you know, so it has
[21:04.520 --> 21:05.520]  to be automated.
[21:05.520 --> 21:09.960]  You need parsing, you need logging, you need to parse the protocol, you need to log it
[21:09.960 --> 21:15.000]  correctly, all those things require time and effort, you need specific keywords so you
[21:15.000 --> 21:20.800]  can hook up detection to for different parts of the protocol.
[21:20.800 --> 21:25.280]  And we need, like, secure protocol implementation.
[21:25.280 --> 21:34.200]  So by that way, Suricata needs to parse everything and anything on the network, and trust me,
[21:34.200 --> 21:38.880]  everything and anything on the network doesn't fold the RFC, it just doesn't.
[21:38.880 --> 21:45.040]  So we need to follow the RFC one, and two, we don't, because we can't, you know, we can't
[21:45.040 --> 21:52.000]  crash, we need to actually keep inspecting and alert for problems.
[21:52.000 --> 22:00.320]  Suricata has, not everybody, a lot of organization, a lot of tools have vulnerability based on
[22:00.320 --> 22:01.320]  protocol parsers.
[22:01.320 --> 22:04.160]  Workshack has a lot, Suricata has a few and similar.
[22:04.160 --> 22:09.320]  So one way to battle and combat that is the combination of Rust and known for, memory
[22:09.320 --> 22:15.520]  safety, trust safety, C is not safe, right, C's memory requires a manual, if it's not
[22:15.520 --> 22:21.640]  done correctly, it's not done properly, SecFalse Memlix, they can all occur in there.
[22:21.640 --> 22:25.680]  There is an example of Rust known parser that we use in Suricata, so Suricata is a combination
[22:25.680 --> 22:33.680]  of C and Rust known implementation, and that started only a couple years ago, and it's
[22:33.680 --> 22:40.000]  more and more of that, just to help us be more safe when we inspect and do things.
[22:40.000 --> 22:46.520]  There's the outside evolution, right, so networks' speeds increase, demand increases, there is
[22:46.520 --> 22:52.080]  encryption, there is less visibility, but a lot of data.
[22:52.080 --> 22:58.880]  I was earlier, in January, I had a talk at a different conference, and after the talk,
[22:58.880 --> 23:04.600]  a person approached me, he's like, do you have any recommendations of how to tune or
[23:04.600 --> 23:10.760]  improve Suricata performance, I'm like, yeah, sure, he's like, and I said, what's your setup?
[23:10.760 --> 23:19.800]  He's like, we have over 25, 100 giblets, I'm like, okay, we need to talk, so it's very
[23:19.800 --> 23:25.440]  interesting, things like that are dominant and happening, so it's different, you need
[23:25.440 --> 23:30.680]  to keep up with those evolutions, too, and make sure that these people actually, these
[23:30.680 --> 23:34.000]  setups and people can benefit from everything we do.
[23:34.000 --> 23:38.960]  Challenges, there's a lot, everything from mirroring the traffic to one side, the traffic
[23:38.960 --> 23:43.360]  to encryption, to nick-off loading, because we actually do need to inspect the traffic
[23:43.360 --> 23:48.840]  as the end user or the end device, we'll see it, not as the devices in the network pass
[23:48.840 --> 23:53.200]  it over to one another.
[23:53.200 --> 23:58.920]  Volume, size of logs, it's not uncommon to have, depending on the link speed, of course,
[23:58.920 --> 24:02.680]  it's not uncommon to have one, two, three, five more billion of logs a day, what do
[24:02.680 --> 24:03.680]  we do with them?
[24:03.680 --> 24:05.480]  That's a different topic.
[24:05.480 --> 24:08.960]  So here it comes, the deduplication and all the stuff that we actually also need to take
[24:08.960 --> 24:11.960]  care of.
[24:11.960 --> 24:16.520]  And QA anyone while we're at this?
[24:16.520 --> 24:18.280]  It's quite an effort.
[24:18.280 --> 24:22.640]  So when we talk about encryption, I mentioned, so depending on the protocol version and similar
[24:22.640 --> 24:29.760]  things you have, TLS12, 113, 11, all sorts of things, but during the clear and shake,
[24:29.760 --> 24:33.280]  you can actually extract a lot of information, these are some of the things that we extract
[24:33.280 --> 24:37.680]  actually, the SNI, the subject, the shore, you can deduct cipher codes from there as
[24:37.680 --> 24:42.640]  well, J3J3S, fingerprinting, TLS version is similar.
[24:42.640 --> 24:46.680]  So we need to tell sort of what to do when it detects that the connection is encrypted.
[24:46.680 --> 24:47.680]  So what do you do?
[24:47.680 --> 24:48.680]  You want to keep inspecting it?
[24:48.680 --> 24:55.880]  It might be pointless because it's encrypted or you want to pass it to a specific, some
[24:55.880 --> 24:59.840]  hardware has already built in function so it can say bypass it on the hardware level
[24:59.840 --> 25:03.240]  as soon as it detects it's encrypted because there's nothing more we can do.
[25:03.240 --> 25:07.360]  And there's certain things that we can continue on tracking and generate logs, for example,
[25:07.360 --> 25:12.400]  the flow, how big is it and things like that, but we need to be able to relate that information
[25:12.400 --> 25:15.160]  because it's pointless, as I mentioned, if it's encrypted.
[25:15.160 --> 25:20.160]  There's also a lot of decryption devices and similar things that Suricada 6 next to or
[25:20.160 --> 25:25.880]  behind, but that's a setup, that's an architecture issue.
[25:25.880 --> 25:32.400]  So these four major factors that impact Suricada performance, rules, Suricada version, hardware
[25:32.400 --> 25:34.280]  use and type of traffic.
[25:34.280 --> 25:37.640]  Again university traffic is much more different than a regular corporate traffic where everything
[25:37.640 --> 25:38.640]  is vetted.
[25:38.640 --> 25:46.440]  So you learn a lot from both deployments, for example, just using these two as an example.
[25:46.440 --> 25:47.440]  We're software, right?
[25:47.440 --> 25:50.600]  So we need to run on any hardware and that's not easy to achieve.
[25:50.600 --> 25:55.680]  We need a lot of persistence queuing and all those similar things.
[25:55.680 --> 26:00.000]  So what actually happens, so here's an example of workers more than Suricada.
[26:00.000 --> 26:04.960]  As you can see, this is a network card and it has different queues and each protocol,
[26:04.960 --> 26:13.080]  sorry, each thread, each record actually enters and goes through these points, capture the
[26:13.080 --> 26:16.440]  cold stream, detect output, output, especially when you write in.
[26:16.440 --> 26:21.360]  So it needs to be in, this is an example of that specific order.
[26:21.360 --> 26:24.800]  When the traffic comes to the network, how it's passed to the Suricada and what Suricada
[26:24.800 --> 26:29.040]  goes through on a very high level.
[26:29.040 --> 26:33.800]  Most of NICs are made for web file servers at scale.
[26:33.800 --> 26:39.840]  They're not specifically made for IDEs, some are, but IDEs needs to see the traffic.
[26:39.840 --> 26:43.960]  The network security monitoring needs to see the traffic as this end device will actually
[26:43.960 --> 26:45.560]  see it in order.
[26:45.560 --> 26:52.960]  Everything needs to be in order in the same flow so that we can expect it properly.
[26:52.960 --> 26:58.320]  And a small word, so back in the day when I started, there was different capture methods
[26:58.320 --> 27:00.480]  and they evolved over time.
[27:00.480 --> 27:04.160]  But one of the fastest things that was back there was PF ring.
[27:04.160 --> 27:08.600]  And that was actually, we received a lot of help from Luca and Alfredo.
[27:08.600 --> 27:09.800]  Thank you guys.
[27:09.800 --> 27:16.880]  So Colonel 2.6 and 2.6, yeah, PF ring was the only thing that offered speed and performance.
[27:16.880 --> 27:24.440]  There's others that we were upcoming in the Suricada 7, you know, DPDKF, IKTXDP and similar,
[27:24.440 --> 27:26.120]  but we need to have different methods.
[27:26.120 --> 27:30.840]  I am going just to finish up here.
[27:30.840 --> 27:36.200]  And so QA in Suricada, a lot of, we need to cover a lot of angles.
[27:36.200 --> 27:38.680]  We have code on GitHub, we have code in GitLab.
[27:38.680 --> 27:43.880]  When you submit a PR publicly, it goes through an automated checks to as much as possible
[27:43.880 --> 27:46.240]  before we put it in the code.
[27:46.240 --> 27:49.320]  There's private ones, there's unit sets, there's thousands of checks.
[27:49.320 --> 27:54.360]  So anytime you submit a PR or a code, it automatically triggers checks.
[27:54.360 --> 27:57.480]  And some of them could finish nightly.
[27:57.480 --> 28:02.980]  This is a GitLab screenshot going through some checks.
[28:02.980 --> 28:07.960]  Some of these checks can include thousands of definitions inside.
[28:07.960 --> 28:11.800]  In one check, we have 22,000 files extracted, we need to make sure all of them are there
[28:11.800 --> 28:14.360]  the same way they were there before the code change.
[28:14.360 --> 28:16.640]  Things like that need to happen.
[28:16.640 --> 28:20.600]  And here's an example of a PR that's going through a regular checks on GitHub.
[28:20.600 --> 28:25.080]  But information is actually public on GitHub, you can see it in all the different OS compilations
[28:25.080 --> 28:28.040]  that it goes through.
[28:28.040 --> 28:33.520]  Address sanitizers, leak sanitizers, code analysis, CPP checks, all those things need
[28:33.520 --> 28:40.400]  to actually happen before we can say, okay, we could put this code without affecting us.
[28:40.400 --> 28:42.640]  Regressions, traffic replacement, similar.
[28:42.640 --> 28:45.200]  I am going over with a time apologize.
[28:45.200 --> 28:49.520]  This is how to contribute.
[28:49.520 --> 28:59.520]  Any feature and code can be donated, put on our red mine ticket and start a discussion.
[28:59.520 --> 29:04.320]  And the current reviews could be done on GitHub, they're public.
[29:04.320 --> 29:09.800]  So in conclusion, it has to work because you need to create a community around it.
[29:09.800 --> 29:14.320]  And the power is in the community because it's, you have a lot of ideas, a lot of feedback
[29:14.320 --> 29:19.760]  and you need to be open about it, you need to have open discussions about roadmap and
[29:19.760 --> 29:24.400]  input from all the different people that are actually using it.
[29:24.400 --> 29:31.680]  And that is the, our point is that is the ultimate power comes in numbers.
[29:31.680 --> 29:34.480]  Thank you very much for having me here.
[29:34.480 --> 29:35.480]  Much appreciated.
[29:35.480 --> 29:36.480]  Open to questions.
[29:36.480 --> 29:43.480]  Thank you Peter.
[29:43.480 --> 29:44.480]  Anybody has one question?
[29:44.480 --> 29:45.480]  One question here.
[29:45.480 --> 29:52.480]  So I'm just wondering, I don't know what the current date is, but you have MPF Bluefield
[29:52.480 --> 29:56.480]  as well, and how else does it sort of pay that increase?
[29:56.480 --> 29:57.480]  Have I looked?
[29:57.480 --> 29:58.480]  I'm sorry, I'm didn't hear.
[29:58.480 --> 29:59.480]  MPF Bluefield.
[29:59.480 --> 30:02.600]  Oh, yes, yes, yes, yes, yes, yes, yes.
[30:02.600 --> 30:03.600]  We have a conversation going.
[30:03.600 --> 30:04.600]  Yes.
[30:04.600 --> 30:08.560]  Yeah, part of the whole process, staying and keeping on.