SAP-säkerhet - var ska man börja?

Aktie
  • Säkerhet

Under många år nu, när jag träffar C-Level och diskuterar SAP-säkerhet, får jag detta meddelande tillbaka:

“Vi har spenderat flera miljoner zloty på implementeringen av SAP och du vill säga att det inte är ett säkert system?”

Hur man än vrider och vänder på det - frågan är helt rätt ställd. När allt kommer omkring, en kraftfull leverantör, en uppsjö av implementeringspartners, enorm kompetens, verktygsutveckling och permanent stöd från tillverkaren.

Svaret på frågan är enkel - SAP är säkert, men...

“Men” nr 1 - konfiguration

Det är kundens ansvar att parametrisera systemet på rätt sätt. Det finns en mängd olika konfigurationsinställningar, vars felaktiga definition kan leda till ett antal farliga situationer.

Exempel:

Lösenorden för standardkonton bör ändras och profiler med hög behörighet (t.ex. SAP_ALL) bör tas bort.
Det viktiga är att om standardkontot tas bort kommer det att återskapas automatiskt (med standardlösenordet). SAP*-kontot bör därför få ett nytt lösenord och parametern login/no_automatic_user_sapstar bör sättas till 1 (ingen automatisk återskapande av SAP*-kontot).

Det är därför kundens ansvar att anpassa dessa parametrar till sina behov.

På den tekniska sidan svarar SAP också regelbundet på sårbarheter som hittats genom att publicera säkerhetsmeddelanden som effektivt laddar sårbarheter och risker. Det är dock upp till kunden att ladda upp notiserna på rätt sätt, och det är inte alltid lätt eller snabbt.

Exempel:

Kommunikation utan kryptering - ofta till och med påtvingad av komplexa miljöer som ansluter till systemet. Det är bara att lyssna på det interna nätverket för att få reda på innehållet i kommunikationen.

 

Notera arkitekturen ovan. Alla lager, inklusive de som ligger „under” applikationslagret, får inte glömmas bort. En korrekt parameterisering av DB eller OS är därför avgörande för att en smart användare inte ska få möjlighet att kringgå sina behörigheter.

„Men” nr 2 - bemyndiganden

När man tittar på SAP-implementeringsprojekt får man intrycket att säkerhetsfrågorna behandlas - om de alls behandlas - på ett försumbart sätt. Jag har inte sett någon SAP-implementering som på ett heltäckande sätt har tagit itu med skapandet av ett sådant behörighetskoncept, där kritiska behörigheter och behörighetskonflikter skulle vara en viktig del.

Sammantaget kan man inte bli förvånad om implementeringen måste slutföras i tid och inom budget - de viktigaste delarna av en sådan implementering är att få igång affärsfunktionerna snabbt (och jag motsätter mig inte detta på något sätt).

Slutligen tillhandahåller SAP fördefinierade roller och profiler, och det är mycket enkelt att börja arbeta med dem. Detta är en genväg som kan slå tillbaka i revisioner eller (ännu värre) i effektivt missbruk från användarnas sida.

Om vi talar om dem - användare i mogna system där de historiskt sett har „färdats” genom organisationen, har för mycket makt. Detta är en följd av denna „resa” och av en särskild funktion i SAP - positiva rättigheter. I SAP kan man inte bara subtrahera behörigheter, vektorn är bara positiv. Dessutom kommer en subtraherad behörighet i en roll att spridas till andra användare för en kort stund.

Allt detta innebär att när den berömda Smith har arbetat i en organisation i många år - den roller tillkommer oftare än de försvinner. Och här kommer vi till ett värde som inte är en fröjd för ögat:

10%

 

Detta är genomsnittligt värde på de behörigheter som används i systemen, som vi har haft möjlighet att säkerhetstesta. Detta innebär inte mindre än att 90%-tillstånden är helt enkelt onödiga. Och detta är en enkel väg till kritisk åtkomst och privilegiekonflikter, och därmed den första röda lampan vid revisioner.

Konflikter om befogenheter - Här är frågan enkel per definition.

„Behåll principen om två par ögon när du implementerar kritiska processer”.

Det finns dock hundra- och tiotusentals transaktioner som standard i SAP. Utan lämplig automatisering kan vi inte verifiera vad alla transaktioner betyder. En person som har kunskap om sitt eget modulområde känner inte till de andra, och konflikter mellan moduler är en mardröm.

I exemplet ovan var uppmärksam på kolumnen „Transaktioner”.
Kan du med hjälp av denna nomenklatur svara på frågan om vilka risker som är förknippade med en sådan uppsättning transaktioner?

Tänk om jag sa att det kan finnas hundratals sådana här konflikter?

Då blir frågan mer komplicerad.

„Men” nr 3 - övervakning

Mindre än en fjärdedel av SIEM-systemen övervakar affärsapplikationer i organisationer globalt (HPE/2016-undersökning). Det är omöjligt att skapa riskdefinitioner på ett enkelt sätt utan en noggrann riskdefinition för att SOC ska kunna tolka kritiska händelser.

Mångfalden av SAP-loggkällor är också en faktor som bidrar till bristen på insyn i vad som händer i systemet.

Ovan, ett exempel på hur timmergrupper går „runt” SAP.
Var och en av dessa loggar innebär sina egna utmaningar, t.ex. felaktig klassificering av händelser, överskrivning eller bristande läsbarhet. Och det gör att utmaningarna med SAP-övervakning inte är så lätta.

Exempel på attack

Vi råkade ut för smarta missbruk, utförda av en administratör som hanterade beställningar av varor och deras avräkning (till falska konton) med hjälp av en förberedd användare. Förfarandet pågick i ungefär ett år och skulle ha passerat obemärkt om det inte hade varit för girighet (men om det inte idag).

Administratören antog att det skulle räcka med att skapa en bakdörr för användaren på ett sådant sätt att han kunde dölja sina spår så mycket som möjligt. Processen är enkel:

Jag ändrar typen av teknisk användare till „service”. (Här ska tilläggas att en teknisk användare är en som ofta har väldigt mycket rättigheter och ingen ska kunna logga in i den i dialogläge via SAP GUI).

Efter denna ändring av SU01 skapade vi en användare med bakdörr.

Här lägger vi bara till SAP_ALL, och det finns inga gränser för våra åtgärder.

Slutligen rensar vi upp och återställer den tekniska användaren till systemläget. Hela saken tar inte mer än 5 minuter. Låt oss titta på spåren i systemet. Låt oss ta en titt på SAL:

Och där:

  • ingen profilinformation SAP_ALL
  • ingen information om hur man ändrar den tekniska användaren till serviceläge
  • i rött skapandet av en användare (ja, SAL i rött visar skapandet av varje användare, så i den dagliga verksamhetens brus är det lätt att missa).

Det är naturligtvis möjligt att använda standardverktyg som SAST Security Radar, som har sådana scenarier inbakade i sina bibliotek.

Och här en hel uppsättning varningar, till exempel:

  • växla till serviceläge och inloggning i teknisk användardialog,
  • lägg till SAP_ALL.

 

SAMMANFATTNING

SAP är säkert i sig självt. Det är dock upp till kunden att ta hand om datasäkerhetsfrågor. I just detta sammanhang är det omöjligt att bortse från de fördelar som dedikerade SAP Security-verktyg ger.

Ju mer heltäckande säkerhetsfrågorna behandlas (dvs. både övervakning, auktorisering och tekniska frågor behandlas) - desto lägre är riskerna för dina uppgifter.

SAP-säkerhet - var ska man börja?

Tomasz Jurgielewicz

Chef för säkerhetsavdelningen på Lukardi. Han har lett ett team av SAP Security-specialister i 10 år och tillhandahåller omfattande tjänster och verktyg för att säkra SAP-system och optimera licenser. Erfarenhet inom följande områden: - identifiering av behörighetskonflikter och omorganisering av behörigheter, - identifiering av SAP-sårbarheter, - integration av SIEM-lösningar med SAP, - optimering av SAP-licenser.