WEBVTT 00:00:00.540 --> 00:00:04.380 When considering the implementation of log capture and analysis, 00:00:04.390 --> 00:00:07.650 would you be shocked to know that there is a standard for it? 00:00:08.540 --> 00:00:09.440 Probably not. 00:00:09.500 --> 00:00:13.010 If you were to look NIST Special Publications 800‑92, 00:00:13.010 --> 00:00:16.160 Guide to Computer Security Log Management, 00:00:16.540 --> 00:00:22.510 it focuses on the log being a record of events that have occurred within an 00:00:22.510 --> 00:00:25.860 organization's systems and the organization's network. 00:00:26.240 --> 00:00:31.050 And when you think of what is composed of the things in the log, 00:00:31.100 --> 00:00:35.640 there could be many sources. It could be filled with events that are 00:00:35.640 --> 00:00:41.840 completely innocuous. Elements of log collection are focusing on what is 00:00:41.850 --> 00:00:45.300 regulatory or a compliant requirement that we have. 00:00:45.310 --> 00:00:51.090 What is the non‑repudiation? If we have looked at the authentication, 00:00:51.100 --> 00:00:54.840 the authorization, and the identification of an entity, 00:00:54.850 --> 00:00:57.600 how do we know that that entity is actually doing what it's 00:00:57.600 --> 00:01:01.810 supposed to be doing? The performance is also a good key reason 00:01:01.810 --> 00:01:04.190 in our motivation for log collection. 00:01:04.209 --> 00:01:08.210 This is performance both of the cloud service provider's platform 00:01:08.220 --> 00:01:10.570 and anything that we have created on top of it. 00:01:10.740 --> 00:01:15.450 We need to be aware of the separation between real‑time alerts 00:01:15.460 --> 00:01:18.240 and the recording of things inside of logs. 00:01:18.250 --> 00:01:22.650 So the real‑time alerts can be something that we put on top of 00:01:22.650 --> 00:01:26.450 the logging event correlation that says that this is a matter 00:01:26.460 --> 00:01:28.060 that needs higher escalation. 00:01:28.070 --> 00:01:28.640 Why? 00:01:28.740 --> 00:01:33.610 Because that event could actually be part of an incident that deserves 00:01:33.610 --> 00:01:37.180 an investigation. A little bit later, we'll look through a 00:01:37.180 --> 00:01:41.290 demonstration of creating something that has the full lifecycle 00:01:41.290 --> 00:01:43.970 management of the monitoring, the collection, 00:01:43.970 --> 00:01:47.760 the real‑time alerts, and even event correlation. When it comes to 00:01:47.760 --> 00:01:50.620 log management in the log management process, 00:01:50.830 --> 00:01:54.400 we first have to define the logging requirements and the goals. 00:01:54.410 --> 00:01:56.820 What is it that the organization wants to accomplish? 00:01:56.890 --> 00:02:00.110 That means that there has to be prioritization of log 00:02:00.110 --> 00:02:03.270 management appropriate to the organization's risk 00:02:03.270 --> 00:02:05.620 tolerance and risk management behaviors. 00:02:05.700 --> 00:02:11.660 The idea is to reduce risk. Policies need to be developed that 00:02:11.660 --> 00:02:14.990 clearly define the mandatory requirements and suggested 00:02:14.990 --> 00:02:18.270 recommendations for log management activities. 00:02:18.430 --> 00:02:20.860 It includes log generation, the transmission, 00:02:20.860 --> 00:02:25.060 the storage, the analysis, and the disposal of the logs. 00:02:25.440 --> 00:02:31.830 There needs to be a step‑by‑step process for collecting logs needed as evidence. 00:02:31.840 --> 00:02:35.800 Organizations may wish to acquire copies of original log files, 00:02:35.810 --> 00:02:39.450 centralized log files, and to interpret the log data. 00:02:39.540 --> 00:02:42.700 This may mean additional conversations with the cloud service 00:02:42.700 --> 00:02:47.770 provider to have access to resources that may not be part of what 00:02:47.770 --> 00:02:50.250 is naturally supplied inside of the SLA. 00:02:50.840 --> 00:02:56.980 Additional factors that will influence the log design could be the cost and the 00:02:56.980 --> 00:03:00.180 volume of the data that's going to be processed or stored. 00:03:00.220 --> 00:03:02.340 Typically, with cloud service providers, 00:03:02.540 --> 00:03:08.820 it's not the management of the log in their platform that has cost, but it's 00:03:08.820 --> 00:03:15.220 typically the storage of it and also the movement of that log outside of the 00:03:15.220 --> 00:03:18.420 platform that tends to exponentiate the cost. 00:03:18.480 --> 00:03:22.010 You also should be concerned about the disposition of the logs, 00:03:22.010 --> 00:03:25.740 whether it's in transit or at rest so that it's secure. The information 00:03:25.740 --> 00:03:30.670 that's coming from these logs could actually be quite detrimental if 00:03:30.670 --> 00:03:33.950 exposed to eyes that should not be seeing it. 00:03:34.240 --> 00:03:39.910 The security concerns for logs have to do with what the logging status is. 00:03:40.060 --> 00:03:42.100 When we talk about logging status, 00:03:42.200 --> 00:03:46.710 we're saying there should be monitoring of the log sources 00:03:46.770 --> 00:03:49.430 and monitoring of the logs themselves. 00:03:49.600 --> 00:03:52.970 What kind of archival process do the logs go through? 00:03:52.980 --> 00:03:55.950 Is there some kind of overriding that takes place at 00:03:55.950 --> 00:03:57.660 the end of a particular period? 00:03:57.940 --> 00:04:01.650 How about checking for upgrades and patches to logging software and 00:04:01.650 --> 00:04:05.610 acquiring the testing and deploying them in a correct way? 00:04:05.960 --> 00:04:09.630 Logs also need to be concerned about synchronizing time, 00:04:09.700 --> 00:04:12.980 ensuring that each log's host clock is synchronized to a 00:04:12.980 --> 00:04:17.140 common time source. Also, reconfiguring logging as needed 00:04:17.140 --> 00:04:18.709 based upon policy changes, 00:04:18.709 --> 00:04:22.510 technology changes, and other factors that may take place. And then 00:04:22.610 --> 00:04:28.670 the operational existence of the log so that we can detect anomalies 00:04:28.670 --> 00:04:31.260 that may occur that need to be addressed. 00:04:31.740 --> 00:04:36.020 The SIEM system is the centralized collection and monitoring of 00:04:36.020 --> 00:04:39.000 security and event logs from different systems. 00:04:39.010 --> 00:04:43.400 The SIEM system allows for the correlation of different events and 00:04:43.410 --> 00:04:47.710 early detection of attacks. At the most basic level, a SIEM system can 00:04:47.710 --> 00:04:53.040 be rules based or employ a statistical correlation engine to establish 00:04:53.040 --> 00:04:55.470 relationships between event logs. 00:04:55.480 --> 00:05:00.700 So, what are some common characteristics? That you're pulling in raw 00:05:00.710 --> 00:05:05.550 information from various system logs. Going through a process of aggregating 00:05:05.560 --> 00:05:09.380 those many different systems into a single repository. 00:05:09.390 --> 00:05:14.430 You're normalizing that information so that it conforms to a particular 00:05:14.430 --> 00:05:18.300 format, and the comparisons can be more meaningful. 00:05:18.310 --> 00:05:24.060 You're doing the analyzing of the capabilities. You're analyzing and using 00:05:24.060 --> 00:05:28.250 analyzation tools in order to map and extract target information. 00:05:28.340 --> 00:05:32.580 And then, you also may be doing some type of alerting as well. 00:05:32.710 --> 00:05:35.510 Different SIEM characteristics and benefits. 00:05:35.520 --> 00:05:37.610 If you have a locally hosted SIEM, 00:05:37.620 --> 00:05:42.570 it offers easy access and lowered risk of external disclosure. 00:05:42.580 --> 00:05:48.540 You can have externally hosted, which may prevent an attacker from tampering 00:05:48.540 --> 00:05:51.970 with the data based upon the expertise of the one hosting it. 00:05:51.980 --> 00:05:54.900 It could be a hybrid because you're consuming 00:05:54.900 --> 00:05:57.710 services both locally and in the cloud. 00:05:57.870 --> 00:06:03.110 It could be done from an external storage perspective to support policy so that 00:06:03.120 --> 00:06:07.260 the administrators locally do not have access to the log. 00:06:07.340 --> 00:06:11.410 It could be part of your disaster recovery in that it is taking 00:06:11.410 --> 00:06:16.230 place based upon transactions, and it is creating a transaction 00:06:16.230 --> 00:06:18.200 log that you can recover based upon. 00:06:18.210 --> 00:06:20.970 And like we said, with privilege users, 00:06:20.980 --> 00:06:25.410 we want to make sure that we're screening out and preventing the capability 00:06:25.590 --> 00:06:29.190 for those privilege users from managing their own logs. 00:06:30.040 --> 00:06:34.680 Next generation capabilities and log management says that the SIEM 00:06:34.680 --> 00:06:40.480 system may be based upon a modern data lake technology like Amazon's 00:06:40.490 --> 00:06:46.940 S2 or Hadoop or Elasticsearch. Having large amounts of low‑cost 00:06:46.940 --> 00:06:51.940 space can afford greater retention when it comes to doing this on a 00:06:51.950 --> 00:06:53.350 large‑scale basis. 00:06:53.740 --> 00:06:56.890 You also may be using other types of analytics, 00:06:56.900 --> 00:06:59.980 like user and entity behavior, 00:06:59.990 --> 00:07:04.140 which utilizes machine learning and behavioral profiling for deeper 00:07:04.140 --> 00:07:08.080 intelligence in identifying threats that may not seem like an anomaly 00:07:08.080 --> 00:07:11.650 from a log that is looking just at two dimensions. 00:07:11.840 --> 00:07:16.690 There is growing usefulness in this world as we connect the SIEM 00:07:16.690 --> 00:07:21.350 along with other security orchestration and automation technology 00:07:21.360 --> 00:07:25.050 that assist in identifying and responding to security incidents 00:07:25.060 --> 00:07:26.520 that are inside the SOC. 00:07:26.630 --> 00:07:30.220 Large amounts of telemetry data also supports the continuous 00:07:30.220 --> 00:07:33.070 improvement of a zero trust architecture.