No tengo claro dónde está el borde entre lo interno y lo externo. Por ejemplo, ¿el usuario externo incluye un usuario registrado?

La prueba de penetración interna se realiza dentro de su propia red. La prueba de penetración externa estaría fuera de eso. Realmente no considera el estado de autenticación de un usuario, solo el diseño de la red.

  

Habíamos planeado tener una configuración (servidor web, etc.) por cliente para que todos sus datos, etc., estuvieran completamente aislados y permitieran la personalización, cada cliente tendría su propio subdominio. Me pregunto ahora si eso requeriría una prueba de penetración por configuración?

En su configuración, donde la página de pago está alojada en un Iframe, PCI-DSS solo se aplica a Critical Systems , es decir, los sitios web reales que alojan la página de pago basada en Iframe. Si bien su exposición a la conformidad con el PCI-DSS se reduce en el escenario, todavía tiene que certificar el cumplimiento, pero de forma más limitada. Si se diseñan correctamente, sus servidores de aplicaciones no caerían dentro del alcance de PCI-DSS.

A menos que realmente necesite hospedar la página de pago, en realidad podría subcontratar ese sitio web a un servicio de hospedaje de terceros y controlar su propio cumplimiento con PCI-DSS. Consulte la Guía de Pruebas de Penetración de PCI Sección 2.2.1 Esto eliminaría el requisito para que usted maneje las pruebas de penetración completamente. Nuevamente, si está diseñado para aislar estos servidores de pago Iframe a un tercero compatible con PCI, podría omitir legítimamente su propio requisito de cumplimiento con PCI-DSS por completo.

Si, por razones técnicas u otras, necesita hospedar esa página, entonces nuevamente, su alcance de prueba de penetración está limitado a esos sistemas críticos.

Aunque es posible que desee realizar pruebas de penetración en sus servidores de aplicaciones reales, es de esperar que pueda pasar por alto el requisito y costo de PCI-DSS al dividir claramente la aplicación y los servidores de pago en su red.

  

De los ejemplos en el SAQ sobre pruebas de penetración, parece que se debe hacer uno nuevo para (lo que yo consideraría) cambios bastante pequeños, por ejemplo. actualizando el sistema operativo. ¿Cómo se relaciona esto con el nivel de aplicación? ¿Podremos hacer nuevos lanzamientos sin tener que hacer una nueva prueba de penetración?

El documento anterior Guía de pruebas de penetración también detalla lo que se considera un Cambio significativo de una página 2.6 del Sistema crítico designado. Depende de usted considerar el impacto de un cambio de configuración según su Medio ambiente y procesos. Suponiendo que haya aislado los datos del titular de la tarjeta de sus servidores de aplicaciones, puede aislar sus lanzamientos del ámbito de cumplimiento de PCI-DSS.

Vea también Pautas de comercio electrónico de PCI DSS página 22, para conocer las funciones y responsabilidades de una configuración de comercio electrónico basada en Iframe .

Depende mucho de las compañías específicas que elija utilizar, hay algunos términos comunes, pero no es extraño que se encuentre con "pruebas automatizadas de penetración" o "exploración manual de vulnerabilidades".

En general, una exploración de vulnerabilidades está diseñada para detectar fallas comunes: detectará software de servidor desactualizado, sistemas no parcheados, puertos abiertos que deberían filtrarse y algunas fallas más específicas, como nombres de usuario predeterminados y Contraseñas que se utilizan en los sistemas disponibles públicamente. También puede tener lugar externamente, donde mira lo que es visible desde el exterior de su red (generalmente un servicio remoto, alojado por la compañía de seguridad), o internamente, donde mira lo que puede verse desde la perspectiva de un usuario en su red (por lo general, un dispositivo preconfigurado que proporciona la compañía de seguridad y que usted hospeda en su red en algún lugar).

Por otro lado, una prueba de penetración tiende a ser más específica, mirando específicamente a sus sistemas. Un probador buscará puertos abiertos y software en los sistemas que pueden ver, y trabajará para abusar de ellos. Esto podría incluir pruebas para problemas de inyección de SQL o de secuencias de comandos entre sitios, o ejecutar ataques de fuerza bruta contra contraseñas o nombres de usuarios. Estos tipos de pruebas pueden ser más peligrosos para los sistemas que se están probando, por lo que las pruebas automatizadas tienden a errar por el lado de la precaución, para evitar interrupciones accidentales. Los evaluadores de lápiz también tienen más probabilidades de detectar errores lógicos, donde la aplicación hace algo que no debería (¿puede comprar productos sin pagar? ¿Puede cambiar sus privilegios de usuario?), Que las pruebas de vulnerabilidad automatizadas no detectarán. / p>

El escaneo interno y externo para la prueba de la pluma es generalmente el mismo que se mencionó anteriormente: las pruebas internas examinan el sistema desde el punto de vista de un dispositivo conectado a la red interna y, a menudo, encuentran problemas que pueden ser explotados por actividades maliciosas personal de la empresa. Las pruebas externas se parecen más a los ataques estándar de terceros maliciosos.

Ambas son herramientas muy útiles, y se pueden usar muy bien en conjunto: tienen un escaneo de vulnerabilidad inicial para detectar cualquier fruta de bajo rendimiento. Repárelas, luego realice una prueba de penetración, que probablemente detectará problemas más difíciles (al clasificar la fruta de bajo rendimiento, los evaluadores de penetración tendrán más tiempo para examinar las partes más especializadas de su sistema; tienen que informar las cosas simples si están ahí). Luego, realice un análisis de vulnerabilidad programado regularmente para asegurarse de que las nuevas implementaciones no tengan problemas. También puede obtener una prueba de penetración para nuevos sistemas, si lo desea, o si hay cambios importantes en su código o sistemas, pero suponiendo que haga uso de un ciclo de vida de desarrollo seguro, no debería necesitar probar cada pequeño cambio. a menos que se encuentre en un área comercial con altos niveles de cumplimiento (por ejemplo, las aplicaciones bancarias a menudo se prueban después de cambios menores).

  

Habíamos planeado tener una configuración (servidor web, etc.) por cliente para que todos   sus datos, etc. serían completamente siledados y permitirían la personalización,   Cada cliente tendría su propio subdominio. Me pregunto ahora si eso   ¿Requeriría una prueba de penetración por configuración?

Esto requeriría análisis de vulnerabilidad internos y externos, pero no es necesario realizar pruebas de penetración. La exploración de vulnerabilidad externa debe ser realizada por un ASV, y debe incluir todas IPs y dominios externos en su alcance. La exploración de vulnerabilidad interna debe incluir todas las IP privadas internas y debe ser realizada por un recurso interno calificado o por una compañía externa especializada en seguridad.

Como según la guía , las pruebas de penetración se pueden realizar en un entorno previo al lanzamiento. Página 7 estados:

  

2.3.4 Entorno de prueba separado

     

Debido a la naturaleza y la intención de las pruebas de penetración, tales pruebas en una producción   El ambiente durante las horas normales de oficina puede afectar el negocio.   operaciones, y los intentos de evitar la interrupción pueden aumentar el tiempo,   Recursos y complejidad de las pruebas. Esto es especialmente importante   Para sistemas de alta disponibilidad que pueden ser impactados por la penetración.   Pruebas en un entorno de producción. Para evitar interrupciones y acelerar.   hasta pruebas, un entorno separado que es idéntico a la producción   El entorno puede ser utilizado para pruebas en lugar de la producción.   ambiente. El probador de penetración tendría que garantizar el mismo   La aplicación y los controles de capa de red como producción existen en el   entorno de prueba. Esto se puede lograr a través de métodos para mapear   el entorno de producción para verificar que coincida con las pruebas   ambiente. Esto debe ser incluido en las reglas de compromiso. Todos   Las vulnerabilidades explotables identificadas durante la prueba deben ser   Corregido en sistemas de producción y pruebas repetidas para verificar que   Se han solucionado las debilidades de seguridad.

Entonces, mientras cada entorno de cliente refleje el entorno previo al lanzamiento en el que se realizó la prueba de la pluma, esperaría que esto fuera suficiente.

Sí, debe proporcionar nombres de usuario. De esta manera, el probador puede garantizar que los permisos se hayan configurado correctamente para cada uno de sus niveles de acceso documentados.

Además de lo anterior, recuerde que todo código personalizado debe tener algún tipo de evaluación de seguridad (PCI DSS 6.6):

  

Para las aplicaciones web públicas, aborde las nuevas amenazas y vulnerabilidades de forma continua y asegúrese de que estas aplicaciones sean   protegido contra ataques conocidos por cualquiera de los siguientes métodos: