OP.ACC.7 Acceso remoto

Documentos de referencia

• Guías CCN-STIC:

  • Guía CCN-STIC-827 - Gestión y uso de dispositivos móviles

• ISO/IEC 27000

  • 27002:2013:
    • 9.4.2 - Procedimientos seguros de inicio de sesión
    • 10.1.1 - Política de uso de los controles criptográficos
    • 13.1.1 - Controles de red
    • 13.1.2 - Seguridad de los servicios de red
    • 18.1.5 - Regulación de los controles criptográficos

• NIST SP 800-53 rev4:

• [AC-10] Concurrent Session Control

• [AC-17] Remote Access

• [AC-18] Wireless Access

• [AC-20] Use of External Information Systems

• [MA-4] Nonlocal Maintenance

• [SA-9] External Information System Services

• [SC-10] Network Disconnect

• Otras referencias:

  • http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2006/m06-16.pdf
  • http://www.sans.org/security-resources/policies/Remote_Access.pdf
  • http://www.sans.org/reading_room/whitepapers/vpns/remote-access-vpnsecurity-concerns-policy-enforcement_881

  Guía de implantación

  168. El acceso remoto es fuente de numerosos problemas porque no puede suponer el mismo nivel de controles de seguridad física que en las instalaciones corporativas.
       Por ello conviene tener reglas específicas respecto a qué se puede hacer y qué no se puede hacer desde un acceso remoto. E incluso dentro de lo que está autorizado, hay que esmerarse en el cuidado del proceso de identificación y autenticación para prevenir la suplantación de la identidad de un usuario autorizado.

169. Se exige establecer un mecanismo robusto de identificación y autenticación según [op.acc.6].

170. Prácticamente se exige establecer una red privada virtual (VPN), según [mp.com.2] y [mp.com.3].

171. Se debe redactar una política que rija lo que se puede hacer remotamente: qué aplicaciones se pueden usar, qué datos son accesibles y en qué condiciones estos datos pueden almacenarse en el dispositivo externo de acceso.

172. La política también debe establecer límites al tiempo que puede estar abierta una sesión y e imponer un tiempo máximo para cerrar sesiones inactivas.

173. Además de redactar la política, hay que imponerla. Esto es casi imposible si el dispositivo es del usuario (Bring your own device, BYOD) y en general si el usuario tiene derechos de administrador del equipo. Es por ello que se procurará que el equipo remoto sea propiedad del organismo, esté configurado por el organismo y el usuario no tenga derechos de administrador.

174. A fin de limitar lo que se puede hacer en remoto, se debe establecer un filtro, bien en el servidor, bien en el propio cliente.

175. Si las limitaciones se imponen en el servidor, haremos que el usuario acceda a un segmento de red separado del núcleo corporativo y entre el segmento de acceso remoto y el núcleo estableceremos un cortafuegos interno que sólo permita las aplicaciones y protocolos autorizados.

176. Si las limitaciones se imponen en el equipo cliente, instalaremos un cortafuegos personal, configurado por el organismo, que establezca las limitaciones correspondientes.

177. En ambos escenarios se debe considerar la oportunidad de instalar una función de prevención de fuga de datos (Data Loss Prevention, DLP) que monitorice los datos que viajan por la red.

178. En todos los casos se deben activar los registros de actividad y analizar regularmente que se cumple la política autorizada. Considere la oportunidad de un sistema de información de seguridad y administración de eventos (Security Information and Event Management, SIEM) que levante alertas ante comportamientos no autorizados.