Goedemiddag, in eerdere artikelen maakten wij kennis met het werk van ELK Stack. Laten we nu eens kijken naar de mogelijkheden die een informatiebeveiligingsspecialist kan realiseren bij het gebruik van deze systemen. Welke logboeken kunnen en moeten worden ingevoerd in elasticsearch. Laten we eens kijken welke statistieken er kunnen worden verkregen door het opzetten van dashboards en of hier winst uit te halen is. Hoe kunt u automatisering van informatiebeveiligingsprocessen implementeren met behulp van de ELK-stack. Laten we de architectuur van het systeem opstellen. In totaal is de implementatie van alle functionaliteit een zeer grote en moeilijke taak, daarom kreeg de oplossing een aparte naam: TS Total Sight.
Momenteel winnen oplossingen die informatiebeveiligingsincidenten op één logische plek consolideren en analyseren snel aan populariteit, met als resultaat dat de specialist statistieken ontvangt en een actielijn om de staat van informatiebeveiliging in de organisatie te verbeteren. We hebben onszelf deze taak gesteld bij het gebruik van de ELK-stack en als resultaat hebben we de hoofdfunctionaliteit in 4 secties verdeeld:
- Statistieken en visualisatie;
- Detectie van informatiebeveiligingsincidenten;
- Prioritering van incidenten;
- Automatisering van informatiebeveiligingsprocessen.
Vervolgens zullen we elk afzonderlijk nader bekijken.
Detectie van informatiebeveiligingsincidenten
De belangrijkste taak van het gebruik van Elasticsearch in ons geval is het verzamelen van alleen informatiebeveiligingsincidenten. U kunt informatiebeveiligingsincidenten verzamelen via elk beveiligingsmiddel, als deze ten minste enkele manieren voor het verzenden van logboeken ondersteunen; de standaard is syslog of scp, opslaan in een bestand.
U kunt standaardvoorbeelden geven van beveiligingshulpmiddelen en meer, van waaruit u het doorsturen van logboeken moet configureren:
- Alle NGFW-tools (Check Point, Fortinet);
- Eventuele kwetsbaarheidsscanners (PT Scanner, OpenVas);
- Firewall voor webapplicaties (PT AF);
- Анализаторы netflow (Flowmon, Cisco StealthWatch);
- AD-server.
Nadat u het verzenden van logs en configuratiebestanden in Logstash heeft geconfigureerd, kunt u incidenten uit verschillende beveiligingstools correleren en vergelijken. Om dit te doen, is het handig om indexen te gebruiken waarin we alle incidenten met betrekking tot een specifiek apparaat opslaan. Met andere woorden: één index bestaat uit alle incidenten op één apparaat. Deze verdeling kan op 2 manieren worden geïmplementeerd.
De eerste optie Dit is om de Logstash-configuratie te configureren. Om dit te doen, moet u het logboek voor bepaalde velden dupliceren naar een aparte eenheid met een ander type. En gebruik dit type dan in de toekomst. In het voorbeeld worden logboeken gekloond vanaf de IPS-blade van de Check Point-firewall.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Om dergelijke gebeurtenissen op te slaan in een aparte index, afhankelijk van de logvelden, bijvoorbeeld zoals Destination IP-aanvalshandtekeningen. U kunt een soortgelijke constructie gebruiken:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
En op deze manier kunt u alle incidenten opslaan in een index, bijvoorbeeld op IP-adres of op domeinnaam van de machine. In dit geval slaan we het op in de index "smartdefense-%{dst}", op IP-adres van de handtekeningbestemming.
Verschillende producten zullen echter verschillende logvelden hebben, wat tot chaos en onnodig geheugengebruik zal leiden. En hier zul je ofwel de velden in de Logstash-configuratie-instellingen zorgvuldig moeten vervangen door vooraf ontworpen velden, die voor alle soorten incidenten hetzelfde zullen zijn, wat ook een moeilijke taak is.
Tweede implementatieoptie - dit is het schrijven van een script of proces dat in realtime toegang krijgt tot de elastische database, de nodige incidenten eruit haalt en ze opslaat in een nieuwe index, dit is een moeilijke taak, maar je kunt hiermee naar wens met logs werken, en direct correleren met incidenten van andere beveiligingsapparatuur. Met deze optie kunt u het werken met logboeken zo configureren dat het voor uw geval het nuttigst is, met maximale flexibiliteit, maar hier doet zich het probleem voor bij het vinden van een specialist die dit kan implementeren.
En natuurlijk de belangrijkste vraag: en wat kan worden gecorreleerd en gedetecteerd??
Er kunnen hier verschillende opties zijn, en het hangt af van welke beveiligingstools in uw infrastructuur worden gebruikt, een paar voorbeelden:
- De meest voor de hand liggende en, vanuit mijn oogpunt, de meest interessante optie voor degenen die een NGFW-oplossing en een kwetsbaarheidsscanner hebben. Dit is een vergelijking van IPS-logboeken en scanresultaten op kwetsbaarheden. Als er door het IPS-systeem een aanval is gedetecteerd (niet geblokkeerd) en deze kwetsbaarheid op de eindmachine op basis van de scanresultaten niet is gedicht, is het nodig om te fluiten, aangezien de kans groot is dat de kwetsbaarheid is uitgebuit .
- Veel inlogpogingen vanaf één machine op verschillende plaatsen kunnen kwaadwillige activiteiten symboliseren.
- Gebruiker downloadt virusbestanden vanwege het bezoeken van een groot aantal potentieel gevaarlijke sites.
Statistieken en visualisatie
Het meest voor de hand liggende en begrijpelijke waarvoor ELK Stack nodig is, is de opslag en visualisatie van logs, er werd getoond hoe je met Logstash vanaf verschillende apparaten logs kunt maken. Nadat de logs naar Elasticsearch zijn gegaan, kun je dashboards instellen, die ook werden genoemd , met de informatie en statistieken die u nodig heeft door middel van visualisatie.
Voorbeelden:
- Dashboard voor bedreigingspreventiegebeurtenissen met de meest kritieke gebeurtenissen. Hier kunt u weergeven welke IPS-handtekeningen zijn gedetecteerd en waar ze geografisch vandaan komen.
- Dashboard over het gebruik van de meest kritische applicaties waarvoor informatie kan lekken.
- Scanresultaten van elke beveiligingsscanner.
- Active Directory-logboeken per gebruiker.
- Dashboard voor VPN-verbindingen.
Als u in dit geval de dashboards zo configureert dat ze elke paar seconden worden bijgewerkt, kunt u een redelijk handig systeem krijgen voor het in realtime monitoren van gebeurtenissen, dat vervolgens kan worden gebruikt voor de snelste reactie op informatiebeveiligingsincidenten als u de dashboards op een aparte plek plaatst. scherm.
Prioriteit voor incidenten
In omstandigheden met een grote infrastructuur kan het aantal incidenten buiten de schaal liggen en zullen specialisten geen tijd hebben om alle incidenten op tijd af te handelen. In dit geval is het allereerst noodzakelijk om alleen die incidenten te benadrukken die een grote bedreiging vormen. Daarom moet het systeem incidenten prioriteren op basis van hun ernst in relatie tot uw infrastructuur. Het is raadzaam om voor deze gebeurtenissen een e-mail- of telegramwaarschuwing in te stellen. Prioritering kan worden geïmplementeerd met behulp van standaard Kibana-tools door visualisatie in te stellen. Maar bij notificaties is het lastiger; deze functionaliteit zit standaard niet in de basisversie van Elasticsearch, alleen in de betaalde versie. Koop daarom een betaalde versie, of schrijf opnieuw zelf een proces dat specialisten in realtime per e-mail of telegram op de hoogte stelt.
Automatisering van informatiebeveiligingsprocessen
En een van de meest interessante onderdelen is de automatisering van acties bij informatiebeveiligingsincidenten. Eerder implementeerden wij deze functionaliteit voor Splunk, hierover leest u hier iets meer over . Het hoofdidee is dat het IPS-beleid nooit wordt getest of geoptimaliseerd, hoewel het in sommige gevallen een cruciaal onderdeel is van informatiebeveiligingsprocessen. Een jaar na de implementatie van NGFW en het ontbreken van acties om IPS te optimaliseren, verzamelt u bijvoorbeeld een groot aantal handtekeningen met de actie Detecteren, die niet worden geblokkeerd, wat de staat van informatiebeveiliging in de organisatie aanzienlijk vermindert. Hieronder vindt u enkele voorbeelden van wat kan worden geautomatiseerd:
- Overdracht van IPS-handtekening van Detecteren naar Prevent. Als Prevent niet werkt voor kritische handtekeningen, dan is dit niet in orde en een ernstig gat in het beveiligingssysteem. We veranderen de actie in het beleid naar dergelijke handtekeningen. Deze functionaliteit kan worden geïmplementeerd als het NGFW-apparaat over REST API-functionaliteit beschikt. Dit is alleen mogelijk als u programmeervaardigheden heeft; u moet de benodigde informatie uit Elastcisearch halen en API-verzoeken indienen bij de NGFW-beheerserver.
- Als er meerdere handtekeningen worden gedetecteerd of geblokkeerd in het netwerkverkeer vanaf één IP-adres, dan is het zinvol om dit IP-adres een tijdje te blokkeren in het Firewall-beleid. De implementatie bestaat tevens uit het gebruik van de REST API.
- Voer een hostscan uit met een kwetsbaarheidsscanner, als deze host een groot aantal IPS-handtekeningen of andere beveiligingshulpmiddelen heeft; als het OpenVas is, kunt u een script schrijven dat via ssh verbinding maakt met de beveiligingsscanner en de scan uitvoert.
TS Totaal zicht
In totaal is de implementatie van alle functionaliteit een zeer grote en moeilijke taak. Zonder programmeervaardigheden kunt u de minimale functionaliteit configureren, die voldoende kan zijn voor gebruik in de productie. Maar als u geïnteresseerd bent in alle functionaliteit, kunt u op TS Total Sight letten. Meer details vindt u op onze . Als gevolg hiervan zal het gehele werkingsschema en de architectuur er als volgt uitzien:
Conclusie
We hebben gekeken naar wat er met de ELK Stack kan worden geïmplementeerd. In volgende artikelen zullen we afzonderlijk dieper ingaan op de functionaliteit van TS Total Sight!
Dus blijf op de hoogte (, , , ), .
Bron: www.habr.com