Serverless Architecture Security Patterns for Securing the Unseen

### Overview In this talk, Jabez Abraham, a Cloud Security Architect at Asurion (referred to phonetically as Osurion), examines the security challenges and architectural design patterns essential for securing serverless environments. While serverless technologies abstract away infrastructure management and patching, Abraham emphasizes that ephemeral compute functions are not inherently secure. Organizations must shift their security mindset from traditional infrastructure-centric controls to a data-centric model focused on protecting what matters most throughout its entire lifecycle.

### Key Topics - **The Data Lifecycle and Threat Actors:** Understanding data creation, storage, and consumption across producers, consumers, protection boundaries, and perpetrators. - **The Serverless Threat Landscape:** The "invisible" threat model of the cloud (the iceberg metaphor) where cloud providers manage the underlying physical layers, but application weaknesses, configuration, and ephemeral runtime permissions remain customer responsibilities. - **Demonstration of Ephemeral Vulnerability:** A live demonstration using an interactive Lambda shell environment (lambdashell.com) showing how an attacker can extract runtime AWS environment variables (access key, secret key, session token) and interact with cloud resources externally. - **Layered Architectural Patterns:** Applying defense in depth across the Edge, Compute, Middleware, and Back-End layers. - **DevSecOps and Shared Responsibility:** Integrating security directly into developer sprint cycles and balancing user experience with compensating controls under the cloud shared responsibility model.

### Technical Details Abraham illustrates security requirements by breaking serverless architectures down into distinct architectural tiers: - **Front-End / Edge Layer:** Implement edge protections such as Web Application Firewalls (WAF), geographic and IP restrictions, CDN caching, enforcement of TLS/HTTPS redirects, security headers, and rate-based rules. Access to storage like Amazon S3 should be restricted using tight bucket policies that enforce least privilege (e.g., restricting specific source IPs and limiting actions strictly to `s3:GetObject`). - **Middleware Layer:** Protect APIs through token validation, strong input sanitization, and standardized input validation to prevent injection or unexpected execution. When using JSON Web Tokens (JWT) for authentication and authorization, best practices include validating issuers, audiences, signatures, and expiration times while minimizing token scope. - **Compute Layer & Lateral Movement:** The demonstration highlighted that even with a default minimal execution role (`AWSLambdaBasicExecutionRole`), exposed temporary session credentials allow attackers to execute AWS CLI calls remotely. While privilege restriction prevents unauthorized role listing, an attacker could still create log groups and streams to generate garbage events and drive up billing costs. Overprivileged roles (such as admin privileges) create critical risks of lateral movement and account takeover. Additionally, developers must be mindful of shared global context across Lambda function warm invocations. - **Back-End Layer:** Isolate databases (such as Amazon DynamoDB) within VPCs, use VPC endpoints and granular database resource policies (e.g., restricting queries strictly to designated source VPCs and specific actions like `GetItem`). Abraham emphasizes that while cloud providers protect physical data centers, data-level encryption and strict IAM policies prevent exfiltration. He also recommends automated containment strategies, where compromised or anomalous instances are tagged, snapshot for external forensic analysis, and isolated without disrupting business availability.

### Takeaways Securing serverless architectures requires moving away from one-size-fits-all tooling toward layered, tower-specific controls. Abraham advises organizations not to "boil the ocean" but instead structure planning into immediate, short-term (e.g., 3–4 months), and long-term (e.g., 4–6 months) phases. Security teams must actively participate in DevOps sprint cycles from the ground up to educate developers and implement guardrails collaboratively. Ultimately, serverless security is not a fixed destination, but an ongoing journey of continuous iteration and adaptation as cloud services evolve.