DE{CODE}: Mantenere i vostri siti WordPress al sicuro durante l'aumento degli attacchi informatici globali

Unisciti agli esperti di WP Engine e Cloudflare per questa sessione specifica sulla sicurezza su come bloccare i tuoi siti web. La discussione evidenzia le recenti tendenze degli attacchi informatici insieme a esempi specifici di come WP Engine protegge i tuoi siti. Gli sviluppatori se ne andranno con un chiaro elenco di controllo dei passaggi da eseguire per proteggere i propri siti.

Slide della sessione

Trascrizione del testo completo

ERIC JONES : Benvenuto in DE{CODE} e grazie per esserti unito a quella che promette di essere un'incredibile sessione di discussione. Mi chiamo Eric Jones e sono il vicepresidente del marketing aziendale qui a WP Engine. Non potrei essere più entusiasta di moderare questa discussione oggi tra Joe Sullivan, Chief Security Officer di Cloudflare, e Brent Stackhouse, Vice President of Security per WP Engine, che insieme hanno decenni di esperienza nella sicurezza.

La nostra discussione, Keeping Your WordPress Sites Safe Amid A Rise in Global Cybersecurity Attacks, non potrebbe essere più opportuna dato che gli attacchi informatici non solo sono in aumento, ma sono ai massimi storici di tutti i tempi. Joe, perché non iniziamo da te? Mi piacerebbe sentire da una prospettiva ampia e macro quali tendenze stai vedendo nel panorama della sicurezza informatica.

JOE SULLIVAN : Certo. Sono felice di partecipare. Grazie per avermi invitato a questa conversazione. Anch'io non vedo davvero l'ora. Penso che ci siano due, immagino, megatrend nel mondo della sicurezza in questo momento. Numero uno è che è molto più importante agli occhi del mondo.

Quindi, prima di passare al lato tecnico e alle vere sfide che affrontiamo giorno dopo giorno, vale la pena dedicare un momento a osservare quanto si è evoluto il mondo della sicurezza da quando io e Brent abbiamo iniziato questa professione, come hai detto, decenni fa.

La sicurezza non è più un team o un concetto che siede nell'angolo di un'organizzazione. È centrale in tutto ciò che facciamo. Gli amministratori delegati sono ritenuti responsabili. I consigli di amministrazione pongono domande difficili. I venture capitalist non contribuiranno a meno che non vedano il giusto livello di investimento.

E, cosa ancora più importante, i nostri clienti, consumatori e acquirenti aziendali dei nostri prodotti ci chiedono molto di più. E quindi questa, per me, è la tendenza più importante e il motivo per cui stiamo avendo questa conversazione. È importante per ogni sviluppatore in ogni aspetto del proprio lavoro.

Quindi, passando a ciò che sta realmente accadendo nel mondo della sicurezza, non sta diventando più facile. E le sfide continuano ad arrivare da noi. Se stai prestando attenzione ai titoli dei giornali, hai assistito solo all'ultimo momento all'ascesa del ransomware. È davvero spaventoso.

Il ransomware ha cambiato il gioco in termini di sicurezza perché è passato dal rubare alcuni dati o esporre qualcosa al mondo alla chiusura della tua attività. E così l'intero concetto dell'importanza della sicurezza è stato amplificato da quel rischio, l'idea che potremmo svegliarci la mattina e non essere in grado di accendere i nostri laptop, non far funzionare il nostro sito web. È davvero spaventoso.

Anche le cose geopolitiche stanno davvero iniziando ad avere un impatto su tutti noi. La situazione in Ucraina non è contenuta nel mondo fisico. È fortemente nel contesto informatico in questo momento. E si sta riversando per avere un impatto sul resto di noi. Quindi gli eventi geopolitici che stanno accadendo nel mondo fisico hanno implicazioni tecniche per quelli di noi che stanno cercando di gestire attività che si trovano su Internet.

E penso che la terza cosa che vorrei menzionare da un punto di vista tecnico è che non viviamo in mondi del nostro codice. Viviamo in mondi che sono una fusione di software e codice che si uniscono per rappresentare un'organizzazione.

E così, nella sicurezza, usiamo il termine supply chain per parlare di tutto quell'altro codice e altre applicazioni e tutto ciò che diventa parte della nostra identità come azienda. Quindi, ad esempio, quando di recente ci sono state storie sulla compromissione di Okta, non era solo una questione se Okta fosse compromessa. Si trattava di stabilire se la mia azienda e tutte le altre società che utilizzano Okta fossero compromesse.

E ai miei clienti non importava di Okta. Si preoccupavano del loro uso di noi e quali controlli avevamo in atto per mitigare il rischio che Okta venisse compromesso? Quindi c'è solo molto da fare in questo momento. Ed è un buon momento per avere questa conversazione.

ERIC JONES: Joe, solo come domanda di follow-up, come pensi alla definizione delle priorità di tutte quelle sfide specifiche che hai e che ogni organizzazione di sicurezza ha?

JOE SULLIVAN: Certo. Penso che sia l'ultima domanda. Se avessimo un budget illimitato e persone illimitate che potrebbero fare il lavoro, potremmo fare tutto. Ma questa non è la realtà in nessuna organizzazione in nessuna fase del suo sviluppo.

Quindi siamo sempre in fase di definizione delle priorità. E quindi quello che direi è che devi prima dare la priorità alle basi. È scioccante vedere come una grande percentuale dei compromessi provenga da fallimenti nelle basi.

In qualità di professionisti della sicurezza, amiamo approfondire l'attacco zero-day o l'attacco O-day e osservare questa cosa davvero complicata. Ma il 90% delle volte, le compromissioni provengono da e-mail di phishing o da qualcuno che sceglie di utilizzare la stessa password utilizzata su un sito Web personale che è stato compromesso e non attiva l'autenticazione a più fattori.

Molte volte abbiamo effettivamente gli strumenti per fare bene le basi, ma non ci prendiamo il tempo per implementarle.

ERIC JONES: Sì, penso che tu stia toccando un punto cruciale della sicurezza, giusto? Che è qualcosa di cui siamo tutti responsabili. È una responsabilità condivisa in tutta l'organizzazione. Non vive solo all'interno del team di sicurezza. Vive con ogni singolo dipendente di una determinata azienda.

Brent, rivolgendomi a te, dal punto di vista di WordPress, cos'è lo stesso, cosa c'è di diverso in WordPress e quali sono alcuni dei maggiori punti di vulnerabilità che vedi nel panorama?

BRENT STACKHOUSE : Grazie, Eric, e grazie per avermi invitato. Apprezzo la condivisione del tempo con Joe. Sa un sacco di cose. Abbiamo fatto il giro dell'isolato un paio di volte. Quindi questo è affascinante.

WordPress in molti modi: la notizia è generalmente buona, nel senso che WordPress Core si differenzia da tutti i plugin, i temi e altre cose nell'ecosistema di WordPress. WordPress Core continua a essere robusto e resiliente contro gli attacchi comuni.

Quindi WordPress stesso è una piattaforma buona, stabile e forte che i clienti dovrebbero generalmente sentirsi a proprio agio nell'usare praticamente in qualsiasi contesto. La sfida è principalmente nel lato plugin delle cose, dove wordpress.org o quegli sviluppatori principali non hanno nulla a che fare generalmente con la maggior parte dei plugin e dei temi.

E la variabilità della qualità del codice, simile alle app che otterrai nel Play Store di Google o qualcosa del genere, quelle non sono scritte da, come stavo appena dicendo, Google. Non sono scritti da WordPress, questi plugin e temi e potrebbero essere qualsiasi cosa, da un singolo sviluppatore a un team. L'impronta di quei plugin o temi potrebbe essere da molto piccola a molto grande. Potrebbero avere una buona storia di patching rapido o meno.

E quindi dipende. Quindi, man mano che WordPress cresce in popolarità e l'ecosistema cresce in popolarità, puoi presumere che gli aggressori continueranno a intensificare i loro sforzi perché gli aggressori vanno dove sono i soldi, in modo simile al motivo per cui Windows ha più malware rispetto ai Mac in generale. Questo perché è lì che c'è l'impronta, ed è lì che sono i soldi.

Quindi WordPress non è diverso e man mano che aumenta di popolarità, puoi aspettarti che gli aggressori continuino a fare quello che sta facendo. La buona notizia è che, rispetto a quando ho avviato il WP Engine quattro anni fa, l'ecosistema è in gran parte più sano.

Gli sviluppatori di plug-in, gli sviluppatori di temi sono più consapevoli del fatto che riceveranno input da ricercatori di sicurezza o altre persone che notano vulnerabilità. E la maggior parte di loro sta costruendo responsabilmente quel muscolo in modo da poter girare i cerotti molto, molto rapidamente.

Quindi le cose vanno molto meglio di prima. Quattro anni fa, molti sviluppatori sono rimasti sorpresi quando si sono verificate vulnerabilità e non sono stati così rapidi o in grado di soddisfare le esigenze dei loro clienti in termini di patch regolari.

Tutti noi consumatori di tecnologia siamo abituati, cito senza virgolette, "Patch Tuesday" o i nostri aggiornamenti regolari da Apple, eccetera. Quindi non siamo sorpresi delle vulnerabilità. Saremmo, tuttavia, molto sorpresi se quel fornitore non patchasse qualcosa in modo responsabile e rapido.

Quindi l'ecosistema WordPress è in generale più sano di quanto non fosse, credo, quattro anni fa. Ancora una volta, WordPress Core è fantastico, ma penso che i plugin e i temi stiano generalmente tenendo il passo. Quindi è abbastanza positivo.

ERIC JONES: Solo per fare doppio clic su qualcosa che hai detto su WordPress Core, di cosa si tratta proprio nella natura stessa del software open source che forse aiuta con quel problema relativo alla sua sicurezza? Perché penso che sia una di quelle idee sbagliate e miti là fuori che in qualche modo il software open source non sia fondamentalmente sicuro.

BRENT STACKHOUSE: Beh, questa è un'ottima domanda. E sarei interessato ai pensieri di Joe su questo. E non per prenderti in giro, Eric, ma sono abbastanza grande. Ho visto cosa intendiamo per open source cambiare parecchio nel tempo.

L'open source in passato era un progetto molto noto come Apache, o, diciamo, OpenSSH, o, diciamo, Linux, e cose del genere e quindi quando diciamo open source allora, questo è quello che di solito eravamo riferito a.

E, sì, c'erano un sacco di progetti secondari, terziari, qualsiasi cosa più piccola là fuori che non erano altrettanto ben mantenuti, ecc. altro può afferrare.

Stai parlando di librerie, codice molto piccolo che chiunque potrebbe dire, oh, sembra fantastico in base alle sue caratteristiche, che lo incorporeremo. E parlerò un po' più tardi, come ha accennato Joe con i problemi della catena di approvvigionamento. Parlerò un po' più avanti delle sfide specifiche degli sviluppatori in termini di mitigazione del rischio della catena di approvvigionamento.

Perché open source, ripenso alla tua domanda, Eric, su WordPress. È fantastico che la fonte sia là fuori. Molte persone lo stanno guardando. Penso che sia vero anche in passato con Apache e cose del genere. Tutto ciò che viene utilizzato su base diffusa riceverà un sacco di controllo sia dai buoni che dai cattivi e penso che sia una buona cosa. La sicurezza attraverso l'oscurità non è mai stata una buona pratica. E quindi avere il codice là fuori è fantastico.

Ma l'open source equivale a una sicurezza migliore rispetto a quella chiusa o viceversa è una domanda difficile a cui rispondere. Perché sono letteralmente mele e arance. Penso che WordPress come squadra abbia fatto un ottimo lavoro utilizzando altri input diversi dalla propria intelligenza, come l'utilizzo di un programma di bug bounty. WordPress Core lo fa da anni. Penso che sia intelligente.

Indubbiamente hanno ricercatori non affiliati che li eseguono regolarmente con i loro risultati. E i team intelligenti prendono questi input e fanno la cosa giusta. Sono sicuro che si stanno sottoponendo a test con la penna, ecc. Quindi facciamo cose simili su WP Engine, ma è una specie di norma per il corso.

Joe, qualche idea in merito? Mi dispiace subentrare, Eric, ma–

ERIC JONES: No, è perfetto.

JOE SULLIVAN: Penso che tu abbia colpito molto nei punti più alti. Quando penso al soft open source, quando penso al software da qualsiasi fonte, penso che dobbiamo valutarlo prima di inserirlo nel nostro ambiente. E a volte il software open source sarà la scelta migliore rispetto a qualcosa di proprietario. Perché sai cosa? La luce solare uccide l'infezione.

E quello che abbiamo con un sacco di software open source è che anche molte altre persone lo stanno guardando. Penso che sia qualcosa nel mondo della sicurezza in generale che non facciamo abbastanza bene se ci sediamo tutti nei nostri piccoli team e angoli, e proviamo a risolvere tutto da soli.

Coinvolgere la comunità è una buona cosa. La trasparenza e il dialogo sui rischi relativi a particolari software sono una buona cosa. E stiamo migliorando. Il tuo esempio di un programma di bug bounty è un altro modo per portare trasparenza e invitare terze parti a fare buchi.

Il software open source ha molte persone che lo guardano quando parliamo dei pezzi di software open source più utilizzati e più importanti. Ma allo stesso modo, non prenderei semplicemente del codice da GitHub e lo inserirei nel mio prodotto senza esaminarlo veramente.

Direi anche che è necessario esercitare la stessa cautela quando si acquista una licenza per software proprietario. Devi ancora guardare chi lo sta facendo, quali pratiche hanno e quanto è robusto.

BRENT STACKHOUSE: Sì, molto si tratta di– e questo è un termine nerd del rischio– ma di sicurezza. Quale garanzia possiamo ottenere per tutto ciò che stiamo facendo in senso tecnico di quanto siamo sicuri una volta che facciamo A, B, C. E molte assicurazioni, a seconda della situazione con closed source, è più difficile da ottenere.

Nell'open source, puoi avere un'idea migliore più facilmente di chi ha fatto cosa controllare il codice. È un po' più complicato con il codice sorgente chiuso. Devi utilizzare input indiretti che dimostrano che questa azienda ha adottato buone pratiche di sicurezza nel tempo, ecc.

Ma, sì, ottenere garanzie è alla fine della giornata ciò che stai cercando di fare quando stai implementando, utilizzando qualsiasi tecnologia in generale. Grazie.

ERIC JONES: Quindi, per gli sviluppatori che sono là fuori, quali sono quelle garanzie specifiche che cercate entrambi nelle aziende? Se questi progetti o pezzi di software hanno queste cose, allora li consideri buoni, un po' più sicuri di quanto potrebbero essere altrimenti.

BRENT STACKHOUSE: Vuoi una risposta WordPress? Lascerò andare Joe se vuoi iniziare in generale.

ERIC JONES: Sì, Joe, se potessi fornire forse una prospettiva ampia, e poi, Brent, puoi fornire la prospettiva WordPress più specifica.

JOE SULLIVAN: Sì, quindi, da dove mi siedo, penso a questa domanda come acquirente e come venditore perché lavoro in Cloudflare, dove le persone implementano i nostri prodotti. E la domanda numero uno che ogni cliente di Cloudflare si pone prima di implementare Cloudflare è: dovrei fidarmi di Cloudflare? Perché siamo seduti di fronte a tutti i loro affari. E questo è un posto davvero rischioso per mettere qualcuno a meno che non ti fidi di loro.

Ma anche io, poiché stiamo crescendo e abbiamo bisogno di costruire i nostri prodotti, ci affidiamo anche a terzi. E quindi sono alla fine delle domande difficili, e sono alla fine delle domande difficili.

E, guarda, nessuno di noi ha il tempo di andare o le risorse per entrare e controllare ogni singola volta che lavoreremo con una terza parte. Non abbiamo squadre abbastanza grandi. Non abbiamo l'abilità impostata per. Quindi iniziamo con le certificazioni di sicurezza come concetto che conta qui.

Quando dico certificazioni, intendo cose come SOC 2, SOC 2 Type II come WP Engine, ISO 27001 o PCI. Quando senti quelle parole e certificazioni, quello che dovresti pensare è che una terza parte ha utilizzato una serie di standard riconosciuti per entrare e controllare quell'azienda e valutare se stavano soddisfacendo tutti i controlli per quell'area.

E così ognuno di noi - Cloudflare ha un rapporto SOC 2 di tipo II che possiamo condividere. WP Engine ha un report SOC 2 Type II che possiamo condividere. E la cosa bella di quando dico Tipo II, significa che non era solo un audit puntuale. È stato un lungo periodo di tempo.

Quindi, ad esempio, con il nostro SOC 2 Tipo II, significa che nell'ultimo anno, in qualsiasi momento durante il periodo in cui esiste tale certificazione, siamo stati conformi a quei controlli di sicurezza minimi. Così spesso è abbastanza per un cliente. Tipo, oh, quella compagnia ha un SOC 2 di tipo II. OK, mi fiderò di loro.

Ma allora potresti voler scavare un po' più a fondo in base alla tua implementazione specifica. Quindi, quando penso all'acquisto di un prodotto, non penso solo alla qualità del codice, ma a come si integra con il mio ambiente.

E quindi qualcosa che conta molto per me è l'autenticazione. Posso integrarlo con il mio single sign on in modo da poter gestire chi all'interno e all'esterno della mia organizzazione ha accesso ad esso? Perché è da lì che, come ho detto prima, viene una grande percentuale dei problemi di sicurezza.

Quindi vuoi scegliere prodotti come WP Engine, dove puoi integrarlo con il tuo SSO e lasciare che la sicurezza passi attraverso gli strumenti senza che tu debba fare molto lavoro pratico. Quindi, per me, sono le certificazioni più la combinazione di tutto ciò che desideri per il tuo ambiente specifico.

ERIC JONES: E, Brent, riportandoti la domanda, come ne pensi in un contesto WordPress?

BRENT STACKHOUSE: Sì, penso che sia grandioso. Quando le persone stanno cercando di estendere l'ecosistema di WordPress, per così dire, utilizzando plugin e temi, un paio di cose da cercare anche solo da un contesto aziendale o livello aziendale è, quanto è popolare questo dato pezzo di codice, plugin o tema? E posso vedere nel loro registro delle modifiche che si aggiornano regolarmente, anche per gli aggiornamenti di sicurezza?

Queste sono misure o input molto qualitativi, ma sono comunque rilevanti. In genere, gli sviluppatori di plug-in o sviluppatori di temi che hanno una grande impronta - hanno molti clienti - hanno qualcosa da perdere e da guadagnare, per così dire, mantenendo bene o male il loro codice, a seconda di come si voglio capovolgerlo. E quindi semplicemente scegliere quelli comuni più popolari per tutto ciò di cui hai bisogno è generalmente una buona pratica.

A livello di sviluppatore, puoi applicare più controllo, per così dire. È possibile utilizzare strumenti di sicurezza delle applicazioni statiche per un determinato plug-in. È probabile che tu trovi qualcosa che un altro ricercatore di sicurezza non ha? Forse no, ma è comunque una buona idea eseguire queste cose attraverso qualunque sia il tuo strumento. E ci sono molti strumenti gratuiti open source là fuori o anche strumenti commerciali con licenze a basso costo o gratuite che possono consentirti di ottenere una migliore sicurezza su qualunque codice tu stia utilizzando nel tuo ambiente.

Una cosa che Joe ha toccato e di cui parlerò un po' anche con te, è che WP Engine è sia un consumatore di codice che un produttore e quindi siamo anche un fornitore di servizi e molto preoccupati per l'integrità del nostro sforzi di sviluppo end-to-end. Ed è una sfida continua.

Quindi una delle cose per i nostri sviluppatori là fuori che gestiscono siti WordPress è che dovrebbero essere consapevoli, si spera, del contesto della loro organizzazione in merito al rischio. Ad esempio, in che verticale si trovano? Quanta tolleranza ha l'organizzazione per le cose brutte che accadono? Alcuni settori o organizzazioni sono molto più suscettibili a cose come attacchi DDoS, ecc.

Quindi, pensando a questo e potenzialmente codificando per quelle cose, non puoi codificare per DDoS, ma puoi certamente esserne consapevole e farlo emergere. È molto importante, credo, per gli sviluppatori che fanno la cosa giusta.

ERIC JONES: Cambiando marcia un po', e con l'obiettivo di provare a fornire alcune raccomandazioni molto specifiche, Joe, da una prospettiva di sicurezza di alto livello, cosa consiglieresti ai proprietari di siti web per aiutare a rafforzare la loro sicurezza?

JOE SULLIVAN: Sì, quindi per come la penso io, un'oncia di prevenzione vale una libbra di cura. E, nel contesto della sicurezza, ciò significa scegliere gli strumenti e le piattaforme giusti che utilizzerai prima di iniziare piuttosto che provare a costruire qualcosa, e ora cerchiamo di capire come avviare la sicurezza su di esso.

Quindi, quando selezioni le piattaforme, quando selezioni gli strumenti, quando selezioni il codice, devi pensarci con la sicurezza in mente fin dall'inizio. E quindi, come ho detto, se riesci a ottenere la sicurezza automaticamente attraverso gli strumenti che scegli, ti troverai in un posto molto migliore che se dovessi assumere persone per entrare dalla parte e fare un un sacco di controlli, e poi prova a sistemare tutto mentre la nave sta navigando attraverso l'oceano.

Non puoi rattopparlo in questo modo. E quindi, per me, cerco sempre, cosa ottengo fuori dagli schemi dal punto di vista della sicurezza? Quali sono le impostazioni disponibili per me? E se prendo le basi della sicurezza, penso che in realtà ci siano solo alcune aree.

Il numero uno, per me, è sempre la gestione dell'identità e degli accessi. Ecco perché ho parlato della possibilità di integrare il Single Sign-On fin dall'inizio. Se stessi avviando un'azienda, lo farei, una delle prime cose che sceglierei sarebbe la giusta configurazione Single Sign-On che si adatterà alla mia organizzazione. E proverei sempre a scegliere prodotti che si integreranno con esso.

La seconda cosa a cui penserei è, OK, avrò un sacco di codice di fronte a Internet. Come resisto agli attacchi da Internet? Dovrò seguire i miei… Brent ha menzionato gli attacchi denial of service.

Devo capire personalmente come avere bilanciatori di carico e gestire tutto ciò e acquistare prodotti come Cloudflare? Oppure è integrato con una piattaforma che sto acquistando in modo da non dover pensare alla sicurezza. So che è già lì integrato, e così via. Quindi esaminerei metodicamente i miei dipendenti e la gestione dell'identità e degli accessi, il codice rivolto a Internet.

E poi come il terzo pilastro è probabilmente - di cui non stiamo davvero parlando qui - è, come installo i laptop e cose del genere?

ERIC JONES: E, Brent, forse passando a te, quali sono alcune cose specifiche a cui gli sviluppatori di WordPress dovrebbero pensare per creare i siti più sicuri che possono?

BRENT STACKHOUSE: Sì, la mia risposta iniziale è che è interessante. Gran parte di ciò di cui stiamo parlando è una decisione su quando costruire rispetto all'acquisto. Costruirai i tuoi plugin e tutte le cose che vuoi fare per estendere il tuo ecosistema WordPress? O comprerai per così dire anche se è gratis?

Ma questo vale, penso, anche per me e Joe, nel senso che consumiamo il codice di altre persone tramite GitHub o qualsiasi altro meccanismo e potremmo plausibilmente assumere sviluppatori e fare tutto da zero. Oppure possiamo usare qualcosa che qualcun altro ha già fatto.

E perché ricreare la ruota quando non è necessario? Ma allora come si ottiene la certezza che il codice che si sta utilizzando sia in buone condizioni? Quindi, tornando a WordPress in particolare, penso che ci siano un paio di cose: questo è probabilmente buon senso per un pubblico di sviluppatori, ma lo diremo comunque. Quando stai programmando, codifica in modo sicuro, il che significa sapere cosa stai cercando di fare. Cerca di limitare ciò che stai cercando di fare in termini di funzioni o di tutti questi tipi di cose.

Ma tieni a mente la OWASP Top 10. OWASP Top 10 è probabilmente ben noto al nostro pubblico. Ma, ancora una volta, le basi sono importanti come Joe ha accennato in precedenza e quindi le basi per gli sviluppatori includono sicuramente OWASP Top 10.

E poi usa uno di quegli strumenti di sicurezza delle applicazioni statiche che ho menzionato che è molto buono prima della distribuzione o durante la distribuzione. Puoi farlo automaticamente, per così dire. E assicurati che il codice che stai inviando lì sia effettivamente in buone condizioni e che non ci siano evidenti vulnerabilità note con il tuo codice se stai sviluppando codice personalizzato.

La terza cosa si ricollega al problema della catena di approvvigionamento di cui abbiamo parlato. E GitHub ha alcune funzioni gratuite che possono effettivamente dirti quando le tue dipendenze a monte hanno vulnerabilità note. Quindi Dependabot, un bot di dipendenza, è un'ottima cosa fornita da GitHub e dovresti assolutamente averlo abilitato nei tuoi repository. E può effettivamente creare PR automaticamente. E poi avrai la possibilità di unirlo se ritieni di averne bisogno in modo che almeno le tue dipendenze a monte non abbiano alcuna vulnerabilità nota.

Presumibilmente tutto il codice ha bug anche quando lo spedisci e ha un sottoinsieme di quelli che probabilmente sono bug di sicurezza, ma almeno dobbiamo evitare le ovvie sfide a cui Joe ha accennato prima. Non vogliamo finire sui giornali perché ci manca l'ovvio. Tipo, ehi, dovresti rattoppare le cose. Quindi, sì, queste sono tre cose che penso che gli sviluppatori potrebbero tenere a mente per tenersi fuori dal fuoco, per così dire.

ERIC JONES: Immagino che la domanda per entrambi sia, quali sono le cose che vedete scendere dal luccio che non sono proprio sul radar in questo momento? E quali sono le cose a cui la gente, gli sviluppatori, i proprietari di siti web dovrebbero pensare che non sono in questo momento? E questa è una domanda aperta per entrambi.

BRENT STACKHOUSE: Beh, sì, voglio entrare perché Joe ha risposto prima alla cosa Okta. Quindi quel particolare gruppo... questo è interessante. Quindi l'abbiamo già visto. Quindi non posso nemmeno dire che questo sta quasi venendo giù dal luccio.

Ma il gruppo che ha fatto esplodere Okta e anche altri grandi nomi che non abbiamo bisogno di menzionare necessariamente in questo podcast o in questa intervista, usano principalmente tecniche di ingegneria sociale molto, molto interessanti, attacchi non molto tecnici.

E quindi forse gli sviluppatori non sono suscettibili a questo tipo di attacco. Dipende dall'organizzazione e da dove si inserisce lo sviluppatore. Ma certamente chiunque agisca come personale IT o persona con accesso alle risorse, per così dire, per una data organizzazione potrebbe benissimo essere preso di mira da attacchi di social engineering.

Quindi è qualcosa di cui non ci piace parlare perché non possiamo risolverlo tecnicamente. Ma onestamente gli umani continuano ad essere il punto debole. Attraversare la porta principale, come lo chiamiamo noi, intendendo un attacco esterno, è spesso tecnicamente più difficile e richiede più lavoro per gli aggressori. E a volte, o spesso, subiranno attacchi di social engineering. Il phishing è ancora molto, molto efficace attraverso qualsiasi mezzo.

Quindi penso che sia qualcosa che si sta dimostrando ancora una sfida. E le organizzazioni probabilmente non concentrano il proprio tempo su questo quanto dovrebbero.

JOE SULLIVAN: Sì, penso che un altro modo per dire ciò che Brent ha detto con una voce leggermente diversa sia che in realtà non voglio che gli sviluppatori passino molto tempo con una sfera di cristallo, cercando di anticipare il prossimo problema di sicurezza. È più importante avere le basi giuste.

E quelle basi si prenderanno cura della maggior parte della prossima grande cosa, qualunque essa sia. E a titolo di esempio, ho detto che c'è stato un cambiamento fondamentale in termini di comparsa del ransomware. Ha bloccato le aziende in un modo che il crimine informatico non aveva mai fatto prima.

Ma non è che esci e acquisti un prodotto per bloccare il ransomware. Torni indietro e fai esattamente le stesse cose che avresti dovuto fare già per affrontare le minacce precedenti. Cos'è il ransomware? È un software dannoso che viene inserito nel tuo ambiente.

Beh, ogni volta che un intruso entra nel tuo ambiente, va male. Quindi abbiamo il diritto: se continuiamo a concentrarci sul perimetro e non lasciamo che i nostri dipendenti vengano compromessi o il nostro codice venga compromesso, allora non dobbiamo occuparci del ransomware.

Quindi, invece di sederti e preoccuparti di quale sarà il prossimo ransomware in arrivo, continua a concentrarti sulle basi. E lasciamo che il resto di noi nel mondo della sicurezza speculi sul futuro.

ERIC JONES: Joe e Brent, grazie mille per la tua prospettiva, il tuo tempo e i tuoi consigli oggi. C'è così tanto da pensare dall'ottenere i fondamenti giusti, l'importanza della trasparenza, cosa cercare dal punto di vista di un'assicurazione.

E poi forse la cosa più importante di tutte è che la sicurezza non dovrebbe mai essere un ripensamento. Devi integrarlo fin dall'inizio. Incoraggio tutti, se siete interessati a saperne di più sulle offerte di sicurezza di WP Engine o Cloudflare, visitate i nostri siti web. E, naturalmente, in WP Engine, abbiamo una vasta gamma di informazioni sulla sicurezza a disposizione di tutti nel nostro Centro risorse se sei interessato a una specifica prospettiva di WordPress. Quindi, ancora una volta, a tutti coloro che si sono sintonizzati oggi, grazie per aver dedicato il vostro tempo e per esservi uniti a noi oggi.