What should be watched when office network is accessed remotely
Remote and hybrid work have made secure remote access a normal part of IT operations. While this brings flexibility, it also introduces additional information-security and availability risks that need constant attention.
Working remotely can be tricky; especially when we talk about a network and/or system administrator work. What’s worse, administrator’s access shouldn’t be interrupted, putting the entire setup at stake. What should be paid attention to in such a situation?
Network connectivity
In normal situation, there’s usually fair enough network speed available for all business activity within the intranet.
However, when most staff switches to work remotely, network speed at the intranet gateway can become a bottleneck. To prevent that, traffic monitoring can show whether the Internet connection, VPN gateway, or remote-access edge is approaching saturation when many users connect at once.
Tip #1: if there are several Internet connections for office network, it would be useful to reserve one of ti, or most of its capacity solely for administrator’s access; otherwise, it wouldn’t be possible to efficiently adjust the network configuration.
Tip #2: if business processes include internal service-to-service traffic, avoid forcing that traffic through the external connection unnecessarily. For example, if an internal application talks to an intranet database, running the application remotely may waste bandwidth and increase latency. Instead, use SSH or Remote Desktop over a secured path and run the task from inside the intranet where possible. Current IPNetwork Monitor documentation also describes accessing the monitoring GUI remotely through Remote Desktop with TCP 3389 forwarded over SSH, which is a cleaner pattern than exposing remote administration directly.
Security concerns
When an employee connects to the intranet from outside, the remote-access path itself becomes part of the security perimeter and requires constant attention.
Apart from new threats (since external system, connecting to intranet, may as well be infected with malware – and intranet services should be well-guarded against these new dangers), remote access also requires enforcing access control. At a minimum, secure remote access should use a protected path such as VPN, and multi-factor authentication should be enabled wherever available.
Tip #3: with sensitive data crossing the intranet boundary, tracing movement and spotting misuse becomes harder. Thus, one should make sure that monitoring and detection tools are in place for both hosts and network traffic. In particular, a network IDS/IPS such as Snort can be used to watch internal or remote-access traffic for anomalies, while host-level logging and event monitoring should remain enabled on critical systems.
Similarly, Syslog-based monitoring can be enabled to detect unwanted access attempts, suspicious firewall activity, and unusual events coming from remote-access infrastructure or Unix-like hosts.
Tip #4: with security-related problems coming in numbers, it is mandatory to make sure there are not only viable services with all the latest security updates applied, but all critical data and services backups being done on regular basis.
Conclusion
Depending on one’s company specifics, one’s mileage can vary. There can be many other concerns, apart from those already mentioned, but almost all of them are related either to availability of resources, or to their capacity.
If you administer your own intranet, feel free to share with us your situation and your specific concerns.