Taggat med: SBOM

Docker SBOM

Docker har precis släppt en ny funktion som gör det möjligt att skapa en Software Bill Of Materials (SBOM) på en docker-image. Förutom att det är ett krav på amerikanska myndigheter att upprätta en SBOM så är det säkerhetsmässigt mycket bra att veta exakt vilka beroenden som återfinnes i ett IT-system eller mjukvara. Vid sårbarheter såsom den i log4j går det snabbare och enklare att identifiera var sårbara bibliotek återfinnes.

syft

Dockers sbom-funktion bygger på open-source projektet Syft. Och följande paket stödjer docker sbom/syft att identifiera i containers:

  • Alpine (apk)
  • Dart (pubs)
  • Debian (dpkg)
  • Go (go.mod, Go binaries)
  • Java (jar, ear, war, par, sar)
  • JavaScript (npm, yarn)
  • Jenkins Plugins (jpi, hpi)
  • PHP (composer)
  • Python (wheel, egg, poetry, requirements.txt)
  • Red Hat (rpm)
  • Ruby (gem)
  • Rust (cargo.lock)

Och för att skapa själva rapporten så finns ett antal olika SBOM-format såsom spdx, cyclonedx, json och text. Jag testade att snabbt jämföra debian med alpine utan några extra paket och då såg det ut så här:

  • Alpine – 14 paket (apk)
  • Debian – 96 paket (deb)
  • Alma Linux – 153 paket (rpm)
  • Rocky Linux – 151 paket (rpm)

Och tittar vi på hur en text-rapport från alpine:latest ser ut som är skapad med hjälp av kommandot docker sbom alpine:latest

Syft v0.43.0
 ✔ Loaded image
 ✔ Parsed imag
 ✔ Cataloged packages      [14 packages]

NAME                    VERSION      TYPE
alpine-baselayout       3.2.0-r18    apk
alpine-keys             2.4-r1       apk
apk-tools               2.12.7-r3    apk
busybox                 1.34.1-r5    apk
ca-certificates-bundle  20211220-r0  apk
libc-utils              0.7.2-r3     apk
libcrypto1.1            1.1.1n-r0    apk
libretls                3.3.4-r3     apk
libssl1.1               1.1.1n-r0    apk
musl                    1.2.2-r7     apk
musl-utils              1.2.2-r7     apk
scanelf                 1.3.3-r0     apk
ssl_client              1.34.1-r5    apk
zlib                    1.2.12-r0    apk

Hjälptext för docker sbom:

Observera att docker sbom bara finns i Docker Desktop från version 4.7.0 än så länge. Men givetvis går syft att ladda hem och köra separat.

Tips för att höja cybersäkerheten

Tips för att höja cybersäkerheten

Med anledning av senaste tidens händelser och en ökad hotbild på cyberarenan så tänkte jag passa på att skriva ner några bra tips och råd på hur Er organisation kan höja cybersäkerheten.

Cyberresiliens och överbelastningsattacker

Er hemsida kan utsättas för överbelastningsattacker eller DDoS som det också brukar kallas. Antagonisten kommer att försöka identifiera kritiska punkter och skicka anrop om och om igen till dessa. Därför är det viktigt att se över hela den exponering som återfinnes mot Internet. Glöm inte API:er, subdomäner, DNS, SMTP osv.

Se till att ha en nödsajt samt alternativa vägar för att kommunicera inom Er organisation. Om internetförbindelsen går ner till Er organisation eller om tjänster såsom Slack går ner på grund av ökad belastning, hur kan ni då kommunicera? Om ni använder tjänster såsom Cloudfront, Akamai eller Cloudflare, se då till att den bakomliggande infrastrukturen inte går att nås via utanför dessa tjänster.

Internetexponering

Att veta hur organisationen ser ut från internet är otroligt viktigt. För det är just på dessa exponerade punkter som antagonisten kommer att fokusera först på. Kontrollera därför Er domän eller IP-adresser mot följande tjänster:

360PassiveDNS, ARIN, Ahrefs, AlienVault, AnubisDB, BinaryEdge, BGPView, BufferOver, BuiltWith, C99, Chaos, CIRCL, Censys, CommonCrawl, DNSdumpster, DNSDB, DNSlytics, DNSRepo, Detectify, FOFA, FullHunt, GitHub, GitLab, Greynoise, HackerTarget, Hunter, IntelX, IPdata, IPinfo, Maltiverse, Mnemonic, N45HT, NetworksDB, ONYPHE, PassiveTotal, PentestTools, Quake, RADb, Robtex, SecurityTrails, ShadowServer, Shodan, SonarSearch, Spamhaus, Spyse, Sublist3rAPI, TeamCymru, ThreatBook, ThreatCrowd, ThreatMiner, Twitter, Umbrella, URLScan, VirusTotal, WhoisXMLAPI, ZETAlytics, ZoomEye.

Eller använd OAWSP amass som gör det automatiskt. Använd DNS Anycast och försök att fronta via CDN och WAF. Även om jag inte är ett stort fan av Web Application Firewalls så kan det vinna Er några timmar.

Autentisering

Denna punkt har också att göra med ovan punkt. Dvs identifiera alla exponerade delar mot internet där en användare kan autentisera sig. Här är det otroligt viktigt att använda flera lager av skydd, jag rekommenderar att använda VPN som omslutning för allt. Och se till att också använda tvåfaktorsautentisering med hårdvaru-tokens såsom Yubikeys och certifikat.

Så kortfattat: Exponera inget mot internet som går att köra över VPN. Se till att den som ansluter via VPN inte kommer åt mer än nödvändigt, tänk zero-trust arkitektur.

Patchning och uppdatering

Om möjligt, se till att systemen uppdaterar sig själva automatiskt med nya säkerhetspatchar. Men var också medveten om att det finns möjlighet för bakdörrar att sig sig in den vägen. Dvs gör ett noga övervägande om för respektive nackdelar med automatiskt säkerhetspatchning. För majoriteten så är detta rätt väg att gå men inte något för alla.

Patcha inte bara mjukvaror, glöm inte heller switchar, skrivare, firmware och annat som också måste uppdatera. Och håll koll på om produkter eller system börjar närma sig End-of-Life och vad ni har för möjligheter då.

Har ni system som är äldre och som inte går att uppdatera men som ni ändå är beroende av, se till att isolera dessa extra noga. Exempelvis ett eget segment i nätverket där allt är filtrerat in och ut samt en speciell jump-host måste användas för att komma åt detta gamla system.

Härda systemen och se till att enbart mjukvaror som används exponeras eller är påslagna.

Övervaka, öva och testa

Testa säkerheten kontinuerligt med automatiska testverktyg såsom Holm Security, Detectify eller Nessus. Anlita konsulter som gör återkommande manuella penetrationstester samt genomför kodgranskning löpande om ni utvecklar mjukvara.

Öva på att återställa backup och se till att backuperna lagras offline eller på annat sätt icke åtkomliga från den ordinarie IT-infrastrukturen.

En komprometterad klient kan snabbt leda till att hela Er Windows AD-miljö blir övertagen. Se därför till att ni snabbt kan detektera om en klient börjar att bete sig suspekt. Har ni inte förmågan själva så se till att anlita ett företag som är experter på SIEM/SOC. Och vad gör ni när ni upptäcker något suspekt eller blivit utsatta för intrång, då är det bra att redan ha upparbetade kontaktvägar eller plan hur delar ska isoleras för att begränsa skada.

Glöm inte att allt ni ansluter kan producera loggfiler och hjälpa till att upptäcka intrång, syslog har funnits med länge och går att slå på och använda på nästan allt som kopplas upp.

Sammanfattning

Sist men inte minst, det ni inte känner till kan ni inte heller skydda. Se därför till att inventera och ha en god koll på vilken utrustning ni har, såväl mobiltelefoner, servrar, laptops och annat.

Administrativa konton bör användas ytterst begränsas och om möjligt med dubbelhandsfattning, tidsbegränsat eller liknande. Inventera dessa konton kontinuerligt.

Se också över beroendet gällande leverantörer, underleverantörer och tredjepartsberoenden. Upprätta en SBOM eller liknande. Jobba långsiktigt och systematiskt med cybersäkerheten och genomför omvärldsbevakning löpande, jag själv använder Twitter som en källa.

FRA FMV Försvarsmakten Säkerhetspolisen Polisen Post och Telestyrelsen MSB

Relevanta myndighetsdokument att läsa vidare:

Identifiera log4j med OSS-Fuzz och några säkerhetshöjande tips

Såhär i efterhand är det bra att dra lärdomar från log4j-sårbarheten och hur vi i framtiden kan förhindra liknande sårbarheter. En av mina personliga metoder är att genomföra fuzz-tester för att identifiera indikationer på att något är fel i ett system, bibliotek eller mjukvara.

Ett av Googles projekt som har identifierat flest antal sårbarheter genom tiderna heter OSS-Fuzz och drivs av ett antal backends såsom  libFuzzerAFL++ och Honggfuzz. I början av 2021 så fick libFuzzer stöd för att fuzza Java-kod med hjälp av Jazzer. Främst kod som är skriven JVM-baserade språk, såsom Java, Kotlin och Clojure.

Bildkälla: code-intelligence.com

För den fuzzing-kod som har hand om Remote JNDI-lookups så går den att se här. Men givetvis är fuzz-tester inte enbart den enda lösningen på att bygga säkra och robusta IT-system. Några andra säkerhetshöjande åtgärder för att försvåra attacker såsom Log4Shell (log4j) i framtiden:

  • Begränsa så att servrar och klienter inte får prata godtyckligt ut mot internet. Gäller även DNS-uppslag
  • Använd data-dioder för att föra in loggar i fysiskt separerade system. Till exempel en SOC/SIEM (airgap)
  • Se över Er software bill of materials (SBOM)
  • Genomför regelbundet automatiska och manuella penetrationstester
  • Öva regelbundet olika scenarior där ni exempelvis snabbt måste identifiera ett tredjepartsbibliotek och begränsa skadan som kan uppstå till följd av en sårbarhet
  • Se till att ni har verktyg som stödjer alla olika former av aktiviteter såsom den på raden ovan. Buzz-word för ett sådant verktyg kan vara Endpoint Detection & Response (EDR). Rekommenderar att snegla på Velociraptor (blogginlägg kommer)
  • Mjukvaror, system osv bör separeras så mycket som det går och gå med så låga behörigheter som möjligt. Se till att ha en förmåga att logga om en mjukvara avviker från detta
  • Ställ relevanta säkerhetskrav vid anskaffning av produkter och system. Följ upp så att dessa krav efterlevs

Photo by Danial Igdery on Unsplash