WEBVTT 00:00.000 --> 00:27.960 Okay, let's go, let's go for the last ball for today. 00:27.960 --> 00:36.960 I'm Peter Tick and today I'm here to talk about the DSD-order. 00:36.960 --> 00:42.960 So, it was system-end and some other system-end changes. 00:42.960 --> 00:44.960 I used to like the DSD. 00:44.960 --> 00:55.600 First of all, I used to put a half-stranded-day-end DSD with a C-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S 00:58.440 --> 01:06.080 and then Oswo had a really-haves with a really-haves using the DSD-S-S-S-S-S-M-GOS 01:08.080 --> 01:09.800 I'd like to give you a pick of all of those right now. 01:12.620 --> 01:13.620 OK. 01:13.620 --> 01:14.820 Ogasol. 01:14.820 --> 01:16.020 OK. 01:16.020 --> 01:23.280 The idea for the, uhh,ossip-Ede-CD, the Disreasprobable Freeman Arcure Unit, 01:23.280 --> 01:25.720 SON feel like the S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-S-P-P-M-G-C-S-S-S-S-S-S-S-S-S-S-S-S-H-I-I-S-B-Today-Min formation and I-I-B-D-V-A test team. 01:25.720 --> 01:37.000 couple of phone figures and I did it in the coming days. So today I will introduce you to sister 01:37.000 --> 01:45.000 genji, few works also about the previous the audit subsystem, then how I will show you how to 01:45.000 --> 01:55.480 work with audit logs within the surgery and finally I will show you a couple of more 01:55.480 --> 02:04.280 sister genji news related to previous day. But first of all, what is login? Logging is a 02:04.280 --> 02:13.160 recording of event, like an SSH, login message and sister genji is a login demon with a strong 02:13.160 --> 02:18.760 focus on portability and high-performance center of collection. Polygium info is developed in C but 02:18.760 --> 02:26.920 now you can extend it in Java and Python as well. It has four major roles, it can collect 02:26.920 --> 02:33.080 logmasities, it can process macities, it can filter them and finally store them either locally 02:33.080 --> 02:46.440 or to remote destination. Sister genji can collect system and application logs together which 02:46.440 --> 02:55.640 can provide Python useful contextual data for either side. It's a portable software so it can 02:55.640 --> 03:02.360 collect logmasities from wide variety of platforms, specific sources like download, journal, 03:02.360 --> 03:12.520 sound screens, and so on. As a one of the world has still in use sister genji implementations, 03:12.520 --> 03:22.360 it can work with the legacy in sister logmasities or the news using the new sister protocol 03:22.360 --> 03:28.360 where UDP, PCT, or NPT connectivity connections, and it can collect all kinds of 03:28.360 --> 03:34.360 decades later from applications through five socket spikes and application output. 03:34.360 --> 03:40.360 That's what we will use today for our uploads. But there are many more possibilities 03:40.360 --> 03:48.360 as you can easily extend sister genji in Python and implement an HTTP source, Kafka source 03:48.360 --> 03:58.920 or many other. In my view the most important role of sister genji that it can process 03:58.920 --> 04:05.320 of logmasities, it can classify and organize structure logs using built-in parsers, 04:05.880 --> 04:13.320 the part-time DDP parser, CSC parser, JSON parsers, and many others. It can also 04:13.320 --> 04:18.520 divide the cities and not just, and you do not have to think about the falsifying logmasities. 04:18.520 --> 04:23.800 But for example, anonymization is required by various compliance regulations. 04:25.160 --> 04:33.960 It can also enrich the log data with NGIT or reformer term to the requirements of 04:33.960 --> 04:39.000 various destinations using JSON, formatting, or ISD, or whatever. 04:40.280 --> 04:45.960 And I already mentioned Python. You can create 04:46.360 --> 04:50.920 implement any of the above features in Python, but you can also use it to enrich 04:50.920 --> 04:57.240 logmasities from databases or do filtering, which leads us to next topic. 04:57.320 --> 05:05.000 If you are trying, it has two main uses. Discutting surface logmasities, like making sure 05:05.000 --> 05:13.800 that you do not store any debug logmasities as that can be pretty expensive quite quickly, 05:14.600 --> 05:22.600 or for message routing, like making sure that all your authentication related events reach 05:22.680 --> 05:29.160 your CINC system. There are many possibilities. It can be based on message content various 05:29.160 --> 05:34.840 message parameters. You can use comparisons, white card, various filtering functions, 05:35.560 --> 05:40.280 and best of all, you can combine all of these using Boolean operators. 05:41.800 --> 05:46.600 Finally, you have this stored logmasities somewhere. Traditionally, you either stored logmasities 05:46.600 --> 05:54.280 local to a text file, or for what the logmasities using the CIS log protocol and saved logmasities 05:55.080 --> 06:02.280 there to to text files. But nowadays, there are many more possibilities. 06:03.320 --> 06:11.400 You can forward messages in various formats to a CINC system, various log analytics applications, 06:12.040 --> 06:18.600 but also stored them to databases, big data destinations, like Hadoop, 06:19.720 --> 06:25.560 document stores, like LSD, search, MongoDB, various message filtering systems, like Kafka. 06:27.400 --> 06:38.360 And here we have two generic solutions as well. I often mention Python. You can use Python to write 06:38.840 --> 06:49.880 destinations, but you can also use the HTTP destination, and we try as APIs using the HTTP 06:49.880 --> 06:55.880 destination. This is actually used for error stick search, telecom, Slack, and some other. 06:58.920 --> 07:05.800 Here, I want to emphasize a system, an important system again to feature. It's message parsing. 07:05.800 --> 07:14.680 It creates names that you pass from interesting message parts. Why is it important? Because 07:14.680 --> 07:27.000 normally, when a logmasit arrives, this is a huge string, and doesn't know anything what is 07:27.000 --> 07:34.600 inside it. But if you parse these logmasities and create name value parts, these name value parts 07:34.600 --> 07:40.440 and be where you use for later on. For unstructured logmasities, you can use the port nptb message 07:40.440 --> 07:47.480 parts are. For structured logs, we have parts that are commasaparated values, JSON, XML, 07:48.760 --> 08:01.800 key value parts, and others. And you can combine these new parts, and we have quite a few examples 08:01.800 --> 08:07.880 for this in the system and the configuration library. So we have parsers for pseudo logmasities, 08:07.880 --> 08:15.800 Apache logmasities, Cisco logmasities, as they look like systemmasities, but where they do not 08:15.800 --> 08:23.880 really compliant. They are not really compliant. So some additional parsing helps to get the 08:23.880 --> 08:35.480 information out of them. So why in the UPRs are so important? Because they help in filtering a lot, 08:35.480 --> 08:41.320 just consider the previous mentioned SSH logmasit. If it's just a long long string, 08:41.320 --> 08:47.560 then you cannot re-fill their based on the content of this logmasit. But if you parse it, 08:47.560 --> 08:55.160 then you can see that it's using a root, trying to connect from a given IP address from 08:55.160 --> 09:02.120 the user in the given port, and an authentication method, and you can create an all-art, 09:02.120 --> 09:10.600 for example, based on the user name. It's also useful for discard being served as full-considering. 09:11.000 --> 09:21.960 And for storage, it's also useful as you can re-format logmasities to the needs of a given 09:23.720 --> 09:31.800 destination, like sending the UPRs to Rustic Search, or one of my favorite examples is 09:32.760 --> 09:42.440 one of our users is sending VMware logmasities or at the network. But those are really 09:42.440 --> 09:49.800 long logmasities with lots of content, but from those only very minimal information, 09:49.800 --> 09:57.240 what is really necessary for security analytics. So they forward only the parsed logmasage 09:57.240 --> 10:02.760 and forward only those two fields, which are necessary for security analytics, and this way, 10:02.760 --> 10:14.040 they save the robots of network, traffic, and storage costs each day. 10:17.400 --> 10:23.240 Overuse the name that UPRs are also very useful outside of system energy, for reporting, 10:23.240 --> 10:27.640 or reporting, and dashboard, just think of elastic search and kibana. 10:30.040 --> 10:40.280 Now, let's change to FreeBSD audit. It's a security subsystem within FreeBSD, which can 10:40.280 --> 10:50.280 log circulate in Iran. It's highly configurable what is included in these logs, and these 10:50.680 --> 11:00.200 logs can be used for intuition, detection, or postmark them analysis of security incidents. 11:01.240 --> 11:09.000 These are binary files and compatible with the macOS audit logs, as well. 11:09.560 --> 11:23.560 You can enable audit logs in RC.com, or you can start it from the command right as well. 11:25.320 --> 11:32.840 And configuration is under the ETC security directory, where you can find 11:32.840 --> 11:42.200 you in what is logged, what is not included in the logs. By default, these logs are stored in 11:42.200 --> 11:50.280 where audit current. The content of this file can be displayed using PR audit. 11:51.240 --> 12:08.520 When freeBSD guys, you will be as the contacted me. I thought that we need to try to 12:09.080 --> 12:22.280 base on C, but that's quite a long process. Luckily, when I checked how the freeBSD 12:22.280 --> 12:31.800 audit subsystem works, I realized that we can use the PR audit command, the output of the PR 12:32.040 --> 12:43.480 command within C, and that way creating a new source fiber for C, plus a few hours, including 12:43.480 --> 12:53.080 writing the documentation instead of much longer times. What you need to be careful when creating 12:53.080 --> 13:08.520 the driver for C, that even should be on a single line. The application showing the output 13:09.560 --> 13:15.320 should be able to work from input from pair, or be able to continuously run. 13:16.200 --> 13:25.720 And in a good case, it can each of us provide a structured output. In case of 13:28.280 --> 13:36.120 PR audit, these are the command lines, command line options I used, a minus r for single line, 13:36.120 --> 13:44.920 output, minus p to be able to work from the input from pair, command, and minus x for 13:44.920 --> 13:54.440 axonal output. And if you want to integrate something else, which is again G, you should check 13:54.600 --> 14:10.520 for signal options. This was my original sysloganges source freeBSD audit sysloganges source, 14:11.480 --> 14:19.720 it works, but it has all of the implementation details, and it's not really nice. 14:19.720 --> 14:31.720 And if you want to use it multiple times, then you copy and paste, that's also not 14:31.720 --> 14:33.720 going to be nice. 14:33.720 --> 14:40.320 So instead of that, what I did was creating that reuseable configuration block for 14:40.320 --> 14:47.720 CISO GenG, this is something quite clear to be part of the next CISO GenG release. 14:47.720 --> 14:52.720 This will hide the way of the implemented, well, most of the implementation details 14:52.720 --> 14:57.720 from the users as you will see in later slides. 14:57.720 --> 15:07.720 Here, what we did, we defined, we use, we are outed. 15:07.720 --> 15:13.720 And for that, we defined some default command light options. 15:13.720 --> 15:19.720 Here, we use the options shown on the previous slide. 15:19.720 --> 15:26.720 So single line, use is still and has XML output. 15:26.720 --> 15:32.720 Note that XML output is very nice. 15:32.720 --> 15:36.720 It works with CISO GenG, but only if you compile CISO GenG or 15:36.720 --> 15:44.720 have from ports, it's not among the default options. 15:44.720 --> 15:49.720 So here is how you can use it. 15:49.720 --> 15:56.720 As you can see, it's much nicer than seeing all of the command light options and 15:56.720 --> 16:02.720 the findings and everything. 16:02.720 --> 16:06.720 Instead, just write 3D as the audit and that's all. 16:06.720 --> 16:17.720 Next, we defined an XML parser and all of the fields are expected with a prefix. 16:17.720 --> 16:23.720 So we can easily identify what is coming from the XML parser. 16:23.720 --> 16:28.720 We also defined JSON format output. 16:28.720 --> 16:36.720 This way, you can see all of the name that you pass extracted from the audit logs. 16:36.720 --> 16:42.720 And finally, we have a log statement, which connects all of these building blocks together. 16:42.720 --> 16:49.720 The source, the XML parser and the file destination. 16:49.720 --> 16:59.720 And here, you can see a log message written by CISO GenG. 16:59.720 --> 17:10.720 And you can see that it's SSH, login message found by the audit, 17:10.720 --> 17:18.720 out in 3D as the audit subsystem. 17:18.720 --> 17:27.720 You can also work with a plain output if you do not have XML support included in CISO GenG. 17:27.720 --> 17:36.720 In this case, you need to define parameters for, 17:36.720 --> 17:44.720 without XML support. 17:44.720 --> 17:47.720 So it's just minus p minus r. 17:47.720 --> 17:52.720 Here, we simply write the results to a text file. 17:52.720 --> 17:58.720 And the log statement at the end connects these two building blocks together. 17:58.720 --> 18:03.720 Here, you can see plain text output. 18:03.720 --> 18:10.720 And here, the CISO GenG message header. 18:10.720 --> 18:12.720 So the date, the host name. 18:12.720 --> 18:25.720 And after that, you can see the VBS, the audit log, a spring text. 18:25.720 --> 18:33.720 There are a couple of limitations of this solution. 18:33.720 --> 18:42.720 We are most likely fixed, some of these, but some of these are outside of the scope of CISO GenG, 18:42.720 --> 18:53.720 which means that if a field coming from the audit logs has a space in it, 18:53.720 --> 19:01.720 then CISO GenG adds double quotation marks to the given field. 19:01.720 --> 19:07.720 For text, the actioner parts are actually leading underscore to techniques, 19:07.720 --> 19:12.720 which cannot be changed or removed. 19:12.720 --> 19:19.720 And as we do not read log 5 directly, we cannot bookmark where we are, 19:19.720 --> 19:24.720 which means that when CISO GenG is restarted, 19:24.720 --> 19:32.720 that there might be duplicate audit logs or some of these single logs, 19:32.720 --> 19:39.720 depending on the amount of log messages. 19:39.720 --> 19:45.720 And finally, some good news for CISO GenG. 19:45.720 --> 19:55.720 These are some VBSD. And actually, I'm trying actively push VBSD related improvements 19:55.720 --> 19:59.720 within CISO GenG, as next to Ratatly Nox. 19:59.720 --> 20:03.720 VBSD is our second largest CISO community. 20:03.720 --> 20:12.720 So I'm very happy to share that the latest CISO GenG release fixed, 20:12.720 --> 20:19.720 long-standing programs with code compatibility, 20:19.720 --> 20:25.720 which means that we can compile a lot more diverse on CISO GenG. 20:25.720 --> 20:30.720 And CISO GenG, we have open terminally and BigQuery support, 20:30.720 --> 20:33.720 and a few more, you know, adderable on VBSD. 20:33.720 --> 20:37.720 We also fixed a few. 20:38.720 --> 20:45.720 Configure related box, which means that NQTT support is no available on VBSD. 20:45.720 --> 20:52.720 And we have a brand new implementation for directory monitoring, 20:52.720 --> 21:01.720 based on KQ, which means that reading files, 21:01.720 --> 21:05.720 especially if you have many files in a directory, 21:05.720 --> 21:11.720 it's now much faster, and it's using a lot less resources on VBSD. 21:11.720 --> 21:20.720 And actually, it's much better on VBSD than on any other operating systems. 21:20.720 --> 21:28.720 So let me summarize my talk. 21:28.720 --> 21:35.720 You can easily integrate application output, 21:35.720 --> 21:39.720 which CISO GenG in just like VBSD audit logs, 21:39.720 --> 21:43.720 if the application runs continuously, 21:43.720 --> 21:48.720 and can print single-line messages preferable in a structured format. 21:48.720 --> 21:57.720 There are several new drivers available for CISO GenG on VBSD. 21:57.720 --> 22:04.720 So you can start working on open terminally, for example, 22:04.720 --> 22:12.720 and file reading and directory monitoring became a lot more efficient 22:12.720 --> 22:17.720 on VBSD with latest release. 22:17.720 --> 22:23.720 So thank you for your attention, and I look forward to some questions. 22:27.720 --> 22:34.720 Thank you.