ArcSight-detectieregels migreren naar Microsoft Sentinel

In dit artikel wordt beschreven hoe u uw ArcSight-detectieregels kunt identificeren, vergelijken en migreren naar Microsoft Sentinel analyseregels.

Regels identificeren en migreren

Microsoft Sentinel maakt gebruik van machine learning-analyse om incidenten met hoge kwaliteit en uitvoerbaar te maken. Sommige van uw bestaande detecties zijn mogelijk overbodig in Microsoft Sentinel. Migreer daarom niet al uw detectie- en analyseregels blindelings. Bekijk deze overwegingen bij het identificeren van uw bestaande detectieregels.

• Zorg ervoor dat u use cases selecteert die regelmigratie rechtvaardigen, rekening houdend met bedrijfsprioriteit en efficiëntie.
• Controleer of u Microsoft Sentinel regeltypen begrijpt.
• Controleer of u de terminologie van de regel begrijpt.
• Controleer eventuele regels die de afgelopen 6-12 maanden geen waarschuwingen hebben geactiveerd en bepaal of ze nog steeds relevant zijn.
• Elimineer bedreigingen op laag niveau of waarschuwingen die u regelmatig negeert.
• Gebruik bestaande functionaliteit en controleer of de ingebouwde analyseregels van Microsoft Sentinel uw huidige gebruiksscenario's kunnen aanpakken. Omdat Microsoft Sentinel gebruikmaakt van machine learning-analyse om incidenten met hoge kwaliteit en actie mogelijk te maken, zijn sommige van uw bestaande detecties waarschijnlijk niet meer vereist.
• Bevestig verbonden gegevensbronnen en controleer uw gegevensverbindingsmethoden. Ga opnieuw naar gesprekken over gegevensverzameling om ervoor te zorgen dat de gegevens diep en breed zijn in de gebruiksscenario's die u wilt detecteren.
• Verken communityresources zoals de SOC Prime Threat Detection Marketplace om te controleren of uw regels beschikbaar zijn.
• Overweeg of een online queryconversieprogramma, zoals Uncoder.io, voor uw regels kan werken.
• Als regels niet beschikbaar zijn of niet kunnen worden geconverteerd, moeten ze handmatig worden gemaakt met behulp van een KQL-query. Controleer de toewijzing van regels om nieuwe query's te maken.

Meer informatie over aanbevolen procedures voor het migreren van detectieregels.

Uw analyseregels migreren naar Microsoft Sentinel:

1. Controleer of u een testsysteem hebt voor elke regel die u wilt migreren.

   1. Bereid een validatieproces voor voor uw gemigreerde regels, inclusief volledige testscenario's en scripts.

   2. Zorg ervoor dat uw team nuttige bronnen heeft om uw gemigreerde regels te testen.

   3. Controleer of u alle vereiste gegevensbronnen hebt verbonden en controleer uw gegevensverbindingsmethoden.

2. Controleer of uw detecties beschikbaar zijn als ingebouwde sjablonen in Microsoft Sentinel:

   • Als de ingebouwde regels voldoende zijn, gebruikt u ingebouwde regelsjablonen om regels voor uw eigen werkruimte te maken.

     Ga in Microsoft Sentinel naar het tabblad Configuration > Analytics-regelsjablonen > en maak en werk elke relevante analyseregel bij.

     Zie Geplande analyseregels maken op basis van sjablonen voor meer informatie.

   • Als u detecties hebt die niet worden gedekt door de ingebouwde regels van Microsoft Sentinel, kunt u een online queryconversieprogramma proberen, zoals Uncoder.io om uw query's te converteren naar KQL.

     Identificeer de triggervoorwaarde en regelactie en stel vervolgens uw KQL-query samen en controleer deze.

   • Als de ingebouwde regels en een online regelconversieprogramma niet voldoende zijn, moet u de regel handmatig maken. Gebruik in dergelijke gevallen de volgende stappen om te beginnen met het maken van uw regel:

     1. Identificeer de gegevensbronnen die u in uw regel wilt gebruiken. U wilt een toewijzingstabel maken tussen gegevensbronnen en gegevenstabellen in Microsoft Sentinel om de tabellen te identificeren die u wilt opvragen.

     2. Identificeer kenmerken, velden of entiteiten in uw gegevens die u in uw regels wilt gebruiken.

     3. Identificeer uw regelcriteria en logica. In deze fase kunt u regelsjablonen gebruiken als voorbeelden voor het samenstellen van uw KQL-query's.

        Denk aan filters, correlatieregels, actieve lijsten, verwijzingssets, volglijsten, detectieafwijkingen, aggregaties, enzovoort. U kunt verwijzingen van uw verouderde SIEM gebruiken om te begrijpen hoe u de querysyntaxis het beste kunt toewijzen.

     4. Identificeer de triggervoorwaarde en regelactie en stel vervolgens uw KQL-query samen en controleer deze. Wanneer u uw query bekijkt, kunt u rekening houden met hulpmiddelen voor KQL-optimalisatie.

3. Test de regel met elk van uw relevante use cases. Als er geen verwachte resultaten worden weergegeven, kunt u de KQL controleren en deze opnieuw testen.

4. Wanneer u tevreden bent, kunt u overwegen de regel te migreren. Maak zo nodig een playbook voor uw regelactie. Zie Reactie op bedreigingen automatiseren met playbooks in Microsoft Sentinel voor meer informatie.

Meer informatie over analyseregels:

• Geplande analyseregels in Microsoft Sentinel. Gebruik waarschuwingsgroepering om de vermoeidheid van waarschuwingen te verminderen door waarschuwingen te groeperen die binnen een bepaald tijdsbestek optreden.
• Wijs gegevensvelden toe aan entiteiten in Microsoft Sentinel zodat SOC-technici entiteiten kunnen definiëren als onderdeel van het bewijs dat tijdens een onderzoek moet worden bijgehouden. Entiteitstoewijzing maakt het ook mogelijk voor SOC-analisten om te profiteren van een intuïtieve onderzoeksgrafiek die kan helpen tijd en moeite te verminderen.
• Onderzoek incidenten met UEBA-gegevens, als voorbeeld van hoe u bewijs kunt gebruiken om gebeurtenissen, waarschuwingen en bladwijzers die aan een bepaald incident zijn gekoppeld, weer te geven in het voorbeeldvenster van incidenten.
• Kusto-querytaal (KQL), waarmee u alleen-lezenaanvragen kunt verzenden naar uw Log Analytics-database om gegevens te verwerken en resultaten te retourneren. KQL wordt ook gebruikt in andere Microsoft-services, zoals Microsoft Defender voor Eindpunt en Application Insights.

Regelterminologie vergelijken

Met deze tabel kunt u het concept van een regel in Microsoft Sentinel in vergelijking met ArcSight verduidelijken.

Regelvoorbeelden toewijzen en vergelijken

Gebruik deze voorbeelden om regels van ArcSight te vergelijken en toe te wijzen aan Microsoft Sentinel in verschillende scenario's.

Filtervoorbeeld (AND): ArcSight

Hier volgt een voorbeeld van een filterregel met AND voorwaarden in ArcSight.

Filtervoorbeeld (AND): KQL

Dit is de filterregel met AND voorwaarden in KQL.

SecurityEvent
| where EventID == 4728
| where SubjectUserName =~ "AutoMatedService"
| where isnotempty(SubjectDomainName)

Bij deze regel wordt ervan uitgegaan dat de Azure Monitoring Agent (AMA) de Windows-beveiliging-gebeurtenissen verzamelt. Daarom gebruikt de regel de tabel Microsoft Sentinel SecurityEvent.

Houd rekening met deze aanbevolen procedures:

• Als u uw query's wilt optimaliseren, vermijdt u indien mogelijk hoofdlettergevoelige operators: =~.
• Gebruik == als de waarde niet hoofdlettergevoelig is.
• Bestel de filters door te beginnen met de where instructie, waarmee de meeste gegevens worden uitgefilterd.

Filtervoorbeeld (OF): ArcSight

Hier volgt een voorbeeld van een filterregel met OR voorwaarden in ArcSight.

Filtervoorbeeld (OF): KQL

Hier volgen enkele manieren om de filterregel te schrijven met OR voorwaarden in KQL.

Gebruik als eerste optie de in instructie:

SecurityEvent
| where SubjectUserName in
 ("Adm1","ServiceAccount1","AutomationServices")

Gebruik als tweede optie de or instructie:

SecurityEvent
| where SubjectUserName == "Adm1" or 
SubjectUserName == "ServiceAccount1" or 
SubjectUserName == "AutomationServices"

Hoewel beide opties qua prestaties identiek zijn, raden we de eerste optie aan, die gemakkelijker te lezen is.

Voorbeeld van geneste filter: ArcSight

Hier volgt een voorbeeld van een geneste filterregel in ArcSight.

Hier volgt een regel voor het /All Filters/Soc Filters/Exclude Valid Users filter.

Voorbeeld van geneste filter: KQL

Hier volgen enkele manieren om de filterregel te schrijven met OR voorwaarden in KQL.

Als eerste optie gebruikt u een direct filter met een where instructie:

SecurityEvent
| where EventID == 4728 
| where isnotempty(SubjectDomainName) or 
isnotempty(TargetDomainName) 
| where SubjectUserName !~ "AutoMatedService"

Als tweede optie gebruikt u een KQL-functie:

1. Sla de volgende query op als een KQL-functie met de ExcludeValidUsers alias.

       SecurityEvent
       | where EventID == 4728
       | where isnotempty(SubjectDomainName)
       | where SubjectUserName =~ "AutoMatedService"
       | project SubjectUserName
   

2. Gebruik de volgende query om de ExcludeValidUsers alias te filteren.

       SecurityEvent    
       | where EventID == 4728
       | where isnotempty(SubjectDomainName) or 
       isnotempty(TargetDomainName)
       | where SubjectUserName !in (ExcludeValidUsers)
   

Als derde optie gebruikt u een parameterfunctie:

1. Maak een parameterfunctie met ExcludeValidUsers als de naam en alias.

2. Definieer de parameters van de functie. Bijvoorbeeld:

       Tbl: (TimeGenerated:datetime, Computer:string, 
       EventID:string, SubjectDomainName:string, 
       TargetDomainName:string, SubjectUserName:string)
   

3. De parameter functie heeft de volgende query:

       Tbl
       | where SubjectUserName !~ "AutoMatedService"
   

4. Voer de volgende query uit om de parameterfunctie aan te roepen:

       let Events = (
       SecurityEvent 
       | where EventID == 4728
       );
       ExcludeValidUsers(Events)
   

Als vierde optie gebruikt u de join functie:

let events = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName) 
or isnotempty(TargetDomainName)
);
let ExcludeValidUsers = (
SecurityEvent
| where EventID == 4728
| where isnotempty(SubjectDomainName)
| where SubjectUserName =~ "AutoMatedService"
);
events
| join kind=leftanti ExcludeValidUsers on 
$left.SubjectUserName == $right.SubjectUserName

Overwegingen:

• We raden u aan een direct filter met een where instructie (eerste optie) te gebruiken vanwege de eenvoud. Vermijd voor geoptimaliseerde prestaties het gebruik van join (vierde optie).
• Als u uw query's wilt optimaliseren, vermijdt u indien mogelijk de =~!~ niet-hoofdlettergevoelige operatoren. Gebruik de == operators en != als de waarde niet hoofdlettergevoelig is.

Voorbeeld van actieve lijst (opzoeken): ArcSight

Hier volgt een actieve lijstregel (opzoeken) in ArcSight.

Voorbeeld van actieve lijst (opzoeken): KQL

Bij deze regel wordt ervan uitgegaan dat de volglijst voor Cyber-Ark uitzonderingsaccounts bestaat in Microsoft Sentinel met een accountveld.

let Activelist=(
_GetWatchlist('Cyber-Ark Exception Accounts')
| project Account );
CommonSecurityLog
| where DestinationUserName in (Activelist)
| where DeviceVendor == "Cyber-Ark"
| where DeviceAction == "Get File Request"
| where DeviceCustomNumber1 != ""
| project DeviceAction, DestinationUserName, 
TimeGenerated,SourceHostName, 
SourceUserName, DeviceEventClassID

Bestel de filters door te beginnen met de where instructie waarmee de meeste gegevens worden gefilterd.

Voorbeeld van correlatie (vergelijken): ArcSight

Hier volgt een voorbeeld van een ArcSight-regel waarmee een voorwaarde wordt gedefinieerd op basis van een set basisgebeurtenissen, met behulp van de Matching Event -instructie.

Voorbeeld van correlatie (vergelijken): KQL

let event1 =(
SecurityEvent
| where EventID == 4728
);
let event2 =(
SecurityEvent
| where EventID == 4729
);
event1
| join kind=inner event2 
on $left.TargetUserName==$right.TargetUserName

Aanbevolen procedures:

• Als u uw query wilt optimaliseren, moet u ervoor zorgen dat de kleinere tabel zich aan de linkerkant van de join functie bevindt.
• Als de linkerkant van de tabel relatief klein is (maximaal 100 K records), voegt u toe hint.strategy=broadcast voor betere prestaties.

Voorbeeld van correlatie (tijdvenster): ArcSight

Hier volgt een ArcSight-voorbeeldregel die een voorwaarde definieert op basis van een set basisgebeurtenissen, met behulp van de Matching Event instructie en de Wait time filtervoorwaarde gebruikt.

Voorbeeld van correlatie (tijdvenster): KQL

let waittime = 10m;
let lookback = 1d;
let event1 = (
SecurityEvent
| where TimeGenerated > ago(waittime+lookback)
| where EventID == 4728
| project event1_time = TimeGenerated, 
event1_ID = EventID, event1_Activity= Activity, 
event1_Host = Computer, TargetUserName, 
event1_UPN=UserPrincipalName, 
AccountUsedToAdd = SubjectUserName 
);
let event2 = (
SecurityEvent
| where TimeGenerated > ago(waittime)
| where EventID == 4729
| project event2_time = TimeGenerated, 
event2_ID = EventID, event2_Activity= Activity, 
event2_Host= Computer, TargetUserName, 
event2_UPN=UserPrincipalName,
 AccountUsedToRemove = SubjectUserName 
);
 event1
| join kind=inner event2 on TargetUserName
| where event2_time - event1_time < lookback
| where tolong(event2_time - event1_time ) >=0
| project delta_time = event2_time - event1_time,
 event1_time, event2_time,
 event1_ID,event2_ID,event1_Activity,
 event2_Activity, TargetUserName, AccountUsedToAdd,
 AccountUsedToRemove,event1_Host,event2_Host, 
 event1_UPN,event2_UPN

Voorbeeld van aggregatie: ArcSight

Hier volgt een voorbeeld van een ArcSight-regel met aggregatie-instellingen: drie overeenkomsten binnen 10 minuten.

Voorbeeld van aggregatie: KQL

SecurityEvent
| summarize Count = count() by SubjectUserName, 
SubjectDomainName
| where Count >3

Volgende stappen

In dit artikel hebt u geleerd hoe u uw migratieregels van ArcSight kunt toewijzen aan Microsoft Sentinel.