Remote Security in Times of Expansion

The COVID-19 pandemic has skyrocketed interest in and deployment of remote access arrangements. Previously, many organizations had arrangements for a limited amount of remote access - often professionals, IT staff, and field personnel. Some larger organizations, particularly those in finance and related industries, have already had long-standing contingency plans for remote working situations when their office facilities are unavailable (e.g., 9/11). Such plans are easily altered to deal with the lockdown in response to a pandemic.

Expanding remote access is dangerous. The threat environment is now complex and sophisticated. Twenty years ago there were far fewer dangers. Since then major security breaches have occurred, such as the incident involving TJ Maxx. A major security breach at Target was traced to hacking of credentials of an HVAC contractor. Among the common factors in both episodes was the fact that once access was gained, the entire network was accessible.

This broad grant of access is not generally necessary. In the Computer Security Handbook, Third Edition (1995, Wiley), I wrote about the need to establish security zones within networks to limit access to network assets. At the time, the main concern was systems provided by third parties (e.g., trading portals). Later, I noted that the same conceptual issue arises when implementing guest Wi-Fi access to the Internet for corporate visitors and/or customers (see Safe Computing in the Age of Ubiquitous Connectivity).

The same issue arises with large-scale remote work. Enabling remote work is not simply a matter of providing a connection to the worker's desktop system. More commonly, workers are using a hosted desktop, with access via Citrix, RDP, or similar technologies. It is also not merely a question of authentication; it is a question of what level of access is available to each remote worker.

Some remote workers need access to the entire network and many, if not all, systems on it. However, the need for this degree of access is limited to systems support staff. Applications development staff need access to their test and development systems, but access to production-level systems with customer data should be tightly controlled. Customer service and clerical personnel need access to their applications, but should not need the degree of access required by applications developers (e.g., HTTP/HTTPS, not ssh or ftp).

In effect, each category of remote access is ensconced in its own secure enclave, with access limited to what is needed for their role. I described such configurations in Compartmented Networks: A Corporate Solution for Privacy, Integrity, and Security at the 11th Annual New York State Cybersecurity Conference.

Configuring a compartmented network is admittedly more complex than configuring a single firewall. However, the additional configuration and management effort incurs far less effort and risk than uncovering and mitigating a major security breach.

This is particularly true of networks which include systems handling payments (e.g., retailers), personnel data, and industrial control systems. At a minimum, each class of system should be in limited to its own enclave, with the appropriate limitations. Using previous episodes as an example, breaches would have been limited, with the compromise being limited well short of a corporation-wide breach.

Broadening remote working arrangements increases the chances that someone's credentials will be compromised. It is more important than ever that the damage caused by a compromised credential be limited to the extent possible before the compromise occurs.