Fino a quando non è possibile ottenere una scansione pulita o fare firmare il protocollo PCI-QSA sulla prova che si è conformi, la responsabilità è di soddisfare i requisiti di conformità indipendentemente dalle implicazioni sulla sicurezza del mondo reale.
La conformità non equivale a sicurezza e sicurezza non equivale alla conformità.
Detto questo, in genere un'organizzazione documenterà sia la prova del fornitore che un determinato CVE trovato in una scansione viene indirizzato da una specifica sotto-versione di patch / applicazione, sia la prova che tutti i sistemi in una zona PCI hanno quella versione di codice applicato (dipende da ciò che in realtà implica la riparazione).
Il QSA può quindi attestare che il rilevamento della scansione ASV è in realtà un falso positivo.
La tua domanda sta anche portando a un altro problema: cosa succede se c'è una vulnerabilità nota maggiore e il fornitore non la patch? In tal caso, potrebbe essere necessario elaborare le proprie misure correttive per affrontare la vulnerabilità. Incontrerai anche il caso in cui qualcuno potrebbe obiettare che sì, l'ultima versione della tua distro potrebbe essere solo X, ma l'ultima versione di OpenSSL (o inserire qui l'applicazione) è Y. In questo scenario, sei responsabile delle patch a livello di applicazione rimanendo aggiornato oltre alle patch del sistema operativo . Pertanto, non aggiornando il pacchetto individuale, si è fuori conformità.
Per la compilazione di OpenSSL penso che troverai che non è particolarmente difficile, ma testalo prima su un altro sistema (non sulla produzione).
In definitiva, devi ancora consultare il tuo QSA (presumendo che tu ne abbia uno) in quanto possono fornire una guida molto specifica che può aiutarti. Un buon QSA può farti risparmiare tempo anche qui. Il processore di schede potrebbe non volerti consigliare in caso di una causa successiva. Di nuovo, chiedi al tuo QSA.
Da un punto di vista strettamente legato alla sicurezza, ignorando tutti gli aspetti di conformità: assicurati sempre che la superficie di attacco sia applicata correttamente alle patch release più recenti e, ove possibile, aggiungi ulteriori controlli per la difesa in profondità. Strumenti come Fail2Ban potrebbero essere tuoi amici qui. Allo stesso modo, tieni presente che le patch non risolvono i tuoi problemi di sicurezza, hai davvero bisogno di controlli aggiuntivi per proteggere i tuoi dati. Allo stesso modo, soddisfare uno standard di conformità dato non ti darà una buona architettura di sicurezza. È davvero necessario progettare la sicurezza in profondità nella soluzione e non solo cercare di soddisfare una linea guida di conformità di base o livelli di patch del fornitore.
Ricorda che se sei il custode dei dati o il proprietario dei dati hai la responsabilità diretta di mantenere il sistema che protegge questi dati (o l'accesso ad essi) il più sicuro possibile. Fare affidamento solo sulle patch non è sufficiente.
La sicurezza e la conformità sono a volte obiettivi concorrenti. Purtroppo questi due non sono sempre allineati e non è raro vedere i soldi spesi dalle aziende sottratti a cose che potrebbero effettivamente proteggere i dati e spenderli in cose che rende un'organizzazione "conforme" (a volte questo processo aumenta anche il rischio). Fai attenzione a non confondere questi due obiettivi. Hai un problema di conformità E un problema di sicurezza questi non sono uno nella stessa cosa. Se mantieni separati questi due obiettivi otterrai buone soluzioni sia più facili che se proverai a risolvere entrambi con la stessa soluzione ogni volta. È fantastico quando una soluzione le risolve entrambe, ma non sempre ciò avverrà nel modo desiderato.
Infine, affronta questo con il tuo distributore di distribuzione. Aggiungere pressione su di loro per tenere il passo con le patch di sicurezza, laddove possibile, aiuterà a dare priorità agli sforzi di sicurezza.