Riscurile lanțului de aprovizionare v-au doborât? Păstrează-ți calmul și fii strategic!

În mod colectiv, industria de securitate își pierde mințile atunci când sunt descoperite noi vulnerabilități în software. OpenSSL nu face excepție, iar două noi vulnerabilități au copleșit fluxurile de știri la sfârșitul lunii octombrie și începutul lunii noiembrie 2022. Descoperirea și dezvăluirea sunt doar începuturile acestui ciclu de vulnerabilitate fără sfârșit. Organizațiile afectate se confruntă cu remedieri, ceea ce este deosebit de dureros pentru cei din linia întâi a IT. Liderii de securitate trebuie să mențină o strategie eficientă de securitate cibernetică pentru a ajuta la filtrarea zgomotului asupra noilor vulnerabilități, pentru a recunoaște impactul asupra lanțurilor de aprovizionare și pentru a-și asigura activele în consecință.

Atacurile lanțului de aprovizionare nu dispar

În aproximativ un an, am suferit vulnerabilități grave în componente, inclusiv log4j, Cadrul de primăvară, și OpenSSL. Exploatarea vulnerabilităților mai vechi nu încetează niciodată din implementările care sunt configurate greșit sau care utilizează dependențe vulnerabile cunoscute. În noiembrie 2022, publicul a aflat despre un campanie de atac împotriva ramului executiv civil federal (FCEB), atribuită unei amenințări iraniene sponsorizate de stat. Această entitate federală din SUA rula infrastructura VMware Horizon care conținea vulnerabilitatea Log4Shell, care a servit ca vector de atac inițial. FCEB a fost lovit de un lanț de atac complex, care includea mișcare laterală, compromiterea acreditărilor, compromisul sistemului, persistența rețelei, ocolirea protecției punctelor terminale și cryptojacking.

Organizațiile se pot întreba „de ce să consumați OSS deloc?” după incidente de securitate din pachete vulnerabile precum OpenSSL sau Log4j. Atacurile lanțului de aprovizionare continuă să aibă o tendință ascendentă, deoarece reutilizarea componentelor are „sens de afaceri bun” pentru parteneri și furnizori. Proiectăm sisteme prin reutilizarea codului existent, mai degrabă decât construirea de la zero. Acest lucru este pentru a reduce efortul de inginerie, a scala operațional și a livra rapid. Software-ul cu sursă deschisă (OSS) este în general considerat demn de încredere în virtutea controlului public pe care îl primește. Cu toate acestea, software-ul este în continuă schimbare și problemele apar din greșeli de codare sau dependențe legate. Noi probleme sunt, de asemenea, descoperite prin evoluția tehnicilor de testare și exploatare.

Abordarea vulnerabilităților lanțului de aprovizionare

Organizațiile au nevoie de instrumente și procese adecvate pentru a asigura design-urile moderne. Abordările tradiționale, cum ar fi managementul vulnerabilităților sau evaluările punctuale nu pot ține pasul. Reglementările pot încă permite aceste abordări, ceea ce perpetuează diferența dintre „sigur” și „conform”. Majoritatea organizațiilor aspiră să obțină un anumit nivel de maturitate DevOps. „Continuu” și „automatizat” sunt trăsături comune ale practicilor DevOps. Procesele de securitate nu ar trebui să difere. Liderii de securitate trebuie să mențină concentrarea pe parcursul fazelor de construire, livrare și execuție, ca parte a strategiei lor de securitate:

• Scanare continuă în CI/CD: Încercați să securizați conductele de construcție (de exemplu, shift-stânga), dar recunoașteți că nu veți putea scana tot codul și codul imbricat. Succesul abordărilor cu schimbare la stânga este limitat de eficacitatea scanerului, corelarea rezultatelor scanerului, automatizarea deciziilor de lansare și finalizarea scanerului în ferestrele de lansare. Instrumentele ar trebui să ajute la prioritizarea riscului constatărilor. Nu toate constatările pot fi acționate și este posibil ca vulnerabilitățile să nu fie exploatate în arhitectura dvs.

• Scanare continuă în timpul nașterii: Compromisul componentelor și deviația mediului au loc. Aplicațiile, infrastructura și încărcăturile de lucru ar trebui scanate în timp ce sunt livrate, în cazul în care ceva a fost compromis în lanțul de aprovizionare digital atunci când a fost preluat din registre sau depozite și bootstrap.

• Scanare continuă în timpul de execuție: Securitatea runtime este punctul de plecare al multor programe de securitate, iar monitorizarea securității stă la baza majorității eforturilor de securitate cibernetică. Aveți nevoie de mecanisme care pot colecta și corela telemetria în toate tipurile de medii, inclusiv mediile cloud, container și Kubernetes. Persoanele colectate în timpul de execuție ar trebui să fie transmise în fazele anterioare de construire și livrare. Interacțiuni de identitate și servicii

• Prioritizează vulnerabilitățile expuse în timpul de execuție: Toate organizațiile se luptă să aibă suficient timp și resurse pentru a scana și a repara totul. Prioritizarea bazată pe risc este fundamentală pentru activitatea programului de securitate. Expunerea la internet este doar un factor. O alta este severitatea vulnerabilității, iar organizațiile se concentrează adesea pe probleme de gravitate ridicată și critică, deoarece se consideră că acestea au cel mai mare impact. Această abordare poate risipi în continuare cicluri ale echipelor de inginerie și securitate, deoarece acestea pot urmări vulnerabilități care nu se încarcă niciodată în timpul execuției și care nu pot fi exploatate. Utilizați inteligența de rulare pentru a verifica ce pachete sunt încărcate efectiv în aplicațiile și infrastructura care rulează pentru a cunoaște riscul real de securitate pentru organizația dvs.

Noi am creat îndrumări specifice produsului pentru a conduce clienții prin recenta nebunie OpenSSL.

Cea mai recentă vulnerabilitate OpenSSL și Log4Shell ne amintesc de necesitatea pregătirii pentru securitate cibernetică și a unei strategii de securitate eficiente. Trebuie să ne amintim că CVE-ID-urile sunt doar acele probleme cunoscute în software-ul sau hardware-ul public. Multe vulnerabilități nu sunt raportate, în special punctele slabe ale codului propriu sau configurările greșite ale mediului. Strategia dvs. de securitate cibernetică trebuie să țină cont de tehnologia distribuită și diversă a modelelor moderne. Aveți nevoie de un program modernizat de gestionare a vulnerabilităților care să folosească informații despre timpul de execuție pentru a prioritiza lucrările de remediere pentru echipele de inginerie. De asemenea, aveți nevoie de capabilități de detectare și răspuns a amenințărilor care corelează semnalele în medii pentru a evita surprizele.

Despre autor

Michael Isbitski, director al Strategiei de securitate cibernetică la Sysdig, a cercetat și a oferit consiliere în domeniul securității cibernetice timp de peste cinci ani. Este versat în securitatea în cloud, securitatea containerelor, securitatea Kubernetes, securitatea API, testarea securității, securitatea mobilă, protecția aplicațiilor și livrarea continuă sigură. El a ghidat nenumărate organizații la nivel global în inițiativele lor de securitate și în sprijinul afacerii lor.

Înainte de experiența sa de cercetare și consiliere, Mike a învățat multe lecții grele în linia întâi a IT, cu peste 20 de ani de experiență de practician și conducere concentrată pe securitatea aplicațiilor, managementul vulnerabilităților, arhitectura întreprinderii și ingineria sistemelor.