Come rimanere al top della sicurezza nel 2023

La sicurezza e le prestazioni sono alla base di ogni progetto, sito, app e componente che sviluppi. Ma in questo panorama in continua evoluzione, può essere difficile rimanere al passo con le best practice fondamentali, innovando al tempo stesso.

In questa conversazione, ascolta i migliori tecnologi su come stanno mantenendo la sicurezza e le prestazioni nel 2023.

Altoparlanti:

• Ramadass Prabhakar, SVP e Chief Technology Officer di WP Engine
• Lawrence Edmondson, CTO di Barbarian
• Sergi Isasi, vicepresidente prodotto, prestazioni delle applicazioni presso Cloudflare
• Tim Nash, consulente per la sicurezza di WordPress presso timnash.co.uk
• Jimmy Squires, CTO di space150

Trascrizione:

RAMADASS: Salve a tutti. Benvenuti alla quarta edizione di Decode. È stato meraviglioso vedere la crescita dei partecipanti ogni anno. Negli ultimi due anni, c'è stato un cambiamento significativo nel panorama della sicurezza in tutto il settore. Abbiamo visto bollettini di notizie regolari su violazioni della sicurezza e la sicurezza come argomento viene spesso nelle discussioni con clienti e sviluppatori. Quindi oggi abbiamo riunito un favoloso gruppo di esperti del settore appassionati di sicurezza e sono qui per rispondere alle nostre domande e condividere con noi quanto appreso. Quindi iniziamo con una breve introduzione ai nostri relatori. Lorenzo, tocca a te.

LAWRENCE EDMONDSON: Grazie mille per averci ospitato. Lawrence Edmondson qui, CTO di Barbarian. Barbarian è un'agenzia digitale a servizio completo. Ci troviamo a New York.

RAMADASS: Grazie, Lorenzo. Passo a te, Sergio.

SERGI ISASI: Grazie. Sono un vicepresidente del prodotto presso Cloudflare. Cloudflare, costruiamo prodotti che rendono qualsiasi cosa i nostri clienti e partner, come WPE, si connettono a Internet in modo più sicuro e veloce e sono a San Francisco.

MODERATORE: Grazie, Sergi. E Tim, passo a te.

TIM NASH: Sono un consulente per la sicurezza di WordPress qui nel Regno Unito. E fondamentalmente passo la mia vita a spaventare gli sviluppatori.

MODERATORE: Grazie. E Jimmy.

JIMMY SQUIRES: Sì, grazie. Sono con Space 150, anche un'agenzia digitale a servizio completo di Minneapolis e CTO lì.

MODERATORE: Grazie per aver accettato di far parte del nostro panel oggi. Quindi vorrei iniziare parlando di qualcosa di unico che state facendo oggi in sicurezza all'interno della vostra organizzazione o all'interno dei vostri team. Quindi forse iniziamo con Sergi.

SERGI ISASI: Sì, partirò dall'intro di Tim, dove spaventa gli sviluppatori. Una delle cose che stiamo cercando di fare di più in Cloudflare è offrire ai nostri clienti maggiori informazioni sul loro traffico e ridurre il carico operativo. Quindi storicamente, se volessi trovare cosa potrebbe influenzare la tua rete, cosa potrebbe attaccare potresti vedere, distribuiresti un WAF, lo metteresti in modalità registro e poi avresti un analista della sicurezza che guarda i registri e vedere cosa ha rilevato. E ci sono solo molte meno risorse per farlo in questi giorni.

Quindi il nostro obiettivo per quest'anno è fornire informazioni ai nostri clienti sugli attacchi che vediamo su di loro, anche se non stanno utilizzando il prodotto che impedirebbe quell'attacco oggi. In questo modo possono sapere se la loro applicazione è sotto attacco o in generale in buone condizioni. E questo è il nostro obiettivo per il resto dell'anno, introdurre tutti i nostri prodotti di sicurezza e far sapere ai nostri clienti cosa potrebbe accadere o cosa sta realmente accadendo sulla loro rete e se vogliono o meno bloccarla.

MODERATORE: Meraviglioso. Sembra davvero molto potente. Non vedo l'ora di saperne di più. Allora Tim, e te stesso?

TIM NASH: Quindi lavoro con molti clienti diversi, entrambe agenzie, ma anche siti web individuali più piccoli. E faccio molte revisioni del codice e revisioni del sito. E fino a quest'anno, non ho visto la crescita delle persone che si preoccupano così tanto che le persone sono abbastanza felici di ricevere una recensione e di fare solo il lavoro che dici loro di fare. Quindi, se dai loro un sacco di consigli, seguono e basta. Ma poi se torno sul sito l'anno successivo, sto solo dando loro un altro mucchio di raccomandazioni. Quindi ho visto molto un cambiamento in quest'ultimo anno di persone che si preoccupano davvero abbastanza da fare domande. E quindi per me, gli audit del codice sono stati buttati via nella grande, lunga qui riga 6, 4, 2 di questo file, blah, deve essere fatto in questo modo.

Mi sono sbarazzato di tutto questo e ho davvero iniziato a concentrarmi sull'istruzione e mi sono reso conto che, ad essere onesti, ciò che la maggior parte delle persone vuole non è che gli venga detto, devi correggere questa linea, ma per sentirlo dire, ecco come risolvere ogni linea che c'è lì. Quindi per me, il grande cambiamento e il grande cambiamento di focus è stato verso l'istruzione. E questo è qualcosa che riguarda l'intero settore. Penso che quest'anno ci siano sempre più persone che parlano di sicurezza rispetto all'anno scorso e sempre di più rispetto agli anni precedenti.

MODERATORE: No, è meraviglioso. Mi piace molto l'obiettivo di passare dal darti il ​​pesce all'insegnarti come catturarlo. Quindi è davvero–

TIM NASH: Stavo cercando di evitare a tutti i costi quell'analogia per essere un cliché.

MODERATORE: Grazie.

TIM NASH: ben fatto.

MODERATORE: Va bene, Jimmy.

JIMMY SQUIRES: Sì, penso che ci sia così tanto, ho deciso di concentrarmi su una cosa veramente specifica di cui parlare per questa risposta. E questo sta davvero limitando il tuo ambito quando hai a che fare con i token API e l'accesso. Penso che la violazione del repository Heroku, GitHub dell'anno scorso sia stata un ottimo promemoria del fatto che hai il controllo solo di così tante cose. Quindi, quando lavoriamo con i nostri sviluppatori, ricordiamo loro l'importanza di quella politica di accesso con ambito su qualsiasi piattaforma o sistema con cui potresti lavorare. Molte volte, uno sviluppatore desidera davvero un accesso piuttosto ampio all'inizio dello sviluppo solo per facilità. E a volte quelle cose che probabilmente – ci vergogniamo tutti di ammettere – non vengono ridotte al livello che dovrebbero essere prima della produzione. Quindi iniziare presto considerando davvero quegli ambiti di sicurezza.

MODERATORE: Grazie, Jimmy. E Lawrence, so che lavori molto anche con gli sviluppatori. Quindi cosa state cercando in quel fronte per quello?

LAWRENCE EDMONDSON: Sì, certo. Solo per costruire su ciò che ha detto Jimmy, di sicuro, entrambi lavoriamo nella pubblicità. Quindi penso che vediamo molte delle stesse sfide quando lavori nella pubblicità piuttosto che lavorare in un ambiente di prodotto. Per noi, tocchiamo molte tecnologie diverse, molti stack tecnologici diversi. Dobbiamo essere tecnicamente agnostici. Quindi quello che stiamo vedendo è che i consumatori si stanno impegnando in più modi ora attraverso dispositivi mobili e social. Alcuni anni fa, il desktop era il mezzo principale per accedere a siti e contenuti. Ora è completamente ribaltato. È passato dal desktop al mobile fino, ora, ai social.

Quindi, quindi, i tuoi livelli API e i tuoi livelli applicativi devono essere bloccati in modi che hanno un po' di sana paranoia ad essi associata. Quindi quello che stiamo vedendo è che lo spettro di attacco sta crescendo, quindi siamo costantemente alla ricerca di nuovi modi per convincere DevOps a pensare come i programmatori in modo che comprendano i possibili modi in cui le cose possono essere violate. Quindi è più o meno quello che stiamo facendo oggi.

MODERATORE: Grazie per questo. E hai menzionato come il vettore di attacco sta aumentando. Ed è qualcosa che abbiamo qui, in WP Engine, abbiamo esaminato di più da come adottare un meccanismo di difesa in profondità. Quindi non fidarti di nessun livello per essere sicuro. E quindi come lo incorpori nel modo in cui codifichi e nel modo in cui scrivi software. Quindi grazie. Mentre tutti voi avete parlato della tendenza al cambiamento che sta avvenendo là dentro, delle violazioni che si sono verificate nell'ultimo anno. Quindi, guardando al 2023, quali sono alcuni temi o minacce principali a cui state prestando attenzione? E forse, Sergi, puoi darci il via. Sì.

SERGI ISASI: Certo. E sembrerà sciocco perché è il 2023 e dirò la parola DDOS, ma è ancora una cosa. Ed è stato davvero un cambiamento interessante negli ultimi nove, 12 mesi nel mondo DDOS. Volumetrico non è proprio un vettore DDOS in questi giorni. C'è molta meno riflessione. E dal punto di vista di un attore di minacce, è più facile lanciare un DDOS perché hai molti strumenti pronti all'uso, giusto? Siamo quasi tornati ai giorni di script TD, ma hai anche molti meno sistemi compromessi da attaccare. Quindi, se stai cercando di riflettere, non c'è molta infrastruttura gestita da qualcuno che potrebbe non aver patchato il proprio sistema, quindi puoi prendere un pacchetto e trasformarlo in 10. Non è più una cosa importante.

Quindi stanno passando al livello 7. E il livello 7 è sia più costoso da avviare in quanto è necessaria molta CPU per farlo, ma è anche molto più costoso da mitigare. Quindi, se hai una sorta di sistema di protezione DDOS, devi effettivamente accettare la connessione, esaminarla e quindi iniziare a rilasciarla rispetto a qualcosa che potresti rilasciarla a un livello inferiore. Quello che abbiamo trovato e abbiamo mitigato il più grande DDOS Layer 7 segnalato solo il mese scorso mai registrato. Il grande tema di questi attacchi sono i dispositivi più potenti.

Quindi, se pensi a tutte le cose che abbiamo collegato a casa in questi giorni, il processore su quel dispositivo è significativamente migliore rispetto a tre o quattro anni fa. Quindi la tua fotocamera fa molto di più. Quindi ha una CPU più robusta, anche i tuoi router sono in realtà una macchina abbastanza potente. E qualsiasi compromissione a quei dispositivi può consentire un grande, grande attacco, soprattutto perché, se ne comprometti uno, ora comprometti praticamente tutti quelli che sono connessi.

L'altra cosa di cui parliamo un po' in questi giorni, ma è un po' più tranquilla, è che siamo passati da dispositivi hardware compromessi ad account compromessi sui servizi cloud. I servizi cloud hanno una CPU effettivamente illimitata. Quindi, se posso accedere a un numero di account individuali o aziendali e far girare tutto ciò che voglio in quel sistema cloud, posso quindi lanciare un attacco estremamente ampio. Ed è quello che stiamo vedendo negli attacchi da record. Quindi sì, 2023, ancora DDOS, ancora una cosa, ma ora al livello 7 rispetto ai livelli inferiori.

MODERATORE: Grazie. È spaventoso, ma allo stesso tempo, penso che indichi come continuiamo a migliorare i nostri protocolli di sicurezza e l'area di interesse continua a crescere. Lo so, Lawrence, tu ed io abbiamo parlato in passato dell'intelligenza artificiale sia come boom che come minaccia. Mi piacerebbe sentire alcuni dei tuoi pensieri sull'IA generativa e su come vedi che influirà effettivamente sulla superficie della sicurezza nel 2023.

LAWRENCE EDMONDSON: Quindi sono molto eccitato, molto ottimista sull'IA. Siamo al Barbarian, ma allo stesso tempo è molto spaventoso. Il potenziale di qualcosa come un chatGPT utilizzato in modi dannosi. Quindi, ad esempio, potresti chiedere a Chat GPT di commentare il tuo codice. E in realtà fa un lavoro abbastanza decente, a seconda della lingua e di quanto sia disordinato il tuo codice, fa un ottimo lavoro. Quindi la prossima cosa, penso, vedremo è per Chat GPT– e questo potrebbe già essere in corso perché ogni giorno, c'è tipo, Chat GPT lo fa. Come oggi, ho appena visto che è in grado di rispondere in Slack e trovare risposte in Slack.

Quindi penso che la prossima cosa, in termini di sicurezza, in Chat GPT sia fare in modo che Chat GPT trovi gli exploit e scriva effettivamente il codice in codice dannoso per sfruttare davvero i punti deboli che trova. Quindi lo stiamo vedendo, specialmente il potenziale per quello nella memoria. Quindi gli attacchi di memoria non lasciano sempre una firma. Quindi i virus e gli scanner antivirus tradizionali lavorano alla ricerca delle firme di un attacco. All'interno degli attacchi alla memoria, stai attaccando l'applicazione. Stai facendo qualcosa come un overflow del buffer. Stai cercando di compromettere l'applicazione in fase di esecuzione. Penso di pensare che Chat GPT sia effettivamente pronto a farlo. E penso che sia solo una questione di tempo fino a quando non vedremo accadere il primo exploit ChatGPT su larga scala.

TIM NASH: Come immagini che accada davvero? Perché ovviamente ChatGPT, in fondo, è solo un insieme di richieste API a un server. E stai inviando una richiesta che dice, ehi, generami del codice dannoso. Lo sta riportando indietro. Voglio dire, ci sono un sacco di persone che stanno già generando codice dannoso. Come faresti a farlo diventare peggiore del codice dannoso già esistente?

LAWRENCE EDMONDSON: Quindi questa è la cosa esatta. C'è già un grande repository da cui imparare. Quindi ChatGPT, quello che fa, in realtà guarda: devi addestrare il modello. Quindi, nel tempo, gli ingegneri addestrano il modello a riconoscere quando qualcuno dice questo, questo è effettivamente ciò che intende. Quindi comprendi il contesto. Quindi è esattamente così, ma in modo diverso. Sta addestrando il modello a scrivere effettivamente il codice e cosa significa effettivamente. E alcune lingue sono molto facili. Quindi PHP, abbastanza facile scrivere codice in PHP. Queste lingue interpretate sono molto più facili. È molto più disordinato, ma rispetto a fare qualcosa come Java, che deve essere compilato, capisci cosa intendo?

Quindi penso che un modo semplice per farlo sarebbe quello di creare un modello basato su chatGPT 3 che in realtà, lo alleni a effettivamente– superi le cose di sintassi, superi tutte le cose di base dell'informatica e poi lo prendi un passo avanti e via, OK, questi pacchetti NPM hanno questi exploit. Cercalo e trova un modo per effettivamente– hanno queste vulnerabilità, mi dispiace, e cerca un modo per sfruttarle. Te lo garantisco, non siamo troppo lontani dal vedere accadere qualcosa del genere.

MODERATORE: Grazie, Lorenzo. Penso che sia un'area molto nascente. Ciò che è interessante in questo spazio riguarda solo il fatto che con l'IA, in generale, ha sia l'equilibrio di ciò per cui puoi sfruttarlo, sia che si tratti effettivamente di utilizzare queste firme per prevenire e imparare da esso per vedere come puoi impedirci di scrivere codice scadente o codice vulnerabile. E allo stesso tempo, proprio come abbiamo visto di cui la gente parla, ehi, ho scritto il mio primo plug-in in cinque minuti con Chat GPT, penso– sì, si tratta più di questo inizia a consentire alle persone di creare un po' di malware Più veloce? Ma penso che abbia entrambi gli aspetti.

Riguarda più come continuare a sfruttare uno di questi strumenti per migliorare la scrittura del codice, ma scrivere un codice più sicuro. E lo so, Tim, è un'area di tua passione. Ti piacerebbe parlare un po' di più di come vedi l'evoluzione di Secure Code nel 2023 e di cosa stai facendo in questo spazio?

TIM NASH: Beh, voglio dire, per molti versi Chat GPT ne è un buon esempio. Se stavo pensando a un vettore di attacco, sarò onesto, non stavo pensando che facesse scansioni di massa, dandogli un sacco di cose come un cattivo attore. Lo pensavo come lo sviluppatore di codice medio che stava cercando di risparmiare tempo e stava inserendo materiale in Chat GPT e buttandolo fuori e non necessariamente comprendendo appieno tutto il codice che viene scritto, prodotto, non ho scritto alcun test per procedi. Questa è solo una cosa veloce, è solo una sceneggiatura veloce, va tutto bene. Entra in produzione, non va bene e brucia tutto.

Ora questo è esattamente lo stesso di qualcosa che ogni sviluppatore fa ogni singolo giorno, a prescindere. Chat GPT non lo sta cambiando, ma lo abilita leggermente più facilmente. Dà– ci sono meno barriere.

SERGI ISASI: Sì, quindi non è proprio la stessa cosa che copiare e incollare da come Stack Overflow, che penso sia ciò a cui ti riferisci, Tim, che è praticamente tutto ciò che faccio per il codice. Ma penso che sia sicuramente un aumento dell'efficienza, sia in positivo che in negativo. Ma penso che consenta modifiche più sottili e uno sfruttamento più rapido di qualcosa che la maggior parte del motore basato sulle firme non può davvero raggiungere. Quindi davvero, quando esegui il rilevamento, devi disporre di un sistema che dica, questo sembra simile a qualcosa che ho visto in passato, invece di abbinare direttamente qualcosa che ho visto in passato. E questo è in realtà dal lato del rilevamento, probabilmente anche meglio servito con ML o AI o come vuoi chiamarlo.

Lo abbiamo imparato con il traffico automatizzato attivo, sai, fondamentalmente i robot. Il modo migliore per scoprire come aggirare il rilevamento basato sulle firme è con il machine learning. Ma ora ti stai spostando da, so assolutamente che questo è un male, a, beh, è ​​probabile che sia automatizzato, o probabilmente assomiglierà a una firma che ho visto prima, ma non una corrispondenza esatta.

MODERATORE: Meraviglioso. Grazie. Grazie, Sergi e Tim per quel contesto aggiunto. Quindi, tra i nostri partecipanti, abbiamo molti sviluppatori e agenzie che sono presenti qui oggi. E molte persone stanno pensando di stabilire le migliori pratiche, soprattutto perché gli scenari stanno cambiando in termini di vettori di minacce. Quindi quali sono alcune best practice che consiglieresti durante la creazione di un sito, un'app o una piattaforma o semplicemente quando stai iniziando un nuovo progetto. Quindi quali sono alcune cose che le persone dovrebbero cercare?

SERGI ISASI: Quindi posso iniziare. Sarebbe più sul lato operativo che sul lato dello sviluppo. Penso che una delle cose che predichiamo qui sia, una, presupporre che accadrà qualcosa di brutto. Quindi sta arrivando una breccia, non puoi semplicemente lasciartene sorprendere. È probabile che accada ad un certo punto. E la nostra chiave– quindi, uno, crea un runbook per quello. Quindi, quando succede, sappi quali persone contattare e quale sarà la tua risposta, sia dal rilevamento che dalla risposta, ma anche comunicando ai tuoi clienti se li riguarda. E a tal fine, la cosa che, penso, facciamo molto bene in Cloudflare ed è stata parte del nostro marchio e penso che ci sia servito molto bene è essere schietti, aperti e comunicativi come si potrebbe essere su qualsiasi cosa che è successo.

L'apertura è stata la chiave per ristabilire la fiducia con i clienti quando si verifica qualcosa, che si tratti di una violazione del software o di un errore che hai commesso in termini di incidente. Nascondersi dietro non è mai la scelta giusta.

MODERATORE: Sì.

JIMMY SQUIRES: Penso che anche qualcos'altro sia che abbiamo - ora che tutti sono ovviamente remoti e specialmente nei team di sviluppo, ci stiamo davvero prendendo il tempo all'inizio di un progetto per fare un po' di lavagna bianca e pianificazione architettonica. È così facile immergersi direttamente nei requisiti e buttare giù storie di sviluppo, ma passare del tempo con i tuoi colleghi per sfidare come potrebbe essere sfruttato? Corri attraverso gli scenari. Facciamo molta pianificazione dello scenario che porta a molte buone conversazioni su come vogliamo sostenere diverse parti dell'applicazione.

LAWRENCE EDMONDSON: E proprio su questo, non so se qualcuno lo sa, ma MPM è in realtà il più grande repository di librerie condivise – è un singolo più grande repository di librerie di applicazioni là fuori, ma ciò significa che rappresenta anche il rischio maggiore. Quindi una cosa di cui siamo molto consapevoli quando intraprendiamo un nuovo progetto se stiamo usando NPM è assicurarci di esaminare le vulnerabilità, che stiamo bloccando le versioni che spingiamo a produrre, che prima di stiamo facendo un aggiornamento, ci assicuriamo che sia compatibile, ma anche molto sicuro. Non ci sono minacce aperte perché abbiamo visto molte vulnerabilità insinuarsi attraverso NPM. Quindi questa è solo una cosa a cui prestare attenzione.

TIM NASH: Penso che stiamo girando tutto intorno.

JIMMY SQUIRES: Avanti, Tim.

TIM NASH: Penso che stiamo collegando tutto questo all'idea che, davvero, la fiducia è stata completamente infranta nei cicli di sviluppo per anni. Le persone stanno solo arrivando a rendersene conto ora. E se sei uno sviluppatore PHP che lavora in WordPress, ad esempio, ti siedi lì a chiamare azioni e filtri, ma non dovresti fidarti di quelle azioni e filtri. Tutti i dati che arrivano, dovresti convalidarli, dovresti controllarli. Dovrebbe essere igienizzato. Ma quando esce dal database, non dovresti comunque fidarti di esso.

Anche se potresti aver inserito quei dati nel database, non dovresti fidarti dei dati che escono. Se passiamo qualcosa a una libreria di terze parti, che si tratti di NPM, di quel pacchetto di compositore o solo di un altro plug-in di WordPress, immediatamente è fuori dal nostro controllo, non ci fidiamo più. Ma quando torna, anche se l'abbiamo controllato, non ci fidiamo ancora. E se entri con quella mentalità, come sviluppatore, che ogni pezzo di dati non dovrebbe essere considerato attendibile e dovrebbe essere isolato fino in fondo e dovresti fare i controlli di sicurezza su di esso in ogni dato punto, verrai fuori con un sistema molto più sicuro. Potresti uscire con un sistema leggermente più lento. Potresti imbatterti in un sistema leggermente più frustrante e che richiede molti più test per assicurarti che ciò che stai facendo non stia effettivamente causando più problemi di quanto non stia aiutando.

MODERATORE: Sì.

TIM NASH: Aggiungi complicazioni, ma ti ritroverai con un sistema molto più sicuro. E per la maggior parte delle persone, questo è quello che vogliono.

LAWRENCE EDMONDSON: Sì.

MODERATORE: Sì. Hai assolutamente ragione. Si tratta di non fidarsi di nessun altro pezzo di codice che sta arrivando. E di ciò di cui hanno parlato Jimmy e Sergi, è avere un piano e dal punto di vista dell'architettura, o dal punto di vista operativo, ma riunire tutto ciò nella tua pratica generale, sia che si tratti di meccanismi di codifica sicuri per la sicurezza o che si tratti di un registro degli incidenti. Quindi Tim, sono molto interessato a sentire di più da te in giro: ti alleni molto, insegni molto in tutto il mondo. Quali sono alcuni errori comuni che vedi quando le persone iniziano a lavorare su progetti o errori che potresti aver commesso, ne ho fatti molti.

TIM NASH: Stavo per dire, sono abbastanza sicuro di essere colpevole di ogni errore di cui sto per parlare. E il più grande e il più semplice è essere una brava persona. La maggior parte degli sviluppatori presuppone buone intenzioni. La maggior parte delle persone presume che utilizzerai la loro applicazione come hai scritto la loro applicazione. Ora molto spesso non scriviamo la documentazione, quindi l'utente non ha idea di come utilizzare l'applicazione in primo luogo, ma questo è un problema separato. Un cattivo attore entrerà e prenderà qualsiasi insetto e se ne andrà, non è un insetto, per un cattivo attore, questa è una caratteristica. Questa è un'opportunità. Sta facendo qualcosa che lo sviluppatore non si aspetta, quindi, c'è un potenziale percorso in questo.

E nel complesso, qualcosa che vedi più e più volte, quando dici, oh guarda, hai una serie di test unitari. Oh grande. Ma hai testato solo le cose positive, il risultato che volevi. Non hai testato cosa succede se usciamo da questi confini. Hai appena testato per assicurarti che la cosa funzioni in base a ciò che vuole il tuo capo. Quindi quello che hai davvero sono test di accettazione, dubbi test di accettazione. E poi si torna a tutte le basi. Come sviluppatore, è tornato indietro su questo, non fidarti delle cose. E se sei uno sviluppatore di WordPress in particolare, WordPress in realtà ha delle ottime funzioni di supporto per fare tutte le cose di sicurezza standard che chiediamo alle persone di fare.

E si tratta di educare e imparare a usarli. Quando eseguo revisioni del codice, vedrò più e più volte gli stessi problemi. E se lo vedo una volta in un pezzo di codice, lo vedrò 1.000 volte nello stesso set di codice. E saranno cose come, sì, beh, abbiamo semplicemente permesso a qualsiasi roba vecchia di apparire sulla pagina. Non ci siamo preoccupati di controllare se conteneva o meno qualcosa. Sì, mettiamo roba nel database. Oh guarda, potrebbe sembrare una query SQL, potrebbe non esserlo.

Tutte queste cose sono facili da risolvere e abbiamo già fornito gli strumenti per risolverle. E il motivo per cui non li risolviamo spesso non è nemmeno perché le persone non sanno che non dovrebbero lasciare che queste cose accadano, è solo che diventiamo pigri, stiamo facendo le cose velocemente, stiamo prendendo il codice da Stack Overflow, stiamo convincendo Chat GPT a fare cose per noi, non stiamo controllando le cose. E molti problemi di sicurezza derivano da questo stato di, devo affrettarmi. Devo affrettarmi. Devo affrettarmi, devo farlo. Sto passando alla prossima cosa, sto passando alla prossima cosa.

Quindi, stranamente, per molti sviluppatori, in realtà, solo dando loro il tempo e lo spazio e dicendo, va bene prendersi del tempo per controllare effettivamente cosa hai fatto in modo che quando si scende– e nei casi in cui entro in gioco, Torno e dico, beh, tutte queste cose e gli sviluppatori sembrano imbarazzati. Stanno andando, sì, sappiamo tutto questo. Semplicemente non abbiamo avuto tempo.

Quindi, si spera, dando alle persone più tempo e dando loro effettivamente gli strumenti, che abbiamo già in particolare all'interno di WordPress. WordPress ha un set davvero brillante di funzioni di supporto per i problemi di sicurezza più comuni che potresti avere in un plugin o tema WordPress. Quindi si tratta solo di impararli e poi investire il tempo per implementarli effettivamente.

MODERATORE: Sì. E penso che sia davvero potente, investire il tempo. Molto spesso, gli sviluppatori sanno cosa deve essere corretto. Quindi dando loro tempo. Quindi mi piace davvero quel messaggio. E Jimmy, so che hai inserito questo nel tuo flusso di lavoro presso la tua agenzia. Vuoi parlare un po' di più delle pratiche di flusso di lavoro sicure che hai implementato?

JIMMY SQUIRES: Sì, assolutamente. E davvero, inizia con qualcosa che Sergi ha detto è avere un piano, in realtà avere linee guida e standard che il tuo team di sviluppo deve seguire. So che probabilmente suona molto semplice, ma ho visto molte organizzazioni e sentito da molti ingegneri che abbiamo assunto nel corso degli anni che non esisteva. Non c'era organizzazione nel posto di lavoro da cui provenivano.

Quindi quello che ci piace fare è avere una serie standard di linee guida, tutti i nostri nuovi ingegneri devono leggerle da cima a fondo. Non è così pesante da non essere consumabile. Ci piace tenerlo in markdown, quindi è tutto in un repository. Probabilmente lo renderemo effettivamente open source a un certo punto. Non c'è nulla che sia veramente proprietario, quindi incoraggiamo tutti a contribuire. Questa è una domanda per tutti gli ingegneri.

Quindi, anche nelle nostre linee guida, fai dei buchi dove possiamo aggiungere, dove possiamo essere migliori, crescendo continuamente. Ma passare del tempo con quello, alcune delle cose di base come OWASP, è una pratica davvero vecchia, ma affrontarla con la tua applicazione, considerando quelle cose. È un po 'quello che ha detto Tim, è davvero prendersi il tempo ed essere OK per prendersi il tempo con quello. Volevo aggiungere un punto in più alla conversazione sull'IA. Parlare con alcuni dei nostri ingegneri la scorsa settimana ha effettivamente avuto un evento. Questo è qualcosa per cui stiamo usando Chat GPT è in realtà il test dell'unità. Prendendo una funzione ed esplorandola in modi interessanti, come puoi sfruttare qualcosa come Chat GPT per scrivere un test unitario in cui non sarai il miglior autore di quel test unitario, al punto di Tim. È lì che penso che possiamo sfruttare l'intelligenza artificiale molto di più in modo preventivo.

LAWRENCE EDMONDSON: Sì. Quello che stiamo facendo dalla nostra parte, penso che le liste di controllo e avere un playbook siano fantastici. Utilizziamo strumenti automatizzati come SonarQube e abbiamo davvero linting in atto e cose del genere, solo per aumentare la qualità del codice con linting, ma utilizziamo anche SonarQube per assicurarci che il codice sia più sicuro, che stiamo cercando per vulnerabilità e cose del genere. Penso che alcune lingue siano più facili di altre in cui trovare exploit, come ho detto prima, proprio per la natura della lingua. E anche solo alcuni framework in cui la qualità dei programmatori che contribuiscono a quella base di codice in genere - in genere lo vediamo con Open Source, dove è proprio come - c'è un sacco di copia e incolla di Stack Overflow in corso, rispetto a persone che hanno effettivamente studiato CS e sanno davvero cosa stanno facendo. Quindi questa è solo una cosa che ho visto.

TIM NASH: Sento che dovremmo sottolineare, certamente per me stesso, che uso Stack OverFlow praticamente ogni giorno. E quindi ne siamo tutti colpevoli. È bello inveire su di esso, ma non credo– voglio dire, ricordo quando ho iniziato a scrivere codice. Ho preso una rivista e stavo digitando il codice dalla rivista e premendo Invio. Non riesco a immaginare che il Web funzioni davvero oggi se continuassimo a farlo e non avessimo Stack Overflow o simili.

Sergi: No, è l'accelerante. E si spera che l'intelligenza artificiale sia la fase successiva. Ma sì, è un meme divertente.

MODERATORE: Grazie. Quindi spostandoti un po'. C'è molto slancio che sta accadendo nel settore intorno alle implementazioni Headless e Headless. E abbiamo anche visto in alcuni dei nostri altri canali oggi o in altre sessioni che parlano di Headless. Quindi, quando abbiamo iniziato a lavorare con Atlas su WP Engine, abbiamo incontrato molti sviluppatori e la sicurezza è sempre stata una motivazione chiave. Quindi, come vedi la sicurezza con Headless? E lo so, Jimmy, questa è un'area in cui hai realizzato alcuni progetti al riguardo. Ci piacerebbe avere la tua opinione su questo.

JIMMY SQUIRES: Sì, lavoriamo molto in Headless. Penso che quasi tutti i nostri progetti a questo punto adottino probabilmente un approccio all'architettura Headless. Penso che voglio solo sottolineare un paio di punti, in quanto riguarda la sicurezza. Quindi penso che il primo sia che quando scegli un'architettura Headless, all'inizio ti metti di più nel campo dell'open source. E c'è molto dibattito, ovviamente, su cosa sia più sicuro, open source o closed source. Tendo a cadere nel campo dei progetti OSS che sono più sicuri per natura. Quindi stai scegliendo framework come Next, WordPress, dove hai una community gigantesca. E questo tende a prestarsi a una maggiore sicurezza attraverso la semplice esposizione.

Quindi penso che sia uno. Penso che il secondo sia qualcosa come Static Generation. Quindi molti siti Web e prodotti che vengono costruiti, non hai bisogno della natura dinamica di una grande gestione dei contenuti, sistema monolitico in senso tradizionale. Puoi sfruttare qualcosa come Cloudflare e generare in modo davvero statico grandi porzioni di quell'applicazione, riducendo così il tuo footprint per i vettori e l'esposizione. Quindi ne siamo grandi fan. E poi, ovviamente, ottieni anche tutti i vantaggi in termini di prestazioni. Quindi questi sono solo un paio di punti che volevo sottolineare sull'architettura Headless. Ma ci sono molte altre ragioni dal punto di vista della sicurezza per cui ci piace. Ma penso che quelle siano probabilmente due delle aree più importanti.

TIM NASH: Vorrei solo tornare indietro e ricordare alle persone che c'è ancora un sistema di gestione dei contenuti lì dietro. E lo sento troppo spesso, Headless è totalmente sicuro. È come, sì, ma quell'istanza di WordPress esposta che è ancora lì, solo perché non la stai chiamando direttamente dal sito web, sì, è ancora lì su admin.yoursite.com. E non hai– c'è una certa convinzione che, oh sì, beh, ora siamo al sicuro, quindi non dobbiamo preoccuparci di tenerlo aggiornato perché non è il sito web. È come, no, no, hai ancora bisogno di tutte le cose che stavi facendo prima e ora abbiamo anche l'altro lato.

E voglio dire, Headless è un termine fantastico per qualcosa che esiste da molto tempo e sta prendendo molto slancio, ma lo facevamo da prima che WordPress avesse un'API REST. Stavamo spingendo i contenuti da WordPress a cose come Jekyll per ricavarne almeno un sito statico. E il motivo originale per farlo era di metterlo a variare il sistema WordPress o il tuo sistema di gestione dei contenuti all'interno della tua rete. Quindi potresti bloccarlo e tenerlo lontano dalla grande e spaventosa rete.

Ora stiamo ricevendo molte società di hosting che forniscono soluzioni Headless. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Grazie. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.