¿Qué puede hacer una empresa contra los insiders que se vuelven ilegales y afectan negativamente la infraestructura esencial?

  

¿Qué se puede hacer para evitar que los informantes maliciosos repentinos   impacto negativo en la infraestructura esencial utilizando técnicas que están   privilegiado para hacer?

En la práctica, muy poco . Pero para explicar por qué, déjame hablar sobre lo que puedes hacer.

El problema aquí es que el usuario está "privilegiado": se le ha otorgado el poder legítimamente.

Se pueden hacer algunas cosas para limitar el poder otorgado a los usuarios legítimos, incluso a los administradores privilegiados:

• Controla los comandos disponibles usando algo como sudo o PowerBroker.
• Control dual (la "regla de dos hombres" @ paj28 describe
• Controles de flujo de trabajo (que a menudo son una forma de doble control)

Ahora, estos controles se usan mucho menos de lo que podrían ser. ¿Por qué? Porque los usuarios privilegiados son de confianza por definición . Por eso digo muy poco no porque no haya controles, sino porque la relación costo-beneficio de tales controles cuando se aplican a personal de confianza no es suficiente para justificarlo.

También tenga en cuenta que el vector de ataque aquí fue "en la tubería": si Citibank tiene controles duales, es probable que estén enfocados en cosas como transferencias de fondos, mientras que este ataque llegó de rodillas y simplemente eliminó la red subyacente. Estos sistemas vitales pero silenciosos a menudo tienen círculos más pequeños de usuarios privilegiados y menos controles excesivos.

El error real aquí no fue que no existieran controles técnicos, sino que los controles de personal fallaron miserablemente. Es una práctica estándar revocar el acceso de los empleados privilegiados antes de que finalicen. Quien haya decidido que no era necesaria tal precaución cuando se introdujo un conflicto con un empleado privilegiado, utilizó un juicio pobre.

(La compañía también empleó controles punitivos: el atacante ahora está sentenciado a casi 2 años de prisión y debe pagar casi $ 80,000. Como señala el artículo, esas cosas no solucionan nada de esto).

Regla de dos personas : configure sus sistemas de modo que todos los accesos privilegiados requieran dos personas.

Esto podría ser un control físico: el acceso privilegiado solo puede provenir del CON y, dentro del CON, la gente aplica físicamente la regla.

Más práctico sería un sistema de scripting. Los administradores de sistemas no tienen acceso de root directamente, pero pueden enviar scripts para que se ejecuten como root. Solo se ejecutarán después de que otra persona haya revisado y aprobado el script. Todavía tendría que haber un método para el acceso SSH en una emergencia, y la regla de dos personas se podría mantener en ese caso utilizando controles físicos.

La NSA implementó esto Después de las fugas de Snowden. Nunca he visto un sistema completo de dos personas en ninguno de los sistemas comerciales o gubernamentales que he auditado, aunque he visto varios intentos parciales.

Actualización : hay más información sobre cómo implementar esto en un pregunta separada .

Un enfoque es aceptar que las acciones ilegales no pueden prevenirse y enfocarse en asegurarse de que el daño pueda repararse. Por ejemplo, asegúrese de que los enrutadores tengan un plano de control separado a través del cual puedan volver a conectarse. Asegúrese de tener copias de seguridad de solo lectura (por ejemplo, cintas externas), por lo que si alguien borra todos los discos duros, puede recuperar los datos. Asegúrese de que los datos y el código puedan revertirse rápidamente a un buen estado conocido.

Estas salvaguardas también ayudarán mucho en el caso de errores no intencionales.

Auditoría. En particular, el tráfico de red y las acciones / operaciones realizadas en máquinas particulares. Desea capturar, quién hizo qué , cuando lo hicieron y de dónde . Si bien esto no evitará un ataque, ayudará a disuadir tales acciones si el interno cree que serán identificados y atrapados.

Luego tiene que entrar en el tema de los mecanismos de auditoría a prueba de falsificaciones

La cuestión de proteger un sistema o red de una información privilegiada, más específicamente de la descripción de trabajo de la gente que incluye la creación y administración de dicho sistema siempre ha sido delicada.

Primero, lo que uno debe entender es que, al final, es totalmente imposible evitar todo tipo de ataques contra una infraestructura desde el interior, ya que eso implicaría restringir todo contacto con la infraestructura. , haciéndolo particularmente inútil.

Sin embargo, hay formas en que podemos prevenir y minimizar cualquier daño al sistema. A este proceso, reconozco personalmente que hay tres etapas:

1. La regla de los dos hombres
2. La regla de responsabilidad
3. División del Trabajo

Estos procesos se complementan entre sí para ayudar a cualquier sistema a mantenerse protegido de los intrusos que trabajan desde adentro.

La regla de los dos hombres

Comencemos con el más obvio, la regla de Dos Hombres. Una parte importante para la seguridad de TI e infraestructura es asegurarse de que todo el comportamiento dentro del sistema sea identificable y deseado. Esto implica que cualquier acción que se realice dentro del sistema es de confianza .

Cuando muestro un ejemplo de esto, mi forma favorita de explicar es el sistema Git de Forking and Pulling. En Git, todos los que tengan acceso al repositorio (La infraestructura en este caso) pueden hacer una copia. Luego, las personas con acceso pueden solicitar que ingresen su código en el repositorio. Sin embargo, para que esto suceda, el código extraído debe ser analizado, marcado como compatible y luego autorizado por otra persona.

Lo mismo podría decirse y hacerse para una infraestructura segura. Todo el personal de administración puede cambiar el código, pero para que los cambios entren en producción, deben ser aprobados por uno o más empleados.

La regla de responsabilidad

Otro problema común con ciertos tipos de sistemas y redes es que hay una cuenta de administración, cuya contraseña es conocida por todos los miembros con acceso. El primer problema con la rendición de cuentas se plantea aquí. Muchas empresas, cuando se encuentran en situaciones de miembros deshonestos que realizan cambios no autorizados en el servidor, confían en métodos primitivos, como verificar la dirección IP de la máquina, para localizar quién podría haber publicado cambios en el sistema. Esto puede solucionarse simplemente asegurándose de que todos tengan su propia cuenta, y avisándoles de que se han registrado sus cambios.

Como se mencionó en el último párrafo, el registro es el segundo problema. El problema de confianza vuelve a salir a la superficie en este caso. Como el miembro es de confianza para realizar ciertos cambios en el sistema, en la mayoría de los casos el sistema no registra correctamente las acciones del usuario.

Esta situación es el punto perfecto para implementar la responsabilidad de la acción. El usuario de administración debe ser consciente de que no solo se realiza un seguimiento de sus acciones en todo momento mientras se modifica la infraestructura, sino que también tendrán responsabilidades y sanciones vinculadas al contrato por acciones deliberadas.

División del Trabajo

Este es otro concepto que se pasa por alto en la mayoría de las posiciones gerenciales de infraestructura de TI. Los equipos de TI tienen la tendencia a dividir sus tareas, sin embargo, no es raro que la mayoría de los usuarios tengan acceso para realizar cualquier tarea.

La mejor manera de evitar esto es tener tareas específicas de administración del sistema asignadas a solo dos personas (para evitar los casos en que una persona no está disponible). Mientras que otros usuarios aún pueden verificar y aprobar los cambios, utilizando la Regla de Two-Man , solo un puñado de usuarios pueden comenzar esos cambios en primer lugar.

Sugerencia personal

Una forma personal favorita de implementar la seguridad en todo el sistema, especialmente en grandes entornos empresariales, es tener 3 conjuntos de servidores. Alpha, Beta y Production, los dos primeros son un clon de este último. Cualquiera puede mover los cambios a Alpha, usamos este sistema para probar cómo reaccionaría en Producción. Beta es para cambios que se han probado y están listos para ser implementados. Para llegar a esta etapa, varios miembros (~ 5) del departamento de TI deben aprobar el cambio. Cuando se encuentra en esta etapa, el departamento de TI también documenta los cambios y los envía a la Administración y como Memo a TI. Para llegar a Producción, 3 miembros de la administración de alto perfil deben aprobar el cambio, utilizando sus propias cuentas, a las que el departamento de TI no puede acceder.

Última nota

Como habrás notado, este no es un proceso fácil. Implementar muchas de estas ideas ralentizará la producción. Esta es una de las cuestiones por excelencia de la seguridad. Cuanto más seguro es un sistema, más difícil se vuelve cambiar y modificar. Para que su negocio sea productivo, debe equilibrar Seguridad y Confianza .

Al garantizar que los comandos que podrían afectar negativamente a la infraestructura de forma tal que no se pueda acceder de forma remota, solo se pueden ejecutar localmente.

Esto se puede lograr de varias maneras. Por ejemplo, deshabilitar el comando de apagado. Otra forma es tener un watchdog (dispositivo de hardware que detecta cambios en la disponibilidad) que reiniciará dicha infraestructura o ejecutará un procedimiento de recuperación si la infraestructura se vuelve inalcanzable.

Una tercera forma es garantizar el acceso remoto, por ejemplo, mediante el uso de soluciones KVM sobre IP, y luego vincular estos recursos a controles que solo pueden manipularse en el sitio. Por lo tanto, si la infraestructura se desactiva, se puede restaurar fácilmente de forma remota.

Por supuesto, es importante tener copias de seguridad de los archivos de configuración, sistemas importantes y demás. Dado que los archivos de configuración rara vez se cambian, yo diría que sería bueno hacer una copia de seguridad de los archivos de configuración después de cada cambio de configuración que se haya decidido confirmar.

En caso de que sea necesario desconectar la infraestructura debido a eventos de seguridad críticos, se puede usar un sistema de emergencia, que desconectará la infraestructura de manera que la administración pueda recuperarla fácilmente, sin necesidad de una visita in situ.

El problema aquí no era realmente ese empleado deshonesto. ¿Qué pasa si ese empleado hizo lo mismo, pero como un error. Digamos que su intención era reparar un dispositivo de red que funciona mal, sin darse cuenta de que el equipo se desconectará después de un borrado de la configuración, y hace ese código en particular & comando mencionado en la pregunta, con la intención de volver a crear el archivo de configuración después de que se haya borrado, pero después de haber ejecutado el comando, se da cuenta de que "oops, ya no puedo conectar con el dispositivo".

¿Y por lo tanto causa el mismo tipo de daño? Confíe en mí, he cometido el mismo error, principalmente con mis propios sistemas, que luego me obligaron a visitar la ubicación física del equipo. (pero en ese caso las cosas no eran críticas, pero si los sistemas son críticos, deberías hacer algo al respecto)

Es por eso que deben existir dispositivos de seguridad, por lo que es imposible causar ese tipo de daño de forma remota, intencional o no.

Muchas buenas respuestas aquí, pero una que parece faltar es abrazar el Principio del privilegio mínimo (PoLP). Si no hay un caso de uso legítimo para borrar los archivos de configuración del enrutador, no le dé a nadie acceso para hacerlo. Si hay un caso de uso legítimo pero no es relevante para las operaciones diarias, se requiere (y audita) un proceso de aprobación para obtener ese privilegio (esto es, en efecto, una variación de la regla de dos personas que solo se aplica a operaciones especialmente sensibles).

También hay copias de seguridad y cajas de seguridad. Para tomar el ejemplo original, si se borra la configuración de un enrutador, se debe revertir a una configuración ineludible ineludible (y activar una alarma). Esto también debería suceder si falla una comprobación de estado interna. Alternativamente, si tiene controles de estado, puede hacer que el sistema vuelva a una configuración de "última buena conocida", esencialmente restaurándose a partir de una copia de seguridad si algo sale mal. El acceso de escritura a estas comprobaciones a prueba de fallas / copias de seguridad / estado de salud debe estar bajo una seguridad extremadamente estricta - nadie debe tener privilegios diarios para ellos, o ser capaz de obtener tales privilegios fácilmente, de modo que incluso la mayoría el personal de confianza de alta confianza no puede ignorarlos ni sobrescribirlos unilateralmente.

Obviamente, todas estas soluciones tendrán costos. Casi siempre hay una compensación entre la seguridad y los recursos de gasto (generalmente descritos como "conveniencia", pero los recursos también pueden ser tiempo y / o dinero). Un PoLP realmente bueno significa que nadie obtiene acceso genuino a nivel raíz (a nivel de dios) a nada, por ejemplo, lo que ralentiza las cosas para las personas a las que se les puede confiar tanto acceso a probablemente (nunca se puede saber realmente ). El código a prueba de fallos es más difícil de escribir que el código que solo confía en cualquier comando que se alimenta de una fuente "confiable", incluso si ese comando es HCF . La paranoia tiene su precio ... pero ese precio puede ser inferior a lo que cuesta si pierde el 90% de su conectividad de red.

Un solo empleado nunca debería tener el poder de realizar un daño tan generalizado. Acciones administrativas de este tipo siempre deben requerir la autenticación de dos o más administradores independientes, donde el sistema de autenticación solo puede ser desactivado por los administradores de nivel superior.

En caso de que ya haya ocurrido, el empleador tendría todo el derecho de despedir al empleado.

En todas las empresas que he visto, también había reglas internas de seguridad muy estrictas. No pudimos ver nada de otros proyectos, solo nuestras tareas reales.

Si nos movíamos entre proyectos / departamentos, nuestros permisos siempre se ajustaban con precisión.

Solo un conjunto reducido de administradores de sistemas tuvo acceso a grandes partes de la infraestructura, todos trabajaron al menos 5-10 años allí. Probablemente nadie tuvo acceso a toda la red.

Conectar cualquier cosa a la red de la empresa sin un permiso explícito (era imposible incluso pedir eso) siempre estaba estrictamente prohibido. Una vez que conecté mi teléfono inteligente al puerto USB (solo para cargarlo), en 5 minutos mi compañero de trabajo me preguntó qué estaba haciendo.

Nuestras computadoras / computadoras portátiles nos fueron entregadas preinstaladas con los certificados de la compañía. Después de dejar la empresa, los devolvimos.

Hubo controles de seguridad regulares, que fueron realizados por una empresa externa (- > nadie sabía, qué y cómo lo hacen). También nuestro software lo que producimos, fueron examinados por ellos.

Lo que hemos hecho en la red de la empresa, probablemente se registraron y se respaldaron hasta la fecha.

Si hubiéramos tenido dudas, no sabríamos cómo se almacenarán y examinarán los registros. Después de dejar la empresa, nuestras computadoras también fueron verificadas por la empresa externa, y probablemente se hicieron copias de seguridad a nivel sectorial, para el caso de un "problema" que aparezca más adelante, como evidencia.