Denne sårbarheten har i likhet med Log4J sårbarheten Log4Shell fått 10/10 som CVSS score. Dette betyr at den er enkel å misbruke, og at det kan ha store konsekvenser.
Anbefaling nummer 1 for begge sårbarhetene har vært/er software. For Log4Shell skulle det oppgraderes, flere ganger, mens for XZ skal det nedgraderes.
Suksessfulle hendelser skjer i tillatt trafikk
Dette er ferdig snakka, for slik er det bare. Når en sårbarhet blir kjent, evalueres den alene uten å ta hensyn til rundtomliggende systemer og tiltak. Det er forståelig, da ting blir veldig komplisert ellers.
Dette betyr da også at det antas at tingene rundt er liberalt, være seg brannmuren på selve enheten, brannmuren i nettverket, hardening av server og applikasjon, endepunktsikkerhet, osv.
For at denne spesifikke sårbarheten skal være farlig, må SSH være tillatt i nettverket, fra internett og inn, men også internt (Assume Breach). Og det er her poenget mitt kommer.
Log4J/Log4Shell og XZ sårbarhetene
Proaktiv sikkerhet er svaret. Elementene som kan og vil adressere disse to 10/10 sårbarhetene er omtalt i mitt årshjul:
- Mars: Redusér angrepsflaten i nettverket med Least Privilege prinsippet. Start med utsiden for å redusere muligheten til å komme inn til absolutt minimum. Dette er en av de første tingene som adresseres når man optimaliserer brannmurer hos kunder, og det er veldig enkelt å adressere.
- XZ sårbarheten. Hvem og hva trenger SSH tilgang, både fra internett og internt?
- April: Adresser VG testen med Least Privilege utgående for tjenester og verdier for å redusere angrepsflaten og muligheten for nedlasting av skadevare, samt etablering av bakdører. Dette er også et punkt som adresserer når optimalisering av brannmurer skjer hos kunder.
- Log4J sårbarheten. Sikre utgående hvitelisting. Tenk Kill Chain. Anta at uvedkommende er på maskinene og systemene deres.
- XZ sårbarheten. Anta at sårbarheten er utnyttet. Sikre at hvitelisting er på plass utgående mot internett for maskiner, systemer og applikasjoner.
- Juni: Øk graden av segmentering prioritert av risikovurdering. Ransomware er den største trusselen, hvordan kan dette skade? Hva bør isoleres for å redusere risiko?
- Begge nevnte sårbarheter. Anta at sårbarhetene er misbrukt og at uvedkommende er inne. Assume Breach. Vanskeliggjør videre bevegelse i systemene.
Tenk Cyber Kill Chain, og proaktiv sikkerhet
Det er mange lavthengende tiltak som ikke blir prioritert. Veldig synd. Derfor blir det også veldig stress når nye alvorlige sårbarheter blir kjent. En 10/10 sårbarhet skal man ikke ignorere, da den er alvorlig, men man må ta et helikopterview på saken. Man må se på hva sårbarheten er for noe, hvor den er, hvordan den kan utnyttes, og hva det videre kan muliggjøre.
Trusselforståelse og kompetanse er étt fokusområde. Forebyggende og proaktiv sikkerhet er et annet.
Med et årshjul for tekniske tiltak, et årshjul som aldri vil, kan eller bør stoppe opp, kan man bygge grunnmuren bedre og bedre, steg for steg. Gjøres dette kontinuerlig vil den neste 10/10 sårbarheten, eller nulldagssårbarheten, plutselig bli mye mindre skummel.
Konklusjon
Anta at du har alvorlige sårbarheter. Reduser sannsynlighet for at sårbarheten kan misbrukes.
Anta at sårbarheter misbrukes, Assume Breach, og reduser konsekvensen av det. Lagvis sikkerhet.
Leave a Reply