During a global crisis like COVID-19, it’s easy for organizations to give managed security services providers (MSSPs) too much control in the name of business continuity. In turn, MSSPs eager to be helpful may give their own staffers more access than they would during normal times. Both situations are problematic, especially in a time of increased risk across the board.
The best approach is to understand the context of what you need people to do and then adjust the systems so that doing anything else is either difficult or easily detectable. This could mean enhancing the classic MSSP access model with more cloud-friendly options (e.g., Amazon Workspaces in AWS or Windows Virtual Desktop in Azure), or moving to newer API-first or zero trust approaches.
In the end, identifying the ideal trust level with your MSSP and restricting remote access appropriately will provide long-term security benefits – long after the current crisis is over.
Many organizations use a fairly simple model of control for MSSPs. Some older MSSPs still use direct site-to-site virtual private network (VPN) connections, but increasingly, virtual desktops -- Citrix and VMware VDI are the most common -- provide the MSSP with access restricted to a certain set of known IP addresses.
Organizations will stand up their own virtual infrastructure and lock access to it down to a VPN connection going to the MSSP. The MSSP then allows access to that VPN connection to offices located offshore. This model works well until the MSSP suddenly has to expand access.
During situations like the current pandemic, when MSSPs are forced to support a large number of remote workers, they will often simply allow those workers to VPN into their own network, and then access customer systems in the same way they always have. However, that situation changes the risk dynamic because when MSSP staffers access systems from home, it becomes possible for them to engage in actions that would not be possible in a more strictly managed environment.
To address these concerns, it’s important to re-evaluate the services the MSSP performs and reconsider the fundamental nature of its access. The re-evaluation process can push organizations into one of two models:
- Enhancing the classic model of control.
- Looking to entirely new methods of allowing MSSP remote access.
Enhancing the Classic Model of Control
Rather than using a business-to-business connection, the enhanced model connects an organization-controlled Citrix session with a system that is more cloud-friendly, such as Amazon Workspaces in AWS or Windows Virtual Desktop in Azure.
Those cloud tools allow access from anywhere and leverage stronger initial access controls than if you simply allowed remote workers to either remote directly into your VPN or trust your MSSP to allow secure remote access to its VPN.
Unlike allowing direct access to Citrix/VDI via uncontrolled personal laptops, using cloud access points allows you to:
- Set group policy.
- Achieve multifactor authentication (MFA).
- Take advantage of the cloud provider’s automated patching and extensive logging capabilities.
While it is certainly possible to leverage similar controls on your own Citrix/VDI environment, doing so takes resources that are often unavailable during pandemics and similar disasters. Plus, such controls are automated by cloud providers, so your confidence levels can be higher when using them.
In cases where the MSSP must administer the very systems it uses for remote access, some organizations are even moving all MSSP access to cloud-based virtual desktop environments – providing for a separation of duties between the MSSP and AWS/Azure.
Role management within AWS, in particular, is very granular. With a bit of effort, it is possible to restrict MSSP capabilities even further than can be done on traditional infrastructure.
Alternative Methods of Control
If taking the cloud-friendly route doesn’t fit the bill, two newly mature alternatives may be used, depending on the type of work the MSSP is doing:
APIs and Logging
The first combines API-first systems with modern logging systems to allow organizations to define specifically what actions may be performed by specific roles.
While the API-first design is new, and many systems do not currently support it, systems that follow this design pattern have defined interactions between components. This approach allows for customized connections to be made using quickly developed web applications or by leveraging web application firewalls (WAFs) to restrict access to existing applications.
Modern logging allows for specific scenarios to be monitored for and alerted on. Newer logging systems can – in theory – leverage machine learning to alert on anomalous behavior through user behavior analytics (UBA).
By combining API-first systems with modern logging technologies, it is possible to create apps that restrict MSSP actions to only those authorized and to trigger immediate alerts should MSSP actions differ from the norm. This approach can detect several scenarios that are difficult to detect/control within the more classic models, including:
- Unusual requests to access sensitive data.
- Unusual transfers of large volumes of data.
- Unusual constant transfers of small volumes of data.
- Unusual access times and durations that do not match timeframes in tickets.
- Unusual access to specific systems or out-of-scope systems.
- Unusual changes to identity and access management (IAM) systems.
So long as the API implementations and the logging functions are not accessible to the MSSPs – or are, at least, not changeable without alerting – this design can restrict access to such a point that MSSPs may perform their work from any system in the world without greatly raising the security risk.
Another alternative model of control is the zero trust model, which comes in two forms:
- Network-focused, which sends authentication packets through the network, following users as they access different systems. Network-focused zero trust vendors include BlackRidge and Cyxtera.
- Agent-based, which communicates with a central cloud-based service, so access patterns and actions can be centrally monitored away from the MSSP in a similar manner as the API-first/logging model. Agent-based zero trust vendors include Zscaler and Broadcom’s Secure Access Cloud (formerly Luminate).
Both forms are functional, but the agent-based model is more flexible and so is of greater interest when it comes to pandemic response. Zero trust does have it’s pros and cons, however:
- Pro: The big advantage of a zero trust system over the other approaches is that many of the configurations are done for you ahead of time.
- Con: The big disadvantage is that you are reliant on a third party for possible restrictions, whereas when you define your own API, you are in greater control.
Other Work-from-Home Risks
While MSSP staffers working from home increase risk to the MSSP customer in terms of monitoring and level of access, the MSSP work-from-home scenario also presents several other risks that must be considered, including:
- Network availability: MSSP staffers working from home face the same issues everyone does when it comes to family members and neighbors sharing the same internet network. While savvy consumers can activate traffic prioritization on their home routers, many do not have the capability, resulting in situations where latency may be so high as to completely prevent the most common VPN solutions from working reliably. The solution to this problem is to minimize network traffic. Fortunately, both a cloud-based virtual environment and API-driven connectivity are significantly more efficient with respect to network resources than traditional VPN connections.
- Network sharing: In a shared environment, it is possible for one network user to see another’s traffic. Although it is much more common to disable peer-to-peer traffic on wireless networks and shared internet connections these days, it is still possible for an unaffiliated party to see and possibly interfere with the traffic between the MSSP staffer and your systems. Addressing this risk involves leveraging modern TLS with Perfect Forward Secrecy (PFS) enabled – often with HTTP Strict Transport Security (HSTS) as well. This design is commonly available for cloud-based workstation access and would be entirely within your control when it comes to API-first connectivity. However, it is important to test your connection points to ensure they are properly configured. Using the Qualys SSL Labs test is an easy and free way to do this testing.
The Nature of Trust
Fundamentally, when you use an MSSP, you are trusting both the organization and its people. While you can limit what the people can do in different contexts, the element of trust will always be present. There are several ways to limit trust, but – despite the name zero trust – you can never truly get trust down to zero. As with all things in security, the best approach is to understand the context of what you need people to do and then adjust the systems so that doing anything else is either difficult or easily detectable.
This involves an iterative analysis in which you:
- Identify the most common actions performed by your MSSP.
- Determine secure ways to allow it to perform those actions remotely.
- Restrict access to the existing Citrix/VDI environment to people that need elevated rights.
- After a period of time, repeat the process for the privileged individuals while attempting to identify new secure methods to do the remaining actions that need elevated rights. This will help you restrict the privileged individual count with each iteration.
The time it will take to better secure MSSP actions will likely extend beyond the isolation phase of the current pandemic, but identifying the ideal trust level with your MSSP and restricting remote access has long-term security benefits and will certainly help with future needs.
Best Practices for Managing MSSPs, September 17, 2015
Remote Work and COVID-19: A Security Checklist, March 19, 2020
Managing the Risks of Remote Access, June 13, 2016
COVID-19 and the Cloud: Enabling Remote Work and Business as Usual, March 11, 2020
Any views or opinions presented in this document are solely those of the Faculty and do not necessarily represent the views and opinions of IANS. Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our written reports, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by the client in connection with such information, opinions, or advice.