Está bien, por lo que originalmente fue pensado como un comentario a su respuesta a la respuesta dada por @ jl01 pero se hizo demasiado largo y debería tener mérito por sí mismo ...
Hay casi un arte para crear políticas. Idealmente (aunque estoy seguro de que algunas personas no estarían de acuerdo conmigo) una política sería una declaración muy general con respecto al tema. Por ejemplo, algo no mucho más complejo que "Esta compañía operará con las mejores prácticas actuales para parchear el sistema". La idea es que se debe establecer una política y no es necesario cambiarla (si se hace perfectamente). Debe ser lo suficientemente generalizado para que no sea necesario actualizarlo a medida que cambien las diferentes tecnologías, vectores de ataque, regulaciones, etc.
Es muy común dividir las políticas en cada ámbito separado de negocio / tecnología. Esto se presta para producir políticas que se ajusten más a la medida de su empresa y le permite mantener la claridad al referirse a esas políticas.
Otra forma de verlo es que una política es la forma que tiene la empresa de cubrir sus extremos traseros. Se crea para cubrir tanto como sea posible, por lo que si algo sale mal, la compañía puede moldear su respuesta a cada situación por separado mientras sigue usando la misma política.
Esas políticas se ampliarán a través de procedimientos, directrices y regulaciones (pensándolo bien, esto debería ser bastante parecido a cómo lo describen las RAS). Creo que las SAN se refieren a lo que yo llamo "procedimientos" como "estándares". Pido disculpas por cualquier confusión debido a eso.
Un procedimiento sería una práctica real que sigue una política (muchas políticas que he visto parecen referirse a los procedimientos aplicables dentro de la propia política).
Una directriz por otro lado es exactamente eso, una sugerencia de prácticas aceptables. Aunque son solo sugerencias, no deben tomarse a la ligera. Cuando se realizan las auditorías, estos son los frutos colgados a los que un auditor puede adherirse.
Los procedimientos y las pautas son las únicas cosas que debe actualizar con el cambio en el clima empresarial, los problemas ambientales, las amenazas, etc.
Cuando diseñé mi primer conjunto de políticas, concedí que esto era de una clase con respecto a las políticas de seguridad de la información, configuré estas políticas diferentes:
- Política de sensibilidad a la información
- Política de extranet
- Política de correo electrónico
- Política de medios extraíbles
- Política de contraseñas
- Política de supervisión de seguridad
- Política de seguridad del enrutador
- Política de seguridad del servidor
- Política de actualización del sistema
- Política de ASP
- Política de administración del servidor
- Política de entrenamiento de seguridad
Esta no es una lista exhaustiva, pero debería darle una idea de algunos de los desgloses que pueden ocurrir. La forma en que se dividen las políticas depende de las necesidades de esa empresa.
Por último, pero definitivamente no menos importante, cada política debe crearse de tal manera que haya dudas sobre qué y cómo se aplica. Con esto, me refiero a que junto con cada política se debe establecer el propósito, el alcance, la aplicación y las definiciones con respecto a esa política. Siempre me divierto escribiendo la frase "estará sujeto a repercusiones hasta e incluyendo la terminación".
Aunque no lo mencioné anteriormente, debería haber una política de ética en cada conjunto de políticas. Incluso cuando utilice ASP, o cualquier otro servicio, es una buena práctica solicitar su política de ética y, según lo que vea, exigir por contrato que cumplan con la política de ética de su compañía para ese trabajo.
Por lo tanto, es posible que haya profundizado un poco en el tema ... pero espero que haya ayudado.
Descargo de responsabilidad: soy más que consciente de que esta no es la única forma en que se pueden construir las políticas. Desde mi experiencia, la mayoría de las compañías tienen un conjunto de políticas que se han desarrollado libremente a lo largo de años de cambios en la regulación y problemas de cumplimiento.
p.s. Un ASP es un proveedor de servicios de aplicaciones, veo que no he mencionado su definición en ningún lugar arriba.