WEBVTT

1
00:00:00.000 --> 00:00:01.320
In this lesson,

2
00:00:01.320 --> 00:00:04.890
we will learn about monitoring and oversight.

3
00:00:04.890 --> 00:00:08.460
Monitoring and oversight is continuously tracking

4
00:00:08.460 --> 00:00:11.340
and reviewing access, authentication,

5
00:00:11.340 --> 00:00:14.700
and authorization activities to ensure compliance

6
00:00:14.700 --> 00:00:18.570
with security policies and detect any unauthorized

7
00:00:18.570 --> 00:00:20.580
or anomalous behavior.

8
00:00:20.580 --> 00:00:23.130
Monitoring and oversight concepts

9
00:00:23.130 --> 00:00:25.860
include logging and auditing.

10
00:00:25.860 --> 00:00:29.070
Logging captures detailed records of access

11
00:00:29.070 --> 00:00:30.900
and authentication events,

12
00:00:30.900 --> 00:00:34.800
such as successful logins or access attempts.

13
00:00:34.800 --> 00:00:38.670
The logs are then used to track user activities

14
00:00:38.670 --> 00:00:40.170
and for troubleshooting.

15
00:00:40.170 --> 00:00:44.100
Auditing involves analyzing logs to assess compliance

16
00:00:44.100 --> 00:00:45.600
with security policies

17
00:00:45.600 --> 00:00:48.360
and identify potential security breaches

18
00:00:48.360 --> 00:00:50.310
or policy violations.

19
00:00:50.310 --> 00:00:53.490
Let's learn more about logging and auditing.

20
00:00:53.490 --> 00:00:55.440
First, we have logging.

21
00:00:55.440 --> 00:00:59.520
Logging involves collecting detailed records of events,

22
00:00:59.520 --> 00:01:04.170
such as logins, access attempts, or changes to systems.

23
00:01:04.170 --> 00:01:08.100
A key part of effective logging is centralized logging

24
00:01:08.100 --> 00:01:10.200
where logs from various systems

25
00:01:10.200 --> 00:01:13.530
and devices are gathered into one place.

26
00:01:13.530 --> 00:01:17.550
One common method for centralized logging is Syslog,

27
00:01:17.550 --> 00:01:21.210
a protocol that sends logs from different devices

28
00:01:21.210 --> 00:01:23.580
to a central server or location.

29
00:01:23.580 --> 00:01:27.720
Syslog also assigns each log message a PRI code,

30
00:01:27.720 --> 00:01:30.150
which is short for priority code.

31
00:01:30.150 --> 00:01:32.790
This helps categorize the log.

32
00:01:32.790 --> 00:01:36.120
The PRI code is a combination of the facility

33
00:01:36.120 --> 00:01:40.470
and severity levels where the facility represents the type

34
00:01:40.470 --> 00:01:43.530
of system or process that generated the log,

35
00:01:43.530 --> 00:01:46.530
such as an operating system, mail services,

36
00:01:46.530 --> 00:01:49.020
or authentication processes.

37
00:01:49.020 --> 00:01:52.800
In fact, there are 24 different facility codes,

38
00:01:52.800 --> 00:01:56.010
each representing a different type of system.

39
00:01:56.010 --> 00:02:00.270
For example, a facility code of zero corresponds

40
00:02:00.270 --> 00:02:02.550
to kernel-generated messages

41
00:02:02.550 --> 00:02:05.700
while a facility code four corresponds

42
00:02:05.700 --> 00:02:08.160
to security-related logs.

43
00:02:08.160 --> 00:02:12.630
Next, the second part of the PRI code is the severity level.

44
00:02:12.630 --> 00:02:16.980
This indicates the importance or urgency of the event.

45
00:02:16.980 --> 00:02:21.450
Severity is prioritized on a scale from zero to seven,

46
00:02:21.450 --> 00:02:24.300
where zero represents an emergency,

47
00:02:24.300 --> 00:02:26.670
meaning something critical that could lead

48
00:02:26.670 --> 00:02:28.200
to a system failure,

49
00:02:28.200 --> 00:02:31.440
and seven represents debugging information,

50
00:02:31.440 --> 00:02:33.300
which is a low priority.

51
00:02:33.300 --> 00:02:37.020
For instance, a system crash would have a severity level

52
00:02:37.020 --> 00:02:40.170
of zero, while a failed login attempt

53
00:02:40.170 --> 00:02:43.830
might have a severity level of five or six.

54
00:02:43.830 --> 00:02:46.440
Next, the PRI code is calculated

55
00:02:46.440 --> 00:02:49.710
by multiplying the facility number by eight

56
00:02:49.710 --> 00:02:51.960
and adding the severity level.

57
00:02:51.960 --> 00:02:55.710
For example, a log from a facility of four

58
00:02:55.710 --> 00:03:00.710
with a severity level of five would have a PRI code of 37.

59
00:03:00.960 --> 00:03:02.910
This PRI code is calculated

60
00:03:02.910 --> 00:03:06.240
as four times eight plus five.

61
00:03:06.240 --> 00:03:08.790
This PRI code helps central systems

62
00:03:08.790 --> 00:03:11.280
and administrators quickly categorize

63
00:03:11.280 --> 00:03:15.840
and handle log events based on their source and urgency.

64
00:03:15.840 --> 00:03:20.100
In Syslog, the lower the severity level within the PRI code,

65
00:03:20.100 --> 00:03:23.340
the higher the urgency of the log message.

66
00:03:23.340 --> 00:03:24.780
Along with Syslog,

67
00:03:24.780 --> 00:03:28.410
many organizations use a Security Information

68
00:03:28.410 --> 00:03:33.240
and Event Management, or SIEM system to collect, categorize,

69
00:03:33.240 --> 00:03:37.740
and analyze logs from multiple sources in real time.

70
00:03:37.740 --> 00:03:41.340
A SIEM gathers logs from a variety of sources,

71
00:03:41.340 --> 00:03:45.180
including firewalls, servers, operating systems,

72
00:03:45.180 --> 00:03:49.470
applications, databases, and network devices.

73
00:03:49.470 --> 00:03:53.100
These logs from different sources often come

74
00:03:53.100 --> 00:03:57.780
in different formats, such as JavaScript Object Notation,

75
00:03:57.780 --> 00:04:01.920
or JSON, Extensible Markup Language, or XML,

76
00:04:01.920 --> 00:04:03.450
Syslog formats

77
00:04:03.450 --> 00:04:07.980
or other proprietary formats unique to specific vendors.

78
00:04:07.980 --> 00:04:11.880
So one of the core functions of a SIEM platform

79
00:04:11.880 --> 00:04:14.130
is to normalize these logs

80
00:04:14.130 --> 00:04:17.220
by converting the diverse log formats

81
00:04:17.220 --> 00:04:19.890
into a common structured format.

82
00:04:19.890 --> 00:04:21.690
This process ensures

83
00:04:21.690 --> 00:04:23.760
that data from various sources

84
00:04:23.760 --> 00:04:27.060
can be efficiently correlated and analyzed.

85
00:04:27.060 --> 00:04:30.420
Without normalization, it would be very challenging

86
00:04:30.420 --> 00:04:33.630
for the SIEM platform to detect patterns

87
00:04:33.630 --> 00:04:36.210
across heterogeneous systems

88
00:04:36.210 --> 00:04:40.950
since each system logs information in a different way.

89
00:04:40.950 --> 00:04:43.080
Second, we have auditing.

90
00:04:43.080 --> 00:04:45.120
Auditing goes beyond logging

91
00:04:45.120 --> 00:04:48.780
and analyzing collected logs to ensure compliance

92
00:04:48.780 --> 00:04:52.890
with regulations and to identify potential security risks.

93
00:04:52.890 --> 00:04:55.770
One of the primary goals of auditing

94
00:04:55.770 --> 00:04:58.050
is regulatory compliance.

95
00:04:58.050 --> 00:05:02.430
Regularly auditing logs helps confirm that an organization

96
00:05:02.430 --> 00:05:04.830
is adhering to regulations.

97
00:05:04.830 --> 00:05:07.560
For example, in the healthcare industry,

98
00:05:07.560 --> 00:05:10.350
organizations are required to comply

99
00:05:10.350 --> 00:05:12.510
with the Health Insurance Portability

100
00:05:12.510 --> 00:05:15.030
and Accountability Act or HIPAA.

101
00:05:15.030 --> 00:05:17.910
This act mandates that all access

102
00:05:17.910 --> 00:05:21.180
to patient data be logged and audited.

103
00:05:21.180 --> 00:05:24.840
So regular audits of these logs ensure

104
00:05:24.840 --> 00:05:27.000
that only authorized personnel

105
00:05:27.000 --> 00:05:29.550
have accessed sensitive information

106
00:05:29.550 --> 00:05:33.060
that any improper access is quickly detected.

107
00:05:33.060 --> 00:05:35.160
A critical aspect of auditing

108
00:05:35.160 --> 00:05:38.400
is maintaining tamper-proof audit trails.

109
00:05:38.400 --> 00:05:41.880
Tamper-proof audit trails record key actions,

110
00:05:41.880 --> 00:05:44.400
such as who accessed a system,

111
00:05:44.400 --> 00:05:47.430
when it happened, and what was done.

112
00:05:47.430 --> 00:05:51.180
It is essential that these records cannot be altered

113
00:05:51.180 --> 00:05:53.910
or deleted, ensuring their integrity.

114
00:05:53.910 --> 00:05:57.090
Tamper-proof technologies like blockchain

115
00:05:57.090 --> 00:06:02.090
or write once, read many storage devices are commonly used

116
00:06:02.220 --> 00:06:03.660
to achieve this.

117
00:06:03.660 --> 00:06:07.500
In a blockchain system, each audit log is stored

118
00:06:07.500 --> 00:06:11.399
in a cryptographically linked block, making it impossible

119
00:06:11.399 --> 00:06:15.720
to modify past records without triggering alerts.

120
00:06:15.720 --> 00:06:20.310
Similarly, write once, read many, or WORM storage,

121
00:06:20.310 --> 00:06:23.310
allows data to be written to once,

122
00:06:23.310 --> 00:06:25.800
preventing any future changes.

123
00:06:25.800 --> 00:06:28.770
For example, in a financial institution,

124
00:06:28.770 --> 00:06:30.960
transaction records could be stored

125
00:06:30.960 --> 00:06:33.150
on a WORM storage system.

126
00:06:33.150 --> 00:06:35.760
When a transaction is logged, it is written

127
00:06:35.760 --> 00:06:39.630
to the storage device, and that entry becomes permanent.

128
00:06:39.630 --> 00:06:42.420
From that point on, no one can modify

129
00:06:42.420 --> 00:06:44.370
or erase the transaction,

130
00:06:44.370 --> 00:06:47.070
ensuring a tamper-proof audit trail.

131
00:06:47.070 --> 00:06:49.920
This is important for regulatory compliance

132
00:06:49.920 --> 00:06:51.960
and for forensic investigation

133
00:06:51.960 --> 00:06:56.160
because it guarantees that audit logs remain intact

134
00:06:56.160 --> 00:06:58.350
and unaltered over time.

135
00:06:58.350 --> 00:07:01.800
So remember, logging and auditing

136
00:07:01.800 --> 00:07:03.810
are essential for monitoring

137
00:07:03.810 --> 00:07:08.160
and oversight in maintaining security and compliance.

138
00:07:08.160 --> 00:07:12.030
Logging focuses on collecting detailed records

139
00:07:12.030 --> 00:07:16.852
of events, such as access attempts and system changes,

140
00:07:16.852 --> 00:07:20.820
often centralized in systems like Syslog

141
00:07:20.820 --> 00:07:24.900
or security information and event management platforms

142
00:07:24.900 --> 00:07:28.950
to ensure easy management and real-time analysis.

143
00:07:28.950 --> 00:07:31.590
Logs help track user activities

144
00:07:31.590 --> 00:07:35.160
and are valuable for troubleshooting system issues.

145
00:07:35.160 --> 00:07:38.700
On the other hand, auditing analyzes these logs

146
00:07:38.700 --> 00:07:41.130
to ensure compliance with regulation

147
00:07:41.130 --> 00:07:44.940
and to identify potential security risks.

148
00:07:44.940 --> 00:07:47.100
A crucial aspect of auditing

149
00:07:47.100 --> 00:07:50.400
is creating tamper-proof audit trails.

150
00:07:50.400 --> 00:07:52.483
Tamper-proof audit trails ensure

151
00:07:52.483 --> 00:07:55.590
that important records cannot be altered

152
00:07:55.590 --> 00:07:59.250
or deleted, providing a reliable foundation

153
00:07:59.250 --> 00:08:03.033
for investigations and compliance efforts.