The security ecosystem has reached an inflection point – the cloud service providers that form the backbone of every company’s core operations have become a prime target for adversaries, and few solutions exist for protecting data in the face of an upstream breach. 

Material has signed the Cybersecurity Infrastructure Security Agency (CISA) Secure by Design Pledge, and we’re encouraged to see our industry peers take the matter as seriously as we do. We sign this pledge as a promise to our customers that secure design principles have always and will always be a core tenet of Material.

Material Security was founded in the wake of the 2016 election hacks, when our founders decided that the compromise of a single person's account shouldn’t inherently lead to the compromise of all the data it has access to. As attack paths continue to evolve, protecting email means understanding and addressing the total attack surface. 

Material is purpose-built to stop email attacks, limit the blast radius of compromised accounts, and prevent data exfiltration. Our single-tenant deployment model and supporting security operations as outlined in the goals behind this pledge are purposefully designed to maximize customer privacy and trust.

Below, we’ve laid out the ways Material Security meets and exceeds the guidelines of Secure by Design. Security has been the top priority for Material since the company's inception and is baked into every decision we make. 

Multi-Factor Authentication (MFA) and Default Passwords

If you don’t store passwords, you can’t leak passwords. One of the key design decisions was not to include password-based authentication anywhere in Material. The only way to log into a Material instance is by using the customer’s IdP via SSO or by signing in with your Google or Microsoft account. This puts our customers in full control of identity management and service authorization, which is the way it should be. 

We’re also strongly opposed to the SSO and audit log "tax". Customers should not have to pay extra for foundational security controls. SSO and audit logs are included with all deployments of Material without an extra fee or license upcharge.

Reducing Entire Classes of Vulnerabilities

Material has taken several steps to reduce entire classes of vulnerabilities that could impact our services:

Minimizing the Attack Surface Area

Material Security is an API-centric platform. Our service is agentless and passwordless, relying instead on granular OAuth grants to gain authorization to customer environments. On a customer tenant, the only externally available service is the Material Admin console, which can additionally be IP-restricted to customer networks.  Whenever possible, we avoid using or exposing any internet-reachable endpoints to minimize our attack surface. 

Single-Tenant Deployment

Recognizing the extreme sensitivity of the data contained in email inboxes, Material Security developed a single-tenant cloud instance deployment model from day one to ensure safe data isolation. A breach of a multi-tenant cloud service provider can lead to the compromise of data originating from one or more customers due to lack of data isolation. In a properly scoped single-tenant model, services, accounts, and data are always isolated from other customers', which significantly limits the impact of vulnerabilities or potential breaches.

In addition to the audit logging mentioned earlier, Material allows customers full access to the backend infrastructure for their tenants. In practice, this means we will provide "Owner" level access to customers for their GCP project if they desire. This evolution in transparency means that customers have the ability to audit, inspect, and instrument the way the Material platform is processing their data. Customers can bring their own security controls and gather any telemetry they need directly from the infrastructure. They can configure their instance of Material Security with exactly the same tooling they’ve rolled out to their existing infrastructure.

We store 400 days of immutable GCP Cloud Audit Logs for all of our customers. You don't have to take our word for it, our single-tenant model allows you to inspect every aspect of the platform. 

Application Hardening

The CISA guidelines for application hardening call for the use of parameterized queries and the implementation of a robust SDLC. In addition to those baseline controls, Material has invested significant effort in preventing attacks like SSRF in our application. We’ve taken a thoughtful approach to this, ensuring that egress network connections can only be made by authorized services and leveraging a purpose-built proxy to prevent unauthorized connections to internal resources. We use a combination of K8S network policies, VPCs, and Cloud NAT service to properly isolate traffic intended for the internet, versus traffic intended for internal services. Finally, we use service-based authorization to create a unique authorization log entry for any service where HTTP requests can be made.

Privilege Escalation 

Dedicated accounts that employ the least-privilege principle are used by employees when accessing any part of the Material network. By default, these accounts only have minimal read-only access to monitor services and cannot access systems or services that contain or process the confidential data of our company or our customers. Privileged access for debugging or incident response requires a time-bound access request to be submitted and all employees must provide a valid business use case, the requests are logged, and all requests must be reviewed and manually approved. 

Vulnerability Disclosure Policy

We maintain a Coordinated Disclosure Policy and bug bounty program that encourages anyone who thinks they have found a vulnerability in our service to contact us. Our policy clearly makes our commitment to collaborating with and rewarding researchers.

Additionally, we recognize not all penetration tests are created equal. We've all seen it – when processing vendor security reviews, the vendor's "penetration test" is a three-page report showing that a web application scan was run against the public website with a few low-severity findings about CSP headers.

At Material, we take a different approach. Rather than forcing penetration testers to spend days or weeks attempting to bypass our accounts protected by phishing-resistant MFA and device trust controls, we "assume breach" and simulate that by ceding root access to a handful of employee endpoints. The testers start day one of testing with root access to a mixture of privileged and non-privileged employee machines. This allows us to test whether the detections and controls we've put in place to provide defense in depth are effective at limiting the impact of a simulated breach. We work with firms that are on the bleeding edge of offensive security research and utilize custom tooling tailored for testing our corporate and production environments.

We are proud of our part in securing our platform by design. When we collectively adopt cloud services, we opt-in to the respective shared responsibility model. If you’d like more information on our choices and how to implement them, give us a shout at security@material.security, we’ll be happy to help.

Contributors:

• Rajan Kapoor, Field CISO
• Chris Long, Director of Security
• Ivan Dwyer, Senior Director of Product Marketing