Next-Gen Managed Services Security: Social Engineering

By Thomas Robinson, Partner Solutions Architect at AWS

AWS Partner Network (APN) Partners new to managed services often have questions about how to protect their customers from social engineering attacks and how to best test themselves to meet APN Program requirements. In this post, we’ll provide guidance for APN Partners and inform customers on what to expect from their Managed Service Provider (MSP).

A large part of an AWS Solutions Architect’s role is helping customers maintain a robust security posture that follows best practices. An entire pillar of our Well-Architected Framework, which we use to help validate our customer’s critical workloads, is dedicated to security. We work with next-gen AWS MSP Partners and ensure they maintain secure environments.

To join the AWS MSP Program, an APN Partner undergoes a third-party validation audit to demonstrate they are following AWS best practices for securing cloud environments. While part of meeting these controls is technical, the support aspect of a managed services engagement includes a very human element. Items such as 24/7 call centers, helpdesk and escalation e-mails, or chat systems are all an attack surface which a malicious party can use to disrupt a business, or gain additional information useful in another type of attack.

To validate that our AWS MSP Partners are protecting these vulnerable areas, they must identify their attack surface, and then test potential attacks, as seen in the AWS MSP Validation Checklist (updated to v3.2, as of January 19, 2017) under Requirement 8.1.10:

“Partner performs secret shopper testing on vectors vulnerable for social engineering attacks, including call, chat and email systems. User validation should not utilize confidential data like social security numbers, or personal security questions.”

In the same way a traditional MSP is responsible for the physical security of your datacenter, a next-gen MSP is an AWS customer’s trusted resource for helping maintain their portion of the Shared Responsibility Model. Instead of physical keys, the MSP is their customer’s gatekeepers into the cloud, providing secure access methods and enforcement of change processes.

Best Practices and Anti-Patterns for Identifying and Minimizing Attacks

Before building a process for testing, APN Partners should identify exactly what vulnerabilities may exist, and follow best practices to reduce or eliminate the impact of a support channel being an attack vector.

Federated Access for the AWS Console

Managing access to the AWS Console via AWS Identity and Access Management (IAM) covers the entire lifecycle, including creating, providing credentials for, and disabling users. Alternatively, by using a SAML provider for access to the AWS Console, an MSP can allow their customers or MSP Support Staff to use their own SAML-based federation IdP for accessing the AWS Console. This eliminates the need for the MSP to create a support process for resetting passwords and MFA devices, and allow the customer to directly manage their own users through existing processes.

Temporary Credentials for Users

To use services such as Amazon Simple Storage Service (Amazon S3) or Amazon DynamoDB, developers and engineers need access keys with the minimum permissions necessary in accounts managed by the MSP. AWS provides options to manually create and destroy access keys for IAM users. Although access keys are still used, we recommend users take advantage of temporary credentials provided by the AWS Security Token Service (AWS STS), which has the capability of automatically rotating credentials.

Like console access, developers and engineers can be provided temporary credentials via SAML-based federation for API access. This is a common AWS best practice, as automated key rotation reduces the chance your credentials will be exposed and vulnerable in the wild. For MSPs, this eliminates the need for a process to issue and rotate keys for end customers.

Temporary Credentials for Applications

Applications running on AWS also need AWS credentials to use our services. These credentials should be short lived, automatically rotated as they expire, and adhere to the principals of least privilege. By providing IAM Roles applied to an Instance Profile, developers can create applications on Amazon Elastic Compute Cloud (Amazon EC2) using the AWS Software Developer Kit (SDK) without the need to securely store and rotate Access Keys in a configuration file.

Consider Non-AWS Resources

Apart from access to AWS APIs, MSPs should minimize the need for manual interaction with other customer access tasks such as maintaining authentication for SSH or RDP. By using the Amazon EC2 Run Command you can gate routine access to servers by authenticating users via IAM to execute commands instead of accessing them directly with SSH keys or passwords. For secrets management, the MSP should consider the Parameter Store feature to provide a self-service place for customers to keep their configuration data such as database strings and passwords, which is also gated by IAM authorization.

Security-as-Code

As companies move towards more frequent self-service deployments, the change control process for approving changes shifts away from a manual review towards a pre-approved, well-defined, and frequently reviewed configuration. For example, PCI DSS Requirement 1 includes controls such as environments containing cardholder data should not be allowed access to the public internet or untrusted networks, allowing only necessary traffic. These rules should be included as part of your deployment processes to automatically validate that releases meet defined standards. Maintaining a high security environment and deploying frequently are not mutually exclusive.

Testing Considerations

Detecting and Preventing Unauthorized Changes

It is important to identify what changes a user may request from support channels and test the authorization for those changes, as well as ensuring controls around high-impact changes are enforced. Using our previous example of security-as-code, a single requestor should not have authorization to change the definition of acceptable traffic. Testing that appropriate change control review is followed and a requestor cannot bypass this by making an “urgent” support call maintains the integrity of your compliance controls.

Preventing Data Leakage

Even with a support structure where minimal change could be requested over channels such as phone or email, interaction via these methods can be used to extract information about a customer or their environment. Extracting information such as service endpoints, application platforms, or architecture details can help an attacker craft a more intelligent technical attack on customer applications. Always ensure sensitive information is communicated over appropriate channels, such as a support portal secured by multi-factor authentication.

Protecting Against Email and Spear Phishing

Helpdesk emails, specific engineering contact, and known escalation paths are some of the various ways attackers will try and compromise security. Using these paths, an attacker can attempt to enact unauthorized changes, gain additional information, or perform a technical attack by installing malware on an engineer’s device. These support channels should have a technical validation of the requestor, such as directing requests through a password and MFA protected portal, and avoid using personal details such as social security numbers or a challenge question.

Testing Insider Threats

Testing should be tuned to mitigate against insider threats, whether an existing employee exceeding their authority or a disgruntled former employee attempting to regain access. Tests should be crafted to assume an attacker may have a level of insight to processes such as escalation email paths or phone numbers. As such, it’s important to ensure you have safeguards around these paths and are testing them regularly.

Building a Testing Process

Once attack vectors have been identified and minimized, a robust process for testing can be built. This pairs technology solutions to perform phishing style attacks with human driven testing. Some APN Partners train resources to perform tests internally and dedicate time producing actionable output from those exercises. Other APN Partners engage with consulting firms focused on security to help them build a testing plan as well as provide resources for carrying out those tests.

For APN Partners focused on customers in verticals with strict compliance or security requirements, such as financial services or healthcare, this investment in a third-party validation can provide a stronger position when customers are reviewing potential managed services providers.

Next Steps

If you’re interested in learning more about our AWS Managed Service Provider Program, take a look at the MSP website. It’s full of information about the benefits of being a next-gen MSP as well as the requirements that our third-party audit will validate.

If you are a customer looking for a next-gen MSP, you can find a list on the MSP Partner page.