Rischi per la sicurezza di eseguire un'applicazione php su PHP 5.4

Regola uno: copriti il culo: assicurati di avere una registrazione offsite di te che segnali un rischio per la sicurezza al tuo CTO e alla loro risposta.

Oltre a ciò, se il loro è un rischio che l'aggiornamento interromperà l'autenticazione, il primo passo consiste nel caratterizzare tale rischio. Sono a conoscenza dei cambiamenti nell'implementazione blowfish di crypt in 5.3.7 - ma quelli sono compatibili all'indietro e tu sei al momento 5.4

La cosa più importante che puoi fare per garantire la sicurezza delle tue applicazioni è mantenere aggiornate le tue patch. Nel 2015 e nel 2016 US-CERT ha consigliato che l'85% dei compromessi fosse prevenibile (applicando le patch) . Il compromesso di Equifax del 2017 è stato il risultato di un software senza patch su un'applicazione web. Non devi guardare lontano per trovare altri esempi.

L'elenco delle vulnerabilità attuali nello stack non aiuta in realtà il problema: è necessario disporre di processi in atto per mantenere aggiornato il software. Non è necessario enumerare le vulnerabilità attualmente conosciute.

È ragionevole prendere una decisione di non applicare patch se l'organizzazione può dimostrare che le perdite risultanti sarebbero significativamente inferiori al costo di aggiornamento. Ma l'analisi è stata effettivamente fatta?

Sebbene tu possa scegliere di aggirare il tuo CTO con il proprietario / stakeholder, a meno che non si tratti di una società quotata in borsa, è improbabile che comprendano le tue preoccupazioni o favoriscano la tua versione degli eventi rispetto a quella del CTO. Qualsiasi organizzazione competente dovrebbe mantenere un registro dei rischi - dovresti documentare la tua comprensione della situazione attuale, il rischio di trovarti in una situazione in cui non è possibile aggiornare facilmente e richiedere che questo venga aggiunto al registro dei rischi aziendali.

Sono con il tuo CTO.

I changelog per PHP 5 e FFF:

https://secure.php.net/ChangeLog-5.php
https://github.com/bcosca/fatfree/issues?utf8=%E2%9C%93&q=is%3Aissue+security

hanno molto in loro per eccitare un attaccante / un rosso. Ma non è mai così semplice.

L'esecuzione di una piattaforma one-off e l'aggiornamento del framework avranno probabilmente un impatto minimo sulla postura complessiva della sicurezza dell'applicazione.

Naturalmente, applicare patch agli attacchi degli endpoint visibili e mantenersi aggiornati sulle dipendenze a livello di applicazione sono abitudini organizzative importanti / critiche. Ma devono essere abitudini, non progetti.

Trattarli come progetti è come seguire una dieta a rischio. Tre o sei mesi dopo, sei di nuovo nello stesso posto.

Raccomando una diversa linea di condotta. Due azioni:

1. documenta un modello di minaccia per la tua applicazione
2. documenta un piano per difendere il modello di minaccia concentrandoti sulle linee di codice e configurazione di cui sei responsabile, in modo che possano essere confrontati con difese simili eseguite tramite aggiornamenti di piattaforme o infrastrutture

Un modello di minaccia è solo un termine di fantasia per documentare in un linguaggio semplice:

• ciò che fa la tua applicazione, nel contesto della tua azienda e del tuo settore industriale
• delle caratteristiche e delle funzioni che offre, che sono sensibili (e perché e a chi) e che non sono
• che tipo di aggressori sarebbero interessati ai bit sensibili
• quali protezioni esistono attualmente per notare o difendersi da quegli aggressori
• quali mitigazioni esistono per quali tipi di compromessi (assicurazione, ecc.)

Forse hai già qualcosa di simile a un modello di minaccia dal controllo di sicurezza delle app Web, anche se è più probabile che si tratti solo di una lista di carenze, non di qualcosa che guarda l'applicazione nel contesto dell'ecosistema. Gli elenchi di carenze non sono così utili perché ogni singola piattaforma è sfruttabile, con un tempo, risorse e attenzione sufficienti. Anche i punteggi ad alto rischio sono generici, non necessariamente applicabili a qualsiasi situazione particolare.

Le difese più importanti su cui concentrarsi, dato il tempo e l'attenzione limitati, sono quelle che affrontano le aree di maggior rischio per la tua organizzazione di cui la tua applicazione ha la responsabilità funzionale. Questa priorità dovrebbe provenire da un modello di minaccia.

Come manutentore, sai cosa fa l'applicazione e probabilmente conosci il contesto dell'ecosistema. Probabilmente hai un senso di quali caratteristiche / funzioni / dati sono sensibili e quali no. Potresti non avere il contesto completo, ma questa è un'area importante per la comprensione. Probabilmente non sai quali tipi di aggressori potrebbero essere interessati a quale tipo di esposizione, quali protezioni esistono attualmente in altri strati dello stack tecnologico e quali mitigazioni a livello di organizzazione esistono. (Ogni organizzazione ha una lista di "rischi noti". Non difendersi da qualcosa che si considera un rischio noto).

In qualsiasi area dovresti essere in grado di apprendere ciò che non sai già da conversazioni relativamente brevi con il tuo team di sicurezza e / o altri nella gerarchia dell'organizzazione. Un documento di primo passaggio che riepiloga questi apprendimenti non dovrebbe essere più di 2 pagine.

Una volta che hai un modello di minaccia che trova minacce per le quali potrebbe esserci una mitigazione insufficiente, le proposte per mitigare le modifiche al codice dell'applicazione o altri approcci (come gli aggiornamenti della piattaforma) possono essere valutate l'una sull'altra in termini di costi ed efficacia. E ora stai parlando la lingua del tuo CTO.

Dopo aver seguito questi due passaggi, potresti arrivare in un luogo dove un progetto one-off per l'aggiornamento di PHP e FFF, data la difficoltà (gli aggiornamenti di PHP 5 non sono divertenti), non è superiore al 4 ° o 5 ° nell'elenco delle priorità di sicurezza. Va bene. Un progetto migliore è quello di costruire l'automazione che consente di essere sempre aggiornato.

Spero che sia utile, anche se forse non è la risposta che stai cercando. Buona fortuna.