dilema del mandato de la política

Para citar AviD sobre esto:

  

La seguridad a expensas de la usabilidad viene a expensas de la seguridad

Si hace que sea demasiado difícil cumplir una política de seguridad, las personas lo ignorarán o buscarán lagunas y soluciones alternativas que cumplan con la letra pero no con el espíritu. Así llegará a lo contrario de lo que pretendía y debilitaría la seguridad.

Una política de seguridad debería:

• Tenga el objetivo de hacer que las personas sean sensibles a los problemas en lugar de hacer cumplir las soluciones.
• Aliente a las personas a asumir la responsabilidad de mantener una buena seguridad en lugar de seguir ciegamente las instrucciones.
• En su mayoría, las políticas DEBERÍAN y no DEBEN políticas, de modo que las personas puedan divergir cuando tengan una buena razón.
• Encuentre un compromiso razonable entre seguridad y facilidad de uso.

Anécdota: Un amigo mío trabajé en un equipo manteniendo un sistema con una política de contraseña muy estricta. No solo exigía cambios de contraseña regulares, una longitud mínima y el uso de números, minúsculas, mayúsculas y caracteres especiales, sino que también tenía un conjunto largo de reglas que tenían la intención de evitar que las contraseñas fueran demasiado similares a las anteriores. contraseñas El resultado fue que, por lo general, podría encontrar documentos en las papeleras o desperdigados en la oficina donde las personas intentaron construir contraseñas para ajustarse a estas estrictas políticas. Gracias a la política de contraseñas, hubiera sido ridículamente fácil obtener contraseñas a través de Dumpster Diving.

Algunos consejos de alguien que ha escrito muchas políticas:

Regla # 1.

Esta es la regla más importante. De hecho es un requisito para iniciar cualquier otro proceso. Si su equipo de administración no va a respaldar las políticas, no vale la pena su tiempo, el tiempo de las empresas, y mucho menos el tiempo de los usuarios para promulgar nada. Estoy hablando de tu nivel C, si no están a bordo, detente ahora. Salva tu angustia mental.

Política, estándar, procedimiento, directriz

Hay una diferencia drástica entre ellos, y debes leerlo, pero en resumen:

• Política: ¿Por qué necesitamos esto?
• Estándar: ¿Qué se necesita para esto?
• Procedimiento - ¿Cómo ejecutamos esto?
• Directrices: buenas prácticas, notas importantes, etc.

Las políticas son metas

Las políticas son lo que usted busca en su empresa. Sin embargo, surgen situaciones en las que no siempre se puede cumplir el objetivo de sus políticas. Llamamos a estas excepciones, y generalmente hay equipos que analizan el riesgo de no cumplir con los requisitos. Algunas empresas pueden excluirse de una política de seguridad sin sentido (muy mala), otras compañías están tan fuertemente reguladas (piense en la banca) donde el incumplimiento de la política puede tener un gran impacto en las operaciones de las compañías.

Los usuarios son importantes ............

Cuanto más grande sea la organización, más usuarios, más opiniones, más difícil de cambiar. A un cierto nivel, los cambios son promulgados por la gerencia con la ayuda de los empleados. Las organizaciones más pequeñas, pueden ser promulgadas por los empleados con la aprobación de la gerencia. Esto suena similar, pero puede ser muy diferente para las interacciones.

La seguridad de la información tiene un momento bastante difícil con la política por el simple hecho de que normalmente estamos obligando a otros grupos a cumplir con nuestros mandatos. En las grandes empresas, forzar una política como los requisitos de contraseña, no es algo que IS sea responsable de implementar. Normalmente es un equipo OPS, o propietario de la aplicación.

No todos necesitan una política, pero les afecta

A Jenny en contabilidad no le importa que Paul en TI requiera que Frank en TI se asegure de que el servidor esté ejecutando TLS o que implemente una contraseña mínima en la aplicación de contabilidad. A Jenny le importará si no tienes una política y, mágicamente, un día, la contraseña de Jenny de 1234 debe tener 8 caracteres alfanuméricos. Esto no es una política, esto es un impacto y puede o no formar parte de su tratamiento. Nota simple, HR es tu amigo.

Básicamente, tiene dos opciones aquí: 1) considera la capacidad y tiene un proceso para excepciones o 2) se niega a trabajar con cualquiera que no pueda implementar sus políticas.

Si no hace 1) y no puede hacer 2) significa que sus políticas existen solo en papel. Si no tiene el poder de hacer que 2) ocurra, se queda considerando las capacidades. Sin embargo, diría que usted necesita tener cierta capacidad para ser estricto. Si un proveedor no puede hacer un mínimo de 12 caracteres, es posible que pueda aceptar esas otras estrategias de mitigación dadas, pero no querría adaptarse a problemas realmente graves, por ejemplo. una contraseña de administrador codificada

Una cosa que podría hacer dependiendo de las políticas a las que acuda es hacer que sus políticas se complementen entre sí, donde la implementación de una política se vuelve más fácil y / o más segura si también implementa otra política.

Por ejemplo: da la política de ejemplo de requisitos de contraseña. Si junto a esa política también tiene la política de exigir a sus usuarios que utilicen un administrador de contraseñas que pueda encargarse de crear y almacenar una contraseña adecuada de manera segura, sus usuarios estarán menos inclinados a jugar con el sistema, porque no jugarán al sistema. es más fácil.

Otro ejemplo: si requiere que sus usuarios usen TLS en sus servidores front-end, algunos de ellos podrían hacer una implementación de mala calidad con certificados vencidos o inseguros. Una política complementaria sería utilizar Let's Encrypt para facilitar el manejo de certificados.

Algo que podría usar simultáneamente es alentar a las personas a implementar políticas adecuadamente a través de incentivos monetarios. No estoy hablando de otorgar tarifas o multas a quienes hacen un mal trabajo, sino más bien de otorgar un pequeño descuento (como el 1% o algo así) en cosas como licencias o tarifas de soporte basadas en ciertos objetivos cuantificables y justos. Por ejemplo: si el sitio web en el que se está ejecutando su producto TLS obtiene una A en Qualys (que es trivial de verificar), obtendrán un 1% de descuento en su próxima renovación de licencia (a menos que usted sea el que mantiene el sitio web, por supuesto).

Así que escribe su política de tal manera que los segmentos se refuercen mutuamente y recompensen a aquellos que van más allá de su deber.

La respuesta depende de por qué incluso estás pensando en establecer un límite de 12 caracteres.

Si se sabe que el sistema es trivial para atacar con contraseñas de 11 caracteres y se ha demostrado que no es computacionalmente viable para atacar con contraseñas de 12 caracteres y los recursos informáticos previsibles del planeta, entonces lo convierte en un requisito absoluto . Cualquiera que no pueda o no quiera implementar ese límite simplemente no cumple con su política de seguridad, y eso es todo. Las consecuencias para ellos pueden ser muy malas (no pueden vender su producto), pueden ser manejables o absolutamente insignificantes (usan un sistema diferente que se basa en su seguridad en algo diferente a los límites de 12 caracteres y, por lo tanto, tiene una política diferente). ), pero esas consecuencias están justificadas .

Si establece un límite de 12 caracteres porque no tiene idea de qué límite debe establecer, y 6 está bastante bien pero no es suficiente para que lo duplique, entonces debe tener en cuenta lo que es práctico implementar. Presumiblemente, usted quiere que la gente use su póliza (en lugar de: si es un empleado que obtiene un trabajo que no los vuelve locos con demandas imposibles; si es el CEO que la ignora y compra algo que no cumple ninguna parte) de su póliza; si son proveedores que encuentran a otro cliente o duplican sus precios para cubrir el esfuerzo adicional). Entonces, si la política contiene requisitos arbitrarios y onerosos, entonces estás arriesgando innecesariamente esas cosas que suceden.

En la práctica, estás en algún lugar entre esos dos extremos. Pero una vez que sepa por qué está haciendo el requisito, puede decidir:

• es un requisito difícil. Cualquier cosa que no lo satisfaga no está de acuerdo con la política.
• es una recomendación que crees que es alcanzable y explicas las consecuencias de no satisfacerla.
• está a medio cocinar. Debe hacer más trabajo para establecer cuál debe ser el requisito antes de establecer la política.

Considera también el objetivo de la política. Si el objetivo del ejercicio es asegurarse de que no utiliza proveedores con configuraciones de seguridad deficientes o promedio, excluir a los proveedores que no tengan configuraciones de seguridad adecuadas, ya sea por su pequeño tamaño o por otro tipo, es una ventaja de de un requisito que solo pueden cumplir aquellos con buena seguridad. La política está ahí para guiar a las personas, también está ahí para excluir a las personas que no pueden cumplirla.

  

¿A quién se va a culpar cuando suceden las cosas? El equipo de seguridad ¿verdad?

Sí, y hay dos formas en que su política puede fallar y usted será culpado. Puede incluir a alguien que, en retrospectiva, te das cuenta de que debería haberlo excluido, y te culpan por una violación de la seguridad. Puede excluir a alguien que, en retrospectiva, se da cuenta de que debería haberlo incluido, y se le acusa de obstruir el negocio de la empresa. Un sistema crítico se corta en ambos sentidos: no quiere que sea inseguro y también no quiere que nunca se construya porque es muy difícil cumplir con la política. Su trabajo es encontrar algo que sea adecuado y alcanzable (o, si no puede hacerlo, al menos explicar por qué no para que alguien más pueda involucrarse en cambiar las restricciones con las que está trabajando).

Una violación masiva de seguridad es mala, pero si fuera intrínsecamente peor que la insolvencia, las compañías "jugarían de manera segura" (por ejemplo) al no adjuntar nada en Internet en primer lugar, y todo irá en quiebra. Por razones obvias, esto no es lo que eligen hacer. Por lo tanto, las disposiciones de la política deben estar justificadas y las justificaciones deben estar disponibles para su revisión posterior, de modo que, incluso si algo sale mal, parecerán decisiones razonablemente buenas dado lo que se sabía en el momento en que las tomó. p>