Security Posture
Starter+Enterprise
Security Posture gives you a continuous, real-time view of the highest-risk security issues in your cloud environment. Unlike the Compliance module — which evaluates against formal benchmarks on a scheduled basis — Security Posture runs a live set of checks across IAM, S3, encryption, and network exposure, surfacing critical findings as they occur.
Severity Levels
Every finding in Security Posture is assigned a severity level based on the potential impact of exploitation.
| Severity | Colour | Definition | Example finding |
|---|---|---|---|
| Critical | Red | Immediate risk of data exposure or account compromise | Root account has an active access key |
| High | Orange | Significant risk, exploitation likely without intervention | S3 bucket with public read/write access |
| Medium | Yellow | Elevated risk, should be remediated within 30 days | Security group allows 0.0.0.0/0 on port 22 |
| Low | Blue | Best-practice deviation, low immediate impact | EBS volume not tagged with owner |
The Security Posture dashboard opens on the Summary tab which shows a count of open findings at each severity level and a trend chart for the last 30 days.
IAM Misconfigurations
IAM findings cover the identity and access layer — the most common attack surface in AWS compromises.
Root account checks
| Check | Severity | Remediation |
|---|---|---|
| Root account has active access keys | Critical | Delete all root access keys via the cloud Console |
| Root account MFA not enabled | Critical | Enable virtual or hardware MFA on the root account |
| Root account used in the last 30 days | High | Investigate usage and restrict to break-glass scenarios |
IAM user checks
| Check | Severity | Remediation |
|---|---|---|
| Console user with no MFA | High | Enforce MFA via an IAM condition key (aws:MultiFactorAuthPresent) |
| Access key older than 90 days | Medium | Rotate the access key; automate rotation with Secrets Manager |
| Access key unused for 45+ days | Medium | Disable or delete the unused key |
User with AdministratorAccess policy | High | Replace with a least-privilege policy scoped to required actions |
User with inline policy containing *:* | Critical | Remove the wildcard policy; apply a managed policy with explicit allow statements |
IAM role checks
| Check | Severity | Remediation |
|---|---|---|
Role with * in resource and action | High | Scope the policy to specific resources and actions |
Role assumable by any principal (Principal: *) | Critical | Add a condition key or restrict the principal to specific accounts |
| Cross-account role without external ID | Medium | Add an sts:ExternalId condition to the trust policy |
S3 Public Access Exposure
Public S3 misconfiguration is one of the most common causes of cloud data breaches. Calabi checks multiple layers of S3 access controls.
Bucket-level checks
| Check | Severity | What Calabi evaluates |
|---|---|---|
| Public access block not enabled | High | All four BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets flags |
| Bucket ACL grants public read | Critical | AllUsers or AuthenticatedUsers in the bucket ACL |
Bucket policy allows Principal: * | Critical | Bucket resource policy with wildcard principal and no condition |
| Static website hosting enabled | Medium | website_configuration is set — typically not intentional for data buckets |
| No default encryption | High | No server_side_encryption_configuration on the bucket |
Object-level checks
| Check | Severity | Note |
|---|---|---|
| Object ACL grants public read | High | Object-level ACLs can override bucket-level blocks in some configurations |
| Pre-signed URL expiry > 7 days | Low | Pre-signed URLs with long expiry increase exposure window |
Encryption Checks
Calabi verifies that data at rest and in transit is encrypted across the most common AWS storage and database services.
Encryption at rest
| Service | Check | Severity if failed |
|---|---|---|
| EBS volumes | encrypted = false | High |
| RDS instances | storage_encrypted = false | High |
| S3 buckets | No default encryption configured | High |
| Secrets Manager secrets | No KMS key (using default AWS key only) | Medium |
| SNS topics | No server-side encryption | Low |
| SQS queues | No server-side encryption | Low |
| EFS file systems | encrypted = false | High |
| Kinesis streams | encryption_type = NONE | Medium |
Encryption in transit
| Check | Severity | Remediation |
|---|---|---|
S3 bucket policy does not enforce HTTPS (aws:SecureTransport) | Medium | Add a bucket policy statement that denies requests without aws:SecureTransport: true |
| Elastic Load Balancer listener on HTTP (port 80) without redirect | High | Add an HTTP-to-HTTPS redirect rule on the listener |
RDS instance ca_certificate_identifier is rds-ca-2019 (expired) | Medium | Update to rds-ca-rsa2048-g1 or rds-ca-rsa4096-g1 |
Security Group Risk Analysis
Open inbound rules — especially those sourced from 0.0.0.0/0 or ::/0 — expose your resources to the internet.
High-risk port checks
| Port / Protocol | Finding | Severity |
|---|---|---|
22 (SSH) from 0.0.0.0/0 | SSH open to the internet | Critical |
3389 (RDP) from 0.0.0.0/0 | RDP open to the internet | Critical |
3306 (MySQL) from 0.0.0.0/0 | Database port open to the internet | Critical |
5432 (database) from 0.0.0.0/0 | Database port open to the internet | Critical |
1433 (MSSQL) from 0.0.0.0/0 | Database port open to the internet | Critical |
27017 (MongoDB) from 0.0.0.0/0 | Database port open to the internet | Critical |
0–65535 (all traffic) from 0.0.0.0/0 | All ports open to the internet | Critical |
80 / 443 from 0.0.0.0/0 | Web traffic open to the internet | Low (expected for public-facing apps) |
Unused security groups
Security groups that are not attached to any network interface or RDS instance are flagged as Low severity. They represent accumulated configuration debt and should be removed to simplify your security posture.
Remediation Workflow
Every finding in Security Posture follows the same remediation pattern:
- Find — The finding appears in the Security Posture dashboard with severity, resource ARN, and affected region.
- Understand — Click the finding to expand the full description, including the exact condition that triggered it.
- Act — Follow the inline remediation steps. Each step links to the relevant AWS documentation page.
- Verify — Click Re-check to immediately re-evaluate the specific resource. If the finding condition is resolved, the finding moves to Resolved status.
- Suppress (optional) — If a finding is intentional (e.g., a public-facing S3 bucket used for static website hosting), click Suppress and provide a justification. Suppressed findings are excluded from the severity count but remain in the audit log.
Example remediation: S3 bucket ACL grants public read
Finding: S3 bucket 'my-company-data' ACL grants public read
Severity: Critical
Resource: arn:aws:s3:::my-company-data
Region: us-east-1
Remediation steps:
1. Open the S3 Console and navigate to 'my-company-data'.
2. Click the 'Permissions' tab.
3. Under 'Access control list (ACL)', click 'Edit'.
4. Remove the 'Everyone (public access)' grantee.
5. Under 'Block public access', enable all four checkboxes.
6. Click 'Save changes'.
7. Return to Calabi and click 'Re-check' to confirm the finding is resolved.
AWS Reference: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
Exporting Findings
| Format | Contents | How to export |
|---|---|---|
| CSV | All open findings with severity, resource ARN, region, and check name | Click Export CSV on the Security Posture dashboard |
| JSON | Structured finding data suitable for ingestion into a SIEM | Click Export JSON on the Security Posture dashboard |
Exports can be filtered by severity level, service category, or region before downloading.
Related Pages
- Compliance — Run formal CIS, NIST, and AWS benchmark evaluations
- Query Resources — Write custom SQL for ad-hoc security investigations
- Configure — Set up alert channels for new Critical and High findings