¿Es normal que los auditores requieran todas las contraseñas de la compañía?

  

¿Esto es normal para un pentest?

Absolutamente no . El mejor escenario posible: están realizando pruebas de penetración de "ingeniería social" y quieren ver si se le puede presionar para que realice una acción muy peligrosa. Escenario medio, no saben cómo hacer su trabajo. En el peor de los casos, solo pretenden ser una empresa de auditoría y cumplir con su solicitud resultará en una costosa infracción.

En el caso de una auditoría de código, la compañía obviamente necesitará acceso al código fuente. Sin embargo, esperaría que una compañía que preste dichos servicios comprenda la sensibilidad de dicha necesidad y tenga muchos formularios para que usted firme y se ofrezca para trabajar en un entorno estrictamente controlado. Una empresa de seguridad con buena reputación se preocupará no solo de protegerlo (porque es su trabajo) sino también de protegerse de clientes no confiables (nuestro código fuente se filtró justo después de que lo contratamos: ¡¡¡estamos demandando !!!!) . Todo esto para decir: cualquier compañía de seguridad acreditada que no le haga firmar muchos contratos antes de ir a trabajar no es una compañía de seguridad acreditada.

No puedo imaginar ninguna circunstancia en la que sea una buena idea entregar el acceso a cualquiera de esas cosas.

Editar RE: contratos ocultos

Algunos han sugerido que la compañía podría simplemente no haberle dicho al OP sobre cualquier contrato / acuerdo / NDA relevante. Supongo que esto es posible, pero quiero aclarar que la falta de un contrato no es la única bandera roja que veo.

Como alguien que ha creado sitios de comercio electrónico y software empresarial que ha requerido la integración con muchos procesadores CC, no veo ningún beneficio en dar acceso a otra persona a su procesador CC. En ese momento, ya no son pruebas de penetración de sus sistemas: son pruebas de penetración de los sistemas que otra persona utiliza. De hecho, la entrega de credenciales de acceso de tal manera probablemente viola los términos de servicio que firmó cuando comenzó a usar su Procesador CC (sin mencionar los otros sistemas a los que solicita acceso). Entonces, a menos que tenga el permiso de su procesador de CC para entregar sus credenciales a una empresa de auditoría de seguridad (sugerencia: nunca le darían permiso), darles el acceso es una gran responsabilidad .

Muchos otros aquí han hecho un gran trabajo articulando las diferencias entre las pruebas de caja blanca y caja negra. Es cierto que cuanto mayor sea el acceso que otorga a los auditores de seguridad, más eficazmente podrán hacer su trabajo. Sin embargo, un mayor acceso conlleva mayores costos: tanto porque cobran más por una investigación más exhaustiva como también por un aumento de los costos en términos de mayor responsabilidad y mayor confianza que debe extender a esta empresa y sus empleados. Se está hablando de otorgarles un control completo sobre todos de los sistemas de sus compañías. No puedo imaginar ninguna circunstancia en la que esté de acuerdo.

  

¿Cómo debo proceder?

No continúe con ellos. La forma en que actúan no es profesional. Los Pentest conllevan riesgos para ambas partes y no parece que hayan hecho nada para solucionarlos.

Primero, absolutamente no debe entregar nada sin un contrato por escrito (incluido un NDA). Es sorprendente que habitualmente hagan negocios así. ¿Cómo saben el alcance exacto? ¿Bajo qué términos se les paga? ¿Se limitarán a afirmar que están "terminados" en algún momento o hay un horario? ¿Tienes un informe adecuado? ¿Quién paga si causan daños? ¿Están asegurados en caso de que pierdan sus credenciales a un tercero? ¿Cómo sabrá si una futura violación es parte de la prueba o un ataque real de otra persona? Incluso si confía en ellos, estas preguntas deberían responderse antes de iniciar un pentest.

Y no es solo usted, se están poniendo en riesgo. Si nunca aclaró el alcance, podrían estar atacando algunos de sus sistemas sin permiso, con posibles implicaciones legales.

  

Supuse que en su mayoría sería una caja negra.

Las pruebas de caja negra y blanca son comunes y cada enfoque tiene sus propias ventajas . Pero si el modo de prueba nunca surgió, parece que nunca se ha discutido qué se debe lograr al realizar un pentest en primer lugar. Un contratista profesional le habría ayudado a determinar las condiciones y los métodos correctos.

(Una primera gran pregunta para un posible contratista es pedirles un informe de muestra de Pentest. Le dará una idea inicial sobre cómo funcionan y qué resultados puede esperar).

Antes de cualquier prueba de penetración, debe haber un documento (s) de Alcance y Reglas de Compromiso que esté firmado por ambas partes. Estos documentos deben describir en detalle lo que se probará y los métodos acordados por su empresa y el contratista. Si no ha seguido esta discusión con su contratista, interrumpa el compromiso y busque otros profesionales.

Como evaluador de penetración, le pedí a las empresas que proporcionen cuentas o computadoras portátiles que proporcionen a un usuario normal. Esto permite probar desde la perspectiva de un empleado malicioso. Sin embargo, todo esto se acordó antes de la prueba en el Ámbito de aplicación y las Reglas de compromiso.

Solo mis 2cents.

¡NUNCA!

Estamos haciendo un pentest completo en mi trabajo. Los pentesters declararon explícitamente que ni siquiera necesitan el nombre de usuario / contraseña para nada. Afirmamos que fue genial ya que nunca les habríamos lanzado nada de antemano. Hay 3 tipos principales de pentests: cuadro blanco, cuadro gris, cuadro negro.

White Box es que les da toda la información y encuentran problemas con su software, red, etc.

La casilla gris es que les das algunos detalles de lo que quieres que hagan un pentest. Lo usamos ya que no tendrían idea de qué ISP inalámbrico externo estábamos usando. Les dijimos que primero hicieran una prueba externa, así que les dimos algunas IP y se interrumpieron fácilmente.

Black Box es que no les proporcionas nada y tienen que encontrar todo por su cuenta. Después de eso, pueden hacer su pentest en las direcciones IP externas. Para las pruebas internas, es diferente. Estarán dentro de su red ejecutando nmap y otras exploraciones intensas en cada objetivo que encuentren. Este es el más difícil, pero el mejor en mi opinión.

  

Mi empresa actualmente está realizando una auditoría de seguridad enmarcada como un pentest.

y

  

Tenga en cuenta que nunca hemos firmado un solo acuerdo de confidencialidad ni ningún otro contrato con ellos, y estoy muy reacio a proporcionarles esta información debido a esto.

El uso de "comprometido" en este contexto implica una definición de "entrar en un contrato para hacer algo". Esto me deja preguntándome si las declaraciones en conflicto son accidentales o si usted no es la entidad dentro de su compañía que se ha comprometido con la compañía de seguridad.

Si es lo último, es muy posible que haya contratos / acuerdos de los que no se haya informado. Esto no sería inusual, ya que muchas de las pruebas de penetración en las que he estado en el extremo receptor ocultan los detalles específicos de la prueba a los empleados para que no tomen ninguna acción "anormal" para protegerse contra la (s) prueba (s). / p>

Si este es el caso, entonces haga con la solicitud lo que haría normalmente con dicha solicitud. Dígales "no" y si rechazan ("pero es necesario para nosotros que realicemos la prueba de penetración"), ejecute la solicitud (por escrito) hasta que su supervisor le informe sus inquietudes. Si su supervisor le dice (por escrito) que divulgue esta información, entonces debería estar en claro, ya que es posible que comprendan mejor la prueba que usted. Si sus superiores no están claros, hágalo avanzar por la cadena de mando y / o solicite que le soliciten orientación a la entidad que contrató a la compañía de seguridad.

Sin embargo, si usted es la entidad que ha contratado a la compañía de seguridad, entonces yo (como las otras respuestas aquí) tendría serias preocupaciones. Si cree que aún puede valer la pena (o le preocupa que hagan algún tipo de reclamo por "incumplimiento de contrato"), le sugiero que utilice un medio para evaluar si se trata de una prueba de ingeniería social. Por ejemplo, podría generar una lista de cuentas y contraseñas de administrador falsas. Proporcione esto, diga que todavía está trabajando en el resto, y lo enviará cuando esté listo. A continuación, ver cómo responden.

Si es solo una prueba de ingeniería social, todo lo que necesitan es ver una prueba de este tipo de información que se está filtrando (que puede mostrar más adelante en cuentas falsas). Una empresa de seguridad responsable no debería necesitar más de la información solicitada y debería impedirle que la proporcione ("Mirando lo que proporcionó, creo que esto debería ser suficiente para permitirnos continuar; no se preocupe por el resto a menos que gire realmente lo necesitamos "). Si no dejan de recibir más información, desactívela inmediatamente.

Más información solo puede generar sospechas sobre las penetraciones que realizan desde ese momento en adelante (es decir, es fácil penetrar en un sistema si tiene acceso de administrador) y / o exponerlos a posibles demandas de propiedad intelectual (es decir, código fuente filtrado, etc.) ).

Llegando a la pregunta desde un ángulo ligeramente diferente:

¿Eres el CEO o CTO?

No? Entonces no le dé a los auditores ninguna contraseña. Siempre.

Prepare un paquete de información y envíelo por cadena a su Gerente de TI, CTO, CEO o lo que sea. Para decirlo sin rodeos, su trabajo es tomar ese tipo de decisiones (y tomar las consecuencias), no las suyas.

Si su jefe dice: "No, usted lo envía". luego responda: "Como empleado, no me siento cómodo al divulgar información tan peligrosa a un tercero".

Si, de hecho, eres el CTO, sigue los consejos de las respuestas anteriores.

Valide sus suposiciones.

Si se supone que esto es una prueba de caja negra, no deben obtener ni requerir ninguna contraseña.

Si se supone que esto es una revisión de configuración, o pruebas de caja blanca, se deben entregar algunas contraseñas. El procedimiento correcto es cambiarlos antes de la prueba a algo único (cadena aleatoria), y luego cambiarlos nuevamente después de la prueba.

Verifique con su administración y pregunte explícitamente si se firmaron acuerdos de confidencialidad y contratos adecuados.

  

¿Esto es normal para un pentest?

El escenario como lo describiste es inusual, pero no completamente inverosímil. Todo depende de lo que se acordó exactamente para el alcance de la prueba y las actividades.

  

Supuse que en su mayoría sería caja negra. ¿Cómo debo proceder?

Verifique con el gerente responsable de firmar este equipo de pentesting. Su CISO o CSO o gerente de TI o quien sea que sea. Exprese sus inquietudes y pregunte si este enfoque fue acordado.

Dar contraseñas / código fuente

Personalmente, no le daría ninguna contraseña o código fuente a nadie sin un NDA adecuado firmado. También nunca, nunca, les daría las contraseñas reales. En todos los pentests en los que he participado, en ambos lados como cliente y administrador de proyectos (no soy un pentester, pero he manejado pentesters), siempre se crearon cuentas de usuario para el pentest y se cambiaron las contraseñas. Incluso recomendamos a nuestros clientes cambiarlos después de que se realice la prueba (algunos no, lo que siempre es un hallazgo triste para el próximo informe).

Fuerza de la contraseña

En cuanto a lo que escribieron algunas respuestas sobre "evaluar la fortaleza de la contraseña", eso es una carga de tonterías. Sí, hay una "mejor práctica" en las buenas contraseñas, que un tipo abandonó hace algunas décadas y lamenta mucho hoy. Todas las matemáticas sobre el tema están llenas de agujeros y suposiciones no verificadas, y muchas políticas de contraseñas en realidad reducen el espacio de búsqueda en lugar de ampliarlo. La única prueba real para la seguridad de la contraseña tiene dos partes: una, obtener las 10,000 o más contraseñas de una de las 20 listas que flotan en Internet y usarlas como una lista negra. Dos, ejecute el mismo software de cracking que usan los malos (la mayoría de ellos son Software Libre) en sus hashes de contraseña. Si tu instancia de John lo resquebraja, también lo harán las suyas.