Splunk-detectieregels migreren naar Microsoft Sentinel

Splunk-detectieregels zijn SIEM-onderdelen (Security Information and Event Management) die worden vergeleken met analyseregels in Microsoft Sentinel. In dit artikel worden de concepten beschreven die u kunt identificeren, vergelijken en migreren naar Microsoft Sentinel. De beste manier is om te beginnen met de SIEM-migratie-ervaring, die kant-en-klare (OOTB) analyseregels identificeert om deze automatisch te vertalen.

Als u de implementatie van Splunk Waarneembaarheid wilt migreren, vindt u meer informatie over het migreren van Splunk naar Azure Monitor-logboeken.

Controleregels

Microsoft Sentinel maakt gebruik van machine learning-analyses om hoogwaardige en bruikbare incidenten te maken. Sommige van uw bestaande Splunk-detecties zijn mogelijk overbodig in Microsoft Sentinel, dus migreer ze niet allemaal blind. Bekijk deze overwegingen wanneer u uw bestaande detectieregels identificeert.

• 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 verouderde regels die geen waarschuwingen hebben voor de afgelopen 6-12 maanden en bepaal of ze nog steeds relevant zijn.
• Verwijder bedreigingen op laag niveau of waarschuwingen die u regelmatig negeert.
• Bevestig verbonden gegevensbronnen en controleer uw gegevensverbindingsmethoden. Microsoft Sentinel Analytics vereist dat het gegevenstype aanwezig is in de Log Analytics-werkruimte voordat een regel wordt ingeschakeld. Ga opnieuw naar gesprekken over het verzamelen van gegevens om gegevensdiepte en breedte te garanderen in de use cases die u wilt detecteren. Gebruik vervolgens de SIEM-migratie-ervaring om ervoor te zorgen dat de gegevensbronnen correct worden toegewezen.

Regels migreren

Nadat u de Splunk-detecties hebt geïdentificeerd die moeten worden gemigreerd, bekijkt u deze overwegingen voor het migratieproces:

• Vergelijk de bestaande functionaliteit van de OOTB-analyseregels van Microsoft Sentinel met uw huidige use cases. Gebruik de SIEM-migratie om te zien welke Splunk-detecties automatisch worden geconverteerd naar OOTB-sjablonen.
• Vertaal detecties die niet zijn afgestemd op OOTB-analyseregels. De beste manier om Splunk-detecties automatisch te vertalen, is met de SIEM-migratie-ervaring.
• Ontdek meer algoritmen voor uw gebruiksvoorbeelden door communityresources zoals soc Prime Threat Detection Marketplace te verkennen.
• Detecties handmatig vertalen als ingebouwde regels niet beschikbaar zijn of niet automatisch worden vertaald. Maak de nieuwe KQL-query's en controleer de toewijzing van regels.

Zie de aanbevolen procedures voor het migreren van detectieregels voor meer informatie.

Stappen voor regelmigratie

1. Controleer of er een testsysteem is ingesteld 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 resources heeft om uw gemigreerde regels te testen.

   3. Controleer of u de vereiste gegevensbronnen hebt verbonden en controleer de methoden voor gegevensverbindingen.

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

   • Gebruik de SIEM-migratie-ervaring om vertaling en installatie van de OOTB-sjablonen te automatiseren.

     Zie De SIEM-migratie-ervaring gebruiken voor meer informatie.

   • Als u gebruikssituaties heeft die niet in de detecties worden weerspiegeld, kunt u regels maken voor uw eigen werkruimte met kant-en-klare regelsjablonen.

     Ga in Microsoft Sentinel naar de Inhoudshub.

     Filter inhoudstype voor analyseregelsjablonen .

     Zoek en installeer/werk elke bijbehorende Content Hub-oplossing of zelfstandige sjabloon voor analyseregels bij.

     Voor meer informatie, zie Kant-en-klare bedreigingsdetectie.

   • Als u detecties hebt die niet worden gedekt door de OOTB-regels van Microsoft Sentinel, probeert u eerst de SIEM-migratie-ervaring voor automatische vertaling.

   • Als de OOTB-regels en de SIEM-migratie de detectie niet volledig vertalen, maakt u de regel handmatig. In dergelijke gevallen gebruikt u de volgende stappen om uw regel te maken:

     1. Identificeer de gegevensbronnen die u wilt gebruiken in uw regel. Identificeer de Microsoft Sentinel-tabellen waarop u een query wilt uitvoeren door een toewijzingstabel te maken tussen gegevensbronnen en gegevenstabellen.

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

     3. Bepaal uw regelcriteria en logica. In deze fase kunt u regelsjablonen vinden als voorbeelden voor het maken van uw KQL-query's.

        Overweeg filters, correlatieregels, actieve lijsten, referentiesets, 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 bouw en controleer vervolgens uw KQL-query. Wanneer u uw query bekijkt, kunt u hulpbronnen voor KQL-optimalisatie overwegen.

3. Test de regel met elk van uw relevante use cases. Als er geen verwachte resultaten worden opgegeven, controleert en bewerkt u de KQL en test u deze opnieuw.

4. Houd rekening met de gemigreerde regel wanneer u tevreden bent. Maak indien nodig een playbook voor uw regelactie. Zie Bedreigingsreacties automatiseren met playbooks in Microsoft Sentinel voor meer informatie.

Meer informatie over analyseregels:

• Maak aangepaste analyseregels om bedreigingen te detecteren. Gebruik waarschuwingsgroepering om de vermoeidheid van waarschuwingen te verminderen door waarschuwingen te groeperen die binnen een bepaalde periode plaatsvinden.
• Wijs gegevensvelden toe aan entiteiten in Microsoft Sentinel om SOC-technici in staat te stellen entiteiten te definiëren als onderdeel van het bewijs dat tijdens een onderzoek moet worden bijgehouden. Met entiteitstoewijzing kunnen SOC-analisten ook profiteren van een intuïtieve [onderzoeksgrafiek] (investigation-cases.md#use-the-investigation-graph-to-deep-dive) waarmee u tijd en moeite kunt verminderen.
• Onderzoek incidenten met UEBA-gegevens, als voorbeeld van het gebruik van bewijs om gebeurtenissen, waarschuwingen en bladwijzers weer te geven die zijn gekoppeld aan een bepaald incident in het voorbeeldvenster van het incident.
• Kusto Query Language (KQL), waarmee u alleen-lezenaanvragen naar uw Log Analytics-database kunt verzenden 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

Deze tabel helpt u om het concept van een regel op basis van Kusto-querytaal (KQL) in Microsoft Sentinel te verduidelijken in vergelijking met een Splunk-detectie op basis van SPL (Search Processing Language).

Regelvoorbeelden toewijzen en vergelijken

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

Algemene zoekopdrachten

lookup opdracht: KQL-voorbeeld

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

stats opdracht: KQL-voorbeeld

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

mstats opdracht: KQL-voorbeeld

T | summarize count() by price_range=bin(price, 10.0) 

transaction opdracht: SPL-voorbeeld

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

transaction opdracht: KQL-voorbeeld

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

Hiermee row_window_session() kunt u waarden voor sessiestarts berekenen voor een kolom in een geserialiseerde rijset.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

eventstats opdracht: SPL-voorbeeld

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

eventstats opdracht: KQL-voorbeeld

Hier volgt een voorbeeld met de join instructie:

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Hier volgt een voorbeeld met de make_list instructie:

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

anomalydetection opdracht: SPL-voorbeeld

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

anomalydetection opdracht: KQL-voorbeeld

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Algemene eval opdrachten

case(X,"Y",…) Voorbeeld van SPL

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

case(X,"Y",…) KQL-voorbeeld

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

if(X,Y,Z) KQL-voorbeeld

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

isint(X) KQL-voorbeeld

iif(gettype(X) =="long","TRUE","FALSE")

isstr(X) KQL-voorbeeld

iif(gettype(X) =="string","TRUE","FALSE")

like(X,"y") voorbeeld

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

min(X,…) KQL-voorbeeld

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) KQL-voorbeeld

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

mvjoin(X,Y) KQL-voorbeeld

strcat_array(dynamic([1, 2, 3]), "->")

relative time(X,Y) KQL-voorbeeld

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

replace(X,Y,Z) KQL-voorbeeld

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

strptime(X,Y) KQL-voorbeeld

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

time() KQL-voorbeeld

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y)

Retourneert een veldwaarde van X als een tekenreeks.

• Als de waarde van X een getal is, X wordt deze opnieuw opgemaakt met een tekenreekswaarde.
• Als X een Booleaanse waarde is, X wordt deze opnieuw opgemaakt op TRUE of FALSE.
• Als X een getal is, is het tweede argument Y optioneel en kan dit zijn hex (converteert X naar een hexadecimaal getal), commas (notaties X met komma's en twee decimalen) of duration (converteert X van een tijdnotatie in seconden naar een leesbare tijdnotatie: HH:MM:SS).

tostring(X,Y) Voorbeeld van SPL

In dit voorbeeld wordt het volgende geretourneerd:

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

urldecode(X) Voorbeeld van SPL

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

KQL-voorbeeld van algemene stats opdrachten

Volgende stappen

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