Du har sannsynligvis hørt om log4j-sikkerhetssårbarheten – en av de mest utbredte cybersikkerhetssårbarhetene de siste årene. Denne spesifikke sårbarheten påvirker eksepsjonelt mange, men det ville være naivt å tro at dette vil være den siste i sitt slag... eller til og med i nærheten av det.
Ettersom vi må forberede oss på det som kommer, må vi fundamentalt endre vår tilnærming til sikkerhet for å beskytte oss mot "den neste log4j".
Hva skjedde med denne log4j-sårbarheten, og hvorfor er den alvorlig?
Først, la oss starte med en rask ikke-teknisk forklaring på log4j sikkerhetssårbarheten:
Denne sårbarheten ble oppdaget i en gratis programvare med åpen kildekode kalt log4j. Programvaren brukes av tusenvis av nettsteder og applikasjoner, for å utføre helt grunnleggende funksjoner de fleste ikke tenker på, for eksempel logginformasjon for bruk av nettstedets utviklere.
Hver nettapplikasjon trenger funksjonalitet som dette, og som et resultat av det, brukes log4j over hele verden. Dessverre viser det seg at log4j har en tidligere uoppdaget sikkerhetssårbarhet der data sendt til den via den nettsiden – hvis den inneholder en spesiell sekvens av tegn – resulterer i at log4j automatisk henter ekstra programvare fra en ekstern nettside og kjører den.
Hvis en nettangriper utnytter dette, kan de få serveren som kjører log4j til å kjøre hvilken som helst programvare de vil – inkludert programvare som fullstendig kan ta over den serveren. Dette er kjent som et RCE-angrep (Remote Code Execution). Hvis de ikke blir adressert, kan nettangripere fullstendig ta over tusenvis av nettsteder og nettapplikasjoner og stjele penger, data og tilgang.
Den gode nyheten er at avbøtende tiltak er relativt enkle å implementere, men uten slike tiltak er sårbarheten ekstremt enkel å utnytte. Cybersikkerhetsselskaper som F5 har gitt ut oppdateringer med signaturgjenkjenning for å hjelpe selskaper med å beskytte seg mot dette sikkerhetsproblemet.
NSM om nulldagssårbarheter: – Svindyre
Fremtidssikre miljøene våre for det neste store smellet
For fremtiden er det viktig å trekke grensen mellom den fremtidige virkningen av denne spesifikke sårbarheten, og den fremtidige risikoen for andre, men lignende sårbarheter – som er det vi egentlig bør fokusere på.
Denne sårbarheten var alvorlig, men det betyr ikke at vi er maktesløse med vår arkitektoniske kompleksitet. Det er sant at voksende programvareavhengigheter har fått risikooverflaten til å utvide seg på måter vi ikke er rustet til å forutsi. Det som er viktig for fremtiden er å ta dette som en læringsopplevelse og jobbe med vår evne til å redusere denne risikoen. Og en av nøkkelfaktorene for å gjøre det, er å flytte sikkerheten til venstre.
(Hvis du ikke er kjent med «shift left», refererer det i hovedsak til tilnærmingen til å integrere sikkerhet tidlig i utviklingsprosessen.)
Nasjonal Sikkerhetsmyndighet (NSM) anbefalte å bruke en nettapplikasjonsbrannmur (WAF) som ett av tiltakene for å blokkere log4j. WAF kan faktisk effektivt beskytte mot denne typen trusler, men for å være effektiv må WAF selv utvikle seg og skifte til venstre.
En lett WAF som enkelt kan distribueres i alle miljøer og er optimalisert for moderne infrastruktur og utviklingsprosesser, gjør det mulig å stressteste sikkerhetspolicyene under bygge- og funksjonstestfasene til applikasjonskomponenter og APIer, før applikasjonene kjøres i et driftsmiljø. Nøkkelen er å sørge for at WAF automatiserer sikkerhetskonfigurasjon og -policyer slik at du kan klargjøre det innenfor utviklingsprosessen. Det er aldri tilgang på nok sikkerhetspersonell, så automatisering er alltid en god venn i et desentralisert miljø.
Shift Left vellykket og sikkert
Å finne riktig WAF og flytte den til venstre er imidlertid bare en del av historien. Det er friksjon mellom grupper i en moderniserende bedrift, ikke bare fordi sikkerhetskontroller og -prosesser er utdaterte, men på grunn av hvordan sikkerhetsmekanismer som møter bedriftens behov leveres til Dev og DevOps. En analogi som fungerer bra er at Security må bygge autovern, ikke porter, inn i utviklingsprosesser og pipeliner.
Altfor ofte er sikkerhet avbruddsdrevet, med sikkerhetsteam som insisterer på at utviklingen stopper opp mens de reviderer og evaluerer sikkerhetspolicyene og -prosessene. Dev og DevOps er mye lykkeligere når Security gir den typen veiledning som lar utviklingen fortsette samtidig som den sikrer at det skjer på en sikker måte. Med andre ord blir sikkerheten i seg selv like "kontinuerlig" som de andre delene av CI/CD-pipeline.
En måte å oppnå dette på er å velge sikkerhetsverktøy som kan settes inn i pipelinen som kode. Men det krever også at sikkerhetsteam endrer hvordan de tenker på sikkerhetsprosedyrer for stadig mer desentraliserte og distribuerte applikasjoner. Sikkerhetsprosedyrene i seg selv må utvikles, bli mye mer applikasjonsentriske og flyttes til venstre med hensyn til alle slags faktorer, hvordan applikasjonen er bygd, hvilke miljøer applikasjonen er distribuert til, og standard samsvarskrav.
Mens «Shift Left»-strategi og avanserte nettapplikasjonsbrannmurer unektelig er en del av bedrifters strategi, gjenstår den uforanderlige sannheten om applikasjonssikkerhet: det er ingen ensartet tilnærming, og den beste tilnærmingen for hver bedrift inkluderer flere sikkerhetslag. Nøkkelen er å sikre at hver sikkerhetsløsning effektivt passer inn i pipelinen, og utviklings- og sikkerhetsteamene kan innrette seg etter effektive retningslinjer for hvordan bedriftsapplikasjonene og APIene er sikret.
Nytt milliard-anlegg skal fylles med GPU-er
