MMNA
Money Mitra Network Academy
Serverless Architecture & Threat Landscape
Module 1 • Foundational Security Concepts
Understand the serverless computing model, ephemeral execution environments, and the unique threat landscape facing Lambda functions. Learn how event-driven architectures introduce new attack vectors and why traditional security assumptions break down in serverless environments.
Serverless Architecture Overview
What is Serverless Computing?
Serverless computing abstracts away infrastructure management. Developers write functions that execute in response to events without provisioning or managing servers. The cloud provider handles scaling, patching, and runtime maintenance.
- Event-Triggered: Functions execute only when events occur (API calls, file uploads, scheduled triggers)
- Auto-Scaling: Platform automatically scales from zero to thousands of concurrent executions
- Stateless: Each function invocation is independent; no persistent state within the function
- Managed Runtime: Cloud provider manages OS patching, security updates, and infrastructure
Ephemeral Compute Model (Conceptual)
Functions execute in short-lived containers that are created, used, and destroyed. This model introduces unique security implications—traditional persistent monitoring, local state management, and continuous security controls don't apply.
- Execution Container: Fresh container created for each function invocation or reused for rapid re-invocations
- Limited Lifetime: Functions timeout after 15 minutes (Lambda default); execution context destroyed afterward
- Cold Start: Initial function invocation includes container initialization overhead (~1-5 seconds)
- No Persistence: Any runtime changes, installed packages, or modified files disappear after execution
Lambda Execution Flow (Conceptual)
Event Received
API call, S3 upload, message queue
Container Init
Create or reuse execution environment
Code Execution
Function runs with IAM permissions
Response Sent
Return value delivered to caller
Container Destroy
Runtime destroyed; cleanup happens
Threat Landscape for Serverless
Event Injection Risks (High-Level)
Lambda functions respond to untrusted events from multiple sources. Attackers can craft malicious events to trigger unintended behavior, cause denial of service, or inject commands.
- → Malicious API Payloads: Attacker sends specially crafted JSON/data to trigger injection attacks (SQL injection, command injection, XSS)
- → Event Source Spoofing: Fake S3 events, SNS messages, or SQS records bypassing application logic
- → DoS via Event Floods: Overwhelming function with massive event volume causing resource exhaustion
- → Chain Reaction Attacks: One compromised function triggers malicious events to other Lambda functions
Misconfigured IAM Permissions
Functions are assigned IAM roles with permissions to access AWS resources. Over-privileged roles enable attackers to move laterally, access sensitive data, or modify cloud infrastructure.
- → Overly Broad Permissions: Roles with wildcard ("*") actions/resources allow compromise of one function to compromise entire AWS account
- → Lateral Movement: Compromised Lambda function credentials leak; attacker uses them to access databases, S3, Secrets Manager
- → Privilege Escalation: Function has permissions to assume higher-privilege IAM roles or create new roles
- → Data Access: Credentials allow reading from databases, S3 buckets, or Secrets Manager containing sensitive data
Dependency Vulnerabilities Awareness
Lambda functions depend on third-party libraries, SDKs, and runtime packages. Vulnerable dependencies introduce exploitable weaknesses that attackers can leverage.
- → Known CVEs in Libraries: Outdated npm, pip, Maven packages with publicly disclosed vulnerabilities allow remote code execution
- → Supply Chain Attack: Malicious package published to public repository and included as dependency in Lambda function
- → Runtime Vulnerabilities: Python, Node.js, Java runtime versions contain unpatched security flaws
- → No Local Patching: Container image rebuilt and redeployed to apply security patches; stale code remains in production
Shared Responsibility in Serverless
Cloud Provider Responsibilities (AWS)
- ✓ Infrastructure Security: Physical data center protection, network isolation, hardware security
- ✓ Lambda Runtime: Maintaining Lambda service, updating runtimes, managing orchestration
- ✓ Operating System Patches: Kernel updates, system library security patches
- ✓ Compute Isolation: Kernel-level container isolation between functions
- ✓ DDoS Protection: AWS Shield and WAF for infrastructure-level attacks
Developer Responsibilities
- → Application Security: Secure code development, input validation, injection prevention
- → IAM Least Privilege: Design minimal permissions for function roles, avoid wildcards
- → Dependency Management: Update libraries, scan for CVEs, manage supply chain risks
- → Secrets Management: Never hardcode credentials; use AWS Secrets Manager or Parameter Store
- → Monitoring & Logging: Enable CloudWatch, X-Ray, and log analysis for threat detection
Key Insight: Security failures in serverless often stem from developer mistakes—overprivileged roles, insecure coding, unpatched dependencies—rather than platform vulnerabilities.
Enterprise Risk Perspective
Business Impact of Function Compromise
When a Lambda function is compromised, attackers gain access to cloud infrastructure and sensitive data. The blast radius is often organization-wide due to shared IAM roles and cloud interconnections.
- ⚠️ Data Exfiltration: Stolen customer records, financial data, intellectual property
- ⚠️ Service Disruption: Ransomware encrypting databases, DoS attacks causing downtime
- ⚠️ Lateral Spread: Attacker pivots to other systems (databases, APIs, S3 buckets)
- ⚠️ Compliance Violations: GDPR/HIPAA fines, PCI-DSS audit failures, regulatory penalties
- ⚠️ Reputational Damage: Loss of customer trust, brand damage, competitive disadvantage
Data Exposure Scenarios (Conceptual)
Real-world attack scenarios showing how compromised functions enable data theft and infrastructure takeover.
Scenario 1: API Injection
Attacker sends malicious payload to Lambda function processing API requests. Function parses input unsafely, allowing command injection to read /etc/passwd or access environment variables containing secrets.
Scenario 2: Overprivileged Role Abuse
Function has permission to call s3:GetObject on "*" resources. Attacker retrieves credentials from the function environment, then accesses all S3 buckets containing backup databases and source code.
Scenario 3: Supply Chain Attack
Third-party npm package used by Lambda gets compromised. Malicious code exfiltrates environment variables (containing AWS credentials) and sends to attacker's command-and-control server.
External Learning References
AWS Lambda Documentation
Official AWS documentation covering Lambda fundamentals, security best practices, and API reference.
docs.aws.amazon.com/lambda →AWS Lambda Security Best Practices
AWS security documentation specific to Lambda execution environment and threat mitigation.
docs.aws.amazon.com/lambda/security →AWS IAM Best Practices
Identity and Access Management (IAM) security guidance for designing least-privilege policies.
docs.aws.amazon.com/IAM/best-practices →Serverless Application Repository (SAR)
Discover serverless applications and explore security patterns for Lambda deployments.
aws.amazon.com/serverlessrepo →