Protección de recursos

Los recursos incluyen elementos físicos y virtuales, como equipos portátiles, bases de datos, archivos y cuentas de almacenamiento virtual. La protección de recursos críticos para la empresa suelen basarse en la seguridad de los sistemas subyacentes, como el almacenamiento, los datos, los dispositivos de punto de conexión y los componentes de la aplicación. Los recursos técnicos más valiosos suelen ser los datos y la disponibilidad de las aplicaciones, como sitios web empresariales, líneas de producción y comunicaciones.

La protección de recursos implementa controles para admitir la arquitectura, los estándares y las directivas de seguridad. Cada tipo de recurso y requisito de seguridad es único. Los estándares de seguridad para cualquier tipo de recurso deben aplicarse de forma coherente en todas las instancias.

La protección de recursos se centra en la ejecución coherente en todos los tipos de control. La prevención, la detección y otros tipos se armonizan para cumplir las directivas, los estándares y la arquitectura.

La protección de recursos actúa como experto técnico en la materia de los recursos. Funciona con otras materias, como la gobernanza, la arquitectura, las operaciones de seguridad y los equipos de cargas de trabajo. La protección de recursos garantiza que la directiva y los estándares sean factibles y permite la implementación de controles para admitir la directiva y los estándares. La protección de recursos proporciona comentarios para una mejora continua.

Nota:

La protección de recursos la implementan normalmente los equipos de operaciones de TI que mantienen los recursos y se apoyan en la experiencia del equipo de seguridad. Para más información, vea Diseño de controles como equipo.

Los agentes de amenazas son persistentes y buscan vulnerabilidades que se deben a brechas en la aplicación de estándares y directivas. Los atacantes pueden dirigirse directamente a los datos críticos para la empresa o a la aplicación. También pueden dirigirse a la infraestructura que les concede acceso a las aplicaciones y los datos críticos para la empresa. El control de acceso se centra en administrar el acceso autorizado a los recursos. La protección de recursos se dirige a todas las demás formas potenciales fuera de banda de acceder a los recursos o controlarlos. Estas dos materias se complementan entre sí y deben diseñarse conjuntamente para cumplir la arquitectura, las directivas y los estándares. Para más información, vea Control de acceso.

En el diagrama se presenta información general sobre la protección y el control de recursos, con secciones para protegerse y mantenerse seguro.

Vea el siguiente vídeo para obtener información sobre el historial de protección de recursos y cómo mantener seguros tanto los activos antiguos como los nuevos.

Protección

La protección se centra en hacer que recursos cumplan los estándares, las directivas y la arquitectura de seguridad actuales de la organización. Existen dos tipos de actividades:

  • Brownfield: adaptación de los estándares y controles de seguridad actuales a los recursos existentes. Las organizaciones pueden diseñar y operar entornos de TI con la seguridad como una prioridad baja. Este enfoque crea una "deuda técnica": configuraciones de seguridad débiles, software que no está actualizado, comunicación o almacenamiento sin cifrar, software y protocolos heredados, etc. Aplique los controles de seguridad al enfoque actual. Esta mejora es fundamental para mitigar el riesgo, ya que los atacantes mejoran continuamente su capacidad de aprovechar estas oportunidades.
  • Greenfield: asegúrese de que los nuevos recursos y los nuevos tipos de recursos estén configurados para los estándares. Este proceso es fundamental para evitar la creación continua de sistemas nuevos o heredados instantáneos, o sistemas que no cumplen los estándares actuales. Esta deuda técnica tendrá que abordarse más adelante a un costo mayor, lo que provoca una mayor exposición al riesgo hasta que se complete.

Desde el punto de vista financiero, la protección suele asociarse a la dinámica de los gastos de capital (CAPEX) de una inversión única. El presupuesto de Greenfield para la seguridad debe asignarse lo más cerca posible de la creación del recurso, con un porcentaje reservado del presupuesto de seguridad para cada nuevo proyecto de software, actualización de software importante o iniciativa general de adopción de la nube. Muchas organizaciones reservan aproximadamente el 10 % del presupuesto para la seguridad. El presupuesto de Brownfield suele ser un proyecto especial financiado para que los estándares de seguridad cumplan los estándares y el cumplimiento actuales.

Mantener la seguridad

Todo se degrada con el tiempo. Los elementos físicos se desgastan. El entorno cambia en torno a elementos virtuales como software, controles de seguridad y seguridad. Es posible que ya no cumplan los requisitos cambiantes. Estos cambios se producen rápidamente hoy en día debido a los siguientes cambios rápidos:

  • Requisitos empresariales, impulsados por la transformación digital
  • Requisitos tecnológicos, impulsados por la rápida evolución de la plataforma en la nube y las versiones de actualización de características.
  • Requisitos de seguridad, impulsados por la innovación del atacante y la rápida evolución de las funcionalidades de seguridad nativas de la nube.

Esta dinámica afecta a todas las partes de la seguridad, incluidas las operaciones de seguridad, el control de acceso y, especialmente, DevSecOps en la seguridad de la innovación.

Para mantener la seguridad, es necesario tener en cuenta muchos elementos. Céntrese en estas dos áreas específicas de la protección de recursos:

  • Mejora continua de la nube: adopte la mejora continua de las funcionalidades de seguridad que aporta la nube. Por ejemplo, muchos servicios de Azure, como Azure Storage y Azure SQL Database, han agregado características de seguridad para defenderse contra los atacantes a lo largo del tiempo.
  • Final del ciclo de vida del software: cualquier software, incluidos los sistemas operativos, siempre llega al final del ciclo de vida, cuando ya no se proporcionan actualizaciones de seguridad. Esta situación puede exponer aplicaciones y datos críticos para la empresa a ataques baratos y fáciles. Aunque el proveedor de nube mantiene el software como servicio (SaaS) y las plataformas y la infraestructura en la nube, las empresas a menudo tienen una cantidad significativa de software que instalan, crean y deben mantener.

Planee la actualización o retirada del software al final de su ciclo de vida. Invertir en su posición de seguridad reduce el riesgo de un incidente de seguridad importante. Mantener la seguridad forma parte de la dinámica de gastos operativos (OPEX) de una inversión continua regular.

El dilema de la revisión

Es fundamental que los líderes empresariales respalden a sus equipos y líderes de TI y seguridad. La ejecución de software complejo en un entorno hostil plantea un riesgo inherente. Los líderes de seguridad y TI toman constantemente decisiones difíciles sobre el riesgo operativo y el riesgo de seguridad.

  • Riesgo operativo: un cambio en el software donde se ejecuta el sistema podría interrumpir los procesos empresariales. Estos cambios afectan a las suposiciones realizadas cuando el sistema se personalizó para la organización. Este hecho ejerce presión para evitar cambiar el sistema.
  • Riesgo de seguridad: un ataque plantea el riesgo empresarial de tiempo de inactividad. Los atacantes analizan cada actualización de seguridad importante de la versión. Pueden desarrollar una vulnerabilidad de seguridad activa en 24-48 horas para atacar a organizaciones que no han aplicado la actualización de seguridad.

Su organización podría tener este dilema a menudo debido a los continuos cambios en la tecnología y a la evolución de la técnica de ataque. Los líderes empresariales deben reconocer el riesgo de dirigir un negocio con software complejo. Admita la actualización de los procesos empresariales, como estos ejemplos:

  • Integración del mantenimiento de software en los supuestos operativos del negocio, la programación, la previsión y otros procesos empresariales.
  • Inversión en arquitecturas que facilitan el mantenimiento y reducen el impacto en las operaciones empresariales. Este enfoque podría implicar la actualización de las arquitecturas existentes o el cambio total a arquitecturas nuevas mediante la migración a servicios en la nube o a una arquitectura orientada a servicios.

Sin el apoyo del liderazgo empresarial, los líderes de seguridad y TI no otorgan tanta importancia a respaldar los objetivos empresariales importantes. Deben administrar constantemente las políticas de una situación poco favorable.

Aislamiento de red

El aislamiento de red puede ser una opción válida para proteger los recursos más antiguos que ya no se pueden proteger, pero que no se pueden retirar inmediatamente. Este escenario puede producirse normalmente para aplicaciones y sistemas operativos que han llegado al fin de su ciclo de vida. Es común en entornos de tecnología operativa (OT) y sistemas heredados.

El aislamiento se considera control de acceso, aunque los recursos que no se pueden proteger se identifican como parte de la protección de recursos. Para más información, vea Evitar el firewall y olvidarse.

Algunos sistemas al final de su ciclo de vida son difíciles de desconectar y aislar completamente. No se recomienda dejar estos sistemas poco seguros totalmente conectados a una red de producción. Esta configuración puede permitir que los atacantes comprometan el sistema y obtengan acceso a los recursos de la organización.

Nunca es barato ni fácil actualizar o reemplazar la tecnología informática que ha funcionado bien durante una década o más. Puede haber documentación limitada sobre su funcionalidad. El posible impacto empresarial de perder el control de varios recursos críticos para la empresa a menudo supera el costo de la actualización o sustitución. En el caso de estos recursos que no se pueden aislar, las organizaciones suelen observar que la modernización de la carga de trabajo con tecnología y análisis en la nube puede aportar un nuevo valor empresarial que pueda compensar o justificar el costo de la actualización o sustitución.

Mantener la seguridad es un reto en un mundo sujeto a cambios constantes. Es fundamental decidir constantemente qué recursos modernizar y qué proteger de la mejor manera posible. Use el riesgo empresarial y las prioridades empresariales para valolarlo.

Introducción

Para empezar a trabajar con la protección de recursos, se recomienda que las organizaciones den los pasos siguientes.

  • Céntrese primero en los recursos conocidos: piense en máquinas virtuales, redes e identidades en la nube con las que el equipo ya está familiarizado. Esta técnica le permite realizar un progreso inmediato y suele ser más fácil de administrar y proteger con herramientas nativas de la nube, como Microsoft Defender for Cloud.

  • Comience con las líneas de base de proveedor/sector: inicie la configuración de seguridad con una solución conocida y probada, por ejemplo:

    • Líneas de base de seguridad en Azure Security Benchmark. Microsoft proporciona instrucciones de configuración de seguridad adaptadas a los servicios individuales de Azure. Estas líneas de base aplican los bancos de pruebas de seguridad de Azure a los atributos únicos de cada servicio. Este enfoque permite a los equipos de seguridad proteger cada servicio y mejorar las configuraciones según sea necesario. Para más información, vea Líneas de base de seguridad para Azure.
    • Líneas de base de seguridad para Azure. Microsoft proporciona instrucciones de configuración de seguridad para tecnologías de uso común, como Windows, Microsoft Office y Microsoft Edge. Para más información, vea Líneas base de seguridad de Microsoft.
    • Bancos de pruebas de CIS. El Centro de seguridad de Internet (CIS) proporciona instrucciones de configuración específicas para muchos productos y proveedores. Para más información, vea Bancos de pruebas de CIS.

Información importante

Estos elementos clave ayudan a guiar el proceso de protección de recursos:

Equipos competentes y responsables

La responsabilidad de la seguridad siempre recae en el propietario final de los recursos de la empresa que posee todos los demás riesgos y ventajas. Los equipos de seguridad y los expertos en la materia son colectivamente responsables de aconsejar al propietario competente sobre los riesgos, cualquier mitigación y la implementación real.

Las responsabilidades de protección de recursos pueden asumirse mediante operaciones de TI que administran recursos de toda la empresa, equipos de DevOps y DevSecOps responsables de los recursos de su carga de trabajo o equipos de seguridad que trabajan con los equipos de TI o de DevOps y DevSecOps.

A medida que las organizaciones se trasladan a la nube, muchas de estas responsabilidades se pueden transferir al proveedor de nube, por ejemplo, actualizar el firmware y la solución de virtualización, o bien facilitar, por ejemplo, el examen y la corrección de la configuración de seguridad.

Para más información sobre el modelo de responsabilidad compartida, consulte Responsabilidad compartida en la nube.

Elasticidad de la nube

A diferencia de los recursos locales, los recursos en la nube pueden existir solo durante un breve período de tiempo. Según sea necesario, las cargas de trabajo pueden crear más instancias de servidores, Azure Functions y otros recursos, para realizar un trabajo. Después, Azure quita los recursos. Este escenario puede producirse en cuestión de meses, pero a veces en cuestión de minutos u horas. Tenga en cuenta esta posibilidad para los procesos y las mediciones de protección de recursos.

La elasticidad de la nube requiere ajustar muchos procesos. Mejora la visibilidad, con un inventario a petición, en lugar de informes estáticos. La elasticidad de la nube también mejora la capacidad de corregir problemas. Por ejemplo, la creación de una máquina virtual por motivos de seguridad puede realizarse rápidamente.

Administración de excepciones

Una vez que identifique un procedimiento recomendado para un recurso, aplíquelo de forma coherente a todas las instancias del recurso. Es posible que tenga que realizar excepciones temporales, pero administrar las excepciones con fechas de expiración específicas. Asegúrese de que las excepciones temporales no se conviertan en riesgos empresariales permanentes.

Desafíos con la medición del valor

Puede ser difícil medir el valor empresarial de la protección de recursos. El impacto de un problema no es obvio hasta que se produce un error real. El riesgo de no actualizar la seguridad de las vulnerabilidades es silencioso e invisible.

Preferencia de la directiva automatizada

Dé prioridad a los mecanismos automatizados de aplicación y corrección, como Azure Policy, para la protección de recursos. Este enfoque ayuda a evitar problemas de costos y morales al realizar tareas manuales repetidamente. También reduce el riesgo de errores humanos.

Azure Policy permite a los equipos centrales especificar configuraciones que se usarán para los recursos en las nubes.

Diseño de controles como equipo

Todos los controles deben diseñarse como una asociación con las principales partes interesadas:

  • La protección de recursos proporciona experiencia en la materia sobre los recursos, los controles disponibles para ellos y la viabilidad de implementar los controles.
  • El equipo de gobernanza proporciona un contexto de cómo los controles se adaptan a la arquitectura, las directivas y los estándares de seguridad y los requisitos de cumplimiento normativo.
  • Las operaciones de seguridad aconsejan sobre los controles de detección. Integran alertas y registros en herramientas de operaciones, procesos y aprendizaje de seguridad.
  • Los proveedores y proveedores de nube pueden proporcionar una amplia experiencia en la materia sobre los sistemas y componentes para evitar problemas conocidos observados en su base de clientes.

Pasos siguientes

La siguiente materia que se debe revisar es la gobernanza de la seguridad.