Documentación<Anterior | Contenido | Siguiente>
7.1. Definición de una política de seguridad
No es práctico discutir la seguridad a grandes rasgos, ya que la idea representa una amplia gama de conceptos, herramientas y procedimientos, ninguno de los cuales se aplica universalmente. Elegir entre ellos requiere una idea precisa de cuáles son sus objetivos. Asegurar un sistema comienza respondiendo algunas preguntas. Si se apresura a implementar un conjunto arbitrario de herramientas, se corre el riesgo de centrarse en los aspectos incorrectos de la seguridad.
Por lo general, es mejor determinar un objetivo específico. Un buen enfoque para ayudar con esa determinación comienza con las siguientes preguntas:
• What estás tratando de proteger? La política de seguridad será diferente dependiendo de si desea proteger las computadoras o los datos. En el último caso, también necesita saber qué datos.
• ¿Qué estás tratando de proteger? en contra? ¿Es una fuga de datos confidenciales? ¿Pérdida accidental de datos? ¿Pérdida de ingresos causada por la interrupción del servicio?
• También, que estás tratando de protegerte? Las medidas de seguridad serán bastante diferentes para protegerse contra un error tipográfico por parte de un usuario habitual del sistema frente a protegerse contra un grupo atacante externo determinado.
El término "riesgo" se usa habitualmente para referirse colectivamente a estos tres factores: qué proteger, qué debe evitarse y quién podría hacer que esto suceda. Modelar el riesgo requiere respuestas a estas tres preguntas. A partir de este modelo de riesgo, se puede construir una política de seguridad y la política se puede implementar con acciones concretas.
Interrogatorio permanente Bruce Schneier, un experto mundial en cuestiones de seguridad (no solo seguridad informática), intenta contrarrestar uno de los mitos más importantes de la seguridad con un lema: "La seguridad es un proceso, no un producto". Los activos que deben protegerse cambian con el tiempo, al igual que las amenazas y los medios disponibles para los atacantes potenciales. Incluso si una política de seguridad inicialmente se ha diseñado e implementado perfectamente, nunca debe dormirse en los laureles. Los componentes del riesgo evolucionan y la respuesta a ese riesgo debe evolucionar en consecuencia.
Interrogatorio permanente Bruce Schneier, un experto mundial en cuestiones de seguridad (no solo seguridad informática), intenta contrarrestar uno de los mitos más importantes de la seguridad con un lema: "La seguridad es un proceso, no un producto". Los activos que deben protegerse cambian con el tiempo, al igual que las amenazas y los medios disponibles para los atacantes potenciales. Incluso si una política de seguridad inicialmente se ha diseñado e implementado perfectamente, nunca debe dormirse en los laureles. Los componentes del riesgo evolucionan y la respuesta a ese riesgo debe evolucionar en consecuencia.
También vale la pena tener en cuenta las restricciones adicionales, ya que pueden restringir la gama de políticas disponibles. ¿Hasta dónde está dispuesto a llegar para asegurar un sistema? Esta pregunta tiene un gran impacto sobre qué política implementar. Con demasiada frecuencia, la respuesta solo se define en términos de costos monetarios,
pero también deben tenerse en cuenta otros elementos, como la cantidad de inconvenientes impuestos a los usuarios del sistema o la degradación del rendimiento.
Una vez que se ha modelado el riesgo, puede comenzar a pensar en diseñar una política de seguridad real.
Hay extremos que pueden entrar en juego a la hora de decidir el nivel de protección de seguridad a adoptar. Por un lado, puede resultar extremadamente sencillo proporcionar seguridad básica al sistema.
Por ejemplo, si el sistema a proteger solo comprende una computadora de segunda mano, cuyo único uso es agregar algunos números al final del día, decidir no hacer nada especial para protegerlo sería bastante razonable. El valor intrínseco del sistema es bajo y el valor de los datos es cero ya que no se almacenan en la computadora. Un atacante potencial que se infiltrara en este sistema solo obtendría una calculadora. El costo de asegurar un sistema de este tipo probablemente sería mayor que el costo de una infracción.
En el otro extremo del espectro, es posible que desee proteger la confidencialidad de los datos secretos de la manera más completa posible, superando cualquier otra consideración. En este caso, una respuesta adecuada sería la destrucción total de los datos (borrar de forma segura los archivos, triturar los discos duros en bits, luego disolver estos bits en ácido, etc.). Si existe un requisito adicional de que los datos deben mantenerse almacenados para uso futuro (aunque no necesariamente están disponibles fácilmente), y si el costo aún no es un factor, entonces un punto de partida sería almacenar los datos sobre la aleación de iridio y platino. placas almacenadas en búnkeres a prueba de bombas bajo varias montañas del mundo, cada una de las cuales es (por supuesto) totalmente secreta y custodiada por ejércitos enteros.
Estos ejemplos, por extremos que puedan parecer, serían una respuesta adecuada a determinados riesgos definidos, en la medida en que son el resultado de un proceso de pensamiento que tiene en cuenta los objetivos a alcanzar y las limitaciones a cumplir. Al provenir de una decisión razonada, ninguna política de seguridad es más o menos respetable que otra.
Volviendo a un caso más típico, un sistema de información se puede segmentar en subsistemas consistentes y en su mayoría independientes. Cada subsistema tendrá sus propios requisitos y restricciones, por lo que la evaluación de riesgos y el diseño de la política de seguridad deben realizarse por separado para cada uno. Un buen principio a tener en cuenta es que una superficie de ataque pequeña es más fácil de defender que una grande. La organización de la red también debe diseñarse en consecuencia: los servicios sensibles deben concentrarse en un pequeño número de máquinas, y estas máquinas solo deben ser accesibles a través de un número mínimo de rutas o puntos de control. La lógica es sencilla: es más fácil asegurar estos puntos de control que proteger todas las máquinas sensibles contra la totalidad del mundo exterior. Es en este punto cuando se hace evidente la utilidad del filtrado de red (incluso mediante firewalls). Este filtrado se puede implementar con hardware dedicado, pero una solución más simple y flexible es usar un firewall de software como el integrado en el kernel de Linux.