Definición de una política de seguridad para un sistema

Question

La mayoría de la literatura sobre seguridad habla sobre la importancia de definir una política de seguridad antes de comenzar a entrenar en los mecanismos y la implementación. Si bien esto parece lógico, no está claro qué significa realmente definir una política de seguridad.

aquí alguien ha tenido alguna experiencia en la definición de una política de seguridad, y si es así:

1) ¿Cuál es el resultado de esa definición? ¿Es la forma de dicha política, por ejemplo, un sistema distribuido, un documento que contiene una serie de declaraciones sobre los requisitos de seguridad (lo que está permitido y lo que no) del sistema?

2) ¿Puede la política tomar la forma legible por máquina (si tiene sentido) y, de ser así, cómo puede usarse?

3) ¿Cómo se mantiene esta política? ¿La política se mantiene como documentación (como con todo el resto de la documentación) en el sistema?

4) ¿Es necesario hacer referencias al documento de política en el código?

Brian

Answer 1

Si usted tiene que diseñar una política de seguridad, ¿por qué no pensar en los usuarios y los permisos?

Entonces, digamos que tiene una API para algo. Considere algunos arreglos de usuarios que los divide en lo que quieren hacer y qué permisos mínimos necesitan para hacerlo. Entonces, si alguien solo tiene que leer documentos de una base de datos, la API en sí misma no permitirá que el usuario haga otra cosa.

Imagine que se trata de una API JSON web. El usuario hace clic en un botón y JS procesa una solicitud y la envía. Normalmente funciona bien, pero si alguien manipula la solicitud, el servidor simplemente devuelve un código de error porque está listando solo algunas acciones que el usuario puede hacer.

Así que creo que todo se reduce a los usuarios y permisos.

Answer 2

Debe seguir una de las políticas de seguridad estándar y trabajar desde allí. El que es más común es el cumplimiento de PCI (Payment Card Industry). Está muy bien pensado y a excepción de algunos puntos débiles, generalmente buenos. Nunca he oído hablar de una política legible por máquina a excepción de una definición de Microsoft Active Directory o una serie de reglas de iptables de Linux.

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

EDIT:

Echa un vistazo a las políticas SE Linux también:

http://en.wikipedia.org/wiki/Security-Enhanced_Linux

Answer 3

El Proyecto de seguridad de aplicaciones OWASP Web Abierta es un proyecto independiente del idioma para educar sobre la seguridad y proporcionar herramientas para probar y soportar software. Si bien está centrado en la web, muchas de las ideas básicas son ampliamente aplicables. El sitio web está dirigido tanto a los ingenieros de software como a la administración.

Answer 4

Cuando la gente habla de "políticas de seguridad", es posible que se refieran a dos tipos diferentes de políticas de seguridad.

Uno de ellos son de alto nivel, generalmente definidos por las gerencias. Los principales lectores de esta política de seguridad son humanos. Es un documento que define la meta, el contexto, las expectativas y los requisitos de seguridad en la mente de la administración.Los idiomas utilizados dentro de esta política pueden ser imprecisos, pero es la "ley" elemental de seguridad en el contexto de aplicación. Todos los involucrados deberían seguir esa política.

1) El resultado de dicha política son los requisitos de seguridad claramente definidos de la administración. Con estas políticas, todos los involucrados pueden comprender las expectativas de la administración y tomar decisiones relacionadas con la seguridad cuando sea necesario.

2) Como los lectores principales de dichas políticas de seguridad son humanos, y las declaraciones son generalmente muy generales, puede que no estén en forma legible por máquina. Sin embargo, puede haber un par de documentos definidos en base a la política, a saber, pautas de seguridad, procedimientos y manuales. Están en el orden de aumentar el nivel de detalles sobre cómo la seguridad debería implementarse realmente. Por ejemplo, los requisitos definidos en la política de seguridad pueden realizarse en manuales de reforzamiento para diferentes sistemas operativos, de modo que los administradores e ingenieros puedan realizar tareas de refuerzo de manera eficiente sin tener que dedicar demasiado tiempo a interpretar los pensamientos de la administración. Los manuales de endurecimiento se pueden convertir en un conjunto de configuraciones legibles por máquina (por ejemplo, longitud mínima de contraseña, recuento máximo de inicio de sesión de falla antes de bloquear la cuenta, etc.) automatizando las tareas de endurecimiento.

3) El documento debe estar disponible para todos los involucrados y debe ser revisado regularmente por la administración.

4) Prácticamente puede ser difícil hacer tales referencias. Las políticas de seguridad pueden actualizarse de vez en cuando, y es probable que no desee recompilar su programa si los cambios de política solo afectan algunos parámetros. Sin embargo, es bueno hacer referencia a la política en documentos de desarrollo como diseño sepc.

Otro tipo de "políticas de seguridad" podría referirse simplemente a esos conjuntos de parámetros de los programas de seguridad de entrada. Descubrí que a algunos programas de seguridad les gusta usar la palabra "política" para hacer que sus configuraciones estén más organizadas y estructuradas. Pero, de todos modos, estas "políticas de seguridad" en realidad son solo valores y/o instrucciones para que sigan los programas de seguridad. Por ejemplo, Windows tiene su propio conjunto de "políticas de seguridad" para que el usuario configure registros de auditoría, derechos de usuario, etc. Este tipo de "políticas de seguridad" (parámetros para programas) se define en realidad según el primer tipo de "políticas de seguridad" (requisitos de la administración) como se mencionó anteriormente.

Podría estar escribiendo demasiado sobre esto. Espero eso ayude.