Log4j-sårbarheder er kommet for at blive – er du forberedt?

Den udbredte sårbarhed, der først dukkede op i Apache Log4j i 2021 vil fortsat blive udnyttet, potentielt endda på værre måder, end vi har set til dato. Det mere bekymrende aspekt af disse trusler er, at der er en god chance for, at de fortsat vil blive udnyttet måneder eller år ud i fremtiden.

Department of Homeland Security's Cyber ​​Safety Review Board debuterede i 2021 og udgav i 2022 sin indledende sikkerhedsrapport (PDF). I den kaldte bestyrelsen Log4j for en "endemisk sårbarhed", primært fordi der ikke er en omfattende "kundeliste" for Log4j, hvilket gør det til en næsten umulig opgave at holde trit med sårbarheder. En føderal kabinetsafdeling brugte endda 33,000 timer på sit Log4j-svar.

Og mange organisationer og sikkerhedsløsninger på markedet formår ikke at identificere forskellen mellem udnyttelse og sårbarhed - hvilket giver angribere mulighed for at udføre ondsindet aktivitet.

Udnyttelighed vs. sårbarhed

Et af de vigtigste problemer med cybersikkerhed i dag er at forstå forskellen mellem sårbarheder og deres alvor. Når det kommer til at måle udnyttelse versus en sårbarhed, er der stor forskel på, om en sikkerhedstrussel kan udnyttes i din virksomhed, eller om den blot er "sårbar" og ikke kan hindre virksomheden eller nå et kritisk aktiv. Sikkerhedsteams bruger for meget tid på ikke at forstå forskellen mellem de to og løser hver sårbarhed, efterhånden som den kommer, i stedet for at prioritere dem, der kan udnyttes.

Hver virksomhed har tusindvis af fælles sårbarheder og eksponeringer (CVE'er), hvoraf mange scorer højt på Common Vulnerability Scoring System (CVSS), så det er umuligt at rette dem alle. For at bekæmpe dette er håbet, at risikobaserede sårbarhedsstyringsværktøjer (RBVM) vil gøre prioritering lettere ved at afklare, hvad der kan udnyttes.

Sikkerhedsprioriteringstilgange, der kombinerer CVSS-score med RBVM-trusselsinformation, giver dog ikke optimale resultater. Selv efter at have filtreret og kun set på, hvad der kan udnyttes i naturen, har sikkerhedsteams stadig for meget at håndtere, fordi listen er lang og uoverskuelig. Og bare fordi en CVE ikke har en udnyttelse i dag, betyder det ikke, at den ikke har en i næste uge.

Som svar herpå har virksomheder tilføjet prædiktiv risiko AI, som kan hjælpe brugerne med at forstå, om en CVE kan blive udnyttet i fremtiden. Dette er stadig ikke nok og fører til for mange problemer at løse. Tusindvis af sårbarheder vil stadig vise sig at have en udnyttelse, men mange vil have andre sæt betingelser, der skal opfyldes for rent faktisk at udnytte problemet.

For eksempel med Log4j skal følgende parametre identificeres:

• Findes det sårbare Log4j-bibliotek?
• Er det indlæst af et kørende Java-program?
• Er JNDI-opslag aktiveret?
• Lytter Java til fjernforbindelser, og er der forbindelse til andre maskiner?

Hvis betingelserne og parametrene ikke er opfyldt, er sårbarheden ikke kritisk og bør ikke prioriteres. Og selvom en sårbarhed kunne udnyttes på en maskine, hvad så? Er den maskine ekstremt kritisk, eller er den måske ikke forbundet med nogen kritiske eller følsomme aktiver?

Det er også muligt, at maskinen ikke er vigtig, men den kan gøre det muligt for en angriber at fortsætte mod kritiske aktiver på mere skjulte måder. Med andre ord er kontekst nøglen - er denne sårbarhed på en potentiel angrebsvej til det kritiske aktiv? Er det nok at afskære en sårbarhed ved et chokepoint (et skæringspunkt mellem flere angrebsstier) for at forhindre angrebsstien i at nå et kritisk aktiv?

Sikkerhedsteams hader sårbarhedsprocesser og deres løsninger, fordi der er flere og flere sårbarheder - ingen kan nogensinde tørre tavlen helt ren. Men hvis de kan fokus på det, der kan skabe skader til et kritisk aktiv, kan de få en bedre forståelse af, hvor de skal starte.

Bekæmpelse af Log4j-sårbarheder

Den gode nyhed er, at korrekt sårbarhedsstyring kan hjælpe med at reducere og rette eksponeringen for Log4j-centrerede angreb ved at identificere, hvor risikoen for potentiel udnyttelse findes.

Sårbarhedshåndtering er et vigtigt aspekt af cybersikkerhed og er nødvendigt for at sikre sikkerheden og integriteten af ​​systemer og data. Det er dog ikke en perfekt proces, og sårbarheder kan stadig være til stede i systemer på trods af bedste bestræbelser på at identificere og afbøde dem. Det er vigtigt regelmæssigt at gennemgå og opdatere sårbarhedshåndteringsprocesser og -strategier for at sikre, at de er effektive, og at sårbarheder behandles rettidigt.

Fokus for sårbarhedshåndtering bør ikke kun være på selve sårbarhederne, men også på den potentielle risiko for udnyttelse. Det er vigtigt at identificere de punkter, hvor en angriber kan have fået adgang til netværket, samt de stier, de kan tage for at kompromittere kritiske aktiver. Den mest effektive og omkostningseffektive måde at mindske risiciene ved en bestemt sårbarhed på er at identificere forbindelserne mellem sårbarheder, fejlkonfigurationer og brugeradfærd, som kan udnyttes af en angriber, og proaktivt løse disse problemer, før sårbarheden udnyttes. Dette kan være med til at forstyrre angrebet og forhindre skader på systemet.

Du bør også gøre følgende:

• Lappe: Identificer alle dine produkter, der er sårbare over for Log4j. Dette kan gøres manuelt eller ved at bruge open source scannere. Hvis en relevant patch er frigivet til et af dine sårbare produkter, skal du patch systemet ASAP.
• løsning: På Log4j versioner 2.10.0 og nyere, i Java CMD-linjen, skal du indstille følgende: log4j2.formatMsgNoLookups=true
• Blok: Hvis det er muligt, skal du tilføje en regel til din webapplikations firewall for at blokere: "jndi:"

Perfekt sikkerhed er en uopnåelig bedrift, så det giver ingen mening at gøre perfekt til det godes fjende. Fokuser i stedet på at prioritere og låse potentielle angrebsveje ned, som løbende forbedrer sikkerhedspositionen. At identificere og være realistisk omkring, hvad der faktisk er sårbart i forhold til, hvad der kan udnyttes, kan hjælpe med at gøre dette, da det vil tillade muligheden for strategisk at kanalisere ressourcer mod kritiske områder, der betyder mest.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-