1
00:00:00,000 --> 00:00:10,320
Ένα Security Information and Event Management, ένα σύστημα SIEM, είναι ένα ολοκληρωμένο εργαλείο που

2
00:00:10,320 --> 00:00:15,200
λειτουργεί ως το νευραλγικό κέντρο των επιχειρήσεων ασφαλείας ενός οργανισμού.

3
00:00:15,200 --> 00:00:20,800
Συλλέγει logs και δεδομένα σχετικά με την ασφάλεια από ένα ευρύ φάσμα πηγών σε όλη την

4
00:00:20,800 --> 00:00:27,920
ψηφιακή υποδομή, συμπεριλαμβανομένων των endpoints, servers, συσκευών δικτύου, υπηρεσιών cloud,

5
00:00:27,920 --> 00:00:32,960
και διάφορων εργαλείων ασφαλείας όπως firewalls ή συστήματα antivirus.

6
00:00:32,960 --> 00:00:38,480
Το κύριο πλεονέκτημα ενός SIEM είναι η ικανότητά του να κεντρικοποιεί αυτά τα δεδομένα, το οποίο είναι κρίσιμο

7
00:00:38,480 --> 00:00:43,840
για αποτελεσματική παρακολούθηση και ανάλυση. Αυτό επιτρέπει στις ομάδες ασφαλείας να έχουν μια ενιαία

8
00:00:43,840 --> 00:00:49,680
εικόνα όλων των συμβάντων ασφαλείας και των logs επιτρέποντας ταχύτερο εντοπισμό,

9
00:00:49,680 --> 00:00:53,760
διερεύνηση και απόκριση σε πιθανές απειλές.

10
00:00:53,760 --> 00:00:58,640
Μία από τις πρωταρχικές δυνατότητες ενός SIEM είναι η κεντρικοποιημένη διαχείριση των logs (centralized log management).

11
00:00:58,640 --> 00:01:04,560
Συγκεντρώνει logs από διαφορετικές πηγές όπως Syslog, Windows event logs,

12
00:01:04,560 --> 00:01:11,360
και cloud-based υπηρεσίες, απλοποιώντας τη διαδικασία διαχείρισης μεγάλων όγκων

13
00:01:11,360 --> 00:01:14,320
δεδομένων. Αυτή η κεντρικοποιημένη προσέγγιση όχι μόνο

14
00:01:14,320 --> 00:01:18,640
απλοποιεί την αποθήκευση δεδομένων αλλά ενισχύει επίσης την αποδοτικότητα

15
00:01:18,640 --> 00:01:24,160
των λειτουργιών ασφαλείας καθώς οι αναλυτές μπορούν γρήγορα να έχουν πρόσβαση και να συσχετίζουν δεδομένα από

16
00:01:24,160 --> 00:01:28,640
διάφορα συστήματα. Τα συστήματα SIEM προσφέρουν επίσης σημαντική ορατότητα

17
00:01:28,640 --> 00:01:32,400
απειλών. Συσχετίζοντας (correlating) γεγονότα από πολλαπλές

18
00:01:32,400 --> 00:01:37,040
πηγές μπορούν να εντοπίσουν ύποπτα μοτίβα που υποδεικνύουν πιθανές

19
00:01:37,040 --> 00:01:41,120
απειλές όπως lateral movement (πλευρική μετακίνηση) εντός ενός δικτύου

20
00:01:41,120 --> 00:01:44,880
ή απόπειρες κλιμάκωσης προνομίων (privilege escalation) εντός ενός host.

21
00:01:44,960 --> 00:01:48,560
Για παράδειγμα, αν ένας χρήστης με περιορισμένα δικαιώματα πρόσβασης

22
00:01:48,560 --> 00:01:54,000
ξαφνικά προσπαθήσει να προσπελάσει ευαίσθητα δεδομένα, ένα SIEM θα το επισήμαινε αυτό ως πιθανό

23
00:01:54,000 --> 00:01:58,480
περιστατικό ασφαλείας. Επιπλέον, τα συστήματα SIEM παίζουν κρίσιμο

24
00:01:58,480 --> 00:02:03,440
ρόλο στο να βοηθούν τους οργανισμούς να διατηρούν τη συμμόρφωση ασφαλείας (security compliance).

25
00:02:03,440 --> 00:02:07,680
Μπορούν να ρυθμιστούν ώστε να πληρούν διάφορα κανονιστικά πρότυπα

26
00:02:07,680 --> 00:02:16,000
όπως PCI DSS, NIST, ή ISO 27001. Διασφαλίζοντας ότι οι πρακτικές ασφαλείας

27
00:02:16,000 --> 00:02:20,560
ευθυγραμμίζονται με τις απαιτήσεις του κλάδου για αυτή τη συμμόρφωση.

28
00:02:20,560 --> 00:02:24,400
Αυτές οι απαιτήσεις συχνά επιβάλλουν λεπτομερή καταγραφή (logging)

29
00:02:24,400 --> 00:02:30,080
και παρακολούθηση σε πραγματικό χρόνο, τα οποία είναι βασικές λειτουργίες των συστημάτων SIEM.

30
00:02:30,080 --> 00:02:35,040
Για παράδειγμα, μια εταιρεία λιανικής μπορεί να χρησιμοποιήσει ένα σύστημα SIEM για να παρακολουθεί τα συστήματα

31
00:02:35,040 --> 00:02:39,840
επεξεργασίας πληρωμών της. Ένα σύστημα θα μπορούσε να ρυθμιστεί να στέλνει ειδοποίηση

32
00:02:39,840 --> 00:02:45,280
εάν γίνουν απόπειρες σύνδεσης εκτός των ωρών εργασίας

33
00:02:45,280 --> 00:02:50,880
από μια ξένη διεύθυνση IP, σηματοδοτώντας μια πιθανή παραβίαση ασφαλείας.

34
00:02:50,880 --> 00:02:55,440
Αυτή η αυτοματοποιημένη ειδοποίηση επιτρέπει στην ομάδα ασφαλείας να διερευνήσει την

35
00:02:55,440 --> 00:03:01,120
κατάσταση και να αναλάβει δράση πριν συμβεί μια επίθεση πλήρους κλίμακας.

36
00:03:01,120 --> 00:03:05,760
Τα SIEM ξεκινούν τη λειτουργία τους συλλέγοντας logs από μια ποικιλία πηγών

37
00:03:05,760 --> 00:03:09,200
δεδομένων εντός της υποδομής ενός οργανισμού.

38
00:03:09,200 --> 00:03:12,560
Αυτές οι πηγές περιλαμβάνουν endpoints, servers, switches,

39
00:03:12,560 --> 00:03:16,160
routers, firewalls, και συσκευές ασφαλείας,

40
00:03:16,160 --> 00:03:20,240
όλα εκ των οποίων παράγουν logs σε διαφορετικά formats.

41
00:03:20,240 --> 00:03:26,640
Για να βγάλουν νόημα από αυτά τα ανόμοια δεδομένα, τα SIEM χρησιμοποιούν μια διαδικασία

42
00:03:26,640 --> 00:03:32,400
κανονικοποίησης logs (log normalization). Αυτή η διαδικασία περιλαμβάνει τη μετατροπή logs από διάφορα formats

43
00:03:32,400 --> 00:03:36,240
σε μια ενιαία δομή, επιτρέποντάς τους να αναλυθούν και

44
00:03:36,240 --> 00:03:41,040
να συσχετιστούν αποδοτικά. Η τεχνική διαδικασία της συλλογής logs

45
00:03:41,040 --> 00:03:46,000
συνήθως περιλαμβάνει collectors ή agents όπως το NXLog,

46
00:03:46,000 --> 00:03:51,840
Winlogbeat, ή Beats από το ELK Stack, Fluentd, ή άλλους

47
00:03:51,840 --> 00:03:57,600
που τραβούν δεδομένα από αυτούς τους πόρους. Αυτοί οι agents είναι υπεύθυνοι για τη συγκέντρωση

48
00:03:57,600 --> 00:04:01,440
των logs και την αποστολή τους στο SIEM για επεξεργασία.

49
00:04:01,440 --> 00:04:06,480
Μόλις συλλεχθούν, τα logs κανονικοποιούνται χρησιμοποιώντας προκαθορισμένους κανόνες parsing και

50
00:04:06,480 --> 00:04:11,200
αντιστοιχίσεις πεδίων (field mappings). Αυτό το βήμα μετατρέπει τα δεδομένα σε ένα συνεπές

51
00:04:11,200 --> 00:04:16,240
σχήμα όπως το Common Event Format (CEF) ή JSON.

52
00:04:16,240 --> 00:04:20,240
Αυτά τα formats τυποποιούν τη δομή των logs, καθιστώντας τα

53
00:04:20,240 --> 00:04:24,160
ευκολότερα στην ανάλυση και την αναζήτηση σε όλο το σύστημα,

54
00:04:24,160 --> 00:04:29,360
ανεξάρτητα από την αρχική πηγή. Μια άλλη κρίσιμη πτυχή της κανονικοποίησης

55
00:04:29,360 --> 00:04:34,880
είναι η ενοποίηση των χρονοσημάνσεων (timestamp unification). Καθώς τα logs παράγονται

56
00:04:34,880 --> 00:04:40,560
μπορεί να παράγονται σε διαφορετικές ζώνες ώρας ή να αντιμετωπίζουν αποκλίσεις ρολογιού (clock drifts),

57
00:04:40,560 --> 00:04:44,560
είναι απαραίτητο να ευθυγραμμιστούν τα timestamps για να διασφαλιστεί ότι τα γεγονότα

58
00:04:44,560 --> 00:04:47,680
συσχετίζονται με ακρίβεια σε όλα τα συστήματα.

59
00:04:47,680 --> 00:04:52,880
Χωρίς την ενοποίηση timestamps, logs από διαφορετικές πηγές μπορεί να φαίνονται εκτός

60
00:04:52,880 --> 00:04:56,480
σειράς, καθιστώντας δύσκολη την παρακολούθηση της ροής των

61
00:04:56,480 --> 00:05:02,000
γεγονότων και τον εντοπισμό περιστατικών ασφαλείας. Για παράδειγμα, φανταστείτε ένα σύστημα SIEM

62
00:05:02,000 --> 00:05:06,080
που λαμβάνει logs από ένα Cisco ASA

63
00:05:06,080 --> 00:05:12,240
firewall και ένα σύνολο από Linux servers. Κάθε μία από αυτές τις πηγές μπορεί να παράγει logs σε

64
00:05:12,240 --> 00:05:15,520
διαφορετικά formats. Το σύστημα SIEM θα τυποποιήσει

65
00:05:15,520 --> 00:05:20,000
αυτά τα logs ώστε μια ενιαία αναζήτηση να μπορεί να ψάξει για απόπειρες

66
00:05:20,000 --> 00:05:24,960
σύνδεσης SSH και στα δύο συστήματα ανεξάρτητα από το αν τα logs προήλθαν

67
00:05:24,960 --> 00:05:30,640
από ένα firewall ή τους servers. Αυτή η κανονικοποίηση επιτρέπει στους αναλυτές να

68
00:05:30,640 --> 00:05:36,000
συσχετίζουν γρήγορα και αποδοτικά τα γεγονότα οδηγώντας σε ταχύτερο

69
00:05:36,000 --> 00:05:40,080
εντοπισμό πιθανών απειλών ασφαλείας.

70
00:05:40,080 --> 00:05:45,280
Συνοπτικά, τα SIEM βασίζονται στη συλλογή και κανονικοποίηση logs

71
00:05:45,280 --> 00:05:49,200
για να μετατρέψουν ποικίλα δεδομένα σε ένα δομημένο format

72
00:05:49,200 --> 00:05:53,840
που μπορεί να αναλυθεί και να συσχετιστεί αποτελεσματικά. Αυτή η διαδικασία διασφαλίζει ότι

73
00:05:53,840 --> 00:05:58,480
οι ομάδες ασφαλείας μπορούν γρήγορα να εντοπίσουν και να ανταποκριθούν σε περιστατικά

74
00:05:58,480 --> 00:06:03,360
ανεξάρτητα από τα συστήματα που παράγουν τα δεδομένα.

75
00:06:03,360 --> 00:06:07,440
Οι τεχνικές δυνατότητες των SIEM τους επιτρέπουν να εκτελούν

76
00:06:07,440 --> 00:06:12,240
τον τύπο της εξελιγμένης ανάλυσης. Οι μηχανές συσχέτισης (Correlation engines)

77
00:06:12,240 --> 00:06:17,600
είναι στην καρδιά αυτής της λειτουργικότητας. Αυτές οι μηχανές ταιριάζουν μοτίβα χρησιμοποιώντας

78
00:06:17,600 --> 00:06:21,360
προκαθορισμένους κανόνες ή καθιερώνοντας βασικές γραμμές συμπεριφοράς (behavioral

79
00:06:21,360 --> 00:06:26,480
baselines). Κάνοντας αυτό, το SIEM μπορεί να ανιχνεύσει ανωμαλίες

80
00:06:26,480 --> 00:06:30,560
που αποκλίνουν από την κανονική συμπεριφορά ενός συστήματος

81
00:06:30,560 --> 00:06:35,280
ή ενός χρήστη, όπως έναν ασυνήθιστα υψηλό αριθμό αποτυχημένων συνδέσεων σε σύντομο

82
00:06:35,280 --> 00:06:39,680
χρονικό διάστημα. Κατώφλια (Thresholds) και ευρετικοί κανόνες (heuristics) στη συνέχεια

83
00:06:39,760 --> 00:06:45,680
εφαρμόζονται για να καθοριστεί πότε αυτά τα μοτίβα πρέπει να ενεργοποιήσουν μια ειδοποίηση,

84
00:06:45,680 --> 00:06:50,880
βοηθώντας στη μείωση του θορύβου και εστιάζοντας την προσοχή σε γεγονότα που είναι πιο

85
00:06:50,880 --> 00:06:56,480
πιθανό να υποδεικνύουν ένα περιστατικό ασφαλείας. Τα SIEM προσφέρουν επίσης την ευελιξία

86
00:06:56,480 --> 00:07:01,360
να προσαρμόζονται οι κανόνες ειδοποίησης για συγκεκριμένες ανάγκες.

87
00:07:01,360 --> 00:07:06,800
Για παράδειγμα, μπορείτε να δημιουργήσετε κανόνες βασισμένους σε γνωστές υπογραφές επιθέσεων

88
00:07:06,800 --> 00:07:11,280
όπως συγκεκριμένα μοτίβα κίνησης δικτύου που σχετίζονται με malware

89
00:07:11,280 --> 00:07:15,280
ή σε ανωμαλίες συμπεριφοράς όπως ασυνήθιστοι χρόνοι σύνδεσης

90
00:07:15,280 --> 00:07:18,960
ή δραστηριότητα εκτός των κανονικών ωρών εργασίας.

91
00:07:18,960 --> 00:07:23,360
Επιπλέον, πολλές πλατφόρμες SIEM υποστηρίζουν custom rule scripting

92
00:07:23,360 --> 00:07:30,480
σε γλώσσες όπως Lucene, SPL, Search Processing Language η οποία είναι στο

93
00:07:30,480 --> 00:07:34,480
Splunk, Sigma ή

94
00:07:34,560 --> 00:07:39,040
Kibana Query Language (KQL) και άλλες, επιτρέποντας στις ομάδες ασφαλείας να προσαρμόσουν τις

95
00:07:39,040 --> 00:07:43,120
δυνατότητες ανίχνευσής τους στο συγκεκριμένο περιβάλλον τους.

96
00:07:43,120 --> 00:07:48,560
Ένα παράδειγμα του πώς η συσχέτιση (correlation) SIEM λειτουργεί στην πράξη θα μπορούσε να είναι όταν ένας χρήστης συνδέεται

97
00:07:48,560 --> 00:07:52,080
από δύο γεωγραφικά απομακρυσμένες τοποθεσίες όπως η Νέα Υόρκη

98
00:07:52,080 --> 00:07:55,840
και η Σιγκαπούρη μέσα σε λίγα λεπτά.

99
00:07:55,840 --> 00:08:00,960
Αυτό το γεγονός μπορεί να επισημανθεί από το σύστημα SIEM χρησιμοποιώντας έναν προσαρμοσμένο κανόνα ταχύτητας γεωεντοπισμού (geolocation

100
00:08:00,960 --> 00:08:05,360
velocity rule). Αυτός ο κανόνας συγκρίνει τα μοτίβα σύνδεσης του χρήστη

101
00:08:05,360 --> 00:08:10,880
με τις γνωστές γεωγραφικές τοποθεσίες και επισημαίνει μια ταχεία αλλαγή ως

102
00:08:10,880 --> 00:08:16,880
πιθανή ένδειξη παραβίασης διαπιστευτηρίων ή κατάληψης λογαριασμού (account takeover).

103
00:08:16,880 --> 00:08:20,880
Συσχετίζοντας αυτά τα γεγονότα, το σύστημα SIEM μπορεί να παρέχει στους αναλυτές

104
00:08:20,880 --> 00:08:26,240
ασφαλείας αξιοποιήσιμες ειδοποιήσεις που απαιτούν περαιτέρω διερεύνηση.

105
00:08:26,240 --> 00:08:32,240
Συνοπτικά, τα SIEM χρησιμοποιούν συσχέτιση δεδομένων για να συνδέσουν γεγονότα και να αποκαλύψουν πολύπλοκα

106
00:08:32,240 --> 00:08:36,720
μοτίβα επιθέσεων. Συνδυάζοντας προκαθορισμένους κανόνες, ανάλυση

107
00:08:36,720 --> 00:08:41,600
συμπεριφοράς και προσαρμόσιμες συνθήκες ειδοποίησης, τα συστήματα SIEM μπορούν να βοηθήσουν

108
00:08:41,600 --> 00:08:45,520
τους οργανισμούς να ανιχνεύουν και να ανταποκρίνονται σε περιστατικά ασφαλείας πιο

109
00:08:45,520 --> 00:08:49,200
αποτελεσματικά και αποδοτικά.

110
00:08:49,200 --> 00:08:53,360
Τα SIEM dashboards είναι απαραίτητα εργαλεία για τους αναλυτές ασφαλείας παρέχοντας

111
00:08:53,360 --> 00:08:57,360
οπτικοποίηση σε πραγματικό χρόνο των δραστηριοτήτων δικτύου και συστήματος.

112
00:08:57,360 --> 00:09:00,880
Αυτά τα dashboards βοηθούν τις ομάδες ασφαλείας να παρακολουθούν βασικούς δείκτες

113
00:09:00,880 --> 00:09:04,320
απόδοσης όπως αποτυχημένες απόπειρες σύνδεσης,

114
00:09:04,320 --> 00:09:09,760
αρνήσεις firewall και ανιχνεύσεις ιών. Εμφανίζοντας αυτές τις πληροφορίες σε ένα εύκολα

115
00:09:09,760 --> 00:09:13,520
κατανοητό format, τα SIEM dashboards επιτρέπουν

116
00:09:13,520 --> 00:09:16,560
στους αναλυτές να εντοπίζουν γρήγορα και να ενεργούν σε

117
00:09:16,560 --> 00:09:21,280
πιθανές απειλές ασφαλείας, μειώνοντας τον χρόνο που χρειάζεται για την απόκριση σε

118
00:09:21,280 --> 00:09:24,960
περιστατικά. Ένα από τα βασικά χαρακτηριστικά των SIEM dashboards

119
00:09:24,960 --> 00:09:28,880
είναι η ικανότητα να εμφανίζουν τον όγκο των συμβάντων,

120
00:09:28,880 --> 00:09:32,880
τα επίπεδα σοβαρότητας και τις ενεργές ειδοποιήσεις σε πραγματικό χρόνο.

121
00:09:32,880 --> 00:09:38,320
Αυτή η δυναμική προβολή βοηθά τους αναλυτές να παρακολουθούν τη ροή των δεδομένων ασφαλείας και

122
00:09:38,320 --> 00:09:42,880
να προτεραιοποιούν την απόκριση με βάση την κρισιμότητα κάθε συμβάντος.

123
00:09:42,880 --> 00:09:47,600
Για παράδειγμα, αν υπάρχει μια έξαρση στις αποτυχημένες απόπειρες σύνδεσης ή μια ξαφνική

124
00:09:47,600 --> 00:09:51,600
αιχμή σε ύποπτη δραστηριότητα δικτύου, θα είναι αμέσως

125
00:09:51,600 --> 00:09:55,520
ορατό στο dashboard, προτρέποντας περαιτέρω

126
00:09:55,520 --> 00:09:59,600
διερεύνηση. Επιπλέον, πολλά SIEM

127
00:09:59,600 --> 00:10:03,520
dashboards περιλαμβάνουν drill-down προβολές.

128
00:10:03,520 --> 00:10:09,600
Αυτό επιτρέπει στους αναλυτές να κάνουν κλικ σε συγκεκριμένες ανωμαλίες ή ειδοποιήσεις και να εξετάσουν

129
00:10:09,600 --> 00:10:13,600
τις λεπτομέρειες όπως την πηγή της δραστηριότητας,

130
00:10:13,600 --> 00:10:17,280
τον συσχετιζόμενο χρήστη ή συσκευή και άλλες πληροφορίες

131
00:10:17,280 --> 00:10:21,520
πλαισίου. Αυτή η δυνατότητα επιταχύνει τη διαδικασία

132
00:10:21,520 --> 00:10:26,240
διερεύνησης, επιτρέποντας στους αναλυτές να παίρνουν ενημερωμένες αποφάσεις γρήγορα.

133
00:10:26,240 --> 00:10:30,000
Τα συστήματα SIEM παρέχουν επίσης δυνατότητες αναφοράς (reporting),

134
00:10:30,000 --> 00:10:34,960
προσφέροντας προκατασκευασμένα πρότυπα που μπορούν να προσαρμοστούν για να καλύψουν οργανωτικές

135
00:10:34,960 --> 00:10:41,040
ανάγκες ή κανονιστικές απαιτήσεις. Αυτές οι αναφορές βοηθούν στη διασφάλιση συμμόρφωσης με

136
00:10:41,040 --> 00:10:47,200
πρότυπα όπως PCI DSS ή GDPR και χρησιμοποιούνται συχνά για ελέγχους (audits)

137
00:10:47,200 --> 00:10:52,800
ή περιλήψεις για στελέχη. Η ικανότητα προγραμματισμού αυτών των αναφορών διασφαλίζει ότι

138
00:10:52,800 --> 00:10:58,000
οι ενδιαφερόμενοι μένουν ενημερωμένοι για τη στάση ασφαλείας και ότι η συμμόρφωση

139
00:10:58,000 --> 00:11:03,920
παρακολουθείται συνεχώς. Για παράδειγμα, ένα Security Operation Center,

140
00:11:03,920 --> 00:11:08,720
μια ομάδα SOC, μπορεί να χρησιμοποιήσει το dashboard του SIEM για να παρακολουθεί απόπειρες

141
00:11:08,720 --> 00:11:14,000
σύνδεσης SSH σε production servers. Αν συμβούν περισσότερες από 10 αποτυχημένες απόπειρες σύνδεσης

142
00:11:14,000 --> 00:11:18,800
μέσα σε πέντε λεπτά σε οποιονδήποτε server, το σύστημα μπορεί να ενεργοποιήσει μια ειδοποίηση.

143
00:11:18,800 --> 00:11:22,720
Αυτό επιτρέπει στις ομάδες SOC να διερευνήσουν πιθανές απόπειρες επίθεσης brute force,

144
00:11:22,720 --> 00:11:26,080
αναλαμβάνοντας γρήγορα δράση για να αποτρέψουν μια

145
00:11:26,080 --> 00:11:30,880
επιτυχημένη εισβολή. Συνοπτικά, τα SIEM dashboards είναι πολύ κρίσιμα

146
00:11:30,880 --> 00:11:34,720
για την παροχή ορατότητας σε πραγματικό χρόνο στα συμβάντα ασφαλείας

147
00:11:34,720 --> 00:11:39,680
και την απλοποίηση της διαδικασίας διερεύνησης. Συνδυάζοντας λειτουργίες

148
00:11:39,680 --> 00:11:45,120
ζωντανής παρακολούθησης, ανάλυση drill-down και αυτοματοποιημένη αναφορά, τα SIEM ενδυναμώνουν

149
00:11:45,120 --> 00:11:50,080
τις ομάδες ασφαλείας να ανταποκρίνονται ταχύτερα και να διατηρούν τη συμμόρφωση εντός των

150
00:11:50,080 --> 00:11:54,560
οργανωτικών και κανονιστικών προτύπων.

151
00:11:54,560 --> 00:11:58,640
Έτσι, όπως μπορούμε να δούμε, μία από τις βασικές δυνατότητες του SIEM

152
00:11:58,640 --> 00:12:03,440
είναι η ανίχνευση ασυνήθιστης συμπεριφοράς. Για παράδειγμα, αν ένας χρήστης συνδεθεί

153
00:12:03,440 --> 00:12:09,920
σε παράξενες ώρες, όπως στις 3 το πρωί, ή από μια άγνωστη

154
00:12:09,920 --> 00:12:14,000
γεωγραφική τοποθεσία, το SIEM μπορεί να επισημάνει αυτή τη δραστηριότητα ως ύποπτη.

155
00:12:14,000 --> 00:12:19,360
Είναι σαν το User Behavior Analytics (UBA). Αυτές οι ανωμαλίες μπορεί να είναι ενδεικτικές

156
00:12:19,360 --> 00:12:24,080
παραβιασμένων διαπιστευτηρίων ή αποπειρών μη εξουσιοδοτημένης πρόσβασης.

157
00:12:24,080 --> 00:12:28,800
Ένα άλλο ισχυρό χαρακτηριστικό είναι η ικανότητα συσχέτισης πολλαπλών γεγονότων σε μία

158
00:12:28,880 --> 00:12:35,360
ενιαία ενοποιημένη ειδοποίηση. Για παράδειγμα, ένα SIEM μπορεί να ανιχνεύσει μια σειρά από

159
00:12:35,360 --> 00:12:40,400
αποτυχημένες απόπειρες σύνδεσης, ακολουθούμενες από μια επιτυχημένη σύνδεση και επακόλουθη

160
00:12:40,400 --> 00:12:45,280
κλιμάκωση προνομίων (privilege escalation). Όταν αυτά τα γεγονότα συμβαίνουν σε κοντινή διαδοχή,

161
00:12:45,280 --> 00:12:49,760
το SIEM τα συνδέει μαζί, ενεργοποιώντας μια ειδοποίηση που βοηθά τις ομάδες ασφαλείας

162
00:12:49,760 --> 00:12:53,760
να εντοπίσουν πιθανές επιθέσεις όπως απόπειρες σύνδεσης brute force

163
00:12:53,840 --> 00:12:58,800
ή πλευρική μετακίνηση εντός του δικτύου. Επιπλέον, τα SIEM μπορούν να

164
00:12:58,800 --> 00:13:03,680
ενσωματωθούν με ροές πληροφοριών απειλών (threat intelligence feeds), για να ταιριάξουν δραστηριότητα με

165
00:13:03,680 --> 00:13:08,240
γνωστούς indicators of compromise (δείκτες παραβίασης), όπως διευθύνσεις IP,

166
00:13:08,240 --> 00:13:11,680
hashes αρχείων ή ονόματα τομέα που σχετίζονται με

167
00:13:11,680 --> 00:13:16,560
κακόβουλη συμπεριφορά. Αυτό τους επιτρέπει να επισημαίνουν κίνηση

168
00:13:16,560 --> 00:13:19,920
ή ενέργειες που ευθυγραμμίζονται με γνωστά μοτίβα επιθέσεων,

169
00:13:19,920 --> 00:13:24,960
προσθέτοντας ένα άλλο επίπεδο πλαισίου και ακρίβειας στη διαδικασία ανίχνευσης.

170
00:13:24,960 --> 00:13:29,040
Τα SIEM μπορούν επίσης να εξάγουν threat intelligence και

171
00:13:29,040 --> 00:13:34,080
indicators of compromise προκειμένου να βοηθήσουν άλλα SIEM να ανταποκριθούν

172
00:13:34,080 --> 00:13:40,000
σε τέτοιες δραστηριότητες. Ας δούμε, για παράδειγμα, φανταστείτε ένα SIEM που ανιχνεύει μια

173
00:13:40,000 --> 00:13:43,040
σύνδεση λογαριασμού χρήστη στις 3 το πρωί

174
00:13:43,040 --> 00:13:47,040
από μια ξένη διεύθυνση IP. Αν ο χρήστης στη συνέχεια προσπελάσει

175
00:13:47,040 --> 00:13:50,640
ευαίσθητα αρχεία, το σύστημα μπορεί να ενεργοποιήσει μια ειδοποίηση βάσει

176
00:13:50,640 --> 00:13:54,400
προρυθμισμένων κανόνων συσχέτισης που συνδέουν την

177
00:13:54,400 --> 00:14:00,000
ασυνήθιστη συμπεριφορά σύνδεσης με την επακόλουθη πρόσβαση σε ευαίσθητα δεδομένα.

178
00:14:00,000 --> 00:14:04,480
Οπότε είναι σαν ένα kill chain. Αυτό θα εντοπιστεί από το SIEM.

179
00:14:04,480 --> 00:14:09,040
Αυτή η πρώιμη ανίχνευση βοηθά τις ομάδες ασφαλείας να ανταποκριθούν άμεσα,

180
00:14:09,040 --> 00:14:13,120
ελαχιστοποιώντας τον κίνδυνο παραβίασης δεδομένων.

181
00:14:13,120 --> 00:14:16,560
Τα σύγχρονα SIEM έχουν προηγμένες δυνατότητες που πηγαίνουν πέρα από

182
00:14:16,560 --> 00:14:20,960
την απλή ανίχνευση απειλών. Μπορούν επίσης να ενεργοποιήσουν προκαθορισμένες ενέργειες

183
00:14:20,960 --> 00:14:26,640
ως απόκριση σε συγκεκριμένες ειδοποιήσεις, το οποίο μειώνει σημαντικά την ανάγκη για

184
00:14:26,640 --> 00:14:30,160
χειροκίνητη παρέμβαση και επιταχύνει τη διαδικασία

185
00:14:30,160 --> 00:14:34,080
περιορισμού του περιστατικού. Αυτός ο αυτοματισμός επιτρέπει στις ομάδες

186
00:14:34,080 --> 00:14:38,320
ασφαλείας να ανταποκρίνονται σε πιθανές απειλές γρηγορότερα και πιο αποδοτικά,

187
00:14:38,320 --> 00:14:43,840
ελαχιστοποιώντας τον αντίκτυπο των παραβιάσεων ασφαλείας. Για παράδειγμα, ένα SIEM μπορεί αυτόματα

188
00:14:43,920 --> 00:14:48,720
να μπλοκάρει διευθύνσεις IP, φυσικά, στέλνοντας έναν κανόνα firewall στο συγκεκριμένο

189
00:14:48,720 --> 00:14:52,320
firewall που εμπλέκονται σε κακόβουλες δραστηριότητες,

190
00:14:52,320 --> 00:14:57,680
όπως όταν βρίσκονται σε μια απόπειρα σύνδεσης brute force ή επιθέσεις DDoS.

191
00:14:57,680 --> 00:15:02,240
Όταν ανιχνεύθηκαν πολλαπλές αποτυχημένες απόπειρες σύνδεσης, το SIEM μπορεί να ενεργοποιήσει μια

192
00:15:02,240 --> 00:15:05,440
ενέργεια για να μπλοκάρει την ύποπτη διεύθυνση IP,

193
00:15:05,440 --> 00:15:10,320
αποτρέποντας περαιτέρω απόπειρες μη εξουσιοδοτημένης πρόσβασης.

194
00:15:10,320 --> 00:15:15,840
Μια άλλη ενέργεια που λαμβάνουν τα SIEM είναι η αυτόματη απενεργοποίηση παραβιασμένων λογαριασμών.

195
00:15:15,840 --> 00:15:21,120
Εάν το σύστημα ανιχνεύσει ασυνήθιστη συμπεριφορά σύνδεσης, όπως συνδέσεις από

196
00:15:21,120 --> 00:15:26,880
άλλες τοποθεσίες ή περίεργες ώρες, μπορεί άμεσα να απενεργοποιήσει

197
00:15:26,880 --> 00:15:31,760
τον επηρεαζόμενο λογαριασμό για να αποτρέψει οποιαδήποτε πιθανή παραβίαση δεδομένων ή κλιμάκωση.

198
00:15:31,760 --> 00:15:37,280
Έτσι μπορεί να ενσωματωθεί το SIEM με firewalls ή ελέγχους πρόσβασης ταυτότητας

199
00:15:37,280 --> 00:15:41,680
προκειμένου να ανακαλέσει δικαιώματα και στην πραγματικότητα να ανταποκριθεί στην

200
00:15:41,680 --> 00:15:47,920
ειδοποίηση. Επιπλέον, τα SIEM μπορούν να στέλνουν ειδοποιήσεις σε πραγματικό χρόνο στις ομάδες

201
00:15:47,920 --> 00:15:52,000
ασφαλείας μέσω διαφόρων καναλιών όπως email, Slack,

202
00:15:52,000 --> 00:15:55,600
ή ενσωμάτωση με εργαλεία Security Orchestration, Automation

203
00:15:55,600 --> 00:16:01,680
and Response, όπως τα αποκαλούμε SOAR. Αυτό διασφαλίζει ότι οι κατάλληλοι άνθρωποι

204
00:16:01,680 --> 00:16:07,040
ειδοποιούνται άμεσα, επιτρέποντάς τους να αναλάβουν ταχεία δράση.

205
00:16:07,040 --> 00:16:11,680
Ας δώσουμε ένα παράδειγμα. Φανταστείτε ότι ένα SIEM ανιχνεύει πολλαπλές αποτυχημένες απόπειρες

206
00:16:11,680 --> 00:16:15,280
σύνδεσης SSH, ακολουθούμενες από μια επιτυχημένη σύνδεση από μια

207
00:16:15,280 --> 00:16:18,960
άγνωστη πηγή. Με τον εντοπισμό αυτού του μοτίβου, το SIEM

208
00:16:18,960 --> 00:16:23,440
θα μπορούσε αυτόματα να μπλοκάρει την ύποπτη διεύθυνση IP

209
00:16:23,440 --> 00:16:27,440
μέσω του firewall για να αποτρέψει περαιτέρω απόπειρες πρόσβασης.

210
00:16:27,440 --> 00:16:32,400
Ταυτόχρονα, θα μπορούσε να στείλει μια ειδοποίηση email στο Security Operation

211
00:16:32,400 --> 00:16:36,720
Center, στην ομάδα SOC, με τις λεπτομέρειες του περιστατικού για περαιτέρω

212
00:16:36,720 --> 00:16:41,920
διερεύνηση. Ας δούμε ένα συγκεκριμένο εργαλείο, το Splunk.

213
00:16:41,920 --> 00:16:46,640
Το Splunk είναι μια εμπορική λύση SIEM γνωστή για την κλιμακωσιμότητά της (scalability),

214
00:16:46,640 --> 00:16:50,960
την πλούσια οπτικοποίηση και τις ισχυρές δυνατότητες αναζήτησης.

215
00:16:50,960 --> 00:16:56,400
Εισάγει (ingests) logs και δεδομένα μηχανής από μια μεγάλη ποικιλία πηγών, επιτρέποντας

216
00:16:56,400 --> 00:17:01,760
παρακολούθηση σε πραγματικό χρόνο, ανίχνευση απειλών και αναφορά συμμόρφωσης.

217
00:17:01,760 --> 00:17:06,400
Ένα από τα βασικά χαρακτηριστικά του Splunk είναι η Search Processing Language,

218
00:17:06,400 --> 00:17:11,200
επίσης όπως την αποκαλούμε SPL. Η SPL είναι μια domain-specific

219
00:17:11,200 --> 00:17:16,480
γλώσσα ερωτημάτων που επιτρέπει πολύπλοκες αναζητήσεις, στατιστική ανάλυση και τη

220
00:17:16,480 --> 00:17:22,800
δημιουργία οπτικών dashboards. Οι αναλυτές χρησιμοποιούν SPL από το Splunk

221
00:17:22,800 --> 00:17:27,680
για να βουτήξουν στα δεδομένα και να εντοπίσουν πιθανές απειλές.

222
00:17:27,680 --> 00:17:31,120
Παρέχει μια εξαιρετικά προσαρμόσιμη εμπειρία αναζήτησης,

223
00:17:31,120 --> 00:17:35,600
βοηθώντας τους αναλυτές να εντοπίζουν απειλές και ακραίες τιμές (outliers)

224
00:17:35,600 --> 00:17:39,200
σε μεγάλα σύνολα δεδομένων, όπως επαναλαμβανόμενες αποτυχημένες απόπειρες σύνδεσης

225
00:17:39,200 --> 00:17:44,480
ή ασυνήθιστα μοτίβα κίνησης δικτύου. Ένα άλλο ισχυρό εργαλείο στο Splunk είναι το

226
00:17:44,480 --> 00:17:49,440
Machine Learning Toolkit, το οποίο επιτρέπει στους χρήστες να χτίζουν προγνωστικά μοντέλα

227
00:17:49,440 --> 00:17:53,520
για ανίχνευση ανωμαλιών και User Behavior Analytics,

228
00:17:53,520 --> 00:17:59,600
UEBA. Αυτό το toolkit βοηθά στην ανίχνευση άγνωστων απειλών εντοπίζοντας

229
00:17:59,600 --> 00:18:04,720
ασυνήθιστα μοτίβα στα δεδομένα, τα οποία μπορεί να μην επισημαίνονται από παραδοσιακές

230
00:18:04,720 --> 00:18:10,480
μεθόδους ανίχνευσης βάσει κανόνων. Επιτρέπει στο Splunk να πηγαίνει πέρα από τις βασικές αναζητήσεις

231
00:18:10,480 --> 00:18:15,600
και να παρέχει γνώσεις για τη μελλοντική συμπεριφορά, βοηθώντας τους αναλυτές

232
00:18:15,600 --> 00:18:20,640
να ανιχνεύουν προηγμένες απειλές όπως insider threats ή επιθέσεις zero-day.

233
00:18:20,720 --> 00:18:25,520
Το Enterprise Security module του Splunk προσθέτει ένα επιπλέον επίπεδο

234
00:18:25,520 --> 00:18:28,960
λειτουργικότητας προσαρμοσμένο στις επιχειρήσεις ασφαλείας.

235
00:18:28,960 --> 00:18:34,400
Περιλαμβάνει dashboards ειδικά για ασφάλεια, ενσωμάτωση threat intelligence

236
00:18:34,400 --> 00:18:40,000
και χαρακτηριστικά επισκόπησης περιστατικών. Αυτό το module απλοποιεί την ανίχνευση και

237
00:18:40,000 --> 00:18:44,720
διαχείριση περιστατικών ασφαλείας προσφέροντας εξειδικευμένα εργαλεία για threat

238
00:18:44,720 --> 00:18:50,160
hunting και incident response, καθιστώντας ευκολότερο για τους αναλυτές

239
00:18:50,240 --> 00:18:55,840
να διερευνούν και να μετριάζουν πιθανές απειλές σε όλη την υποδομή.

240
00:18:55,840 --> 00:18:59,840
Για παράδειγμα, ένας αναλυτής ασφαλείας μπορεί να χρησιμοποιήσει SPL

241
00:18:59,840 --> 00:19:05,280
για να ψάξει για αποτυχημένες απόπειρες σύνδεσης σε διάφορα συστήματα στο δίκτυο.

242
00:19:05,280 --> 00:19:09,440
Το ερώτημα θα μπορούσε να είναι κάτι σαν index equals

243
00:19:09,440 --> 00:19:15,440
auth sourcetype equals linux_secure action equals failed

244
00:19:15,440 --> 00:19:19,600
και μετά stats count by user and source.

245
00:19:19,600 --> 00:19:24,080
Αυτό επιτρέπει στον αναλυτή να εντοπίσει γρήγορα μη φυσιολογική συμπεριφορά όπως έναν μεγάλο

246
00:19:24,080 --> 00:19:28,720
αριθμό αποτυχημένων συνδέσεων από έναν μόνο χρήστη ή διεύθυνση IP,

247
00:19:28,720 --> 00:19:33,520
που θα μπορούσε να υποδεικνύει μια επίθεση brute force. Χρησιμοποιώντας SPL, ο αναλυτής μπορεί

248
00:19:33,520 --> 00:19:36,560
άμεσα να λάβει ενέργειες όπως κλείδωμα λογαριασμών ή

249
00:19:36,560 --> 00:19:41,040
μπλοκάρισμα κακόβουλων διευθύνσεων IP για να αποτρέψει περαιτέρω κλιμάκωση

250
00:19:41,040 --> 00:19:45,760
της απειλής. Ο συνδυασμός του Splunk με προηγμένα queries, machine

251
00:19:45,760 --> 00:19:49,760
learning και προσαρμοσμένα modules ασφαλείας το καθιστά ένα

252
00:19:49,760 --> 00:19:53,360
απαραίτητο εργαλείο για επιχειρήσεις ασφαλείας μεγάλης κλίμακας.

253
00:19:53,360 --> 00:19:57,120
Επιτρέπει στους οργανισμούς να ανιχνεύουν και να ανταποκρίνονται σε απειλές

254
00:19:57,120 --> 00:20:00,640
γρηγορότερα, παρέχοντας ορατότητα και αξιοποιήσιμες

255
00:20:00,640 --> 00:20:05,360
γνώσεις για τη στάση ασφαλείας του δικτύου.

256
00:20:05,360 --> 00:20:10,720
Ένα άλλο εργαλείο, ένα SIEM, είναι το ELK Stack, που βασίζεται σε Elasticsearch,

257
00:20:10,720 --> 00:20:16,000
Logstash και Kibana. Αυτή είναι μια open-source εναλλακτική που έχει κερδίσει

258
00:20:16,000 --> 00:20:19,920
σημαντική απήχηση στις εγκαταστάσεις SIEM τελευταία.

259
00:20:19,920 --> 00:20:24,240
Ενώ απαιτεί περισσότερη ρύθμιση και διαμόρφωση σε σύγκριση με εμπορικές

260
00:20:24,240 --> 00:20:27,520
λύσεις όπως το Splunk, παρέχει στους οργανισμούς

261
00:20:27,520 --> 00:20:33,280
ευελιξία και έλεγχο κόστους. Αυτό το καθιστά ιδιαίτερα

262
00:20:33,280 --> 00:20:38,560
ελκυστικό για επιχειρήσεις με in-house ομάδες DevOps ή SecOps.

263
00:20:38,560 --> 00:20:43,600
Το ELK Stack προσφέρει ισχυρές δυνατότητες για συγκέντρωση logs, ανάλυση και

264
00:20:43,600 --> 00:20:47,280
οπτικοποίηση, που είναι κλειδί για τη διατήρηση αποτελεσματικής

265
00:20:47,280 --> 00:20:52,320
παρακολούθησης ασφαλείας. Στην καρδιά του ELK Stack είναι το Elasticsearch,

266
00:20:52,320 --> 00:20:57,840
μια γρήγορη και κατανεμημένη μηχανή αναζήτησης σχεδιασμένη να ευρετηριάζει (index) και να αναζητά τεράστιες

267
00:20:57,840 --> 00:21:02,960
ποσότητες δεδομένων log. Επιτρέπει περισσότερα real-time queries,

268
00:21:02,960 --> 00:21:09,120
καθιστώντας το ιδανικό για γρήγορη ανάκτηση και ανάλυση δεδομένων log.

269
00:21:09,120 --> 00:21:15,120
Το Elasticsearch διαπρέπει στον χειρισμό μεγάλων συνόλων δεδομένων, διασφαλίζοντας ταχείες

270
00:21:15,120 --> 00:21:18,880
χρόνους απόκρισης ακόμα και όταν ασχολείται με πολύπλοκες αναζητήσεις.

271
00:21:18,880 --> 00:21:22,880
Αυτό διασφαλίζει ότι οι ομάδες ασφαλείας μπορούν να υποβάλουν ερωτήματα στα δεδομένα αποδοτικά

272
00:21:22,880 --> 00:21:27,040
και να εντοπίσουν μοτίβα ή ανωμαλίες εγκαίρως.

273
00:21:27,040 --> 00:21:30,800
Στη συνέχεια, το Logstash χειρίζεται την εισαγωγή δεδομένων (data ingestion)

274
00:21:30,800 --> 00:21:38,320
και τον μετασχηματισμό. Τραβάει log από δεδομένα, τα δεδομένα log από διάφορους πόρους,

275
00:21:38,320 --> 00:21:43,440
τα αναλύει (parses) και μετά στέλνει τα επεξεργασμένα δεδομένα στο Elasticsearch.

276
00:21:43,440 --> 00:21:48,560
Ο ρόλος του Logstash είναι κρίσιμος επειδή τα logs συχνά παράγονται σε διαφορετικά

277
00:21:48,560 --> 00:21:54,320
formats σε πολλαπλά συστήματα. Διασφαλίζει ότι τα δεδομένα τυποποιούνται,

278
00:21:54,320 --> 00:21:59,440
αναλύονται σωστά και στη συνέχεια εμπλουτίζονται με πρόσθετο πλαίσιο όπου είναι απαραίτητο,

279
00:21:59,440 --> 00:22:05,680
καθιστώντας τα έτοιμα για ανάλυση. Χωρίς αυτό το βήμα τα logs θα ήταν δύσκολο να δουλευτούν

280
00:22:05,680 --> 00:22:10,560
και θα εμπόδιζαν οποιαδήποτε ουσιαστική διερεύνηση.

281
00:22:10,560 --> 00:22:15,440
Τέλος, το Kibana χρησιμεύει ως το επίπεδο οπτικοποίησης του ELK Stack.

282
00:22:15,440 --> 00:22:21,920
Επιτρέπει στους χρήστες να δημιουργούν διαδραστικά dashboards και να τρέχουν queries χρησιμοποιώντας

283
00:22:21,920 --> 00:22:28,000
σύνταξη βασισμένη σε Lucene. Υποστηρίζουν Kibana Query Language (KQL), Elastic Query

284
00:22:28,000 --> 00:22:34,080
Language και ούτω καθεξής. Το Kibana επιτρέπει στους αναλυτές ασφαλείας να οπτικοποιούν

285
00:22:34,080 --> 00:22:37,520
τάσεις δεδομένων, να εντοπίζουν πιθανές απειλές και να παρακολουθούν

286
00:22:37,520 --> 00:22:43,520
βασικές μετρήσεις σε πραγματικό χρόνο. Μέσω προσαρμόσιμων dashboards, οι χρήστες μπορούν

287
00:22:43,520 --> 00:22:48,160
εύκολα να παρακολουθούν ανωμαλίες, να δημιουργούν αναφορές και να ανταποκρίνονται σε αναδυόμενα

288
00:22:48,160 --> 00:22:53,120
γεγονότα ασφαλείας με μια καθαρή οπτική επισκόπηση που παρέχει το Kibana.

289
00:22:53,120 --> 00:22:57,280
Για παράδειγμα, κατά την παρακολούθηση για επιθέσεις brute force SSH,

290
00:22:57,280 --> 00:23:01,440
το Logstash μπορεί να ρυθμιστεί ώστε να αναλύει (parse) τα logs SSH

291
00:23:01,440 --> 00:23:07,920
από τον φάκελο /var/log/auth.log όπου οι απόπειρες σύνδεσης καταγράφονται σε ένα Linux

292
00:23:07,920 --> 00:23:11,760
σύστημα. Αυτά τα logs επεξεργάζονται και ευρετηριάζονται από το

293
00:23:11,760 --> 00:23:17,840
Elasticsearch, μια βάση δεδομένων NoSQL, καθιστώντας εύκολη την αναζήτηση και το ερώτημα.

294
00:23:17,840 --> 00:23:22,800
Το Kibana μπορεί στη συνέχεια να οπτικοποιήσει τις αποτυχημένες απόπειρες σύνδεσης με την πάροδο του χρόνου.

295
00:23:22,800 --> 00:23:26,880
Εμφανίζοντας τάσεις και χαρτογραφώντας τις πηγές IPs.

296
00:23:26,880 --> 00:23:32,320
Αυτή η ρύθμιση επιτρέπει στις ομάδες ασφαλείας να εντοπίζουν γρήγορα μη φυσιολογικά μοτίβα,

297
00:23:32,320 --> 00:23:36,720
όπως πολλαπλές αποτυχημένες απόπειρες από μια ενιαία IP, που μπορεί να σηματοδοτούν

298
00:23:36,720 --> 00:23:39,680
μια επίθεση brute force.

299
00:23:40,000 --> 00:23:44,800
Κατά τη σύγκριση του Splunk και του ELK Stack, υπάρχουν αρκετές βασικές διαφορές σε

300
00:23:44,800 --> 00:23:49,120
όρους χαρακτηριστικών, αδειοδότησης και κλιμακωσιμότητας.

301
00:23:49,120 --> 00:23:52,320
Η κατανόηση αυτών των διαφορών μπορεί να βοηθήσει τους οργανισμούς

302
00:23:52,320 --> 00:23:56,160
να επιλέξουν τη σωστή λύση για τις ανάγκες τους σε παρακολούθηση ασφαλείας και διαχείριση logs.

303
00:23:56,160 --> 00:23:59,280
Η αδειοδότηση είναι μία από τις πιο

304
00:23:59,280 --> 00:24:04,720
σημαντικές αντιθέσεις μεταξύ των δύο. Το Splunk λειτουργεί με ένα εμπορικό

305
00:24:04,720 --> 00:24:09,600
κλιμακωτό μοντέλο τιμολόγησης, που σημαίνει ότι ο οργανισμός πρέπει να πληρώσει με βάση την

306
00:24:09,600 --> 00:24:14,160
ποσότητα των δεδομένων που εισάγονται. Ενώ αυτό το μοντέλο προσφέρει ισχυρή εταιρική

307
00:24:14,160 --> 00:24:19,280
υποστήριξη, μπορεί να γίνει πολύ δαπανηρό καθώς ο όγκος δεδομένων αυξάνεται.

308
00:24:19,360 --> 00:24:24,640
Από την άλλη πλευρά, το ELK Stack είναι open source, που σημαίνει ότι είναι δωρεάν για χρήση.

309
00:24:24,640 --> 00:24:28,160
Ωστόσο, οι οργανισμοί που απαιτούν πρόσθετη υποστήριξη,

310
00:24:28,160 --> 00:24:31,040
η Elastic, η εταιρεία πίσω από το ELK Stack,

311
00:24:31,040 --> 00:24:34,800
προσφέρει επιλογές πληρωμένης υποστήριξης, παρέχοντας την ευελιξία

312
00:24:34,800 --> 00:24:38,960
να κλιμακωθεί όπως χρειάζεται χωρίς μια σημαντική αρχική

313
00:24:38,960 --> 00:24:45,120
επένδυση σε αδειοδότηση. Σε όρους γλώσσας ερωτημάτων (query language), το Splunk χρησιμοποιεί τη δική του

314
00:24:45,120 --> 00:24:51,680
ιδιόκτητη Search Processing Language, SPL. Η SPL είναι εξαιρετικά

315
00:24:51,680 --> 00:24:56,240
ευέλικτη και ισχυρή, επιτρέποντας στους χρήστες να εκτελούν πολύπλοκες αναζητήσεις,

316
00:24:56,240 --> 00:25:00,240
στατιστική ανάλυση, και ακόμη να δημιουργούν προσαρμοσμένα dashboards.

317
00:25:00,240 --> 00:25:05,760
Ενώ η SPL προσφέρει προηγμένες δυνατότητες, μπορεί επίσης να έχει μια πιο απότομη

318
00:25:05,760 --> 00:25:08,960
καμπύλη εκμάθησης για χρήστες που δεν είναι εξοικειωμένοι με αυτά τα μπλοκ

319
00:25:08,960 --> 00:25:12,160
απόφασης. Το ELK Stack, σε αντίθεση, χρησιμοποιεί

320
00:25:12,160 --> 00:25:17,120
Lucene και Kibana Query Language, και οι δύο εκ των οποίων είναι πιο τυποποιημένες

321
00:25:17,120 --> 00:25:22,080
και ευκολότερες στην εκμάθηση, αλλά λιγότερο προηγμένες σε σύγκριση με την SPL.

322
00:25:22,080 --> 00:25:25,360
Για εκείνους που είναι ήδη εξοικειωμένοι με SQL, όπως

323
00:25:25,360 --> 00:25:30,560
γλώσσα ερωτημάτων, η Kibana Query Language προσφέρει ένα πιο προσβάσιμο σημείο εισόδου.

324
00:25:30,560 --> 00:25:35,200
Έχει αίσθηση παρόμοια με την SQL, αλλά μπορεί να υποστηρίζει,

325
00:25:35,200 --> 00:25:40,640
ή να μην υποστηρίζει, το επίπεδο των πολύπλοκων ερωτημάτων που κάνει η SPL.

326
00:25:40,640 --> 00:25:46,000
Όσον αφορά την πολυπλοκότητα ρύθμισης, το Splunk είναι γνωστό ότι είναι εύκολο στην ανάπτυξη,

327
00:25:46,000 --> 00:25:50,320
ειδικά με τις επιλογές υποστήριξης enterprise.

328
00:25:50,320 --> 00:25:53,680
Αυτό το καθιστά ιδανικό για οργανισμούς που χρειάζονται μια γρήγορη

329
00:25:53,680 --> 00:25:58,160
έτοιμη λύση (out-of-the-box) με ελάχιστη διαμόρφωση.

330
00:25:58,160 --> 00:26:04,080
Το ELK Stack, ωστόσο, απαιτεί περισσότερη χειροκίνητη διαμόρφωση και συντονισμό.

331
00:26:04,080 --> 00:26:08,480
Μπορεί να ρυθμιστεί για να καλύψει συγκεκριμένες απαιτήσεις, αλλά αυτό σημαίνει επίσης περισσότερη

332
00:26:08,480 --> 00:26:12,640
προσπάθεια για την ανάπτυξη, ειδικά όταν κλιμακώνεται

333
00:26:12,640 --> 00:26:18,160
σε πολλαπλά περιβάλλοντα. Οι δυνατότητες ενσωμάτωσης επίσης διαφέρουν μεταξύ των δύο

334
00:26:18,160 --> 00:26:22,480
λύσεων. Το Splunk προσφέρει εκτεταμένες ενσωματωμένες

335
00:26:22,480 --> 00:26:27,920
ενσωματώσεις και add-ons, καθιστώντας το ευκολότερο να ενσωματωθεί σε ένα υπάρχον

336
00:26:27,920 --> 00:26:31,440
περιβάλλον. Αυτές οι προκατασκευασμένες ενσωματώσεις με

337
00:26:31,440 --> 00:26:36,800
δημοφιλή συστήματα και εργαλεία βοηθούν στην απλοποίηση των διαδικασιών ανάπτυξης.

338
00:26:36,800 --> 00:26:40,000
Εν τω μεταξύ, το ELK Stack είναι εξαιρετικά επεκτάσιμο,

339
00:26:40,000 --> 00:26:44,320
προσφέροντας την ευελιξία να ενσωματωθεί με πολλά συστήματα μέσω plugins

340
00:26:44,320 --> 00:26:49,200
και Beats, ελαφρών αποστολέων δεδομένων. Οι agents στο ELK

341
00:26:49,200 --> 00:26:55,280
ονομάζονται Beats. Αυτή η επεκτασιμότητα επιτρέπει στο ELK Stack να

342
00:26:55,280 --> 00:27:00,240
προσαρμόζεται και να ράβεται στα μέτρα για συγκεκριμένες περιπτώσεις χρήσης.

343
00:27:00,240 --> 00:27:04,080
Ωστόσο, μπορεί να απαιτεί πρόσθετες διαμορφώσεις

344
00:27:04,080 --> 00:27:07,520
για να διασφαλιστεί η απρόσκοπτη ενσωμάτωση με τα συστήματα.

345
00:27:07,520 --> 00:27:12,400
Τέλος, η κλιμακωσιμότητα (scalability) είναι ένας τομέας όπου και οι δύο λύσεις διαφέρουν.

346
00:27:12,400 --> 00:27:17,360
Το Splunk είναι cloud-native, προσφέροντας δυνατότητες κλιμάκωσης που διαχειρίζονται από το

347
00:27:17,360 --> 00:27:21,600
ίδιο το Splunk cloud. Αυτό καθιστά ευκολότερο για τους οργανισμούς

348
00:27:21,600 --> 00:27:27,440
να κλιμακώνονται καθώς χρειάζεται χωρίς το βάρος της διαχείρισης της υποδομής.

349
00:27:27,440 --> 00:27:32,560
Από την άλλη πλευρά, το ELK Stack απαιτεί περισσότερη χειροκίνητη διαχείριση cluster για

350
00:27:32,640 --> 00:27:36,640
κλιμάκωση. Ενώ μπορεί να κλιμακωθεί για να χειριστεί μεγάλα σύνολα δεδομένων,

351
00:27:36,640 --> 00:27:41,920
αυτή η διαδικασία απαιτεί περισσότερη πρακτική προσπάθεια, συμπεριλαμβανομένης της διαχείρισης

352
00:27:41,920 --> 00:27:47,680
κόμβων (nodes), χειρισμό κατανομής δεδομένων, και διασφάλιση υψηλής διαθεσιμότητας του

353
00:27:47,680 --> 00:27:53,200
ίδιου του συστήματος. Το Graylog είναι μια open-source πλατφόρμα

354
00:27:53,200 --> 00:27:57,920
διαχείρισης logs που χρησιμοποιείται συνήθως για μεσαίου μεγέθους εγκαταστάσεις SIEM.

355
00:27:57,920 --> 00:28:02,000
Είναι χτισμένο πάνω σε Elasticsearch και MongoDB,

356
00:28:02,080 --> 00:28:06,240
προσφέροντας μια φιλική προς το χρήστη, ευέλικτη και επεκτάσιμη λύση

357
00:28:06,240 --> 00:28:11,360
για διαχείριση και ανάλυση logs. Γνωστό για την απλότητά του, το Graylog είναι

358
00:28:11,360 --> 00:28:16,480
ιδιαίτερα κατάλληλο για περιβάλλοντα όπου η ευκολία ρύθμισης και προσαρμογής

359
00:28:16,480 --> 00:28:20,720
είναι κρίσιμες, ωστόσο διατηρεί ισχυρά χαρακτηριστικά που πληρούν τις

360
00:28:20,720 --> 00:28:25,920
απαιτήσεις των ομάδων ασφαλείας. Ένα από τα χαρακτηριστικά που ξεχωρίζουν στο Graylog

361
00:28:25,920 --> 00:28:31,200
είναι η modular αρχιτεκτονική του. Χρησιμοποιεί στοιχεία όπως inputs,

362
00:28:31,200 --> 00:28:36,400
extractors, και pipelines για να επεξεργαστεί, φιλτράρει και εμπλουτίσει τα logs,

363
00:28:36,400 --> 00:28:42,480
το οποίο παρέχει ευελιξία στο πώς τα δεδομένα log εισάγονται, αναλύονται και μελετώνται.

364
00:28:42,480 --> 00:28:47,520
Αυτή η αρχιτεκτονική επιτρέπει στους οργανισμούς να προσαρμόζουν τα pipelines επεξεργασίας logs τους

365
00:28:47,520 --> 00:28:51,520
ώστε να ταιριάζουν σε συγκεκριμένες ανάγκες, καθιστώντας το Graylog μια προσαρμόσιμη

366
00:28:51,520 --> 00:28:56,880
λύση για διάφορες περιπτώσεις χρήσης. Το Graylog παρέχει επίσης

367
00:28:56,880 --> 00:29:02,240
φιλτράρισμα βάσει ροής (stream-based filtering), που βοηθά τους χρήστες να δρομολογούν logs σε συγκεκριμένες ροές (streams)

368
00:29:02,240 --> 00:29:07,120
με βάση το περιεχόμενό τους. Αυτό επιτρέπει προσαρμοσμένη ειδοποίηση και

369
00:29:07,120 --> 00:29:11,280
dashboarding με βάση τους τύπους logs που είναι πιο σημαντικοί

370
00:29:11,280 --> 00:29:16,560
για την ομάδα ασφαλείας. Για παράδειγμα, αν υπάρχουν συγκεκριμένα logs που σχετίζονται

371
00:29:16,560 --> 00:29:20,000
με κρίσιμα συστήματα ή συγκεκριμένες απειλές,

372
00:29:20,000 --> 00:29:23,920
το Graylog μπορεί να ρυθμιστεί ώστε να προτεραιοποιεί αυτά τα γεγονότα και να ενεργοποιεί

373
00:29:23,920 --> 00:29:29,680
ειδοποιήσεις ανάλογα. Η ειδοποίηση και η συσχέτιση είναι βασικά συστατικά

374
00:29:29,680 --> 00:29:33,840
του Graylog, προσφέροντας δυνατότητες παρακολούθησης σε πραγματικό χρόνο.

375
00:29:33,840 --> 00:29:39,040
Οι χρήστες μπορούν να ρυθμίσουν συνθήκες ειδοποίησης με βάση κατώφλια ή συγκεκριμένα μοτίβα

376
00:29:39,040 --> 00:29:43,920
εντός της ροής των logs. Για παράδειγμα, αν ένα προκαθορισμένο κατώφλι

377
00:29:43,920 --> 00:29:47,360
ξεπεραστεί, όπως πολλαπλές αποτυχημένες απόπειρες σύνδεσης,

378
00:29:47,360 --> 00:29:50,880
σε σύντομο χρονικό διάστημα, το Graylog μπορεί να ενεργοποιήσει μια ειδοποίηση,

379
00:29:50,880 --> 00:29:54,560
ενημερώνοντας την ομάδα ασφαλείας για πιθανές απειλές.

380
00:29:54,560 --> 00:30:00,400
Ένα παράδειγμα, ένας διαχειριστής δικτύου ρυθμίζει μια ροή (stream) για να παρακολουθεί αποτυχημένες SSH

381
00:30:00,400 --> 00:30:04,960
συνδέσεις. Η ροή φιλτράρει logs όπου event

382
00:30:04,960 --> 00:30:10,640
dot action equals SSH login failed. Και αν περισσότερες από 10

383
00:30:10,640 --> 00:30:15,760
αποτυχίες συμβούν μέσα σε ένα λεπτό από την ίδια διεύθυνση IP, το Graylog ενεργοποιεί μια

384
00:30:15,760 --> 00:30:20,800
ειδοποίηση, βοηθώντας στον εντοπισμό πιθανών επιθέσεων brute-force.

385
00:30:20,880 --> 00:30:23,920
Από τεχνική σκοπιά, το Graylog υποστηρίζει διάφορες

386
00:30:23,920 --> 00:30:27,920
μεθόδους εισαγωγής (ingestion), συμπεριλαμβανομένων Syslog,

387
00:30:27,920 --> 00:30:34,000
GELF, που είναι το Graylog Extended Log Format, και REST APIs υποστηρίζονται,

388
00:30:34,000 --> 00:30:39,920
καθιστώντας το Graylog συμβατό με ένα ευρύ φάσμα πηγών log.

389
00:30:39,920 --> 00:30:44,080
Η πλατφόρμα χρησιμοποιεί ξανά Elasticsearch για ευρετηρίαση (indexing),

390
00:30:44,080 --> 00:30:47,840
το οποίο παρέχει γρήγορες δυνατότητες αναζήτησης και ερωτημάτων σε

391
00:30:47,920 --> 00:30:52,320
μεγάλα σύνολα δεδομένων. Επιπλέον, το οικοσύστημα plugin του Graylog είναι

392
00:30:52,320 --> 00:30:56,240
ένα άλλο χαρακτηριστικό, προσφέροντας ενσωματώσεις για γεωεντοπισμό,

393
00:30:56,240 --> 00:30:59,920
threat intelligence, και άλλες προηγμένες περιπτώσεις χρήσης.

394
00:30:59,920 --> 00:31:04,560
Αυτή η ευελιξία επιτρέπει στους οργανισμούς να επεκτείνουν τη λειτουργικότητα του Graylog

395
00:31:04,560 --> 00:31:10,080
και να προσαρμοστούν στις συγκεκριμένες ανάγκες ασφάλειας και λειτουργίας τους.

396
00:31:10,080 --> 00:31:15,200
Το IBM QRadar είναι μια ολοκληρωμένη πλατφόρμα SIEM επιπέδου επιχείρησης,

397
00:31:15,280 --> 00:31:20,000
ευρέως χρησιμοποιούμενη σε ρυθμιζόμενους κλάδους, ιδιαίτερα όπου ισχυρή

398
00:31:20,000 --> 00:31:23,360
ασφάλεια και απαιτήσεις συμμόρφωσης είναι απαραίτητες.

399
00:31:23,360 --> 00:31:27,360
Γνωστό για την προηγμένη μηχανή συσχέτισής του και τις δυνατότητες ενσωμάτωσης,

400
00:31:27,360 --> 00:31:31,520
το QRadar είναι σχεδιασμένο να χειρίζεται πολύπλοκα περιβάλλοντα ασφαλείας με ευκολία,

401
00:31:31,520 --> 00:31:35,600
παρέχοντας βαθιές γνώσεις και ανίχνευση απειλών σε πραγματικό χρόνο.

402
00:31:35,600 --> 00:31:38,960
Ένα από τα πιο αξιοσημείωτα χαρακτηριστικά του QRadar είναι η

403
00:31:38,960 --> 00:31:43,440
μηχανή αυτόματης συσχέτισης (auto-correlation engine), η οποία χρησιμοποιεί μια λογική

404
00:31:43,440 --> 00:31:48,240
βάσει κανόνων για να ανιχνεύσει μοτίβα ασφαλείας σε πολλαπλές πηγές log.

405
00:31:48,240 --> 00:31:51,920
Αυτή η μηχανή συσχετίζει αυτόματα γεγονότα από διάφορα συστήματα,

406
00:31:51,920 --> 00:31:57,920
όπως firewalls, endpoints, και servers, για να εντοπίσει ύποπτες δραστηριότητες.

407
00:31:57,920 --> 00:32:02,400
Ένα άλλο βασικό χαρακτηριστικό του QRadar είναι η δυνατότητα μοντελοποίησης πόρων (asset modeling).

408
00:32:02,400 --> 00:32:06,960
Η πλατφόρμα χτίζει δυναμικά μια απογραφή πόρων με βάση παρατηρήσεις κίνησης

409
00:32:06,960 --> 00:32:10,480
δικτύου, δίνοντας στις ομάδες ασφαλείας μια καθαρή εικόνα

410
00:32:10,480 --> 00:32:14,720
των ευπαθειών των πόρων τους. Αυτή η μοντελοποίηση πόρων τους βοηθά να

411
00:32:14,720 --> 00:32:18,240
εντοπίσουν κρίσιμα συστήματα που στοχεύονται

412
00:32:18,240 --> 00:32:22,800
και επιτρέπει στους οργανισμούς να προτεραιοποιούν τις αποκρίσεις ανάλογα.

413
00:32:22,800 --> 00:32:27,600
Οι ενσωματωμένες ροές απειλών (threat feeds) είναι ένα άλλο σημαντικό πλεονέκτημα του QRadar.

414
00:32:27,600 --> 00:32:31,600
Συνδέεται απρόσκοπτα με εξωτερική threat intelligence,

415
00:32:31,600 --> 00:32:36,800
με παρόχους όπως το IBM X-Force και άλλες ροές τρίτων,

416
00:32:36,800 --> 00:32:40,320
εμπλουτίζοντας τη διαδικασία ανίχνευσης και συσχέτισης.

417
00:32:40,320 --> 00:32:45,280
Αυτή η ενσωμάτωση επιτρέπει στο QRadar να διασταυρώνει εισερχόμενα δεδομένα log

418
00:32:45,280 --> 00:32:49,120
με γνωστούς δείκτες επιθέσεων και εξελισσόμενη threat intelligence,

419
00:32:49,120 --> 00:32:54,160
βελτιώνοντας την ακρίβεια των ειδοποιήσεων και βοηθώντας τις ομάδες ασφαλείας να ανταποκρίνονται πιο

420
00:32:54,160 --> 00:32:59,280
προληπτικά. Ας δούμε ένα παράδειγμα χρήσης. Το QRadar

421
00:32:59,280 --> 00:33:04,960
μπορεί να συσχετίσει επαναλαμβανόμενες αποτυχημένες συνδέσεις από πολλαπλούς χρήστες στο ίδιο subnet,

422
00:33:04,960 --> 00:33:09,440
ακολουθούμενες από μια επιτυχημένη σύνδεση από έναν από τους άλλους χρήστες.

423
00:33:09,440 --> 00:33:13,680
Αυτή η ακολουθία υποδηλώνει μια επίθεση credential stuffing, όπου οι επιτιθέμενοι χρησιμοποιούν

424
00:33:13,680 --> 00:33:18,880
κλεμμένα διαπιστευτήρια για να αποκτήσουν μη εξουσιοδοτημένη πρόσβαση. Η μηχανή auto correlation του QRadar

425
00:33:18,880 --> 00:33:21,680
θα δημιουργήσει ένα αδίκημα (offense) υψηλής σοβαρότητας,

426
00:33:21,680 --> 00:33:26,480
ειδοποιώντας την ομάδα ασφαλείας για πιθανή παραβίαση διαπιστευτηρίων.

427
00:33:26,480 --> 00:33:30,160
Από τεχνική σκοπιά, το QRadar είναι εξαιρετικά κλιμακώσιμο,

428
00:33:30,160 --> 00:33:34,320
υποστηρίζοντας εισαγωγή logs από χιλιάδες πηγές, συμπεριλαμβανομένων firewalls,

429
00:33:34,320 --> 00:33:38,880
endpoints, και πλατφορμών cloud. Αυτό καθιστά το QRadar κατάλληλο για

430
00:33:38,960 --> 00:33:43,040
μεγάλα πολύπλοκα περιβάλλοντα που απαιτούν κεντρικοποιημένη διαχείριση logs και ανίχνευση

431
00:33:43,040 --> 00:33:47,440
απειλών. Επιπλέον, το QRadar έχει ενσωματωμένα analytics ροής (flow

432
00:33:47,440 --> 00:33:51,920
analytics) μέσω του QFlow που του επιτρέπει να επιθεωρεί

433
00:33:51,920 --> 00:33:56,720
κίνηση Layer 7, παρέχοντας ορατότητα σε δραστηριότητα επιπέδου εφαρμογής,

434
00:33:56,720 --> 00:34:00,480
που είναι απαραίτητη για την ανίχνευση πιο προηγμένων επιθέσεων.

435
00:34:00,480 --> 00:34:05,200
Το QRadar αξιοποιεί επίσης τη βάση δεδομένων Ariel για αναζήτηση υψηλής ταχύτητας σε

436
00:34:05,200 --> 00:34:09,840
terabytes δεδομένων log, επιτρέποντας γρήγορη απόδοση ερωτημάτων,

437
00:34:09,840 --> 00:34:14,400
ακόμη και σε εγκαταστάσεις μεγάλης κλίμακας. Αυτό επιτρέπει στους αναλυτές ασφαλείας να ψάχνουν γρήγορα

438
00:34:14,400 --> 00:34:18,960
μέσω εκτενών logs και να εντοπίζουν κρίσιμα γεγονότα ασφαλείας,

439
00:34:18,960 --> 00:34:24,640
το οποίο είναι ζωτικό για τη διατήρηση δυνατοτήτων παρακολούθησης σε πραγματικό χρόνο.

440
00:34:24,640 --> 00:34:29,760
Το Microsoft Sentinel είναι μια cloud-native λύση SIEM που είναι στενά

441
00:34:29,760 --> 00:34:32,800
ενσωματωμένη με το Azure, προσφέροντας κλιμακωσιμότητα,

442
00:34:32,800 --> 00:34:37,600
ισχυρά analytics, και δυνατότητες αυτοματοποιημένης απόκρισης.

443
00:34:37,600 --> 00:34:41,520
Αξιοποιεί το AI της Microsoft, μηχανική μάθηση,

444
00:34:41,520 --> 00:34:45,360
και security graph intelligence για να παραδώσει έξυπνη ανίχνευση απειλών

445
00:34:45,360 --> 00:34:50,000
και απλοποιημένες λειτουργίες ασφαλείας, καθιστώντας το ιδιαίτερα κατάλληλο για

446
00:34:50,000 --> 00:34:55,840
επιχειρήσεις που χρησιμοποιούν ήδη Azure ή άλλες υπηρεσίες Microsoft.

447
00:34:55,840 --> 00:34:59,280
Ένα από τα βασικά πλεονεκτήματα του Sentinel είναι η χρήση της

448
00:34:59,280 --> 00:35:04,800
Kusto Query Language, KQL, μια γρήγορη και ευέλικτη γλώσσα ερωτημάτων

449
00:35:04,800 --> 00:35:07,920
βελτιστοποιημένη για ανάλυση logs μεγάλης κλίμακας.

450
00:35:07,920 --> 00:35:12,560
Η KQL επιτρέπει στους αναλυτές ασφαλείας να ψάχνουν γρήγορα και να αναλύουν τεράστιες

451
00:35:12,560 --> 00:35:16,720
ποσότητες δεδομένων log, καθιστώντας την ένα απαραίτητο εργαλείο για τον εντοπισμό

452
00:35:16,720 --> 00:35:20,320
απειλών σε πραγματικό χρόνο. Η γλώσσα είναι αρκετά ισχυρή

453
00:35:20,320 --> 00:35:23,920
για να χειρίζεται πολύπλοκα ερωτήματα ενώ είναι αρκετά αποδοτική

454
00:35:23,920 --> 00:35:27,280
για να λειτουργεί στην κλίμακα εταιρικών περιβαλλόντων.

455
00:35:27,280 --> 00:35:30,800
Μια άλλη σημαντική δυνατότητα του Sentinel

456
00:35:30,800 --> 00:35:35,440
είναι τα behavior analytics του, που περιλαμβάνουν User Behavior Analytics,

457
00:35:35,440 --> 00:35:39,760
UEBA. Αυτή η λειτουργία αναλύει τη συμπεριφορά χρήστη και

458
00:35:39,760 --> 00:35:44,960
συστήματος, για να βρει ανωμαλίες δεδομένων που μπορεί να υποδεικνύουν κακόβουλη δραστηριότητα.

459
00:35:44,960 --> 00:35:48,720
Παρακολουθώντας συνεχώς τις ενέργειες χρηστών και οντοτήτων,

460
00:35:48,720 --> 00:35:52,800
το Sentinel μπορεί να εντοπίσει αποκλίσεις από την κανονική συμπεριφορά,

461
00:35:52,800 --> 00:35:57,840
όπως ασυνήθιστους χρόνους σύνδεσης, άτυπα μοτίβα πρόσβασης,

462
00:35:57,840 --> 00:36:02,800
ή μη εξουσιοδοτημένη πρόσβαση πόρων, που είναι συχνά σημάδια insider threats

463
00:36:02,800 --> 00:36:07,760
ή παραβιασμένων λογαριασμών. Τα Playbooks στο Microsoft Sentinel,

464
00:36:07,760 --> 00:36:12,640
που βασίζονται στο SOAR, Security Orchestration, Automation and Response,

465
00:36:12,640 --> 00:36:16,720
επιτρέπουν στους οργανισμούς να αυτοματοποιούν την απόκριση σε περιστατικά.

466
00:36:16,720 --> 00:36:21,920
Χρησιμοποιώντας Azure Logic Apps, τα playbooks μπορούν να εκτελούν προκαθορισμένες

467
00:36:21,920 --> 00:36:26,240
ροές εργασίας για να ανταποκρίνονται σε περιστατικά ασφαλείας αυτόματα.

468
00:36:26,240 --> 00:36:30,240
Αυτά τα playbooks βοηθούν στη μείωση του χρόνου απόκρισης σε περιστατικά,

469
00:36:30,240 --> 00:36:35,040
διασφαλίζοντας μια γρήγορη και συνεπή αντίδραση σε κοινές απειλές ασφαλείας.

470
00:36:35,040 --> 00:36:39,920
Ας δούμε ένα παράδειγμα. Οι δυνατότητες ανίχνευσης απειλών του Sentinel

471
00:36:39,920 --> 00:36:44,080
είναι η ικανότητά του να επισημαίνει αδύνατες συνδέσεις (impossible logins).

472
00:36:44,080 --> 00:36:49,360
Ας υποθέσουμε ότι ένας χρήστης συνδέεται από τη Γερμανία και μετά από τις ΗΠΑ, εντός ενός παραθύρου δύο λεπτών,

473
00:36:49,360 --> 00:36:53,280
το Sentinel θα χρησιμοποιούσε ερωτήματα KQL σε

474
00:36:53,280 --> 00:36:58,000
logs εισόδου για να το επισημάνει αυτό ως ανωμαλία. Ερωτώντας τα

475
00:36:58,000 --> 00:37:04,400
δεδομένα GeoIP και timestamp, το Sentinel μπορεί άμεσα να εντοπίσει και να ειδοποιήσει

476
00:37:04,400 --> 00:37:09,600
για το αδύνατο σενάριο, υποδεικνύοντας μια πιθανή παραβίαση διαπιστευτηρίων

477
00:37:09,600 --> 00:37:14,160
ή μια απόπειρα μη εξουσιοδοτημένης πρόσβασης. Από τεχνική σκοπιά, το Microsoft

478
00:37:14,160 --> 00:37:17,520
Sentinel παρέχει απρόσκοπτη ενσωμάτωση με τις

479
00:37:17,520 --> 00:37:23,120
υπηρεσίες της Microsoft, όπως Microsoft 365, Defender και Azure

480
00:37:23,120 --> 00:37:26,640
activity logs. Αυτή η στενή ενσωμάτωση βοηθά τις ομάδες ασφαλείας

481
00:37:26,640 --> 00:37:30,320
να αποκτήσουν ολοκληρωμένη ορατότητα σε όλη την έκταση των

482
00:37:30,320 --> 00:37:34,080
cloud και on-premises περιβαλλόντων τους. Επιπλέον,

483
00:37:34,080 --> 00:37:37,920
το Sentinel υποστηρίζει ένα ευρύ φάσμα τρίτων

484
00:37:37,920 --> 00:37:42,960
και connectors όπως AWS, Cisco και Palo Alto,

485
00:37:42,960 --> 00:37:46,720
που επιτρέπουν στους οργανισμούς να εισάγουν δεδομένα, να εισάγουν

486
00:37:46,720 --> 00:37:50,800
δεδομένα από πολλαπλές πηγές σε μια κεντρικοποιημένη πλατφόρμα

487
00:37:50,800 --> 00:37:55,680
για πιο ολοκληρωμένη ανίχνευση και ανάλυση απειλών.

488
00:37:56,160 --> 00:38:01,680
Για να αρχίσετε να αξιοποιείτε το Splunk, για παράδειγμα, για ανάλυση δεδομένων log, είναι

489
00:38:01,680 --> 00:38:05,520
σημαντικό να κατανοήσετε κάθε βήμα της διαδικασίας για εισαγωγή και

490
00:38:05,520 --> 00:38:09,920
διαμόρφωση δεδομένων log. Το πρώτο στάδιο είναι να πλοηγηθείτε στις

491
00:38:09,920 --> 00:38:13,760
ρυθμίσεις (settings) και add data, που ανοίγει μια απλή και

492
00:38:13,840 --> 00:38:17,120
διαισθητική ροή εργασίας για την προσθήκη των πηγών δεδομένων σας.

493
00:38:17,120 --> 00:38:21,360
Αυτή η διαδικασία είναι κρίσιμη καθώς διασφαλίζει ότι η εγκατάσταση (instance) του Splunk σας

494
00:38:21,360 --> 00:38:25,360
μπορεί να συλλέγει σωστά δεδομένα από μια ποικιλία πηγών,

495
00:38:25,360 --> 00:38:30,320
είτε είναι από αρχεία είτε από παρακολούθηση σε πραγματικό χρόνο. Η πρώτη ενέργεια

496
00:38:30,320 --> 00:38:34,320
εδώ είναι να επιλέξετε monitor files and directories.

497
00:38:34,320 --> 00:38:37,760
Αυτό σας επιτρέπει να καθορίσετε ποια αρχεία log θα παρακολουθούνται για

498
00:38:37,760 --> 00:38:41,440
συλλογή σε πραγματικό χρόνο. Για παράδειγμα, αν θέλετε να

499
00:38:41,440 --> 00:38:44,960
παρακολουθείτε logs αυθεντικοποίησης από ένα σύστημα Linux, μπορεί να

500
00:38:44,960 --> 00:38:51,760
επιλέξετε αρχεία όπως /var/log/auth.log ή /var/log/secure kernel ή

501
00:38:51,760 --> 00:38:56,480
οτιδήποτε. Επιλέγοντας την επιλογή files and directories

502
00:38:56,480 --> 00:39:00,560
λέτε στο Splunk να ψάξει για νέες εγγραφές log

503
00:39:00,560 --> 00:39:03,680
που εμφανίζονται μέσα σε αυτά τα αρχεία ή καταλόγους,

504
00:39:03,680 --> 00:39:07,280
οι οποίες θα ευρετηριαστούν (indexed) για μετέπειτα αναζήτηση.

505
00:39:07,360 --> 00:39:13,440
Αυτό είναι κλειδί επειδή σημαίνει ότι το Splunk είναι συνεχώς ενήμερο για νέα γεγονότα,

506
00:39:13,440 --> 00:39:19,120
καθιστώντας ευκολότερο τον εντοπισμό ζητημάτων καθώς προκύπτουν σε πραγματικό χρόνο.

507
00:39:19,120 --> 00:39:24,640
Στη συνέχεια, μία από τις πιο κρίσιμες αποφάσεις στη διαδικασία ρύθμισης είναι

508
00:39:24,640 --> 00:39:28,320
να επιλέξετε έναν τύπο πηγής (source type) για τα δεδομένα log.

509
00:39:28,320 --> 00:39:31,920
Ο τύπος πηγής καθορίζει πώς το Splunk πρέπει να ερμηνεύει

510
00:39:31,920 --> 00:39:36,000
και να αναλύει (parse) τα πρωτογενή δεδομένα log. Χωρίς έναν σωστό τύπο πηγής,

511
00:39:36,000 --> 00:39:39,760
το Splunk δεν θα μπορούσε να εξάγει ουσιαστικά πεδία

512
00:39:39,760 --> 00:39:44,640
ή να δομήσει τα δεδομένα σωστά. Για παράδειγμα, τα logs αυθεντικοποίησης Linux

513
00:39:44,640 --> 00:39:48,080
συνήθως χρησιμοποιούν τον τύπο πηγής linux_secure.

514
00:39:48,080 --> 00:39:51,600
Αναθέτοντας τον κατάλληλο τύπο πηγής,

515
00:39:51,600 --> 00:39:55,360
διασφαλίζετε ότι το Splunk κατανοεί το format του log

516
00:39:55,360 --> 00:39:59,600
και μπορεί σωστά να σπάσει τα logs σε πεδία όπως ονόματα χρηστών,

517
00:39:59,600 --> 00:40:05,440
timestamps, κατάσταση εισόδου ως επιτυχία, αποτυχία, και ούτω καθεξής.

518
00:40:05,520 --> 00:40:10,400
Αφού ορίσετε τον τύπο πηγής, το επόμενο βήμα είναι να διαμορφώσετε ένα index.

519
00:40:10,400 --> 00:40:14,480
Το index λειτουργεί σαν ένα δοχείο (container) για logs

520
00:40:14,480 --> 00:40:18,320
και είναι απαραίτητο για την οργάνωση των μεγάλων ποσοτήτων δεδομένων

521
00:40:18,320 --> 00:40:24,000
που μπορεί να εισαχθούν στο Splunk. Για παράδειγμα, logs ασφαλείας θα μπορούσαν να τοποθετηθούν

522
00:40:24,000 --> 00:40:28,320
σε ένα index που ονομάζεται "security_logs", το οποίο θα καθιστούσε εύκολο

523
00:40:28,320 --> 00:40:32,640
αργότερα το φιλτράρισμα και την αναζήτηση μόνο στα σχετικά με την ασφάλεια γεγονότα στο σύστημά

524
00:40:32,640 --> 00:40:37,920
σας. Ομαδοποιώντας logs σε διαφορετικά indexes,

525
00:40:37,920 --> 00:40:42,720
το Splunk μπορεί πιο αποδοτικά να ανακτήσει τα δεδομένα που χρειάζονται για ανάλυση χωρίς

526
00:40:42,720 --> 00:40:46,160
να ψάχνει μέσα από άσχετες πληροφορίες, βελτιώνοντας

527
00:40:46,160 --> 00:40:49,200
την απόδοση και διασφαλίζοντας ότι τα ερωτήματα αναζήτησης

528
00:40:49,200 --> 00:40:54,160
είναι ταχύτερα και πιο σχετικά. Μόλις ολοκληρώσετε τη διαμόρφωση τύπου πηγής και

529
00:40:54,160 --> 00:40:58,000
index, το Splunk θα αρχίσει αυτόματα

530
00:40:58,000 --> 00:41:02,800
να εισάγει τα δεδομένα log από τα καθορισμένα αρχεία στη βάση δεδομένων.

531
00:41:02,800 --> 00:41:08,160
Καθώς εισάγει αυτά τα logs, το Splunk αναλύει τις πρωτογενείς εγγραφές log σε

532
00:41:08,160 --> 00:41:11,680
δομημένα γεγονότα σύμφωνα με τον τύπο πηγής.

533
00:41:11,680 --> 00:41:16,080
Κάθε γεγονός περιέχει σημαντικά πεδία μεταδεδομένων όπως time,

534
00:41:16,080 --> 00:41:21,360
host, source και source type που βοηθούν στην κατηγοριοποίηση των δεδομένων και τα καθιστούν

535
00:41:21,360 --> 00:41:24,960
αναζητήσιμα. Για παράδειγμα, το πεδίο timestamp

536
00:41:25,120 --> 00:41:29,680
last_time θα σας επιτρέψει να αναζητήσετε logs κατά ημερομηνία και ώρα.

537
00:41:29,680 --> 00:41:33,520
Host θα σας πει από ποιο μηχάνημα προήλθε το log

538
00:41:33,520 --> 00:41:36,960
και source type θα σας βοηθήσει να εντοπίσετε τον τύπο του log,

539
00:41:36,960 --> 00:41:41,920
αν είναι log συστήματος, log εφαρμογής, log ασφαλείας και ούτω καθεξής.

540
00:41:41,920 --> 00:41:46,080
Αυτά τα πεδία κάνουν τα δεδομένα πολύ πιο χρήσιμα και σας επιτρέπουν να βρείτε γρήγορα

541
00:41:46,080 --> 00:41:50,800
σχετικές εγγραφές σε ένα μεγάλο σύνολο δεδομένων. Μόλις τα logs έχουν εισαχθεί

542
00:41:50,800 --> 00:41:55,840
και αναλυθεί στα γεγονότα, το τελικό βήμα είναι να επαληθεύσετε τα δεδομένα τρέχοντας

543
00:41:55,840 --> 00:41:59,360
αναζητήσεις. Εδώ είναι που η δύναμη του Splunk

544
00:41:59,360 --> 00:42:04,240
πραγματικά λάμπει. Ερωτώντας συγκεκριμένα indexes και τύπους πηγών,

545
00:42:04,240 --> 00:42:09,200
μπορείτε γρήγορα να φιλτράρετε μέσα από logs για να αποκαλύψετε πολύτιμες γνώσεις.

546
00:42:09,200 --> 00:42:14,000
Για παράδειγμα, για να παρακολουθήσετε αποτυχημένες απόπειρες σύνδεσης, θα μπορούσατε να ψάξετε για όλες τις αποτυχημένες

547
00:42:14,000 --> 00:42:17,280
εγγραφές κωδικού πρόσβασης στα logs ασφαλείας χρησιμοποιώντας ένα

548
00:42:17,280 --> 00:42:22,640
ερώτημα όπως index=security_logs sourcetype=linux_secure

549
00:42:22,640 --> 00:42:26,960
και μετά το μήνυμα "failed password".

550
00:42:26,960 --> 00:42:31,520
Αυτό το ερώτημα θα επιστρέψει όλες τις εγγραφές που ταιριάζουν με αυτό το string αναζήτησης

551
00:42:31,520 --> 00:42:36,560
το οποίο θα ήταν απίστευτα χρήσιμο για τον εντοπισμό πιθανών παραβιάσεων

552
00:42:36,560 --> 00:42:42,960
ασφαλείας, επιθέσεων brute force ή κακών ρυθμίσεων στο σύστημα.

553
00:42:42,960 --> 00:42:46,480
Μόλις τα logs σας εισαχθούν στο Splunk το επόμενο βήμα

554
00:42:46,480 --> 00:42:50,320
είναι να τα αναλύσετε χρησιμοποιώντας την SPL, την Search Processing

555
00:42:50,320 --> 00:42:54,640
Language. Ένα από τα πιο θεμελιώδη ερωτήματα στην SPL

556
00:42:54,640 --> 00:42:59,520
είναι η χρήση της εντολής stats για τον υπολογισμό μετρήσεων σε διάφορα πεδία στα

557
00:42:59,520 --> 00:43:02,800
logs σας. Για παράδειγμα, αν θέλετε να αναλύσετε πόσα

558
00:43:02,800 --> 00:43:06,240
συμβάντα έρχονται από διαφορετικές πηγές log,

559
00:43:06,240 --> 00:43:12,000
μπορείτε να χρησιμοποιήσετε το ακόλουθο ερώτημα SPL index=security_logs

560
00:43:12,000 --> 00:43:18,880
| stats count by source. Αυτό θα παρέχει μια ανάλυση των μετρήσεων

561
00:43:18,880 --> 00:43:26,000
συμβάντων από κάθε πηγή log βοηθώντας στον εντοπισμό ποιες πηγές είναι πιο ενεργές.

562
00:43:26,000 --> 00:43:30,720
Αυτή η ανάλυση είναι σημαντική για τις ομάδες ασφαλείας για να παρακολουθούν συστήματα

563
00:43:30,720 --> 00:43:35,040
καθώς ασυνήθιστες αιχμές στα συμβάντα από συγκεκριμένες πηγές θα μπορούσαν να υποδεικνύουν ένα

564
00:43:35,040 --> 00:43:40,080
πιθανό περιστατικό ασφαλείας. Ένα άλλο βασικό χαρακτηριστικό της SPL είναι η

565
00:43:40,080 --> 00:43:44,320
εντολή top η οποία εντοπίζει τις πιο συχνές

566
00:43:44,320 --> 00:43:49,440
τιμές σε ένα συγκεκριμένο πεδίο. Για παράδειγμα, αν θέλετε να δείτε ποιοι τύποι πηγών

567
00:43:49,440 --> 00:43:53,600
είναι πιο κοινοί στα logs σας, θα μπορούσατε να χρησιμοποιήσετε το ερώτημα

568
00:43:53,600 --> 00:43:59,520
index=security_logs | top sourcetype.

569
00:43:59,520 --> 00:44:04,480
Οι τύποι πηγών είναι ουσιώδεις κατηγορίες που το Splunk αναθέτει στα logs με βάση

570
00:44:04,480 --> 00:44:07,920
το format τους. Εντοπίζοντας τους πιο

571
00:44:08,880 --> 00:44:13,600
συχνούς τύπους πηγών μπορείτε να αξιολογήσετε εάν οι πηγές log

572
00:44:13,600 --> 00:44:17,920
κατηγοριοποιούνται κατάλληλα και αν παρουσιάζονται τυχόν απροσδόκητοι

573
00:44:17,920 --> 00:44:22,480
τύποι log. Αυτοί οι απροσδόκητοι τύποι πηγών μπορεί να δείχνουν

574
00:44:22,480 --> 00:44:27,600
σε κακώς ρυθμισμένα συστήματα ή στη χειρότερη περίπτωση πιθανούς

575
00:44:27,600 --> 00:44:32,880
κινδύνους ασφαλείας όπως μια νέα μη ανιχνευμένη πηγή δεδομένων.

576
00:44:32,880 --> 00:44:36,720
Με αυτές τις εντολές μπορείτε εύκολα να βουτήξετε στα δεδομένα log σας και να αρχίσετε

577
00:44:36,720 --> 00:44:42,000
να αποκαλύπτετε πολύτιμες γνώσεις. Η γλώσσα SPL υποστηρίζει επίσης

578
00:44:42,000 --> 00:44:45,600
πιο προηγμένα χαρακτηριστικά όπως subsearches,

579
00:44:45,600 --> 00:44:49,440
εξαγωγές πεδίων (field extractions) και analytics βάσει χρόνου.

580
00:44:49,440 --> 00:44:53,520
Για παράδειγμα, αν θέλετε να εστιάσετε σε logs από ένα συγκεκριμένο

581
00:44:53,520 --> 00:44:58,800
χρονικό εύρος ή να φιλτράρετε συγκεκριμένα γεγονότα που δεν είναι σχετικά

582
00:44:58,800 --> 00:45:03,120
με την έρευνά σας, η SPL σας επιτρέπει να τελειοποιήσετε

583
00:45:03,120 --> 00:45:08,160
τα ερωτήματά σας σύμφωνα με τον χρόνο. Αυτό την καθιστά ευέλικτο εργαλείο όχι μόνο για

584
00:45:08,160 --> 00:45:12,320
απόκριση σε περιστατικά ασφαλείας αλλά και για συνεχή λειτουργική

585
00:45:12,320 --> 00:45:16,880
παρακολούθηση. Για την ανίχνευση αποπειρών brute force, μία

586
00:45:16,880 --> 00:45:20,480
αποτελεσματική μέθοδος χρησιμοποιώντας το Splunk είναι να εξετάσετε logs για επαναλαμβανόμενα

587
00:45:20,480 --> 00:45:24,480
μηνύματα αποτυχημένης σύνδεσης. Οι επιθέσεις brute force συχνά περιλαμβάνουν μια

588
00:45:24,480 --> 00:45:28,240
επίθεση που δοκιμάζει επανειλημμένα διαφορετικούς κωδικούς πρόσβασης σε μια προσπάθεια να αποκτήσει μη εξουσιοδοτημένη

589
00:45:28,240 --> 00:45:32,480
πρόσβαση στο σύστημα. Αυτές οι αποτυχημένες απόπειρες τυπικά

590
00:45:32,480 --> 00:45:36,400
καταγράφονται σε logs όπως SSH ή logs αυθεντικοποίησης

591
00:45:36,400 --> 00:45:40,080
πράγμα που τα καθιστά απαραίτητα για την ανίχνευση κακόβουλης δραστηριότητας.

592
00:45:40,080 --> 00:45:44,400
Αναλύοντας αυτά τα logs μπορείτε να εντοπίσετε μοτίβα που υποδεικνύουν επιθέσεις brute force

593
00:45:44,400 --> 00:45:48,160
σε εξέλιξη. Ένας τρόπος ανίχνευσης μιας επίθεσης brute force είναι

594
00:45:48,160 --> 00:45:53,840
χρησιμοποιώντας queries στην ανάλυση log. Οπότε index=security_logs "failed

595
00:45:53,840 --> 00:45:57,840
password" άρα αυτό είναι το μήνυμα που πρέπει να εμφανίζεται στα logs

596
00:45:57,840 --> 00:46:02,400
και μετά | stats count by source. Αυτή η εντολή είναι ειδικά σχεδιασμένη

597
00:46:02,400 --> 00:46:08,800
να βρίσκει περιπτώσεις όπου οι απόπειρες σύνδεσης αποτυγχάνουν. Να πώς λειτουργεί.

598
00:46:08,800 --> 00:46:13,280
index=security_logs καθορίζει ότι το ερώτημα πρέπει να ψάξει εντός του

599
00:46:13,280 --> 00:46:17,280
index security logs που πιθανότατα περιέχει εγγραφές

600
00:46:17,280 --> 00:46:22,160
σχετικές με τις απόπειρες σύνδεσης. "failed password" ψάχνει για γεγονότα

601
00:46:22,160 --> 00:46:25,520
στα logs που περιέχουν τη φράση "failed password"

602
00:46:25,520 --> 00:46:29,840
που χρησιμοποιείται συνήθως για να καταγράψει ανεπιτυχείς απόπειρες σύνδεσης.

603
00:46:29,920 --> 00:46:34,320
| stats count by source είναι μια στατιστική συνάρτηση που μετρά τις

604
00:46:34,320 --> 00:46:39,360
εμφανίσεις πόσες φορές για παράδειγμα αυτή η εμφάνιση παρουσιάστηκε

605
00:46:39,360 --> 00:46:44,000
ομαδοποιημένες κατά τη διεύθυνση IP πηγής. Για παράδειγμα θα έπρεπε να είναι

606
00:46:44,000 --> 00:46:48,160
μια διεύθυνση IP και μετά πόσοι αποτυχημένοι κωδικοί πρόσβασης

607
00:46:48,160 --> 00:46:53,200
ήταν σε μια συγκεκριμένη IP. Ουσιαστικά αυτό το μέρος της εντολής συγκεντρώνει τα

608
00:46:53,200 --> 00:46:56,640
δεδομένα για να δείξει πόσες αποτυχημένες απόπειρες σύνδεσης προήλθαν από

609
00:46:56,640 --> 00:47:00,480
κάθε μοναδική διεύθυνση IP. Το αποτέλεσμα από αυτό το ερώτημα θα μπορούσε να μοιάζει

610
00:47:00,480 --> 00:47:05,440
έτσι IP address και η διεύθυνση IP

611
00:47:05,440 --> 00:47:08,960
πόσες αποτυχημένες απόπειρες σύνδεσης εμφανίστηκαν

612
00:47:08,960 --> 00:47:16,720
20 για παράδειγμα index=security_logs "failed password" | top user

613
00:47:16,720 --> 00:47:21,200
αυτό το ερώτημα λειτουργεί ελαφρώς διαφορετικά αλλά εξακολουθεί να στοχεύει να εντοπίσει

614
00:47:21,200 --> 00:47:26,160
την επίθεση brute force. Πάλι το security logs είναι το

615
00:47:26,160 --> 00:47:30,240
index και το failed password είναι η φράση μέσα στα logs.

616
00:47:30,240 --> 00:47:34,000
Το | top user είναι μια συνάρτηση που επιστρέφει τα πιο συχνά

617
00:47:34,000 --> 00:47:38,640
στοχευμένα ονόματα χρηστών. Συγκεντρώνει τα δεδομένα με βάση τον

618
00:47:38,640 --> 00:47:42,320
αριθμό των φορών που κάθε όνομα χρήστη εμφανίζεται στις αποτυχημένες απόπειρες σύνδεσης

619
00:47:42,320 --> 00:47:46,160
ουσιαστικά κατατάσσοντας τα ονόματα χρηστών με βάση πόσες φορές

620
00:47:46,160 --> 00:47:49,920
στοχεύθηκαν, οπότε θα παρέχει τον υψηλότερο αριθμό των

621
00:47:49,920 --> 00:47:53,280
ονομάτων χρηστών που δοκιμάστηκαν για αυτές τις απόπειρες σύνδεσης.

622
00:47:53,360 --> 00:47:59,120
Οπότε αυτή είναι η εντολή top. Θα εξηγήσουμε έτσι ότι το αποτέλεσμα θα είναι όπως

623
00:47:59,120 --> 00:48:05,440
username root που είναι πολύ κοινό 15 απόπειρες username admin 10

624
00:48:05,440 --> 00:48:09,440
απόπειρες username super user οτιδήποτε

625
00:48:09,440 --> 00:48:13,840
αριθμός αποπειρών. Αυτό σημαίνει ότι τα ονόματα χρηστών root και admin

626
00:48:13,840 --> 00:48:18,400
στοχεύθηκαν συγκεκριμένα. Τέτοια αποτελέσματα υποδηλώνουν ότι οι επιτιθέμενοι

627
00:48:18,400 --> 00:48:22,320
εστιάζουν σε λογαριασμούς υψηλής αξίας από το root του admin

628
00:48:22,320 --> 00:48:30,160
και στην πραγματικότητα προσπαθούν να κάνουν επιθέσεις brute force στα συστήματα.

629
00:48:30,160 --> 00:48:34,560
Η οπτικοποίηση των δεδομένων log είναι απαραίτητη για τον γρήγορο εντοπισμό ύποπτων δραστηριοτήτων

630
00:48:34,560 --> 00:48:39,760
ή μη φυσιολογικής συμπεριφοράς σε πραγματικό χρόνο. Τα dashboards σε εργαλεία SIEM όπως το Splunk

631
00:48:39,760 --> 00:48:43,280
παρέχουν μια διαδραστική διεπαφή για την παρακολούθηση και ανάλυση τάσεων

632
00:48:43,280 --> 00:48:46,960
όπως αιχμές στις αποτυχημένες απόπειρες σύνδεσης ή επαναλαμβανόμενες επιθέσεις.

633
00:48:46,960 --> 00:48:51,200
Αυτές οι οπτικοποιήσεις βοηθούν τους αναλυτές ασφαλείας να παρακολουθούν πιθανές απειλές

634
00:48:51,280 --> 00:48:55,600
χωρίς να χρειάζεται να κοσκινίζουν τα πρωτογενή δεδομένα log χειροκίνητα

635
00:48:55,600 --> 00:48:58,800
επιτρέποντας πιο αποδοτική και αποτελεσματική απόκριση.

636
00:48:58,800 --> 00:49:03,120
Για να παρακολουθήσετε απόπειρες brute force ή άλλες αποτυχίες σύνδεσης

637
00:49:03,120 --> 00:49:07,920
με την πάροδο του χρόνου μπορείτε να χρησιμοποιήσετε το ερώτημα όπως αυτό που εξηγήσαμε security logs

638
00:49:07,920 --> 00:49:11,920
"failed password" και μετά | timechart span=1h count by source.

639
00:49:11,920 --> 00:49:16,640
Αυτό το ερώτημα παράγει ένα χρονοδιάγραμμα που

640
00:49:16,640 --> 00:49:22,560
παρακολουθεί αποτυχημένες απόπειρες σύνδεσης ανά διεύθυνση IP πηγής σε μια συγκεκριμένη χρονική περίοδο

641
00:49:22,560 --> 00:49:28,320
σε αυτή την περίπτωση ωριαία κάθε ώρα. Διασπώντας τα δεδομένα σε χρονικά βασισμένες

642
00:49:28,320 --> 00:49:33,840
προσαυξήσεις μπορείτε να οπτικοποιήσετε πώς εξελίσσονται οι απόπειρες σύνδεσης και να εντοπίσετε ξαφνικές

643
00:49:33,840 --> 00:49:38,720
αιχμές ή μοτίβα που μπορεί να υποδεικνύουν μια επίθεση σε εξέλιξη.

644
00:49:38,720 --> 00:49:43,120
Για να δημιουργήσετε μια οπτική αναπαράσταση αυτού του ερωτήματος στο Splunk

645
00:49:43,120 --> 00:49:48,080
ακολουθήστε τα βήματα πλοηγηθείτε στην ενότητα dashboard και επιλέξτε δημιουργία νέου

646
00:49:48,080 --> 00:49:51,360
dashboard. Επιλέξτε τον τύπο του γραφήματος που θέλετε να χρησιμοποιήσετε

647
00:49:51,360 --> 00:49:56,000
όπως ένα γράφημα γραμμής ή ένα γράφημα στήλης χρησιμοποιήστε το ερώτημα

648
00:49:56,000 --> 00:50:00,640
index=security_logs "failed password"

649
00:50:00,640 --> 00:50:06,240
| timechart span=1h count by source ως την πηγή δεδομένων για το γράφημά σας.

650
00:50:06,240 --> 00:50:10,720
Ορίστε ένα ουσιαστικό χρονικό εύρος όπως τις τελευταίες 24 ώρες για να παρέχετε τη σχετική

651
00:50:10,720 --> 00:50:15,920
προβολή της δραστηριότητας που παρακολουθείτε. Το αναμενόμενο αποτέλεσμα είναι ένα γράφημα βάσει χρόνου

652
00:50:15,920 --> 00:50:19,120
όπου μπορείτε να παρακολουθείτε αποτυχημένες απόπειρες σύνδεσης κατά

653
00:50:19,120 --> 00:50:24,400
IP πηγής. Το γράφημα θα εμφανίσει ποιες διευθύνσεις IP

654
00:50:24,400 --> 00:50:29,200
επιχειρούν συνδέσεις σε συγκεκριμένες ώρες και μπορείτε εύκολα να εντοπίσετε τυχόν διευθύνσεις IP

655
00:50:29,200 --> 00:50:32,960
με μια ασυνήθιστα υψηλή συχνότητα αποτυχημένων αποπειρών.

656
00:50:32,960 --> 00:50:36,240
Αυτές είναι πιθανό να είναι πηγές επιθέσεων brute force.

657
00:50:36,240 --> 00:50:40,320
Με αυτή την οπτικοποίηση μπορείτε γρήγορα να εντοπίσετε τις πιο ενεργές και

658
00:50:40,320 --> 00:50:44,720
δυνητικά κακόβουλες διευθύνσεις IP επιτρέποντάς σας να

659
00:50:44,720 --> 00:50:47,840
λάβετε άμεση δράση όπως το μπλοκάρισμα της IP

660
00:50:47,840 --> 00:50:53,360
ή την περαιτέρω διερεύνηση της δραστηριότητας.

661
00:50:53,360 --> 00:50:58,720
Το Logstash είναι ένα ισχυρό εργαλείο στο ELK Stack σχεδιασμένο για εισαγωγή, επεξεργασία

662
00:50:58,720 --> 00:51:01,840
και προώθηση δεδομένων log από πολλαπλούς πόρους.

663
00:51:01,840 --> 00:51:05,200
Όταν ρυθμίζετε το Logstash να χειρίζεται logs από ένα firewall

664
00:51:05,200 --> 00:51:08,880
παίζει ζωτικό ρόλο στη δόμηση πρωτογενών δεδομένων

665
00:51:08,880 --> 00:51:13,200
log σε μορφές με νόημα και δυνατότητα αναζήτησης. Η διαδικασία ξεκινά με την

666
00:51:13,200 --> 00:51:16,960
εγκατάσταση του Logstash στον server σας η οποία μπορεί να γίνει

667
00:51:16,960 --> 00:51:22,880
χρησιμοποιώντας διαχειριστή πακέτων ή κατεβάζοντας απευθείας τα binaries.

668
00:51:22,880 --> 00:51:26,800
Μόλις εγκατασταθεί προχωράτε στη διαμόρφωση του Logstash pipeline

669
00:51:26,800 --> 00:51:31,200
το οποίο αποτελείται από τρεις κύριες ενότητες input, filter και output.

670
00:51:31,200 --> 00:51:36,400
Στην ενότητα input το Logstash ρυθμίζεται να τραβάει logs από το log file του firewall

671
00:51:36,400 --> 00:51:42,000
σας ή έξοδο syslog. Για παράδειγμα τα logs firewall συχνά αποθηκεύονται σε

672
00:51:42,000 --> 00:51:46,320
αρχεία όπως /var/log/firewall.log

673
00:51:46,320 --> 00:51:49,760
και το Logstash πρέπει να ενημερωθεί πού να τα βρει.

674
00:51:49,760 --> 00:51:55,520
Η επιλογή start position beginning διασφαλίζει ότι το Logstash επεξεργάζεται τα logs

675
00:51:55,520 --> 00:51:59,040
ξεκινώντας από την αρχή του αρχείου log.

676
00:51:59,040 --> 00:52:04,400
Μόλις το Logstash έχει εισάγει τα logs η ενότητα filter μπαίνει στο παιχνίδι.

677
00:52:04,400 --> 00:52:08,880
Εδώ μπορείτε να χρησιμοποιήσετε φίλτρα όπως το Grok για να αναλύσετε και να εξάγετε

678
00:52:08,880 --> 00:52:14,160
συγκεκριμένα πεδία δεδομένων από τα πρωτογενή logs. Για παράδειγμα μπορεί να χρησιμοποιήσετε το Grok

679
00:52:14,160 --> 00:52:18,960
φίλτρο για να τραβήξετε την IP πηγής, την IP προορισμού και την ενέργεια που λήφθηκε από

680
00:52:18,960 --> 00:52:21,760
το firewall. Αυτό το βήμα είναι απαραίτητο για

681
00:52:21,760 --> 00:52:25,280
τον μετασχηματισμό αδόμητων δεδομένων log σε δομημένα

682
00:52:25,280 --> 00:52:29,680
πεδία που μπορούν να ευρετηριαστούν και να αναλυθούν. Τέλος η ενότητα output

683
00:52:29,680 --> 00:52:33,920
της διαμόρφωσης καθορίζει πού θα πάνε τα αναλυμένα δεδομένα.

684
00:52:33,920 --> 00:52:38,000
Σε αυτή την περίπτωση μπορείτε να διαμορφώσετε το Logstash να προωθεί τα επεξεργασμένα δεδομένα στο

685
00:52:38,000 --> 00:52:42,000
Elasticsearch όπου θα ευρετηριαστούν και θα γίνουν διαθέσιμα για

686
00:52:42,000 --> 00:52:46,000
αναζήτηση και ανάλυση. Τα logs συνήθως αποθηκεύονται σε ένα

687
00:52:46,000 --> 00:52:51,760
index format όπως "firewall_logs-date" ή οποιοδήποτε όνομα

688
00:52:51,760 --> 00:52:56,480
επιτρέποντας εύκολη οργάνωση και ερωτήματα με βάση την ημερομηνία που

689
00:52:56,480 --> 00:53:01,280
τα logs δημιουργήθηκαν ή βάσει διαφορετικής τακτικής και μεθοδολογίας.

690
00:53:01,280 --> 00:53:06,480
Μόλις η ρύθμιση ολοκληρωθεί και το Logstash επεξεργάζεται ενεργά τα logs

691
00:53:06,480 --> 00:53:10,400
η έξοδος θα αποτελείται από δομημένα δεδομένα που μπορούν να ερωτηθούν και

692
00:53:10,400 --> 00:53:15,040
να οπτικοποιηθούν χρησιμοποιώντας εργαλεία οπτικοποίησης όπως το Kibana.

693
00:53:15,040 --> 00:53:19,120
Οι καταχωρήσεις firewall όπως μία με τη διεύθυνση IP

694
00:53:19,120 --> 00:53:23,680
προορισμού και πηγής με ενέργεια αποδοχής (accept) θα σπάσουν σε

695
00:53:23,680 --> 00:53:28,400
διαφορετικά πεδία καθιστώντας εύκολη την αναζήτηση για τάσεις, τον εντοπισμό μοτίβων

696
00:53:28,400 --> 00:53:32,320
και την απόκτηση γνώσεων στα γεγονότα ασφαλείας δικτύου.

697
00:53:32,320 --> 00:53:37,440
Αυτή η ενσωμάτωση Logstash και Elasticsearch σας επιτρέπει να δημιουργήσετε ένα ισχυρό

698
00:53:37,440 --> 00:53:41,200
σύστημα διαχείρισης logs που ενισχύει την ικανότητά σας να παρακολουθείτε και

699
00:53:41,200 --> 00:53:45,920
να ασφαλίζετε το δίκτυό σας. Μόλις τα logs ευρετηριαστούν στο Elastic

700
00:53:45,920 --> 00:53:49,520
search μπορείτε να χρησιμοποιήσετε τις ισχυρές δυνατότητες ερωτημάτων του για να ανιχνεύσετε

701
00:53:49,520 --> 00:53:54,320
πιθανές απειλές ασφαλείας. Κατασκευάζοντας στοχευμένα ερωτήματα μπορείτε

702
00:53:54,320 --> 00:53:58,880
να εντοπίσετε ζητήματα ζωντανά όπως μη αυθεντικοποιημένη πρόσβαση

703
00:53:58,880 --> 00:54:02,480
και απόπειρες brute force. Αυτά τα ερωτήματα επιτρέπουν αποδοτική

704
00:54:02,480 --> 00:54:06,240
παρακολούθηση της δραστηριότητας δικτύου καθιστώντας ευκολότερο τον εντοπισμό

705
00:54:06,240 --> 00:54:10,080
περιστατικών ασφαλείας. Ένας τρόπος ανίχνευσης ύποπτης δραστηριότητας είναι

706
00:54:10,080 --> 00:54:14,240
η αναζήτηση για κίνηση από μια συγκεκριμένη διεύθυνση IP πηγής.

707
00:54:14,240 --> 00:54:18,160
Για παράδειγμα χρησιμοποιώντας το ερώτημα source_ip:

708
00:54:18,160 --> 00:54:22,160
και μετά τη διεύθυνση IP AND action:deny

709
00:54:22,240 --> 00:54:28,080
θα φιλτράρει τα logs όπου κίνηση από τη διεύθυνση IP

710
00:54:28,080 --> 00:54:31,280
τη συγκεκριμένη διεύθυνση απορρίφθηκε από το firewall.

711
00:54:31,280 --> 00:54:35,760
Αυτό μπορεί να σας βοηθήσει να εντοπίσετε μια συγκεκριμένη πηγή εάν επιχειρεί

712
00:54:35,760 --> 00:54:40,880
μη εξουσιοδοτημένη πρόσβαση ή προσπαθεί επανειλημμένα να παραβιάσει το firewall.

713
00:54:40,880 --> 00:54:45,600
Μια τυπική έξοδος μπορεί να δείξει logs που υποδεικνύουν ότι αυτή η διεύθυνση IP

714
00:54:45,600 --> 00:54:50,400
της έχει αρνηθεί η πρόσβαση πολλαπλές φορές σε διαφορετικούς προορισμούς

715
00:54:50,480 --> 00:54:56,080
υποδηλώνοντας πιθανή κακόβουλη δραστηριότητα. Αυτοί οι τύποι logs είναι

716
00:54:56,080 --> 00:54:59,520
χρήσιμοι για την ανίχνευση πρώιμων σημαδιών επίθεσης επιτρέποντας έγκαιρη

717
00:54:59,520 --> 00:55:04,400
παρέμβαση. Ένα άλλο σημαντικό ερώτημα εστιάζει στην ανίχνευση ασυνήθιστων μοτίβων

718
00:55:04,400 --> 00:55:08,880
πρόσβασης για συγκεκριμένες θύρες. Για παράδειγμα destination_port:80

719
00:55:08,880 --> 00:55:13,840
AND action:allow ψάχνει για επιτρεπόμενη κίνηση που στοχεύει τη θύρα 80.

720
00:55:13,840 --> 00:55:17,920
Καθώς η θύρα 80 χρησιμοποιείται συνήθως για κίνηση ιστού (web traffic) η παρακολούθησή της για

721
00:55:17,920 --> 00:55:21,680
ασυνήθιστη δραστηριότητα μπορεί να αποκαλύψει αν υπάρχουν μη φυσιολογικά μοτίβα πρόσβασης

722
00:55:21,680 --> 00:55:26,160
όπως συχνές συνδέσεις που μπορεί να μην ταιριάζουν με κανονική συμπεριφορά περιήγησης

723
00:55:26,160 --> 00:55:30,800
ιστού. Τα αποτελέσματα μπορεί να δείξουν μια λίστα επιτρεπόμενων

724
00:55:30,800 --> 00:55:35,200
καταχωρήσεων κίνησης αλλά είναι η συχνότητα και το πλαίσιο αυτών των συνδέσεων που

725
00:55:35,200 --> 00:55:39,600
θα βοηθήσουν να καθοριστεί αν η δραστηριότητα είναι νόμιμη ή

726
00:55:39,600 --> 00:55:44,640
ενδεικτική μιας απόπειρας εκμετάλλευσης. Εξετάζοντας τακτικά αυτά τα μοτίβα

727
00:55:44,720 --> 00:55:48,720
οι διαχειριστές δικτύου μπορούν να εντοπίσουν τις παρατυπίες και να ανταποκριθούν.

728
00:55:48,720 --> 00:55:52,000
Για να ανιχνεύσετε επιθέσεις brute force μπορείτε να ψάξετε για πολλαπλές

729
00:55:52,000 --> 00:55:59,440
αποτυχίες σύνδεσης όπως είδαμε στο Splunk όπως source_ip AND action:deny

730
00:55:59,440 --> 00:56:04,560
| stats count by source_ip. Αυτό το ερώτημα βοηθά στον εντοπισμό επαναλαμβανόμενων

731
00:56:04,560 --> 00:56:08,640
απορριφθέντων αποπειρών σύνδεσης για μια συγκεκριμένη διεύθυνση IP ένα κοινό σημάδι

732
00:56:08,640 --> 00:56:11,840
επίθεσης brute force. Τα αποτελέσματα μπορεί να δείξουν ότι η διεύθυνση

733
00:56:11,840 --> 00:56:15,280
IP έχει κάνει έναν υψηλό αριθμό αποτυχημένων αποπειρών σύνδεσης

734
00:56:15,280 --> 00:56:19,600
υποδεικνύοντας μια αυτοματοποιημένη επίθεση ή μια κακή ρύθμιση ασφαλείας που απαιτεί

735
00:56:19,600 --> 00:56:23,360
προσοχή. Τέτοια ερωτήματα είναι ιδιαίτερα χρήσιμα

736
00:56:23,360 --> 00:56:27,520
για τον εντοπισμό δραστηριοτήτων υψηλού κινδύνου και φυσικά

737
00:56:27,520 --> 00:56:31,600
το ELK Stack μπορεί να μοντελοποιηθεί μπορεί να προσαρμοστεί

738
00:56:31,600 --> 00:56:38,400
για να χρησιμοποιεί τα καλύτερα ερωτήματα που είναι δυνατά για την υποδομή.

739
00:56:38,400 --> 00:56:43,520
Όπως είπαμε το Kibana είναι το ισχυρό εργαλείο για την οπτικοποίηση των δεδομένων που αποθηκεύονται στο

740
00:56:43,520 --> 00:56:47,680
Elasticsearch στο ELK Stack και σας επιτρέπει να δημιουργείτε

741
00:56:47,680 --> 00:56:51,360
διαδραστικά dashboards για να παρακολουθείτε και να αναλύετε τα γεγονότα.

742
00:56:51,360 --> 00:56:56,240
Χρησιμοποιώντας το Kibana οι ομάδες ασφαλείας μπορούν εύκολα να εντοπίσουν τις τάσεις ανωμαλίες

743
00:56:56,240 --> 00:57:00,000
και να παρακολουθούν βασικές μετρήσεις ασφαλείας σε πραγματικό χρόνο.

744
00:57:00,000 --> 00:57:04,320
Για να ξεκινήσετε μπορείτε να ανοίξετε το Kibana και να πλοηγηθείτε στην ενότητα dashboard.

745
00:57:04,320 --> 00:57:08,000
Από εκεί μπορείτε να δημιουργήσετε ένα νέο dashboard ειδικά για τις ανάγκες σας παρακολούθησης

746
00:57:08,000 --> 00:57:12,800
γεγονότων ασφαλείας. Προσθέτοντας διάφορες οπτικοποιήσεις στο dashboard

747
00:57:12,800 --> 00:57:16,160
θα σας βοηθήσει να παρακολουθείτε σημαντικά γεγονότα firewall και να αποκτήσετε

748
00:57:16,160 --> 00:57:21,040
διαφορετικές γνώσεις για τη δραστηριότητα δικτύου. Μία από τις πρώτες οπτικοποιήσεις

749
00:57:21,040 --> 00:57:25,280
που μπορεί να θέλετε να προσθέσετε είναι το ραβδόγραμμα (bar chart) για τις κορυφαίες

750
00:57:25,280 --> 00:57:29,840
απορριφθείσες διευθύνσεις IP. Αυτό το γράφημα θα σας δείξει τις διευθύνσεις IP

751
00:57:29,840 --> 00:57:32,560
πηγής στις οποίες έχει πιο συχνά

752
00:57:32,560 --> 00:57:37,760
απορριφθεί η πρόσβαση από το firewall. Για να το διαμορφώσετε θα συγκεντρώσετε

753
00:57:37,760 --> 00:57:43,360
δεδομένα κατά το πεδίο source IP και θα εμφανίσετε το πλήθος των ενεργειών άρνησης (deny).

754
00:57:43,360 --> 00:57:47,760
Αυτό θα σας δώσει μια γρήγορη άποψη του ποιες διευθύνσεις IP επιχειρούν πρόσβαση

755
00:57:47,760 --> 00:57:52,160
και μπλοκάρονται πιο συχνά ή δυνητικά επισημαίνοντας πηγές

756
00:57:52,160 --> 00:57:55,680
ύποπτης δραστηριότητας. Μια άλλη χρήσιμη οπτικοποίηση είναι το

757
00:57:55,680 --> 00:57:59,920
γράφημα πίτας (pie chart) για ανάλυση ενεργειών. Αυτό θα αναλύσει τις ενέργειες που λήφθηκαν

758
00:57:59,920 --> 00:58:05,040
από το firewall όπως allow έναντι deny. Το γράφημα πίτας μπορεί να διαμορφωθεί

759
00:58:05,040 --> 00:58:09,680
για να συγκεντρώνει δεδομένα κατά το πεδίο action παρέχοντας μια εύκολη στην ανάγνωση αναπαράσταση

760
00:58:09,680 --> 00:58:13,680
της κατανομής των τύπων κίνησης. Αυτή η οπτικοποίηση είναι ιδιαίτερα

761
00:58:13,680 --> 00:58:17,360
χρήσιμη για την κατανόηση της γενικής συμπεριφοράς του δικτύου της

762
00:58:17,360 --> 00:58:21,680
δραστηριότητας του firewall για παράδειγμα. Τέλος μπορείτε να δημιουργήσετε ένα γράφημα γραμμής

763
00:58:21,680 --> 00:58:26,320
για λεπτομερή αρνηθείσα πρόσβαση. Αυτή η οπτικοποίηση θα σας επιτρέψει να

764
00:58:26,320 --> 00:58:29,520
παρακολουθείτε τον αριθμό των απορριφθέντων συνδέσεων ανά ημέρα

765
00:58:29,520 --> 00:58:32,400
που μπορεί να σας βοηθήσει να εντοπίσετε τάσεις με την πάροδο του χρόνου.

766
00:58:32,480 --> 00:58:37,760
Διαμορφώνοντας αυτό το γράφημα γραμμής με ένα χρονικό εύρος 24 ωρών ή πέντε ή

767
00:58:37,760 --> 00:58:42,560
επτά ημερών θα σας επιτρέψει να παρακολουθείτε αν υπάρχουν τυχόν αιχμές στην απορριφθείσα κίνηση

768
00:58:42,560 --> 00:58:46,080
που μπορεί να υποδεικνύουν συνεχιζόμενες ή επαναλαμβανόμενες προσπάθειες παραβίασης

769
00:58:46,080 --> 00:58:49,760
του firewall ή των συστημάτων.