[00:41.720 --> 00:42.400]  All
[00:55.770 --> 01:01.710]  right , before I start, quick show of hands, who is already familiar with RFC?
[01:13.430 --> 01:18.170]  All right, so some of you already know what this presentation is going to be.
[01:18.350 --> 01:19.310]  Fantastic.
[01:20.210 --> 01:29.990]  So we are going to start off with what the current state of the market is in this ever-evolving cybersecurity landscape, during the fancy term.
[01:30.030 --> 01:46.710]  So I was doing some searches online and I found that 48.6, and these are 2024 stats, so these might be a little out of date, but 48.6% of all initial access is from valid credentials.
[01:46.710 --> 01:52.330]  That is an insanely hard thing that you must try and figure out a way to log.
[01:52.370 --> 01:55.970]  It is valid credentials, how do you log that?
[01:56.170 --> 02:06.810]  There is also a rise of click fix, or better known as basically the scammer telling you run this command in command prompt.
[02:06.810 --> 02:19.630]  That is another very hard thing, but it is pretty easy, but the only problem is once they run it, that is like, then you got to do a bunch of back tracing, and that is another very hard thing to recover from.
[02:19.670 --> 02:29.010]  And then also a majority of victims are small medium business, so if they don't have a giant SOC team to help out, it gets pretty difficult.
[02:30.130 --> 02:35.770]  So we are going to talk about some basic security things of what is happening right now in the current industry.
[02:35.770 --> 02:38.030]  The first one is really firewalls.
[02:38.290 --> 02:43.510]  They have their limitations, they are amazing, I love them, everyone loves them, they are fantastic.
[02:44.610 --> 02:50.170]  But they are pretty limited on what they do, mainly blocking just via a set of rule sets.
[02:50.590 --> 03:01.250]  There are some fancy ones that do like malware scanning and TLS decryption, but a lot of that is still happens as soon as they get into your network.
[03:01.250 --> 03:06.410]  Like if it is already reading that traffic, that traffic is already in your network, it is doing its job.
[03:06.890 --> 03:11.110]  So once again, we are very reactive focused at the moment.
[03:11.270 --> 03:15.810]  And then there is also IDS and IPS, love that, fantastic, it is amazing.
[03:15.830 --> 03:25.610]  But like a lot of the better ones are a lot more signature based detection, which takes a lot of time for those signatures to come out after a large incident just happened.
[03:26.210 --> 03:35.230]  Like not too much time, but there is still like maybe a couple of hours, maybe a day that you are still vulnerable and you don't even know about and it doesn't really help with zero days.
[03:35.230 --> 03:45.550]  Now there are like some products in there that help you, that utilize AI anomaly detection, those are fantastic, those are actually a really great product, love those.
[03:45.570 --> 03:47.450]  But it is pretty hard.
[03:47.450 --> 03:48.970]  So how do we combat this?
[03:49.150 --> 03:53.010]  We need some sort of security flag in the IPV4 header.
[03:53.270 --> 03:58.270]  Fortunately, someone a very long time ago has already thought about this.
[03:58.270 --> 04:00.830]  Good old RFC3514.
[04:01.930 --> 04:03.550]  It is pretty simple.
[04:04.390 --> 04:08.790]  If the flag is off, the packet has zero evil intent.
[04:08.930 --> 04:12.190]  And if it is set, then it has evil intent.
[04:13.030 --> 04:13.850]  Boom.
[04:13.850 --> 04:14.690]  We got it.
[04:14.690 --> 04:15.790]  Really easily.
[04:15.790 --> 04:17.550]  So what does this look like?
[04:17.670 --> 04:20.910]  Well, first you have to set it.
[04:21.010 --> 04:24.730]  And let's say you have your end user that has evil intent.
[04:25.330 --> 04:38.550]  There should be, the RFC guideline states that there should be an API to set the evil bit because of course it is pretty lower level in the, it is living in the IPV4 header, so it is pretty low level.
[04:39.210 --> 04:54.950]  So if you are using an application and then you all of a sudden decide to do something with evil intent, there should be a system in place to set that when your packet goes out saying my packet has evil intent.
[04:54.950 --> 04:56.130]  It is pretty simple.
[04:56.130 --> 04:57.170]  Pretty simple.
[04:58.210 --> 05:08.790]  And then also, if a packet gets fragmented up, all non-malicious fragments must be clear to the evil bit because of course they don't have malicious intent.
[05:08.970 --> 05:10.150]  Pretty smart.
[05:11.250 --> 05:13.790]  Now how do we process this?
[05:13.790 --> 05:15.330]  Well, pretty simple.
[05:15.330 --> 05:16.330]  You already said it.
[05:16.330 --> 05:17.790]  We know that this has evil intent.
[05:18.030 --> 05:22.210]  So if we are a firewall, we will drop all packets with evil intent.
[05:22.210 --> 05:23.390]  Pretty simple.
[05:23.710 --> 05:35.370]  Couple other things, if it is not a security device like routers or switches, their job is to move packets across the network as fast as possible.
[05:35.370 --> 05:41.450]  So RFC guideline states that routers and other network devices should not examine this bit.
[05:41.450 --> 05:44.490]  Forward traffic, whatever.
[05:45.210 --> 05:49.230]  And also, end systems, it is up to them.
[05:49.230 --> 05:54.350]  There is a lot of security applications like Windows Firewall, that is probably a fine drop in it.
[05:54.350 --> 05:59.450]  It is up to whoever the end system is to drop said evil bit.
[06:00.870 --> 06:20.990]  So now if we do processing for IDS or IPS, that gets pretty difficult because as you are all aware of IDSs and IPSs, they do have a propensity for false negatives and false positives, of course.
[06:21.690 --> 06:23.030]  You always have that.
[06:23.030 --> 06:24.270]  It is hard to trace .
[06:24.770 --> 06:29.070]  Now if this evil bit comes in here, we don't want those to be useless now, do we?
[06:29.070 --> 06:30.370]  So what do we do?
[06:30.810 --> 06:33.690]  We have to consult a random number generator.
[06:33.730 --> 06:37.710]  We have to figure out if that packet actually has evil intent or not.
[06:37.710 --> 06:44.570]  So we must consult a random number generator to generate if it is a false positive or a false negative.
[06:44.690 --> 06:51.470]  Now of course, RFC guideline states that this may or may not be different values.
[06:51.470 --> 06:56.210]  So you can have two different random number generators depending on what kind of IDS or IPS you have.
[06:56.210 --> 07:00.830]  If you have one that is pretty signature based, then it has low false negatives.
[07:00.830 --> 07:08.210]  So you could probably have that output less false negatives and yada, yada, yada.
[07:08.210 --> 07:16.450]  If you couldn't tell already, this RFC guideline may or may not have happened yesterday.
[07:16.730 --> 07:17.630]  Yesterday?
[07:17.630 --> 07:20.150]  Whenever April 1st was a long time ago.
[07:20.150 --> 07:23.070]  So don't take this presentation too seriously.
[07:23.830 --> 07:26.090]  Now this is my fun part.
[07:26.570 --> 07:32.510]  It's not used widely, of course, because, well, it's an evil bit.
[07:32.510 --> 07:40.110]  How do you... it's hard and it's dumb for a hacker to say, hey, I have malicious intent.
[07:40.110 --> 07:48.630]  I should set this flag showing that I have malicious intent because the job of a hacker is to not show that they have malicious intent.
[07:48.630 --> 07:51.130]  They just throw it in the network.
[07:51.410 --> 07:54.590]  So where is it used?
[07:54.730 --> 08:02.510]  Kaspersky software actually, upon doing research, is known widely to drop these packets.
[08:02.510 --> 08:08.450]  Unfortunately, no one can use Kaspersky software in the United States.
[08:09.210 --> 08:22.210]  Also, I found that FreeBSD, they have implemented some April Fool's patches to drop this, but I have not heard anything if those are still out there.
[08:22.210 --> 08:25.010]  I've heard that sometimes they remove it after a while.
[08:25.010 --> 08:27.030]  I don't know why they would do that.
[08:27.350 --> 08:32.550]  But they are known to have patches that drop off.
[08:33.270 --> 08:36.810]  Surprisingly after that, I haven't heard very much.
[08:36.810 --> 08:48.730]  I haven't done extensive testing on setting the evil bit to see if my packets get dropped or not because, well, some companies don't provide an API.
[08:49.030 --> 08:50.770]  They are not compliant.
[08:51.550 --> 08:54.710]  But that is pretty much all I have.
[08:55.010 --> 08:57.370]  It's not an in-depth presentation.
[08:57.450 --> 08:58.410]  It's not great.
[08:58.410 --> 09:07.550]  Don't go up to your CISO or any of your management saying you should really think about considering implementing this because you might get laughed in the face.
[09:08.910 --> 09:09.810]  Yes.
[09:16.850 --> 09:20.030]  That is a fantastic question.
[09:21.490 --> 09:26.770]  Really you might have to have some sort of like quantum decryption on your firewall then.
[09:26.810 --> 09:32.250]  And then that might have a probabilistic factor as well determining if that is set or not set.
[09:32.250 --> 09:34.090]  But that's a really great question.
[09:35.070 --> 09:38.510]  Anyone else has any questions?
[09:39.410 --> 09:40.390]  Yes.
[09:42.690 --> 09:43.670]  Yeah.
[09:43.670 --> 09:46.890]  Is there any IPv6 implementation of evil bit?
[09:46.890 --> 10:02.230]  Actually, at the very end of the RFC guideline, it does mention briefly that an IPv6 can have a security header with a value of 128 bits that provide the strength.
[10:02.230 --> 10:09.130]  Now, unfortunately, I could not find any RFC guideline that would state how to process said strength value.
[10:09.130 --> 10:17.230]  So I'd like to think that the strength value decreases every layer that the packet goes through because you know the defense in depth.
[10:17.230 --> 10:25.910]  So I'd say like maybe every like layer of security that goes through maybe drops the defense a little bit more of that defense header.
[10:25.910 --> 10:31.610]  But yeah, there's no current implementation of the security flag in IPv6.
[10:31.710 --> 10:33.590]  Anyone else have any questions?
[10:35.310 --> 10:36.190]  Yeah.
[10:52.020 --> 10:53.640]  That's a great question.
[10:53.820 --> 11:00.580]  I would assume if any sort of email header had the evil bit set, it would just be drops and you wouldn't really have to worry about.
[11:00.580 --> 11:02.840]  Please God, make it all stop.
[11:04.580 --> 11:06.180]  That's a great question.
[11:06.820 --> 11:08.220]  Anyone else have any questions?
[11:08.220 --> 11:08.820]  Yes.
[11:21.470 --> 11:25.890]  I would say yes, that is still evil traffic, though it is allowed evil traffic.
[11:25.890 --> 11:32.290]  If you're doing a penetration testing, you can drop the security down a little bit, I guess.
[11:32.290 --> 11:37.390]  But if you are doing a penetration testing, yes, that is still malicious.
[11:37.470 --> 11:42.650]  So I'd say that bit still has to be set because there's malicious intent for that.
[11:42.650 --> 11:46.830]  Even though it's for the greater good, there's still malicious intent to break systems.
[11:48.150 --> 11:49.550]  Anyone else?
[11:50.730 --> 11:53.290]  Otherwise, that's all I have for this presentation.
[11:53.290 --> 11:55.550]  Nice short presentation after lunch.
[11:55.550 --> 11:56.390]  Thank you.