Consejos para escribir mi primera revisión de seguridad de la aplicación

Navega tus respuestas
5

Deseo escribir una revisión de seguridad para una aplicación de cliente / servidor de Windows específica que se ejecute en una LAN o WAN cerrada (entre 1 y más de 200 usuarios en varios sitios); No es una aplicación web. La aplicación es ampliamente utilizada (líder del mercado) dentro de un sector en mi país y la información almacenada dentro de la aplicación es muy sensible.

Los tipos de problemas que ya he identificado son:

  1. Usando un nombre de usuario y contraseña predeterminados de la base de datos (acceso completo de administrador). Este inicio de sesión se mantiene en texto sin formato dentro de la carpeta de la aplicación.
  2. Almacenar contraseñas de usuarios en texto sin formato dentro de la base de datos
  3. No hay requisitos de contraseña complejos
  4. Los usuarios que tienen acceso a herramientas dentro de la aplicación que pueden ejecutar consultas SQL (con privilegios completos; a pesar de sus propias limitaciones de privilegios de nivel de aplicación)
  5. Un servicio de servidor HTTP que se ejecuta en todas las máquinas cliente que responde a las solicitudes de API. No se requiere usuario / contraseña.
  6. El archivo compartido predeterminado con todos los archivos de la aplicación, incluido el archivo que contiene la base de datos / nombre de usuario / contraseña
  7. Información de auditoría de las acciones del usuario (que se puede modificar / eliminar / enmascarar fácilmente, ¡vea cualquiera de las anteriores!) que se han utilizado como evidencia en casos de fraude / legal / HR de millones de dólares

Ni siquiera he visto cosas como desbordamientos de búfer, inyección de SQL, etc. pero un colega se ha ofrecido a ayudarme con esto.

Como soy un poco nuevo en esto; ¿Estoy pensando que esto sería una revisión técnica (similar a un artículo publicado en una revista) no solicitado por el proveedor? Los usuarios más grandes de este software a menudo lo aseguran lo mejor que pueden; Supongo que podría escribir una guía de "endurecimiento" en su lugar?

¿Alguien me puede dar consejos?

  • ¿Algún consejo general basado en lo anterior?
  • ¿Debo escribir una revisión de seguridad o una guía de fortalecimiento?
  • ¿Hay algunos buenos ejemplos de tipos similares de revisiones? (Puedo encontrar tantas revisiones de aplicaciones web, pero no tantas aplicaciones; sin embargo, un par de SCADA fueron útiles

¡Gracias!

    
pregunta Jonathan 27.08.2011 - 06:58
fuente

2 respuestas

3
  

¿Algún consejo general basado en lo anterior?

Hable con las personas que pueden resultar heridas por un posible ataque al sistema: ya sea directa o indirectamente. Comprenda cuáles son sus preocupaciones y hágales saber que hará todo lo posible por proteger sus registros y su privacidad. Como representante de seguridad, su trabajo es proteger los activos (datos personales, etc.) contra amenazas. Su mejor solución centrada en la seguridad surgirá una vez que comprenda lo que está protegiendo.

Busca vulnerabilidades, pero no te detengas demasiado. Siempre habrá vulnerabilidades muy técnicas complicadas, pero en muchos incidentes son las vulnerabilidades relativamente simples que se explotan. Recibirá pocas críticas por perderse una vulnerabilidad que requiere un atacante sofisticado altamente calificado, pero obtendrá mucho por perderse las vulnerabilidades simples.

Piense en la seguridad operacional. En un sistema mayormente cerrado, la amenaza interna es una preocupación importante. La rotación de trabajo es un gran método cuando es práctico. Busque formas de segmentar o dividir los datos para que, en caso de incumplimiento o filtración, el daño sea limitado.

  

¿Debo escribir una revisión de seguridad o una guía de refuerzo?

Creo que deberías centrarte en la revisión de seguridad. Existen recursos de seguridad para las distintas versiones de Windows, y espero que haya administradores competentes que ejecuten esos sistemas Windows.

  

¿Hay algunos buenos ejemplos de tipos similares de revisiones?

    
respondido por el this.josh 05.09.2011 - 09:48
fuente
1

Estoy hablando desde el contexto de la experiencia de un colega y, como tal, debe tratarse como información de terceros, por lo general, las organizaciones que lo contratan para realizar una prueba de lápiz esperan algún tipo de documento que enumere los problemas encontrados y las soluciones de los afectados. sistemas Algo que dijiste despertó preocupación: 

I'm thinking that this would be a technical review (similar a published journal article) un-requested by the vendor

Si fuera este proveedor, demandaría sin demora y me aseguraría de que su empresa perdiera todas las licencias que pudiera hacerles perder. Es a discreción del cliente y el contrato que se firmó. Me gustaría ver las guías de endurecimiento proporcionadas por DISA (STIGS ofrece una forma práctica de presentar una guía de endurecimiento). Lo único que puedo decir con gran confianza es revisar el contrato que se le otorgó a su empresa y continuar desde allí.

    
respondido por el Woot4Moo 28.08.2011 - 01:55
fuente

Lea otras preguntas en las etiquetas

¿Cuándo es posible detectar el tráfico VPN? Pregunta general sobre los requisitos de FIPS