Put yourself in the role of being a professional attacker. It’s a job, like anything else, so you’d want to get the most result for your effort in the shortest amount of time possible. If you could hack an IT Managed Service Provider who uses poor access management practices, you could quickly pivot to access the networks of multiple organizations at once–those of all their clients. If you were really clever, you’d not only get into the infrastructure of multiple clients, but you’d gain access to application-level security keys so that you could A) upload hidden bitcoin mining instances to fund your criminal enterprise, B) infiltrate user accounts and request large sums from one of their investors or customers, or C) make off with and sell their customer data. (Let’s not even think about cases where attackers can access a mission critical custom application that controls pressure valves, or pipelines.) Last December, the US saw so many Chinese threat actor attacks through MSP accounts, where attackers made their way into the MSPs’ customer networks, that a US-CERT warning was issued to raise awareness and help stop the attacks. In our previous installment, Heath Gieson walked us through how data flows can be set up between the MSP and the customer environment to ensure security, as well as the importance of monitoring. This week, the Director of Cloud Strategies at TRUE Digital Security, John Connors, will help us explore a few key considerations that may affect anyone with applications hosted in the cloud: What makes some cloud environments more vulnerable than others? Who bears responsibility for the security of those parts of your environment currently hosted in the cloud? What can any organization hosting applications in the cloud learn from these attacks? Connors will walk us through some broader trends that threat actors may be exploiting in these hacks, and how you can protect your own organization from similar attacks.
"First, MSPs must protect themselves in order to effectively protect their clients," notes Connors, "because if you can compromise the MSP from the inside, you will then be able to gain access to the tools that the MSPs use to manage and maintain their client accounts – both on the Operating System/Application stack level and the Platform level. The MSP firm has to have a comprehensive policy for themselves to effectively secure their client environments, ensuring that internal passwords meet minimum standards, for example. In those cases, multi-factor authentication (MFA) should be required for all areas where sensitive data is stored, credentials will be air-gapped, and Managed Detection and Response (MDR) will be deployed. All things we recommend for clients must also be in place for today’s MSPs." Additionally, credentials must be unique on a client-by-client basis, further limiting an attacker's ability to pivot. "With respect to the Cloud Platforms," Connors points out, "we have found expediency sometimes wins over best practices, and MSP firms will create a singular 'Administrative' account with highest privileges to manage the client’s platform."
Along the lines of expediency, another common practice is for MSPs who manage public cloud platforms like AWS, Azure, and GCP, is to utilize a shared “Administrator” account for accessing the platform, one with unlimited and unfettered access that is utilized by all support staff, rather than creating a named account for each staff member and following the “least privilege model” of tailoring permissions to that person’s role in supporting the MSP’s customer. While the least-privilege model adds some complexity on the management side, the model ensures the client and the MSP can better identify anomalous behaviors on the platform, and if an account is compromised, the potential risk may be mitigated due to rights allocations.
Identifying anomalous behavior requires log capture and a system to assess those logs. All public cloud platforms have some form of log capture – in AWS it is called CloudTrail – but all of them require these logs to be “turned on” to ensure their capture and retention. Once engaged, a process for review, such as Managed Detection and Response (MDR) or Managed SIEM (Security Incident and Event Management) services, must be put into place. These are both proactive and reactive toolsets that are invaluable in understanding how a potential threat or one that has compromised the environment.
Once you have established a solid understanding of proper security controls in a layered approach to protecting your cloud hosted networks and applications, it’s vital to also establish whose job it is to implement each of these controls–especially where vendor relationships may feel complicated. Last month, the Cloud Security Alliance released a study detailing findings on Enterprise Resource Planning (ERP) Applications and Cloud Adoption. It seems that 60% of enterprise organizations believe any breach to their cloud-hosted applications would be the fault of the cloud provider, and another 33% still believe that security is the responsibility of the cloud infrastructure host. What this means, in reality, is that right alongside widespread cloud adoption, there is still a who’s-on-first mentality among organizations with all or part of their environments hosted in the cloud.
The Shared Responsibility Model, followed by most cloud providers, actually places responsibility for outside security on the cloud provider, and security inside the cloud squarely on the customer. As we say often at TRUE, you can outsource applications, but you can’t outsource your risk. At the end of the day, it’s your responsibility to make sure your company’s risks are clearly defined and properly mitigated. You can’t blame Azure if you didn’t see to it that your company’s configurations are set to their most secure, or if you didn’t check to see that your organization is taking advantage of all available security options. In the case of an MSP who procures and architects infrastructure for clients, though, you'll have to define what role each of the stakeholders plays in security–cloud provider, MSP, and customer. These role definitions may vary from one MSP to the next, so we highly encourage you to have these conversations with any potential vendor, getting a defined list of roles/responsibilities (and liabilities) in writing, so proper workflows, security controls, and handoffs can happen at every level. Requiring viable evidence of their security practices (attestations of compliance, SOC2 certifications, etc.) will save you headaches later on.
In the end, you need visibility into your account to know you are secure from attacks that could be leveraged on your cloud environment, and it’s always a good idea to look behind the curtain. So don’t be afraid to ask your administrator for information and verification of practices. Formal vendor evaluations, security assessments, and penetration tests are certainly truth-tellers when it comes to your security posture. Then you will at least have the information you need to develop an immediate plan for remediation, because ultimately, you are the one who has to shoulder the risk.
Click here to learn more about TRUE’s Managed IT & Security Operations.
Click here to learn about our Security Testing and Assessment Services.
To talk with a security expert, reach out to us at info@truedigitalsecurity.com