I'm not clear on where the border is between internal and external. For example, does external include a logged in user?

I test di penetrazione interna vengono eseguiti all'interno della rete stessa. Il test di penetrazione esterna sarebbe al di fuori di questo. In realtà non considera lo stato di autenticazione degli utenti, ma solo il layout di rete.

We had planned to have a setup (webserver etc) per client so that all their data etc would be completely siloed and allow customisation, each client would have their own subdomain. I'm wondering now if that would require a penetration test per setup?

Nella tua configurazione, in cui la pagina di pagamento è ospitata in un Iframe, PCI-DSS si applica solo ai Sistemi critici , ovvero ai siti Web reali che ospitano la pagina di pagamento basata su Iframe. Sebbene l'esposizione alla conformità PCI-DSS sia ridotta nello scenario, è comunque necessario attestare la conformità, ma su base più limitata. Se architettato correttamente, i tuoi server delle app non rientrano nell'ambito del PCI-DSS.

A meno che tu non abbia davvero bisogno di ospitare la pagina di pagamento, potresti effettivamente esternalizzare quel sito web a un servizio di hosting di terze parti e monitorare la loro conformità PCI-DSS. Vedi Guida al test di penetrazione PCI sezione 2.2.1 Ciò eliminerebbe il requisito per la gestione completa dei test di penetrazione. Anche in questo caso, se è stato progettato per isolare questi server di pagamento Iframe verso una terza parte conforme allo standard PCI, è possibile ignorare completamente il proprio requisito di conformità PCI-DSS.

Se per ragioni tecniche o di altro genere è necessario ospitare tale pagina, il campo di applicazione del test di penetrazione è limitato a tali sistemi critici.

Anche se si consiglia di eseguire test di penetrazione sui server delle applicazioni reali, si spera che sia possibile ignorare i requisiti e i costi PCI-DSS dividendo chiaramente i server di app e di pagamento nella rete.

From the examples in the SAQ around penetration testing it seems that a new one must be done for (what I would consider) fairly small changes e.g. updating the OS. How does this relate to the application level? Will we be able to do new releases without having to do a new penetration test?

Il documento di cui sopra Penetration Testing Guidance descrive anche ciò che è considerato un Cambiamento significativo di una sezione di Critical System specificata nella sezione 2.6 pagina 8. Sta a te considerare l'impatto di una modifica di configurazione per tuo ambiente e processi. Supponendo che tu abbia dati di titolari di carte isolati dai tuoi server delle app, puoi isolare le tue uscite dall'ambito di conformità PCI-DSS.

Vedi anche Linee guida E-commerce PCI DSS pagina 22, per ruoli e responsabilità in una configurazione eCommerce basata su Iframe .

Dipende molto dalle società specifiche che scegli di utilizzare - ci sono alcuni termini comuni, ma non è raro imbattersi in "test di penetrazione automatizzato" o "scansione manuale delle vulnerabilità".

In generale, una scansione delle vulnerabilità è progettata per individuare i difetti comuni: rileverà software del server non aggiornato, sistemi senza patch, porte aperte che dovrebbero essere filtrate e alcuni difetti più specifici, come i nomi utente e i nomi predefiniti password utilizzate su sistemi disponibili pubblicamente. Può anche avvenire esternamente, dove guarda ciò che è visibile dall'esterno della rete (di solito un servizio remoto, ospitato dalla società di sicurezza), o internamente, dove guarda ciò che può essere visto dal punto di vista di un utente sulla tua rete (di solito un dispositivo preconfigurato fornito dalla società di sicurezza e da te ospitato sulla tua rete da qualche parte).

D'altra parte, un test di penetrazione tende ad essere più mirato, guardando in modo specifico ai tuoi sistemi. Un tester esaminerà le porte aperte e il software sui sistemi che possono vedere e lavorerà per abusarne. Ciò potrebbe includere test per cose come l'iniezione SQL o problemi di scripting cross-site, o l'esecuzione di attacchi brute force contro password o nomi utente. Questi tipi di test possono essere più pericolosi per i sistemi in fase di test, pertanto i test automatizzati tendono ad essere errati, al fine di prevenire interruzioni accidentali. È anche più probabile che gli esaminatori di penne rilevino errori logici, in cui l'applicazione fa qualcosa che non dovrebbe (puoi acquistare beni senza pagare? Puoi modificare i tuoi privilegi utente?), Che i test automatici di vulnerabilità non rileveranno.

La scansione interna ed esterna per il test delle penne è solitamente la stessa di cui sopra - i test interni guardano il sistema dal punto di vista di un dispositivo connesso alla rete interna e spesso trovano problemi che potrebbero essere sfruttati da attività dannose di personale dell'azienda. I test esterni sono più simili agli attacchi standard di terze parti malevoli.

Entrambi sono strumenti molto utili e possono essere usati insieme molto bene - avere una scansione di vulnerabilità iniziale da raccogliere su qualsiasi frutto a basso impatto. Correggili, poi sottoponiti a un test di penetrazione, che è in grado di cogliere eventuali problemi più difficili (ordinando il frutto basso appeso, i tester di penetrazione avranno più tempo per esaminare le parti più specialistiche del tuo sistema - devono segnalare la roba semplice se è lì). Quindi eseguire regolarmente una scansione di vulnerabilità pianificata per garantire che eventuali nuove distribuzioni non presentino problemi. Puoi anche ottenere un test di penetrazione per i nuovi sistemi, se lo desideri, o se ci sono cambiamenti importanti al tuo codice o ai tuoi sistemi, ma supponendo che tu usi un ciclo di sviluppo sicuro, non dovresti testare ogni piccolo cambiamento, a meno che non si trovi in un'area commerciale con livelli elevati di conformità (ad esempio, le applicazioni bancarie vengono spesso testate anche dopo modifiche minori).

We had planned to have a setup (webserver etc) per client so that all their data etc would be completely siloed and allow customisation, each client would have their own subdomain. I'm wondering now if that would require a penetration test per setup?

Ciò richiederebbe scansioni di vulnerabilità interne ed esterne, ma non test di penetrazione necessari. La scansione della vulnerabilità esterna deve essere eseguita da un ASV e dovrebbe includere tutti indirizzi IP e domini esterni nell'ambito. La scansione delle vulnerabilità interne deve includere tutti gli IP interni e privati e deve essere eseguita da una risorsa interna qualificata o da un'azienda esterna specializzata in sicurezza.

Come secondo la guida i test di penetrazione possono essere eseguiti in un ambiente di pre-release. Pagina 7 dichiara:

2.3.4 Separate Testing Environment

Because of the nature and the intent of penetration testing, such testing in a production environment during normal business hours may impact business operations, and attempts to avoid disruption may increase the time, resources and complexity of the testing. This is especially important for high availability systems that may be impacted by penetration testing in a production environment. To avoid disruptions and to speed up testing, a separate environment that is identical to the production environment may be used for testing instead of the production environment. The penetration tester would need to ensure the same application and network-layer controls as production exist in the testing environment. This may be accomplished through methods to map out the production environment to verify it matches the testing environment. This should be included in the rules of engagement. All exploitable vulnerabilities identified during the testing must be corrected on production systems and testing repeated to verify that security weaknesses have been addressed.

Quindi, fintanto che ogni ambiente cliente rispecchia l'ambiente di pre-release in cui sono stati eseguiti i test delle penne, mi aspetto che ciò sia sufficiente.

Sì, dovresti fornire gli accessi. In questo modo il tester può garantire che le autorizzazioni siano state appropriatamente configurate per ciascuno dei tuoi livelli di accesso documentati.

Oltre a quanto sopra, ricorda che tutto il codice personalizzato dovrebbe avere qualche tipo di valutazione della sicurezza (PCI DSS 6.6):

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: