# AWS Startup Security Baseline (AWS SSB) Evaluation - Comprehensive Security Posture Assessment
You are a cloud security architect with access to AWS Knowledge MCP Server tools. Use these tools to provide data-driven, documentation-backed security baseline evaluation and remediation guidance based on the AWS Startup Security Baseline (AWS SSB) prescriptive guidance.
## Current Environment Context
**Startup Profile:**
- Company Name: [Your startup name]
- Funding Stage: [Pre-Seed / Seed / Series A / Series B]
- Industry Vertical: [SaaS, FinTech, HealthTech, E-commerce, etc.]
- Current Users/Scale: [e.g., 5K DAU, 50K monthly active users]
- AWS Account Structure: [Single account / Beginning multi-account transition]
- Team Size: [Number of engineers, security expertise level]
- Compliance Requirements: [GDPR, HIPAA, SOC2, PCI-DSS, etc.]
**Current AWS Services in Use:**
- Compute: [EC2, ECS, EKS, Lambda, etc.]
- Database: [RDS, DynamoDB, Aurora, etc.]
- Storage: [S3, EBS, EFS, etc.]
- Networking: [VPC, CloudFront, Route 53, etc.]
- Security Services: [IAM, CloudTrail, GuardDuty, etc.]
**Security Assessment Goals:**
- Primary Goal: [e.g., Achieve production-ready security posture, Pass Series A due diligence, Obtain SOC2 certification]
- Timeline: [e.g., 30 days, 60 days, 90 days]
- Budget Constraints: [Current monthly AWS spend, acceptable security tooling costs]
- Critical Concerns: [e.g., Customer data protection, API security, compliance readiness]
---
## AWS SSB Control Assessment Framework
The AWS Startup Security Baseline consists of two main categories of controls:
### Category 1: Account-Level Security Controls (Weighted 60% in Risk Scoring)
Account-level controls protect your AWS account credentials, enable visibility, and establish governance foundations. These are weighted higher because account compromise can affect all workloads.
### Category 2: Workload-Level Security Controls (Weighted 40% in Risk Scoring)
Workload-level controls protect your applications, data, and resources running in AWS. These are essential for production readiness but have more limited blast radius than account-level compromises.
---
## Control Evaluation Methodology (Using AWS Knowledge MCP Tools)
### Step 1: Access AWS SSB Prescriptive Guidance
**Tool: `aws_search_documentation`**
Search for the latest AWS Startup Security Baseline documentation:
- Query: "AWS Startup Security Baseline prescriptive guidance controls"
- Query: "AWS SSB account security controls implementation"
- Query: "AWS SSB workload security controls best practices"
**Tool: `aws_read_documentation`**
Read detailed implementation guides for each control category:
- Focus on control objectives, implementation steps, and validation criteria
- Review AWS service configuration requirements
- Understand dependencies between controls
**Deliverable:** Summarize current AWS SSB control requirements with documentation links for reference.
---
### Step 2: Account-Level Security Controls Assessment
Systematically evaluate each account-level control using MCP tools for validation:
#### Control 1.1: Root User Security
**Control Objective:** Secure the AWS account root user to prevent unauthorized access to all account resources.
**Assessment Checklist:**
- [ ] Root user MFA enabled (hardware or virtual MFA device)
- [ ] Root user access keys deleted (no programmatic access)
- [ ] Root user password meets complexity requirements (min 14 characters)
- [ ] Root user email address monitored and accessible
- [ ] Root user login activity monitored via CloudWatch alarms
**MCP Validation:**
- Search: `aws_search_documentation("AWS root user security best practices MFA")`
- Read: Detailed MFA setup guide from search results
- Verify: Regional availability of MFA services if using hardware tokens
**Risk Rating:**
- 🔴 RED (Critical): Root user has no MFA OR access keys exist
- 🟡 YELLOW (Medium): Root user has MFA but weak password OR email not monitored
- 🟢 GREEN (Low): All controls implemented and validated
**Remediation Guidance:**
If RED or YELLOW, use MCP tools to find implementation steps:
- Search: `aws_search_documentation("enable MFA root user step by step")`
- Search: `aws_search_documentation("delete root user access keys")`
- Estimated Implementation Time: 15-30 minutes
---
#### Control 1.2: IAM Password Policy
**Control Objective:** Enforce strong password requirements for IAM users to prevent credential-based attacks.
**Assessment Checklist:**
- [ ] Minimum password length: 14 characters
- [ ] Require at least one uppercase letter
- [ ] Require at least one lowercase letter
- [ ] Require at least one number
- [ ] Require at least one non-alphanumeric character
- [ ] Password expiration: 90 days
- [ ] Password reuse prevention: last 24 passwords
- [ ] Allow users to change their own password
**MCP Validation:**
- Search: `aws_search_documentation("IAM password policy configuration best practices")`
- Read: IAM password policy documentation for current recommendations
**Risk Rating:**
- 🔴 RED: No password policy configured OR minimum length <8 characters
- 🟡 YELLOW: Password policy exists but doesn't meet all AWS SSB requirements
- 🟢 GREEN: Password policy meets or exceeds all AWS SSB requirements
**Remediation Guidance:**
- Search: `aws_search_documentation("set IAM password policy console CLI")`
- Estimated Implementation Time: 10 minutes
---
#### Control 1.3: CloudTrail Logging
**Control Objective:** Enable comprehensive logging of all API activity for security monitoring, compliance, and forensic analysis.
**Assessment Checklist:**
- [ ] CloudTrail enabled in all regions (multi-region trail)
- [ ] CloudTrail logs delivered to dedicated S3 bucket
- [ ] S3 bucket has versioning enabled
- [ ] S3 bucket has MFA Delete enabled
- [ ] S3 bucket encryption enabled (SSE-S3 or SSE-KMS)
- [ ] S3 bucket access logging enabled
- [ ] CloudTrail log file validation enabled
- [ ] CloudWatch Logs integration enabled for real-time monitoring
**MCP Validation:**
- Search: `aws_search_documentation("CloudTrail multi-region trail setup")`
- Search: `aws_search_documentation("CloudTrail S3 bucket security best practices")`
- Check: `aws_get_regional_availability(region="<your-region>", resource_type="api", filters=["CloudTrail+CreateTrail"])`
**Risk Rating:**
- 🔴 RED: CloudTrail not enabled OR logs not protected (no versioning/encryption)
- 🟡 YELLOW: CloudTrail enabled but missing log file validation OR CloudWatch integration
- 🟢 GREEN: CloudTrail fully configured with all security controls
**Remediation Guidance:**
- Search: `aws_search_documentation("CloudTrail log file validation enable")`
- Search: `aws_search_documentation("CloudTrail CloudWatch Logs integration")`
- Estimated Implementation Time: 30-45 minutes
---
#### Control 1.4: AWS Budget Alerts
**Control Objective:** Monitor AWS spending to detect unexpected cost increases that may indicate security incidents or misconfigurations.
**Assessment Checklist:**
- [ ] AWS Budget created with monthly threshold
- [ ] Budget threshold set at 80% of expected monthly spend
- [ ] Budget alerts configured for actual spend
- [ ] Budget alerts configured for forecasted spend
- [ ] Alerts sent to multiple stakeholders (email/SNS)
- [ ] Budget includes all services and regions
**MCP Validation:**
- Search: `aws_search_documentation("AWS Budgets setup cost monitoring")`
- Read: AWS Budgets best practices documentation
**Risk Rating:**
- 🔴 RED: No budget alerts configured
- 🟡 YELLOW: Budget exists but threshold >100% OR only one alert recipient
- 🟢 GREEN: Budget properly configured with multiple alerts and recipients
**Remediation Guidance:**
- Search: `aws_search_documentation("create AWS Budget alert threshold")`
- Estimated Implementation Time: 15 minutes
---
#### Control 1.5: Amazon GuardDuty
**Control Objective:** Enable continuous threat detection to identify malicious activity and unauthorized behavior.
**Assessment Checklist:**
- [ ] GuardDuty enabled in primary region
- [ ] GuardDuty enabled in all regions where resources exist
- [ ] GuardDuty findings sent to SNS topic for alerting
- [ ] High and medium severity findings have response procedures
- [ ] GuardDuty findings reviewed at least weekly
- [ ] S3 Protection enabled (if using S3)
- [ ] EKS Protection enabled (if using EKS)
- [ ] RDS Protection enabled (if using RDS)
**MCP Validation:**
- Search: `aws_search_documentation("Amazon GuardDuty enable setup")`
- Search: `aws_search_documentation("GuardDuty findings response automation")`
- Check: `aws_get_regional_availability(region="<your-region>", resource_type="api", filters=["GuardDuty+CreateDetector"])`
**Risk Rating:**
- 🔴 RED: GuardDuty not enabled
- 🟡 YELLOW: GuardDuty enabled but no alerting OR findings not reviewed regularly
- 🟢 GREEN: GuardDuty fully configured with alerting and response procedures
**Remediation Guidance:**
- Search: `aws_search_documentation("GuardDuty SNS notification setup")`
- Estimated Implementation Time: 20-30 minutes
---
#### Control 1.6: AWS Trusted Advisor Monitoring
**Control Objective:** Leverage AWS Trusted Advisor to identify security gaps, cost optimization opportunities, and best practice violations.
**Assessment Checklist:**
- [ ] Trusted Advisor security checks reviewed monthly
- [ ] Critical security recommendations addressed within 7 days
- [ ] Trusted Advisor notifications enabled (if Business/Enterprise Support)
- [ ] Security check results documented and tracked
- [ ] Key checks monitored: Security Groups, IAM Use, MFA on Root, S3 Bucket Permissions
**MCP Validation:**
- Search: `aws_search_documentation("AWS Trusted Advisor security checks")`
- Read: Trusted Advisor best practices documentation
**Risk Rating:**
- 🔴 RED: Trusted Advisor security checks never reviewed OR critical issues unresolved >30 days
- 🟡 YELLOW: Trusted Advisor reviewed quarterly OR some critical issues unresolved >7 days
- 🟢 GREEN: Trusted Advisor reviewed monthly with timely remediation
**Remediation Guidance:**
- Search: `aws_search_documentation("Trusted Advisor security recommendations")`
- Estimated Implementation Time: 30 minutes (initial review), 15 minutes (ongoing monthly)
---
#### Control 1.7: Account Contact Information
**Control Objective:** Ensure AWS can reach your team for security notifications, billing issues, and service disruptions.
**Assessment Checklist:**
- [ ] Primary contact email address current and monitored
- [ ] Alternate contact (security) configured
- [ ] Alternate contact (billing) configured
- [ ] Alternate contact (operations) configured
- [ ] Contact information reviewed quarterly
- [ ] Security contact email goes to distribution list (not individual)
**MCP Validation:**
- Search: `aws_search_documentation("AWS account alternate contacts security")`
**Risk Rating:**
- 🔴 RED: No alternate contacts configured OR primary email not monitored
- 🟡 YELLOW: Only one alternate contact configured OR contacts not reviewed in >6 months
- 🟢 GREEN: All alternate contacts configured and current
**Remediation Guidance:**
- Search: `aws_search_documentation("add alternate contact AWS account")`
- Estimated Implementation Time: 10 minutes
---
#### Control 1.8: IAM User Access Management
**Control Objective:** Implement least-privilege access and proper IAM user lifecycle management.
**Assessment Checklist:**
- [ ] No IAM users with AdministratorAccess policy (use roles instead)
- [ ] All IAM users have MFA enabled
- [ ] IAM users with console access have strong passwords
- [ ] Unused IAM users disabled or deleted (no activity >90 days)
- [ ] IAM access keys rotated every 90 days
- [ ] No IAM access keys embedded in code or configuration files
- [ ] IAM policies follow least-privilege principle
- [ ] IAM user permissions reviewed quarterly
**MCP Validation:**
- Search: `aws_search_documentation("IAM user best practices least privilege")`
- Search: `aws_search_documentation("IAM access key rotation")`
**Risk Rating:**
- 🔴 RED: IAM users without MFA OR AdministratorAccess assigned to users OR access keys >180 days old
- 🟡 YELLOW: Some IAM users without MFA OR access keys >90 days old OR unused users not disabled
- 🟢 GREEN: All IAM users follow best practices with MFA, key rotation, and least privilege
**Remediation Guidance:**
- Search: `aws_search_documentation("enforce MFA IAM users")`
- Search: `aws_search_documentation("IAM credential report audit")`
- Estimated Implementation Time: 1-2 hours (initial audit and remediation)
---
### Step 3: Workload-Level Security Controls Assessment
Systematically evaluate each workload-level control:
#### Control 2.1: Application Secrets Management
**Control Objective:** Store and manage application secrets (API keys, database passwords, certificates) securely using AWS Secrets Manager or Systems Manager Parameter Store.
**Assessment Checklist:**
- [ ] No secrets hardcoded in application code
- [ ] No secrets in environment variables (use Secrets Manager instead)
- [ ] AWS Secrets Manager or Parameter Store (SecureString) used for all secrets
- [ ] Secrets rotation enabled for database credentials
- [ ] Secrets rotation enabled for API keys (where supported)
- [ ] Application uses IAM roles to access secrets (not access keys)
- [ ] Secrets access logged via CloudTrail
- [ ] Unused secrets deleted
**MCP Validation:**
- Search: `aws_search_documentation("AWS Secrets Manager best practices rotation")`
- Search: `aws_search_documentation("Systems Manager Parameter Store SecureString")`
- Check: `aws_get_regional_availability(region="<your-region>", resource_type="api", filters=["SecretsManager+CreateSecret"])`
**Risk Rating:**
- 🔴 RED: Secrets hardcoded in code OR stored in plaintext environment variables
- 🟡 YELLOW: Secrets in Secrets Manager but no rotation enabled OR some secrets still in environment variables
- 🟢 GREEN: All secrets in Secrets Manager with rotation enabled and IAM role-based access
**Remediation Guidance:**
- Search: `aws_search_documentation("migrate secrets to Secrets Manager")`
- Search: `aws_search_documentation("enable automatic secret rotation")`
- Estimated Implementation Time: 2-4 hours (depending on number of secrets)
---
#### Control 2.2: Resource Access Minimization
**Control Objective:** Implement least-privilege access to AWS resources using IAM roles, security groups, and resource policies.
**Assessment Checklist:**
- [ ] EC2 instances use IAM roles (not access keys)
- [ ] Lambda functions use IAM roles with minimal permissions
- [ ] ECS tasks use IAM roles for task execution
- [ ] S3 buckets have bucket policies restricting access
- [ ] Security groups follow least-privilege (no 0.0.0.0/0 for SSH/RDP)
- [ ] Network ACLs configured for defense in depth
- [ ] Resource tags used for access control (ABAC where applicable)
**MCP Validation:**
- Search: `aws_search_documentation("IAM roles EC2 instances best practices")`
- Search: `aws_search_documentation("security group rules least privilege")`
**Risk Rating:**
- 🔴 RED: EC2 instances without IAM roles OR security groups allow 0.0.0.0/0 for SSH/RDP
- 🟡 YELLOW: IAM roles used but overly permissive OR some security groups too open
- 🟢 GREEN: All resources use IAM roles with least-privilege and security groups properly configured
**Remediation Guidance:**
- Search: `aws_search_documentation("attach IAM role to EC2 instance")`
- Search: `aws_search_documentation("security group best practices restrict access")`
- Estimated Implementation Time: 1-3 hours (depending on number of resources)
---
#### Control 2.3: Encryption at Rest
**Control Objective:** Encrypt all data at rest using AWS-managed or customer-managed encryption keys.
**Assessment Checklist:**
- [ ] RDS databases have encryption enabled
- [ ] DynamoDB tables have encryption enabled
- [ ] S3 buckets have default encryption enabled (SSE-S3 or SSE-KMS)
- [ ] EBS volumes have encryption enabled
- [ ] EFS file systems have encryption enabled
- [ ] Redshift clusters have encryption enabled (if applicable)
- [ ] Snapshots and backups are encrypted
- [ ] KMS key rotation enabled for customer-managed keys
**MCP Validation:**
- Search: `aws_search_documentation("RDS encryption at rest enable")`
- Search: `aws_search_documentation("S3 bucket default encryption")`
- Search: `aws_search_documentation("EBS encryption by default")`
- Check: `aws_get_regional_availability(region="<your-region>", resource_type="api", filters=["KMS+CreateKey", "RDS+CreateDBInstance"])`
**Risk Rating:**
- 🔴 RED: Databases or S3 buckets with sensitive data not encrypted
- 🟡 YELLOW: Most resources encrypted but some exceptions OR using SSE-S3 instead of SSE-KMS for sensitive data
- 🟢 GREEN: All data at rest encrypted with appropriate key management
**Remediation Guidance:**
- Search: `aws_search_documentation("enable encryption existing RDS database")`
- Search: `aws_search_documentation("S3 bucket encryption migration")`
- Estimated Implementation Time: 2-4 hours (may require downtime for some services)
---
#### Control 2.4: Encryption in Transit
**Control Objective:** Encrypt all data in transit using TLS/SSL to prevent eavesdropping and man-in-the-middle attacks.
**Assessment Checklist:**
- [ ] Application Load Balancer uses HTTPS listeners
- [ ] CloudFront distributions use HTTPS (redirect HTTP to HTTPS)
- [ ] API Gateway uses TLS 1.2 or higher
- [ ] RDS connections use SSL/TLS
- [ ] ElastiCache connections use TLS (if supported)
- [ ] Application enforces HTTPS for all API endpoints
- [ ] TLS certificates managed via ACM (AWS Certificate Manager)
- [ ] TLS certificates auto-renewed
**MCP Validation:**
- Search: `aws_search_documentation("Application Load Balancer HTTPS listener")`
- Search: `aws_search_documentation("CloudFront HTTPS redirect")`
- Search: `aws_search_documentation("RDS SSL connection")`
**Risk Rating:**
- 🔴 RED: Application accepts HTTP traffic without HTTPS OR database connections not encrypted
- 🟡 YELLOW: HTTPS enabled but HTTP not redirected OR some services still using HTTP
- 🟢 GREEN: All traffic encrypted in transit with TLS 1.2+ and HTTP redirected to HTTPS
**Remediation Guidance:**
- Search: `aws_search_documentation("configure HTTPS ALB listener ACM")`
- Search: `aws_search_documentation("enforce SSL RDS connections")`
- Estimated Implementation Time: 1-2 hours
---
#### Control 2.5: VPC Endpoints for AWS Services
**Control Objective:** Use VPC endpoints to access AWS services privately without traversing the public internet, reducing attack surface and data transfer costs.
**Assessment Checklist:**
- [ ] VPC endpoint for S3 (Gateway endpoint)
- [ ] VPC endpoint for DynamoDB (Gateway endpoint)
- [ ] VPC endpoints for other AWS services used (Interface endpoints)
- [ ] VPC endpoint policies restrict access to specific resources
- [ ] Private subnets use VPC endpoints instead of NAT Gateway for AWS service access
- [ ] VPC endpoint DNS resolution enabled
**MCP Validation:**
- Search: `aws_search_documentation("VPC endpoints AWS services setup")`
- Search: `aws_search_documentation("VPC endpoint policies security")`
- Check: `aws_get_regional_availability(region="<your-region>", resource_type="api", filters=["EC2+CreateVpcEndpoint"])`
**Risk Rating:**
- 🔴 RED: No VPC endpoints configured, all AWS service traffic goes over internet
- 🟡 YELLOW: Some VPC endpoints configured but not for all services OR endpoint policies too permissive
- 🟢 GREEN: VPC endpoints configured for all AWS services with restrictive policies
**Remediation Guidance:**
- Search: `aws_search_documentation("create VPC endpoint S3 DynamoDB")`
- Estimated Implementation Time: 30-60 minutes
---
#### Control 2.6: Network Segmentation
**Control Objective:** Implement proper network segmentation using VPCs, subnets, and security groups to isolate workloads and limit blast radius.
**Assessment Checklist:**
- [ ] Resources deployed in VPC (not EC2-Classic)
- [ ] Public and private subnets properly separated
- [ ] Database tier in private subnets (no direct internet access)
- [ ] Application tier in private subnets behind load balancer
- [ ] Bastion hosts or Systems Manager Session Manager for administrative access (no direct SSH)
- [ ] Security groups configured for each tier (web, app, database)
- [ ] Network ACLs provide additional layer of defense
- [ ] VPC Flow Logs enabled for network traffic monitoring
**MCP Validation:**
- Search: `aws_search_documentation("VPC network segmentation best practices")`
- Search: `aws_search_documentation("VPC Flow Logs enable")`
**Risk Rating:**
- 🔴 RED: Resources in default VPC OR databases in public subnets OR no network segmentation
- 🟡 YELLOW: Custom VPC but weak segmentation OR VPC Flow Logs not enabled
- 🟢 GREEN: Proper network segmentation with defense in depth and flow logs enabled
**Remediation Guidance:**
- Search: `aws_search_documentation("migrate resources to custom VPC")`
- Search: `aws_search_documentation("create private subnet database tier")`
- Estimated Implementation Time: 4-8 hours (significant architectural change)
---
### Step 4: Monitoring & Compliance Controls Assessment
#### Control 3.1: Centralized Logging
**Control Objective:** Aggregate logs from all sources for security monitoring, troubleshooting, and compliance.
**Assessment Checklist:**
- [ ] Application logs sent to CloudWatch Logs
- [ ] VPC Flow Logs enabled and sent to CloudWatch Logs or S3
- [ ] Load balancer access logs enabled
- [ ] S3 access logs enabled for sensitive buckets
- [ ] Lambda function logs sent to CloudWatch Logs
- [ ] Log retention configured (minimum 90 days for security logs)
- [ ] Log aggregation to central S3 bucket for long-term storage
- [ ] Log analysis tools configured (CloudWatch Insights, Athena, or third-party SIEM)
**MCP Validation:**
- Search: `aws_search_documentation("centralized logging architecture AWS")`
- Search: `aws_search_documentation("CloudWatch Logs retention policy")`
**Risk Rating:**
- 🔴 RED: No centralized logging OR logs retained <30 days
- 🟡 YELLOW: Centralized logging exists but incomplete OR retention <90 days
- 🟢 GREEN: Comprehensive centralized logging with appropriate retention and analysis tools
**Remediation Guidance:**
- Search: `aws_search_documentation("enable VPC Flow Logs CloudWatch")`
- Search: `aws_search_documentation("ALB access logs S3")`
- Estimated Implementation Time: 2-3 hours
---
#### Control 3.2: Security Monitoring & Alerting
**Control Objective:** Implement real-time security monitoring and alerting for critical security events.
**Assessment Checklist:**
- [ ] CloudWatch alarms for root user login
- [ ] CloudWatch alarms for IAM policy changes
- [ ] CloudWatch alarms for security group changes
- [ ] CloudWatch alarms for CloudTrail configuration changes
- [ ] CloudWatch alarms for failed authentication attempts
- [ ] GuardDuty findings sent to SNS/email for high severity
- [ ] AWS Config rules for compliance monitoring
- [ ] Security Hub enabled for centralized security findings (optional but recommended)
**MCP Validation:**
- Search: `aws_search_documentation("CloudWatch alarms security events")`
- Search: `aws_search_documentation("AWS Config rules security compliance")`
- Check: `aws_get_regional_availability(region="<your-region>", resource_type="api", filters=["SecurityHub+EnableSecurityHub", "Config+PutConfigRule"])`
**Risk Rating:**
- 🔴 RED: No security monitoring or alerting configured
- 🟡 YELLOW: Some alarms configured but missing critical events OR alerts not actionable
- 🟢 GREEN: Comprehensive security monitoring with actionable alerts and response procedures
**Remediation Guidance:**
- Search: `aws_search_documentation("create CloudWatch alarm root user login")`
- Search: `aws_search_documentation("AWS Config rules security best practices")`
- Estimated Implementation Time: 2-4 hours
---
#### Control 3.3: Incident Response Preparation
**Control Objective:** Establish incident response procedures and tools to quickly detect, respond to, and recover from security incidents.
**Assessment Checklist:**
- [ ] Incident response plan documented
- [ ] Incident response team identified with contact information
- [ ] Incident response runbooks created for common scenarios
- [ ] AWS support plan appropriate for response time requirements (Business or Enterprise)
- [ ] Backup and recovery procedures tested
- [ ] Forensic investigation tools identified (EC2 snapshots, memory dumps, etc.)
- [ ] Communication plan for security incidents (internal and external)
- [ ] Incident response plan tested annually
**MCP Validation:**
- Search: `aws_search_documentation("AWS incident response best practices")`
- Search: `aws_search_documentation("security incident forensics AWS")`
**Risk Rating:**
- 🔴 RED: No incident response plan OR plan never tested
- 🟡 YELLOW: Incident response plan exists but incomplete OR not tested in >12 months
- 🟢 GREEN: Comprehensive incident response plan with regular testing and updates
**Remediation Guidance:**
- Search: `aws_search_documentation("incident response plan template")`
- Estimated Implementation Time: 4-8 hours (initial plan creation)
---
## Security Posture Scoring Methodology
### Overall Security Score Calculation
**Account-Level Controls (60% weight):**
- Control 1.1 (Root User Security): 15%
- Control 1.2 (IAM Password Policy): 5%
- Control 1.3 (CloudTrail Logging): 15%
- Control 1.4 (AWS Budget Alerts): 5%
- Control 1.5 (Amazon GuardDuty): 10%
- Control 1.6 (Trusted Advisor): 5%
- Control 1.7 (Account Contacts): 2.5%
- Control 1.8 (IAM User Management): 2.5%
**Workload-Level Controls (40% weight):**
- Control 2.1 (Secrets Management): 10%
- Control 2.2 (Resource Access): 7.5%
- Control 2.3 (Encryption at Rest): 10%
- Control 2.4 (Encryption in Transit): 5%
- Control 2.5 (VPC Endpoints): 2.5%
- Control 2.6 (Network Segmentation): 5%
**Monitoring & Compliance (Bonus Points):**
- Control 3.1 (Centralized Logging): +5%
- Control 3.2 (Security Monitoring): +5%
- Control 3.3 (Incident Response): +5%
**Scoring Scale:**
- 🔴 RED Control: 0 points
- 🟡 YELLOW Control: 50 points
- 🟢 GREEN Control: 100 points
**Overall Security Maturity Levels:**
- 0-40%: 🔴 **Critical Risk** - Not production-ready, immediate remediation required
- 41-60%: 🟡 **High Risk** - Significant gaps, production deployment not recommended
- 61-75%: 🟡 **Medium Risk** - Acceptable for early-stage startups, prioritize remediation
- 76-90%: 🟢 **Low Risk** - Production-ready with minor improvements needed
- 91-100%: 🟢 **Excellent** - Strong security posture, ready for enterprise customers
---
## Output Format
For each control category, provide:
### 1. Executive Summary Dashboard
Overall Security Score: [X]% - [Risk Level]
Account-Level Controls: [X]% ([Y] of [Z] controls GREEN) Workload-Level Controls: [X]% ([Y] of [Z] controls GREEN) Monitoring & Compliance: [X]% ([Y] of [Z] controls GREEN)
Production Readiness: [YES/NO] Investor Due Diligence Ready: [YES/NO] Compliance Framework Readiness: [SOC2: YES/NO, HIPAA: YES/NO, etc.]
### 2. Control-by-Control Assessment Report
For each control, provide:
- Control ID and Name
- Risk Rating (🔴/🟡/🟢)
- Current Status (Implemented / Partially Implemented / Not Implemented)
- Gap Analysis (what's missing)
- AWS Documentation References (URLs from MCP searches)
- Remediation Priority (P0 Critical /