ALSTOM: Difference between revisions
Created page with "category:Alstom" |
Add YouTube video summaries and fix broken video embeds (HTML5video -> EmbedVideo) |
||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[category: | [[category:ALSTOM]] | ||
==Training on ELK Alstom. Dated 17 Feb 2024 - Tetra Support Staff - Biswajit Banerjee== | |||
{{#ev:youtube|R6xAaw4J0-o|640}} | |||
'''Video summary:''' Detailed 1-hour session on the ELK (Elasticsearch/Logstash/Kibana) security log monitoring platform built for Alstom, a French rail-solutions company, as part of a Central Security Program (CSP) requiring centralized log capture and alerting across their Windows and Linux estate. Architecture: an rsyslog relay server receives logs from all devices on ports 514 (TCP) and 8514 (UDP) and forwards them to a 2-node Elasticsearch cluster (both nodes configured as master, for redundancy) via Logstash, with a custom Logstash filter/pipeline tagging entries by hostname and program name. Covers building alert rules from specific Windows Event IDs (account disabled/enabled/deleted, privilege/security-group escalation, failed logins, password resets, audit log clears) and equivalent Linux alerts (sudo escalation, failed su attempts, anti-brute-force config changes), plus McAfee (ePO) event alerts and ELK's own internal health alerts (cluster health, disk/CPU usage, shard/thread-pool sizing). Also walks through building Kibana dashboards for authentication-failure trends, and the snapshot/backup mechanism -- an LVM volume shared across both nodes via NFS, snapshotted via Elasticsearch's Curator/snapshot API, which the presenter had already used once to recover from an accidental data deletion during setup. | |||
Latest revision as of 02:53, 25 July 2026
Training on ELK Alstom. Dated 17 Feb 2024 - Tetra Support Staff - Biswajit Banerjee[edit]
Video summary: Detailed 1-hour session on the ELK (Elasticsearch/Logstash/Kibana) security log monitoring platform built for Alstom, a French rail-solutions company, as part of a Central Security Program (CSP) requiring centralized log capture and alerting across their Windows and Linux estate. Architecture: an rsyslog relay server receives logs from all devices on ports 514 (TCP) and 8514 (UDP) and forwards them to a 2-node Elasticsearch cluster (both nodes configured as master, for redundancy) via Logstash, with a custom Logstash filter/pipeline tagging entries by hostname and program name. Covers building alert rules from specific Windows Event IDs (account disabled/enabled/deleted, privilege/security-group escalation, failed logins, password resets, audit log clears) and equivalent Linux alerts (sudo escalation, failed su attempts, anti-brute-force config changes), plus McAfee (ePO) event alerts and ELK's own internal health alerts (cluster health, disk/CPU usage, shard/thread-pool sizing). Also walks through building Kibana dashboards for authentication-failure trends, and the snapshot/backup mechanism -- an LVM volume shared across both nodes via NFS, snapshotted via Elasticsearch's Curator/snapshot API, which the presenter had already used once to recover from an accidental data deletion during setup.