Crear estándares de prueba para sus hacks éticos

Una falta de comunicación o desliz en sus normas de ensayo pueden enviar los sistemas estrellarse durante sus pruebas de hacking ético. Nadie quiere que eso suceda. Para evitar contratiempos, desarrollar y normas de ensayo documento. Estas normas deben incluir

• Cuando se realizan las pruebas, junto con la línea de tiempo general

• ¿Qué pruebas se realizan

• ¿Cuánto conocimiento de los sistemas a adquirir por adelantado

• ¿Cómo se realizan las pruebas y de las direcciones IP de origen lo

• Lo que se hace cuando se descubre una importante vulnerabilidad

El tiempo de sus pruebas

Esto es especialmente cierto cuando se realizan pruebas de hacking ético. Asegúrese de que las pruebas que se realizan minimizar la interrupción de los procesos de negocio, sistemas de información y personas. Usted quiere evitar situaciones perjudiciales como miscommunicating el calendario de pruebas y provoca un ataque DoS contra un sitio de comercio electrónico de alto tráfico en el medio del día o de la realización de pruebas de descifrado de contraseñas en el medio de la noche.

Incluso los que tienen las personas en diferentes zonas horarias pueden crear problemas. Todo el mundo en el proyecto debe acordar un calendario detallado antes de empezar. Tener el acuerdo de los miembros del equipo pone a todos en la misma página y establece las expectativas correctas.

Su línea de tiempo de prueba debe incluir fechas específicas a corto plazo y los tiempos de cada prueba, las fechas de inicio y fin, y cualquier hitos específicos en el medio. Usted puede desarrollar e introducir su línea de tiempo en una simple hoja de cálculo o un gráfico de Gantt, o puede incluir la línea de tiempo como parte de su propuesta de cliente original y del contrato. Su línea de tiempo también puede ser estructuras de desglose de trabajo en un plan de proyecto más grande.

Ejecutar pruebas específicas

Es posible que haya sido acusado de realizar un general prueba de penetración, o es posible que desee realizar pruebas específicas, tales como grietas contraseñas o tratando de obtener acceso a una aplicación web. O usted podría estar llevando a cabo una prueba de ingeniería social o la evaluación de Windows en la red.

Sin embargo se prueba, es posible que no quiere revelar los detalles de la prueba. Incluso cuando su gerente o el cliente no requiere un registro detallado de sus pruebas, documentar lo que está haciendo en un nivel alto. Documentar su prueba puede ayudar a eliminar cualquier malentendido potencial.

Usted puede ser que sabe las pruebas generales que se realizan, pero si utiliza herramientas automatizadas, puede ser imposible de entender todas las pruebas a realizar por completo. Esto es especialmente cierto cuando el software que está utilizando recibe actualizaciones y parches de vulnerabilidad en tiempo real desde el proveedor cada vez que lo ejecute. El potencial para las actualizaciones frecuentes de relieve la importancia de la lectura de la documentación y los archivos que vienen con las herramientas que utiliza.

Ciegos frente evaluaciones de conocimiento

Tener algún conocimiento de los sistemas que está probando que podría ser una buena idea, pero no es necesario. Pero, una comprensión básica de los sistemas que hackear puede protegerlo a usted ya los demás. La obtención de este conocimiento no debería ser difícil si usted está hackear sus propios sistemas internos.

Si hackear los sistemas de un cliente, puede que tenga que cavar un poco más profundo en cómo los sistemas de trabajo por lo que está familiarizado con ellos. Esto no quiere decir que las evaluaciones ciegas no son valiosos, pero el tipo de evaluación que lleva a cabo depende de sus necesidades específicas.

El mejor enfoque es planear en ilimitado ataques, en los que cualquier prueba de que es posible, incluso posiblemente incluyendo pruebas de DoS.

Considerar si las pruebas se deben realizar para que estén sin ser detectados por los administradores de red y los proveedores de servicios de seguridad gestionados. Aunque no es necesario, esta práctica debe ser considerada, sobre todo para la ingeniería social y las pruebas de seguridad física.

Localización

Las pruebas que se realizan dictan en el que debe ejecutarlos desde. Su objetivo es poner a prueba sus sistemas de lugares accesibles por los hackers o empleados maliciosos. No se puede predecir si serás atacado por alguien dentro o fuera de la red, por lo que cubrir todas sus bases. Combina pruebas externas y pruebas internas.

Puede realizar algunas pruebas, como las evaluaciones de craqueo contraseña y la red de infraestructura, de su oficina. Para hacks externos que requieren conectividad de red, es posible que tenga que ir fuera del sitio o usar un servidor proxy externo. Escáneres de vulnerabilidad Algunos proveedores de seguridad 'se ejecutan desde la nube, por lo que funcionaría también.

Mejor aún, si se puede asignar una dirección IP pública a disposición de su equipo, sólo tiene que conectar a la red por fuera del servidor de seguridad para una vista un hacker de ojos de sus sistemas. Las pruebas internas son fáciles porque usted sólo necesita acceso físico al edificio ya la red. Usted puede ser capaz de utilizar una línea DSL o módem de cable ya existentes para los visitantes y usuarios similares.

Responder a las vulnerabilidades que encuentre

Determinar con antelación si va a detener o seguir adelante cuando se encuentra un agujero de seguridad crítico. No es necesario para mantener la piratería siempre o hasta te estrellas todos los sistemas. Sólo tienes que seguir el camino que eres hasta que no se puede entrar ilegalmente en él por más tiempo. En caso de duda, lo mejor que puede hacer es tener un objetivo específico en mente y luego se detiene cuando se ha cumplido ese objetivo.

Si descubre un agujero mayor, póngase en contacto con las personas adecuadas tan pronto como sea posible para que puedan empezar a fijar el problema de inmediato. Las personas adecuadas pueden ser los desarrolladores de software, gerentes de producto o proyecto, o incluso los CIOs. Si espera unos pocos días o semanas, alguien podría explotar la vulnerabilidad de daños y la causa que podría haber sido prevenido.

Suposiciones tontas

Usted ha oído hablar de lo que hacemos de ti mismo cuando usted asume cosas. Aun así, se hace suposiciones cuando hackear un sistema. Estos son algunos ejemplos de estos supuestos:

• Ordenadores, redes y personas que están disponibles cuando se está probando.

• Usted tiene todas las herramientas de prueba adecuados.

• Las herramientas de prueba que utiliza minimizarán las posibilidades de estrellarse los sistemas se prueba.

• Usted entiende la probabilidad de que no se encontraron vulnerabilidades existentes o que utilizó sus herramientas de prueba de manera incorrecta.

• Usted sabe los riesgos de sus pruebas.

Documentar todos los supuestos y una gestión o su cliente firmar en ellos como parte de su proceso de aprobación general.