Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
I december 2021 gik hele cybersikkerhedsbranchen i beredskab på grund af én sårbarhed: Log4Shell.
Mange eksperter kom med dystre forudsigelser om, at den ville skabe alvorlige problemer for virksomheder verden i flere år. Log4j er nemlig ikke kun et meget udbredt logningsbibliotek, sårbarheden er også nem for trusselsaktører at udnytte.
Nu er der gået næsten et halvt år, og det er en god anledning til at gøre status. Fik Log4Shell den store betydning, som branchen forudså?
Hvad har vi lært af det? Og hvad kan virksomheder gøre for at beskytte sig?
Log4Shell-dommedagen er udeblevet
Indtil nu har Log4Shell ikke medført ligeså alvorlige konsekvenser som dem, flere eksperter forudså, da den kom frem.
Realiteten er, at der kun er et meget begrænset antal offentligt kendte cyberangreb, hvor Log4Shell reelt har spillet en rolle.
Dermed ikke sagt, at Log4Shell ingen betydning har haft.
Der er jævnligt artikler om fortsatte problemer med at patche Log4j og om hackergrupper, der aktivt forsøger at udnytte sårbarheden.
Log4j er som individuel pakke nemmere at patche end for eksempel Poodle eller Eternal Blue. Der hverken behov for at ændre protokoller eller patche tusindvis af endpoints.
Men fordi Log4j er et open-source-bibliotek kan det være en udfordring for virksomheder at finde ud af, hvor i deres systemer, de bruger det, og om de bruger det. Log4j indgår for eksempel i et hav af applikationer og software, uden at leverandørerne nødvendigvis oplyser det.
Trusselsaktører vil lede efter og udnytte Log4Shell, så længe virksomheder forsømmer at patche.
Trusselsaktører har også en tendens til at opholde sig i systemerne længe fra de får den første adgang til de udfører det egentlige angreb.
Derfor forventer jeg også, at vi kommer til at se flere cyberangreb, hvor det viser sig, at Log4Shell har spillet en rolle.
Open-source er ikke sikrere
Der en vigtig lektie at lære i kølvandet på Log4Shell: Open source-komponenter har nogle alvorlige sikkerhedsudfordringer, som virksomheder bør være bevidste om, når de vurderer deres cyberforsvar.
Open-source-biblioteker er ofte meget udbredte, og det er typisk frivillige udviklere, der håndterer dem. I deres natur er de enormt tilgængelige – også for trusselsaktører – og det er her, problemerne opstår.
Selv de største virkomheder i verden anvender open source-biblioteker og -komponenter, herunder Log4j. Men det er individuelle bidragere, der understøtter dem, og der er meget begrænset funding til det.
Open source-projekterne bliver derfor hverken udsat for regelmæssig penetrationstest eller sårbarhedsvurderinger, hvilket er utænkeligt for privat software.
Generelt er der en ide om, at open source-komponeneter er sikre nok, fordi der er mange øjne på koden, men det er ikke nødvendigvis tilfældet.
Langt størstedelen af udviklere har hverken tid eller lyst til at sætte sig ned og gennemgå et logningsbibliotek med henblik på at finde og løse eventuelle sårbarheder i koden.
For det første kan koden være svær at forstå, og for det andet er udviklere mere interesserede i at udvikle deres egen kode.
Trusselsaktører er derimod meget motiverede til at undersøge koden for at finde og udnytte ukendte sårbarheder, fordi det hjælper dem med at nå deres mål.
Resultatet er, at sårbarheder i open source kan eksistere og udnyttes i flere år, før de bliver opdaget. Med det in mente, er det ingen overraskelse, at antallet af supply chain-angreb gennem netop open source-software steg med hele 650 procent sidste år.
Virksomheder er nødt til at ruste deres cyberforsvar til at modstå problemet.
Stå stærkt mod sårbarhederne i open-source
Det er med garanti ikke sidste gang, vi ser en sårbarheder som Log4Shell.
Virksomheder beskytter sig bedst imod disse sårbarheder ved at forstå, at sikkerhedsbrud er uundgåelige og implementere en zero trust-tilgang til cybersikkerhed.
Software er komplekst, så det er ikke nok at være reaktiv og fæste sin lid til trusselsefterretnigner.
Det er afgørende at forudsætte, at malware vil finde vej ind i systemerne, og at man vil blive kompromitteret.
Derfor bør man proaktivt lede efter mistænkelig aktivitet inde bag murene ved at overvåge it-infrastrukturen i realtid.
Det giver en bedre chance for at opdage trusselsaktørers aktivitet, selv hvis deres indledningsvise sikkerhedsbrud går under radaren, og stoppe dem, før de udruller malware, krypterer filer eller stjæler forretningskritiske informationer.
Mange virksomheder oplever, at deres arbejde med cybersikkerhed bliver udfordret af mangel på kompetencer og stigende datamængder.
Derfor bliver machine learning og automatisering stadig vigtigere elementer af cybersikkehedssetuppet.
Machine learning kan fastsætte en baseline for aktivitet på netværket og automatisering af visse opgaver kan frigøre de sikkerhedsprofesionelles tid. Begge dele bidgrager til hurtigere identificering og håndtering af alvorlige sikkerhedshændelser.
Den proaktive tilgang er også vejen frem for de virksomheder, som endnu ikke har fået patchet eller identificeret alle de steder, de bruger Log4j. Ved at scanne applikationslogs for indikatorer på kompromittering, kan de nemlig opdage cyberkriminelle, der har udnyttet Log4Shell til at kompromittere dem og nu ligger og på lur i deres systemer.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
