Normaliseringsfix RSA SecurID i Logpoint

Om man använder RSA SecurID-dosor som MFA-lösning samt Logpoint som central logglösning kanske man som jag kan notera att Logpoints plugin för RSA SecurID inte tolkar loggarna riktigt rätt.

Allmänt kan det ju bli såna problem exempelvis om leverantörens plugin är byggd för en annan version av den applikation som loggas och att formatet på applikationens loggar förändrats något mellan versioner. Alternativt så är pluginen byggd fel från början.

I detta blogginlägg tänkte jag med detta exempel steg för steg visa hur man relativt enkelt kan fixa till så att loggar tolkas som önskat.

Problemet

RSA SecurID-dosor, eller ”tokens”, kan användas som en andra faktor vid vissa autentiseringar, och man har då (i en onprem-lösning) en server på vilka man administrerar dosorna, exempelvis associerar dosorna med Windows-användarnas AD-konton. SecurID-systemet på denna server skickar alltså i mitt scenario sina loggar vidare till Logpoint, där de vid ankomst normaliseras med hjälp av leverantörens (Logpoints) plugin.

Normalisering är den process där råloggarna tolkas och man extraherar intressanta fält/värde-par för att senare kunna söka i loggarna på ett smidigare och effektivare sätt, exempelvis genom en sökning som: ”user=Peder AND source_address=192.168.1.24”, eller som i bilden nedan som visar en sökning på process, action och norm_id.

Logpoints plugin normaliserar alltså inte enligt mina önskemål vid tilldelning av en dosa till en användare, detta är det jag huvudsakligen anser fel:

1. Den användare som blev tilldelad dosan ingår inte alls i normaliseringen, utan värdet för user innehåller den administratör som genomförde ändringen.
2. Serienumret på dosan ingår inte heller i normaliseringen, och är ett intressant värde man skulle vilja ha sökbart.

Dessa värden finns dock i råloggen, så de finns ju tillgängliga för normalisering och vi kan alltså fixa till det i Logpoint.

Fixen

Så för att fixa detta i Logpoint kopierar vi först Logpoints nuvarande version av RSA SecurID:s ”Normalization Package” genom att gå till:
Settings->Knowledge base->Normalization Packages, och i listan över ”Vendor packages” leta upp LP_RSA SecurID, och på dess rad klicka på ikonen för att klona den.

Man får då välja ett nytt namn, och vi lämnar rutan för Replace Exisiting icke ikryssad och klickar vidare.

Det nya paketet dyker då upp i listan ”My packages”, och vi kan där klicka på namnet för att dels ändra namnet om vi ångrade namnvalet, men framför allt lägga till en egen beskrivning vilket ju kan vara på sin plats.

Sen klickar vi på radens ikon för ”Signatures” och får då upp en lista med de olika signaturerna som logpoint letar efter för att tolka loggarna.

Vi går inte idag igenom syntaxen för signaturerna och deras regex-uttryck, men vi ser rätt lätt bland annat att signaturerna verkar skiljas åt framför allt genom att loggarna får olika värden på ”process”.

Om man jämför med vår rålogg från bild 1 är den process vi vill att Logpoint tolkar annorlunda ”audit.admin.com.rsa.authmgr.internal.admin.tokenmgt.impl.TokenAdministrationImpl”.

Det visar sig att denna process saknas i listan, och logpoint kommer då att använda signaturen längst ned (nr 644579) som är gjord som en generisk ”catch all”-signatur för alla loggar som har ett processnamn som innehåller ”audit.admin.”.

Vi ser också att det finns en signatur (nr 644578) med snarlikt namn, bortsett från att namnet slutar på ”.c” istället för ”.TokenAdministrationImpl”, varför man skulle kunna misstänka att den även i övrigt är rätt lik (om man klarar syntaxen kan man ju även kolla om den verkar stämma mot råloggen), och vi därför kanske kan använda den som mall för en ny signatur.

Klickar vi på ikonen för ”Edit Signature” på raden för signaturen vi vill använda som mall får vi upp ett fönster varifrån vi kan kopiera texten vid ”Pattern”, och sedan bara välja Cancel för att komma tillbaks till listan.

Längst upp i listan väljer vi nu ”Add” för att lägga till en egen signatur, där vi klistrar in den kopierade texten på motsvarande ställe, samt lägger till övriga uppgifter från den andra signaturen vid ”Key Values” och ”Replace Keys” så vi nu har en exakt kopia av den (vi kan dock inte spara förrän vi ändrat något, så vi avvaktar med det).

I fältet ”Example” klistrar vi även in en kopia av den rålogg vi vill normalisera, som kan hämtas exempelvis från vår ursprungliga sökning enligt bild 1.

Klickar vi nu på ”Check Pattern” kommer vi i nedre högra hörnet få ett felmeddelande om att mönstret inte matchar exemplet. Det är ju väntat för vi har inte ändrat något i mönstret än för att det ska matcha.

Men däremot är vi redo att göra våra ändringar i mönstet, och testar helt fräckt att byta ut slutet på det tidigare identifierade processnamnet ”.c” mot ”.TokenAdministrationImpl”.

När vi nu klickar på Check Pattern får vi upp ett fönster som säger att mönstret matchar exemplet, och de fält som logpoint kommer att skapa från råloggen visas. Magiskt nog ser man att ett av fälten är serial_number, och att användaren som fick sin dosa tilldelad hamnar i fältet user medan den administratör som utförde tilldelningen istället hamnar i fältet caller_user. Precis vad vi var ute efter.

Då kan vi spara signaturen genom att stänga pattern check-fönstret och sedan klicka ”Save”.

Nu finns vår nya signatur i listan, men den ligger längst ned, vilket betyder att den kommer få lägre prioritet än tidigare nämnda ”catch-all”-signatur. För att vår signatur ska träffas måste vi flytta upp den i listan så den ligger ovanför den signaturen. För att ändra ordningen i listan klickar man inte helt oväntat på ”Re-Order” längst upp ovanför listan.

I fönstret kan man nu dra och släppa signaturerna till önskad plats, och vi väljer att dra vår nyskapade (644580) upp ett steg så den ligger ovanför 644579, och när vi är nöjda sparar vi med ”Done”, och sparar sedan vårat Normalization Package med ”Submit”.

För att logpoint sen ska använda vår nyskapade normalisering istället för sin ursprungliga, går vi till:
Configuration->Normalization Policies, och söker i listan upp den normaliseringspolicy som används av enheter för SecurID, i mitt fall heter den ”RSA_Authentication_Manager” men det kan bero på konfiguration.

Klickar man på namnet får man upp vilka normaliseringspaket som används för de loggkällor som använder denna normaliseringspolicy, och vi kan i listan längst ned till höger se att den som används nu är ”LP_RSA SecurID”, alltså logpoints version, men vi kan även nu hitta vårt nyskapade paket längst ned i vänstra listan som ”Available”.

Vi byter genom att lägga det paket som ska användas, alltså vårt nya, i den högra listan. Man flyttar mellan listorna genom dubbelklick på namnen eller genom att markera och använda pilarna.

När väl vårt paket ligger i högra listan sparar vi genom ”Submit” och vi är därmed klara.

Om vi nu gör en ny sökning motsvarande vår första, kan vi nu bekräfta att våra ändringar funkat som tänkt. Nu visas det nya fältet ”serial_number”, och den användare som fick dosan tilldelad visas i fältet ”user” medan den administratör som genomförde ändringen hamnar i fältet “caller_user“. Precis enligt önskemålet, och vi kan därmed kalla oss klara.

Nu blev det här en rätt lätt fix, där vi knappt behövde bry oss om syntaxen för signaturerna och dess regex-uttryck, men vi visade idag i alla fall grunden hur man kan gå tillväga så får den intresserade titta vidare själv på hur man gör mer avancerade ändringar.

Referenser/mer info:

1. https://community.rsa.com/t5/rsa-authentication-manager/logging/ta-p/581892
2. https://community.rsa.com/t5/rsa-securid-access-knowledge/understanding-rsa-authentication-manager-logging-fields-when/ta-p/5923
3. https://docs.logpoint.com/docs/data-integration-guide/en/latest/Configuration/Normalization%20Packages.html
   (även kapitlen ”Signatures” och Normalization Packages” är relaterade och kan vara intressanta)