Threat Models: Supply Chain Attack

In the second part of our thread model series, we will cover supply chain attacks. If you’re just joining us, we strongly recommend you read the first part of the series, which introduces the concept of threat modeling and defines the relevant key terms and tech stack for the series.

If you don’t heed our recommendation, the main thing you need to know from Part 1 is that we are considering an internet-facing application handling sensitive health and credit card information. The application is a typical three-layer architecture with web, application, and data storage layers and is hosted in a public cloud across data centers in the US and EU.

The Anatomy of a Supply Chain Attack

A supply chain attack is an attack method where threat actors exploit vulnerabilities by compromising a single source and then gain access to multiple targets by moving laterally from that source. We approach this exploration from a customer's perspective, leveraging the services of a breached managed service provider (MSP), and consider how to protect customer-sensitive data from the breached MSP.

The Threat Actor: Sophisticated External Attacker

The architects of successful supply chain attacks are typically part of organized cybercrime syndicates or even nation-state entities. Possessing advanced capabilities and ample resources, these threat actors manage to breach multiple layers of security defenses.

Threats:

• Data Theft
• Service Disruption
• Persistence
• Malware Installation

Vulnerabilities:

• Access to the customer environment is not logged and monitored
• The attacker is “living off the land,” re-using existing MSP accounts
• The attacker account has complete control over the environment, including the backup systems
• The customer cannot disable MSP access
• Sensitive information is not encrypted at a field-level

Attack Vectors:

• Remote administrative management capabilities

Mitigations:

1. Vendor Due Diligence: Implement a stringent vendor evaluation process for any vendor with privileged management access to your systems and data.
   
2. Emergency Access Control: Implement a kill-switch control to disable MSP Access. An MFA jump server methodology may be appropriate, although this depends on the MSP access scope.
   
3. Secured Log Archival: Have a designated log archive outside the MSP control to capture MSP activity to facilitate incident response and forensic analysis.
   
4. Data Encryption: Encrypt all sensitive data at rest and in transit using tools from companies like Evervault. The data should only be decrypted and available to specific applications and authorized roles. Even where the MSP has administrative access, the application of external key management and field-level encryption prevents sensitive data breaches.
   
5. Backup Safeguards: Ensure back-ups are sufficiently protected, ideally immutable/offline archives recorded over time.
   
6. Logging: Implement sufficiently detailed logging to allow for the reconstruction of the events that led to a breach. Native tooling from AWS, like Cloudwatch and Cloud Trails, is an excellent place to start ingesting infrastructure and application logs.
   
7. Monitoring: Implement monitoring to identify unusual patterns of behavior and notify security teams. There are many SIEMs on the market to enable deep visibility into user behavior, including tools like GuardDuty from AWS.
   
8. Define Incident Response: Develop an incident response plan and practice it to ensure that relevant roles understand their responsibilities between the Customer and MSP in the event of an incident. This should include an agreement on breach notification timing and context.

Evervault always advises a holistic layered approach to protect sensitive information. We believe that encryption is one of the most critical factors in mitigating the risk of high-impact data breaches.

Stay tuned for the next part of our Threat Model series, where we will cover threats from accidental cloud misconfiguration.