Moduli CPAN Perl in un ambiente PCI-DSS

Può indicare la sezione dei Requisiti PCI DSS e procedure di valutazione della sicurezza 2.0 che sta usando per giustificare questo? Non è del tutto chiaro se il problema è il fatto che si tratti di codice di terze parti o che provenga da un repository gestito collettivamente.

Se si tratta solo di un controllo PCI-DSS, allora sostieni il tuo caso:

PA-DSS does not apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant's or service provider's normal PCI DSS compliance. [page 9]

e

Note: It is not a PCI DSS requirement to use PA-DSS validated applications. [page 16]

Devi revisionare il tuo codice personalizzato (PCI-DSS §6.3.2), non necessariamente tutto codice (PA-DSS §5.1.4).

In senso stretto, il codice o repository di terze parti non certificati sono rischi. Devi capire in modo dimostrabile per capire e gestire questi rischi.

Dovresti avere un inventario dettagliato:

• Elenco di hardware e software critico in uso nell'ambiente dei dati dei titolari di carta, insieme alla descrizione della funzione / uso per ciascun

Per soddisfare il Requisito 6 , è necessario disporre di un processo verificabile per utilizzare quell'inventario per verificare e applicare tempestivamente gli aggiornamenti di sicurezza pertinenti (§6.1, §6.2) per software di terze parti . Questo dovrebbe anche essere coperto dalle procedure di controllo delle modifiche documentate (§6.4.5).

Dovresti avere un processo per valutare (non controllare) i moduli in modo che le funzionalità che rientrano in PCI-DSS siano verificate e comprese (ad esempio autenticazione, crittografia e registrazione correlati ). Questo probabilmente significa che devi avere versioni di base approvate di determinati pacchetti e linee guida sulla configurazione (ad esempio per gli archivi di CA, i cipher consentiti), dove è pertinente.

Dovresti avere un processo documentato per configurare CPAN, incluso ma non limitato a, una serie di mirror approvati, che richiedono gpg / Module::Signature (ove possibile), procedure per l'approvvigionamento delle chiavi di firma degli sviluppatori e che richiedono un proxy che i download siano registrati e tracciabili.

He thinks that we should have someone from the outside audit all the code from CPAN we want to install. This person would need to have strong security background and deep knowledge of Perl. Unfortunately, they don't know anyone like that.

Bene, perché non pensa la stessa cosa per gli rpms? Sembra solo più rischioso per lui perché si sente perso lì. Ma è solo un'impressione e non una paura logica. In entrambi i casi, dovresti essere in grado di seguire le modifiche prima di aggiornare / installare qualsiasi cosa. Tuttavia, affinché la società cresca, dobbiamo tutti dipendere dagli altri e fidarci dei sistemi di sicurezza. Sembra implicare che CPAN non sia abbastanza sicuro, senza nemmeno indagare adeguatamente. Il modo più sicuro sarebbe probabilmente quello di scaricare una macchina da una fonte attendibile (scoprire quale è la prima), creare un pacchetto e distribuirlo. Esegui l'upgrade solo quando c'è un problema di sicurezza. Tale sistema di tracciamento è obbligatorio per qualsiasi infrastruttura importante. Erano i miei due centesimi.

Ora sulla tua domanda, su come le altre aziende che lavorano con Perl stanno gestendo questo problema. Dalla mia esperienza personale, abbiamo utilizzato i pacchetti forniti dal sistema di packaging del sistema operativo. Semplicemente perché CPAN si rivelerebbe troppo doloroso, alcuni pacchetti non sarebbero stati compilati in modo pulito, alcuni test fallirebbero. L'esternalizzazione di quel lavoro agli addetti al confezionamento sembrava una buona idea imprenditoriale. E non sto immaginando alcun beneficio per la sicurezza. Le firme dei pacchetti non sono disponibili / abilitate su tutti i sistemi operativi, quindi è chiaramente una cosa da investigare per i propri sistemi.

Quindi, se hai una cosa da ricordare: non dare nulla per scontato. Non esiste una risposta giusta. OpenSuse potrebbe non fornire più sicurezza di CPAN, ma potrebbe. Se tutto si riduce alla sicurezza del mirror che stai utilizzando, potrebbe essere necessario in entrambi i casi per garantire che i pacchetti o i bundle possano essere verificati.

CPAN viene fornito con perl, è più vicino alla sorgente dal mio punto di vista e ha anche vantaggi. Quindi questo non è un problema reale a questo punto.

Per quello che vale, ecco OpenBSD Makefile usato per compilare i pacchetti: link . Come puoi vedere, usa cpan. OpenBSD è ben noto per la sicurezza immediata, non penso che OpenSuse possa fare qualcosa di significativamente diverso.

Continua a utilizzare CPAN solo se vedi un vantaggio. Qui la sicurezza è un non-problema, ognuno deve essere studiato in modo diverso (recupero / controllo del checksum, specchi) ma dal mio punto di vista uno non è più sicuro di un altro.

I pacchetti possono essere codice CPAN + patch, le patch possono correggere bug o magari crearne altri, non c'è modo di dirlo.