Cloud Security

The Cloud Security module gives your security team a unified view of your cloud infrastructure posture across AWS, Azure, and GCP. It continuously assesses cloud resource configurations, identifies misconfigurations, maps compliance gaps, and feeds cloud-sourced risk signals directly into the WeaverScore — so your exposure management program reflects the full attack surface, not just on-premises vulnerability data.

Why Cloud Security Posture Management Matters

Most enterprise breaches involving cloud infrastructure trace back to one of four root causes: an S3 bucket left public, an IAM role with excessive permissions, a security group allowing unrestricted inbound traffic, or a storage account with encryption disabled. These are not zero-days — they are configuration mistakes that attackers find in minutes using automated scanners.

Cloud Security Posture Management (CSPM) is the practice of continuously checking that cloud resource configurations match your security baseline. ThreatWeaver's Cloud Security module automates this check across all three major cloud providers. It does not require agents, does not modify cloud resources, and uses only read-only API access. Your cloud team connects their AWS account, Azure subscription, or GCP project once — and the module begins discovering and assessing resources immediately.

For security analysts, CSPM closes the gap between "we deployed to the cloud" and "we know the security state of what we deployed." For executives, it answers the question "are we exposed in the cloud?" with evidence.

---

Architecture Overview

The scanner runs on a polling schedule (default: every 4 hours). It authenticates to each cloud provider using the credentials stored in the connector configuration, calls provider APIs, normalizes the response into ThreatWeaver's internal resource model, evaluates each resource against security rules, and writes findings to the database. No data is sent to any third party — all processing happens within your ThreatWeaver instance.

---

Supported Providers and Services

Amazon Web Services (AWS)

Service	Resources Assessed	Key Checks
IAM	Users, roles, policies, access keys	Root account usage, MFA on root/users, overly permissive inline policies, access keys older than 90 days, unused users
S3	Buckets and bucket policies	Public access settings, bucket policy wildcard principals, ACL public grants, server-side encryption, versioning, access logging
EC2	Instances, security groups, EBS volumes	Unrestricted inbound (0.0.0.0/0) on sensitive ports (22, 3389, 1433, 3306), unencrypted EBS volumes, public instances without IMDSv2
Lambda	Functions and their execution roles	Functions with overly permissive execution roles, functions with environment variable secrets, functions without VPC attachment
VPC	VPCs, subnets, NACLs, flow logs	Default VPC in use, VPC flow logs disabled, NACLs allowing unrestricted ingress
CloudTrail	Trails and log delivery	CloudTrail not enabled in all regions, log file validation disabled, S3 delivery failures
RDS	Database instances	Publicly accessible instances, unencrypted storage, automated backups disabled, minor version auto-upgrade disabled
CloudWatch	Log groups and metric filters	Missing metric filter and alarm for root login, unauthorized API calls, security group changes
KMS	Customer-managed keys	CMKs with key rotation disabled, CMKs with overly permissive key policies
Config	AWS Config recorders	Config recording disabled in one or more regions

Microsoft Azure

Service	Resources Assessed	Key Checks
Azure AD / Entra ID	Users, roles, conditional access	MFA not enforced for admins, guest users with elevated permissions, no conditional access policy for admin accounts
Storage Accounts	Blob containers, file shares	Public blob access enabled, storage not encrypted with customer-managed keys, secure transfer not required, legacy TLS versions allowed
Virtual Machines	VMs, managed disks, extensions	Unencrypted OS/data disks, VMs without endpoint protection extension, VMs with public IPs not behind a load balancer
Network Security Groups	NSG rules	Inbound rules allowing all traffic (Any source, port *), RDP/SSH open to the internet, management port 3389/22 exposure
Key Vault	Vaults, keys, secrets, certificates	Soft delete disabled, purge protection disabled, secrets/keys without expiry dates, public network access unrestricted
SQL Database	Azure SQL instances	Auditing not enabled, threat detection not configured, no Transparent Data Encryption (TDE)
AKS	Kubernetes clusters	RBAC not enabled, network policy not configured, API server publicly accessible
Monitor	Activity log, diagnostic settings	Activity log retention less than 90 days, no alert for key vault deletion, no alert for policy assignment changes

Google Cloud Platform (GCP)

Service	Resources Assessed	Key Checks
IAM	Service accounts, IAM policies	Service accounts with admin/owner roles, service account key age, primitive roles (Owner/Editor) in use, cross-project service account usage
Cloud Storage (GCS)	Buckets and IAM policies	AllUsers or allAuthenticatedUsers access, uniform bucket-level access disabled, no retention policy for audit log buckets
Compute Engine	VM instances, firewall rules	Firewall rules allowing 0.0.0.0/0 on RDP/SSH, instances with public IPs, instances not running Shielded VM, OS Login disabled
VPC	Networks, subnets, firewall rules	Default network in use, VPC Flow Logs disabled for subnets, SSH/RDP firewall rules open to all
GKE	Kubernetes clusters	Workload identity not enabled, basic authentication enabled, dashboard enabled, auto-node repair disabled
Cloud SQL	Database instances	Public IP assigned without authorized networks, SSL not required, audit logging disabled, backups disabled
Cloud Logging	Log buckets, sinks	Cloud Audit Logs not enabled for all services, log retention under 400 days for admin activity
KMS	Key rings and keys	Key rotation period over 90 days, keys without a rotation schedule

---

How ThreatWeaver Connects to Cloud Providers

All cloud provider connections use the principle of minimal read-only access. ThreatWeaver never writes to, modifies, or deletes cloud resources. The connection model depends on the provider:

AWS Connection Model

ThreatWeaver uses an IAM Role with an external trust policy (cross-account assume-role) rather than long-lived access keys. This is more secure and easier to revoke.

• You create an IAM role in your AWS account with SecurityAudit and ReadOnlyAccess managed policies attached
• The trust policy allows ThreatWeaver's scanning service to assume this role using an external ID (unique per connector)
• ThreatWeaver calls sts:AssumeRole with the external ID, receives temporary credentials, and uses those for all API calls
• Temporary credentials expire after 1 hour; ThreatWeaver refreshes them before each scan cycle

If you cannot use cross-account assume-role (e.g., highly restricted environments), ThreatWeaver also accepts IAM access keys — but this is discouraged because long-lived credentials are a higher-risk approach.

Azure Connection Model

ThreatWeaver uses Azure App Registration with a client secret or certificate to authenticate as a service principal.

• You create an App Registration in your Azure tenant
• You assign the Reader role at the subscription scope (or management group scope for multi-subscription coverage)
• ThreatWeaver uses OAuth2 client credentials flow to obtain an access token from https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token
• The access token is scoped to https://management.azure.com/.default and is refreshed automatically

For Entra ID (Azure AD) data (users, MFA status, conditional access), an additional Microsoft Graph permission is needed: Directory.Read.All on the App Registration.

GCP Connection Model

ThreatWeaver uses a GCP Service Account with a JSON key file or Workload Identity Federation.

• You create a service account in your GCP project
• You assign the Viewer role (or equivalent read-only roles: roles/viewer, roles/iam.securityReviewer, roles/cloudasset.viewer) at the project or organization level
• ThreatWeaver authenticates using the service account's JSON key, or via Workload Identity Federation if you prefer keyless authentication

---

Cloud Asset Inventory

The Asset Inventory UI (/cloud/posture) shows every cloud resource discovered across all connected providers. It is designed for analysts who need to answer: "What do we have in the cloud, and which resources have problems?"

Inventory Table Columns

Column	Description
Resource Name	The cloud-native resource name (e.g., prod-api-bucket, web-server-sg)
Type	Resource type (e.g., aws::s3::Bucket, azure::compute::VirtualMachine)
Provider	AWS, Azure, or GCP
Region	Cloud region where the resource is deployed
Status	Compliant, Non-Compliant, or Unknown
Risk Score	0-100 composite score based on misconfiguration severity and asset criticality
Misconfigs	Count of active misconfiguration findings for this resource
Last Scanned	Timestamp of the most recent scan

Filtering and Search

The inventory supports filtering by:

• Provider — show only AWS, Azure, or GCP resources
• Resource Type — narrow to specific services (e.g., only S3 buckets or security groups)
• Region — filter to specific geographic regions
• Status — show only Non-Compliant resources to focus on problems
• Risk Score — set a minimum score threshold (e.g., "show me only resources with risk score above 70")
• Free text search — match on resource name or resource ID

Resource Detail View

Clicking any resource opens the detail panel, which shows:

• Full resource metadata (ARN, subscription ID, or GCP resource path)
• All active findings for this resource with severity and remediation steps
• Compliance benchmark controls mapped to this resource and their pass/fail status
• Scan history — when the resource was last assessed and what changed

---

Cloud Findings

Cloud Findings (/cloud/findings) is the central list of all security issues identified across cloud resources. Each finding represents a specific misconfiguration or security risk on a specific resource.

Finding Anatomy

Field	Description
Title	Human-readable name of the issue (e.g., "S3 Bucket Public Access Not Blocked")
Severity	Critical, High, Medium, or Low (see severity model below)
Provider	AWS, Azure, or GCP
Resource Type	The service category (e.g., s3::Bucket, compute::VM)
Resource ID	The specific cloud resource affected
CIS Control	Mapped CIS Benchmark control ID (e.g., CIS AWS 2.1.1)
Status	Open, Remediated, or Accepted
Solution	Step-by-step remediation guidance
Detected At	When ThreatWeaver first identified this issue

Severity Model for Cloud Findings

Cloud finding severity is determined by a combination of the potential impact of exploitation and the exploitability of the misconfiguration:

Critical — Direct path to data breach or account compromise with minimal attacker effort. No authentication barrier between attacker and impact.

Examples:

• S3 bucket with public read/write access containing production data
• IAM policy with "*" action and "*" resource attached to a role that has internet-reachable execution
• Azure Storage Account with public blob access enabled and no Shared Access Signature requirement
• RDS instance publicly accessible with no security group restriction and weak password

High — Significant risk that requires one additional step (social engineering, phishing, or a separate vulnerability) to reach full impact. Or: a configuration that is demonstrably unsafe but requires some context to exploit.

Examples:

• Security group allowing inbound SSH (port 22) from 0.0.0.0/0
• IAM root account used for daily operations (no MFA)
• Azure AD account without MFA enrolled (admin-level user)
• GCP service account key older than 90 days still active
• CloudTrail logging not enabled — removes visibility after a compromise

Medium — Defense-in-depth failures, missing logging, or configurations that amplify the impact of another exploit. Not directly exploitable in isolation.

Examples:

• EBS volume unencrypted (attacker needs AWS account access to exploit)
• VPC flow logs not enabled (reduces forensic capability)
• S3 server-side encryption not enabled
• Azure Key Vault soft delete disabled
• Lambda function without VPC attachment (network isolation missing)

Low — Best practice deviations, minor hardening gaps, or informational issues with very low exploitation probability.

Examples:

• CloudWatch metric filter not configured for specific API calls
• S3 access logging not enabled
• Minor version auto-upgrade disabled for RDS
• GCP instance running OS with known but low-severity CVEs

Finding Lifecycle

Findings move through three states:

1. Open — Active issue, not yet addressed
2. Remediated — The resource configuration was fixed; ThreatWeaver verified the fix on the next scan
3. Accepted — Your team reviewed and accepted the risk (with a mandatory reason and review date)

When a resource configuration changes to comply with the security rule, ThreatWeaver automatically transitions the finding to Remediated on the next scan cycle. There is no manual remediation confirmation required — the scanner is the source of truth.

Finding Categories

Cloud findings are organized into six categories to help analysts focus by theme:

Category	Description	Example Findings
Public Exposure	Resources directly reachable from the internet without authentication	Public S3 buckets, open security groups, public RDS endpoints
Over-Permissioned Access	IAM roles, policies, or service principals with more access than required	Wildcard IAM policies, root account used daily, Editor roles on service accounts
Unencrypted Storage	Data at rest without encryption	Unencrypted EBS volumes, S3 buckets without SSE, unencrypted SQL database storage
MFA and Authentication Gaps	Missing multi-factor authentication or weak authentication configurations	Admin users without MFA, root account without MFA, Azure AD admins without Conditional Access
Network Exposure	Network configurations that unnecessarily expand the attack surface	Default VPC in use, overly broad NACLs, firewall rules allowing all traffic
Audit and Logging Gaps	Missing or inadequate logging that reduces forensic visibility	CloudTrail disabled, VPC flow logs disabled, Azure Monitor retention too short

---

Compliance Benchmarking

The Compliance page (/cloud/compliance) shows how your cloud environments measure against industry security frameworks.

Supported Frameworks

Framework	Providers	Description
CIS AWS Foundations Benchmark	AWS	58 controls covering IAM, logging, networking, and monitoring
CIS Microsoft Azure Foundations Benchmark	Azure	75 controls for Azure identity, storage, database, and networking
CIS Google Cloud Platform Foundation Benchmark	GCP	63 controls for GCP IAM, networking, VMs, and logging
SOC 2	AWS, Azure, GCP	Maps cloud findings to SOC 2 Trust Service Criteria (CC6, CC7, CC8)

Reading a Benchmark Score

Each benchmark shows:

• Overall Score — percentage of controls passing (e.g., "74/100 controls passing = 74%")
• Controls by Status — Passed / Failed / Not Applicable
• Failed Controls — Drilled down by control section (e.g., "Section 2: Storage" has 4 failing controls)
• Control Detail — For each failed control: the specific rule, affected resources, and remediation steps

A score of 100% means every assessed control passed. Not Applicable controls are excluded from the denominator (e.g., if a CloudTrail control checks for encryption of a trail that doesn't exist, the control is marked N/A rather than failed).

Compliance Score vs. Actual Risk

A high compliance score does not mean zero risk. CIS Benchmarks are a good baseline, but they do not cover every possible misconfiguration. Always review the Findings page alongside compliance scores.

---

Container Security

The Container Inventory (/cloud/containers) inventories running containers discovered across connected cloud providers.

What Gets Inventoried

• ECS (AWS) — Tasks and containers in ECS clusters, with image, tag, task definition version, and cluster name
• EKS (AWS) — Pods running in EKS node groups, with namespace, deployment name, and node details
• AKS (Azure) — Pods and containers in Azure Kubernetes Service clusters
• ACI (Azure) — Standalone container instances
• GKE (GCP) — Pods in Google Kubernetes Engine clusters with workload metadata

Container Inventory Table

Column	Description
Container Name	Name of the container within its runtime
Image	Container image name
Tag	Image tag (latest, specific version, or digest)
Status	Running, Stopped, or Paused
Runtime	Container runtime (docker, containerd, cri-o)
Cluster	Kubernetes cluster or ECS cluster name
Namespace	Kubernetes namespace
Critical Vulns	Count of Critical severity vulnerabilities in the running image
High Vulns	Count of High severity vulnerabilities
Total Vulns	Total vulnerability count across all severities

Container Image Scanning Scope

The container inventory shows vulnerabilities in running container images as reported by the cloud provider's own vulnerability scanning service (e.g., AWS ECR image scanning, Azure Defender for Containers). ThreatWeaver does not independently scan container images — it reads and surfaces the cloud provider's findings. If you have not enabled image scanning in your cloud provider, vulnerability counts will be zero.

---

Integration with WeaverScore

Cloud Security findings are not siloed — they flow into the main ThreatWeaver exposure management dashboard and influence WeaverScore for affected assets.

How Cloud Risk Feeds the Score

When ThreatWeaver discovers a cloud resource finding, it:

1. Looks up whether the cloud resource is linked to any asset in the exposure management asset inventory (matching by IP address, hostname, or resource ARN/ID)
2. If a match is found, the cloud finding's severity is translated into a risk signal and added to the asset's WeaverScore computation
3. Assets with linked cloud findings appear in the main dashboard with a "Cloud Risk" signal alongside their vulnerability data

This means an EC2 instance with an open RDP security group rule will show elevated risk in the exposure dashboard — not just in the Cloud Security module. Analysts working the main vulnerability queue will see it, even if they never open the Cloud Security page.

Cloud Risk Weight in WeaverScore

Cloud Finding Severity	WeaverScore Impact
Critical	+20 points to linked asset score
High	+12 points to linked asset score
Medium	+6 points to linked asset score
Low	+2 points to linked asset score

These boosts stack if multiple cloud findings affect the same asset. The WeaverScore maximum remains capped at 100.

---

Setting Up the AWS Connector

Prerequisites

• AWS account with permissions to create IAM roles and policies
• ThreatWeaver admin access in the Cloud Security module

Step 1: Create the IAM Role in AWS

Open the AWS IAM console and navigate to Roles > Create Role.

1. Trusted entity type: Select "AWS account"
2. Account ID: Enter the ThreatWeaver scanning service account ID (visible in the ThreatWeaver connector setup UI)
3. External ID: Copy the external ID from ThreatWeaver's connector setup — this prevents confused deputy attacks
4. Click Next

Step 2: Attach the Required Policies

On the permissions screen, attach these two AWS managed policies:

arn:aws:iam::aws:policy/SecurityAudit
arn:aws:iam::aws:policy/ReadOnlyAccess

• SecurityAudit grants access to security-relevant describe and list APIs across most services
• ReadOnlyAccess fills gaps in services not covered by SecurityAudit

Why Both Policies?

SecurityAudit alone does not cover every API call ThreatWeaver needs. For example, cloudtrail:GetTrailStatus, kms:ListAliases, and config:DescribeConfigurationRecorders require SecurityAudit, but some S3 control plane APIs require ReadOnlyAccess. Using both managed policies ensures complete coverage without crafting a custom policy.

Step 3: Name and Create the Role

• Role name: ThreatWeaverScanner (or any name your organization prefers)
• Description: "Read-only role for ThreatWeaver CSPM scanning"
• Review and click Create role
• Copy the Role ARN — you will need this in ThreatWeaver

Step 4: Configure the Connector in ThreatWeaver

1. Open ThreatWeaver → Cloud Security → Settings (or navigate directly to /cloud/settings)
2. Click Add Connector → Select AWS
3. Enter:
   • Connector Name: A human-readable label (e.g., "AWS Production")
   • Role ARN: Paste the IAM role ARN from Step 3
   • External ID: Already pre-filled from ThreatWeaver
   • Regions: Select the AWS regions you want scanned (multi-select; select all for full coverage)
   • Scan Schedule: Choose how often to scan (every 4 hours recommended for production accounts)
4. Click Test Connection — ThreatWeaver will attempt to call sts:GetCallerIdentity and iam:ListUsers to verify access
5. If the test passes, click Save

Step 5: Trigger the First Scan

After saving, click Scan Now to run the first discovery pass immediately rather than waiting for the scheduled cycle. The initial scan of a large AWS account (thousands of resources) typically takes 10-20 minutes.

---

Setting Up the Azure Connector

Prerequisites

• Azure subscription with Global Administrator or Application Administrator role to create App Registrations
• ThreatWeaver admin access in the Cloud Security module

Step 1: Create an App Registration

1. Open the Azure Portal → navigate to Azure Active Directory (or Microsoft Entra ID)
2. Go to App Registrations → New Registration
3. Name: ThreatWeaverScanner
4. Supported account types: Single tenant (your directory only)
5. Click Register
6. Copy the Application (client) ID and Directory (tenant) ID — you need both

Step 2: Create a Client Secret

1. In your App Registration, navigate to Certificates & Secrets → Client Secrets
2. Click New client secret
3. Description: "ThreatWeaver CSPM access"
4. Expires: Set to 12 or 24 months (you will rotate this before expiry)
5. Click Add and immediately copy the Secret Value — it is only shown once

Step 3: Assign the Reader Role

1. Navigate to your Azure Subscription
2. Go to Access Control (IAM) → Add role assignment
3. Role: Reader
4. Members: Search for ThreatWeaverScanner (the App Registration you created)
5. Click Review + Assign

For multi-subscription coverage, repeat this role assignment at the Management Group level instead.

Step 4: Grant Microsoft Graph Permissions (for Entra ID data)

1. Return to the App Registration → API Permissions
2. Click Add a permission → Microsoft Graph → Application permissions
3. Add the following permissions:
   • Directory.Read.All — reads users, groups, and directory objects
   • Policy.Read.All — reads Conditional Access policies
4. Click Grant admin consent — a Global Administrator must approve this step

Step 5: Configure the Connector in ThreatWeaver

1. Open ThreatWeaver → Cloud Security → Settings → Add Connector → Azure
2. Enter:
   • Connector Name: e.g., "Azure Production"
   • Tenant ID: Directory (tenant) ID from Step 1
   • Client ID: Application (client) ID from Step 1
   • Client Secret: Secret value from Step 2
   • Subscription IDs: Enter one or more subscription IDs to scan
3. Click Test Connection
4. If the test passes, click Save and trigger the first scan

---

Setting Up the GCP Connector

Prerequisites

• GCP project with permission to create service accounts and assign IAM roles
• ThreatWeaver admin access in the Cloud Security module

Step 1: Create a Service Account

Open the GCP Console → IAM & Admin → Service Accounts → Create Service Account

• Service account name: threatweaver-scanner
• Service account ID: threatweaver-scanner (auto-populated)
• Description: "Read-only service account for ThreatWeaver CSPM"
• Click Create and Continue

Step 2: Assign Required Roles

Assign these roles to the service account at the project level (or organization level for multi-project coverage):

Role	Purpose
roles/viewer	Basic read access across all GCP services
roles/iam.securityReviewer	Read IAM policies, service accounts, and bindings
roles/cloudasset.viewer	Access Cloud Asset Inventory API for bulk resource enumeration
roles/logging.viewer	Read Cloud Logging for audit log checks

Click Continue → Done

Step 3: Create a JSON Key

1. Click on the newly created service account → Keys tab
2. Add Key → Create new key → JSON
3. The JSON key file downloads automatically — store it securely
4. Note: Never commit this key file to source control

Step 4: Configure the Connector in ThreatWeaver

1. Open ThreatWeaver → Cloud Security → Settings → Add Connector → GCP
2. Enter:
   • Connector Name: e.g., "GCP Production"
   • Project IDs: One or more GCP project IDs to scan
   • Service Account Key: Paste the JSON key content (or upload the file)
3. Click Test Connection
4. If the test passes, click Save and trigger the first scan

---

Interpreting Cloud Findings for Security Analysts

"S3 Bucket Public Access Not Blocked"

What it means: The bucket's Block Public Access settings are not fully enabled, meaning bucket policies or ACLs could potentially make objects publicly accessible. This does not necessarily mean data is public right now — it means the guardrail that prevents accidental public exposure is off.

Risk: If a developer adds a permissive bucket policy or a misconfigured ACL, the bucket could become public without any further change to Block Public Access settings.

Remediation: In the S3 console, select the bucket → Permissions → Block Public Access → enable all four options. Alternatively, use the CLI:

aws s3api put-public-access-block \
  --bucket YOUR_BUCKET_NAME \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

"Security Group Allows Unrestricted Inbound on Port 22"

What it means: A security group rule has source 0.0.0.0/0 (all IPv4) or ::/0 (all IPv6) on port 22. This means any machine on the internet can attempt an SSH connection to instances in this security group.

Risk: Exposed SSH is the single most common attack vector for cloud VMs. Brute force, credential stuffing, and known SSH daemon vulnerabilities all require connectivity to port 22.

Remediation: Restrict the source to your organization's IP ranges or a VPN endpoint. If direct SSH is required, use AWS Systems Manager Session Manager as a VPN-free alternative that eliminates port 22 exposure entirely.

"IAM Root Account Used in Last 30 Days"

What it means: The AWS root account (the email address used to create the AWS account) has been logged into recently. The root account bypasses all IAM permission boundaries and cannot be restricted.

Risk: Root account compromise gives complete, unrevokable access to every resource in the account. This is the "keys to the kingdom" finding.

Remediation: Enable MFA on the root account immediately. Create IAM users or roles for all administrative tasks. Do not use root credentials for day-to-day operations under any circumstances.

"Azure Storage Account Allows Public Blob Access"

What it means: The storage account property allowBlobPublicAccess is set to true, allowing individual containers within the storage account to be made publicly accessible.

Risk: A developer creating a blob container could accidentally (or intentionally) set it to public. Unlike S3's Block Public Access, Azure's setting is per-storage-account, not per-container.

Remediation: Set allowBlobPublicAccess to false at the storage account level:

az storage account update \
  --name YOUR_STORAGE_ACCOUNT \
  --resource-group YOUR_RESOURCE_GROUP \
  --allow-blob-public-access false

"GCP Default Network In Use"

What it means: A GCP project is using the automatically-created default VPC network, which comes with pre-configured firewall rules that allow SSH (22) and RDP (3389) from any source and unrestricted internal traffic.

Risk: Teams often add resources to the default network for convenience. The permissive default firewall rules mean every compute resource in the project is reachable via SSH/RDP from the internet by default.

Remediation: Create a custom VPC network with explicit firewall rules. Migrate existing resources to the custom network and delete the default network.

"CloudTrail Not Enabled in All Regions"

What it means: AWS CloudTrail is either not enabled, or is enabled only in specific regions rather than all regions. API call logging — the primary audit trail for AWS accounts — has gaps.

Risk: Without CloudTrail, you cannot answer "who did what and when?" after a security incident. This finding is a forensics gap rather than a direct attack vector.

Remediation: Create a multi-region trail that covers all regions and delivers logs to an S3 bucket with server-side encryption and log file validation enabled.

---

Common Sales and Customer Questions

"We already use a cloud provider's native security tools — why do we need ThreatWeaver's Cloud Security module?"

Native tools (AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center) are excellent at detecting issues within their own environment. ThreatWeaver's value is in unification and correlation. Your security analyst using ThreatWeaver sees cloud findings, vulnerability scanner data, identity risks, and AppSec scan results in one console, with a single prioritization score. They do not need to switch between four different portals and mentally correlate results.

Additionally, ThreatWeaver's WeaverScore propagates cloud risk into the main vulnerability management dashboard. A vulnerable EC2 instance with an exposed security group gets a higher remediation priority than the same vulnerability on a fully isolated server. Cloud context changes remediation urgency — and ThreatWeaver makes that visible.

"Does ThreatWeaver need write permissions to our cloud account?"

No. ThreatWeaver uses strictly read-only API access. It cannot modify, delete, or create any cloud resource. The IAM role/service principal/service account created for ThreatWeaver will only ever read configuration data.

"How does ThreatWeaver handle multi-account AWS organizations?"

Each AWS account requires a separate connector in ThreatWeaver. If you have an AWS Organization with 20 member accounts, you would create 20 connectors, each with a role ARN in the respective account. For efficient setup, you can use AWS CloudFormation StackSets to deploy the IAM role to all member accounts simultaneously, then register the ARNs in ThreatWeaver.

"How often does ThreatWeaver scan cloud resources?"

The default scan interval is every 4 hours. You can configure this per connector — more frequently (hourly) for production accounts with active change management, or less frequently (daily) for stable environments. You can also trigger on-demand scans at any time via the UI or API.

"What happens when we fix a finding? Does it auto-resolve?"

Yes. On the next scan cycle after a finding's underlying misconfiguration is corrected, ThreatWeaver will re-evaluate the resource and automatically transition the finding to Remediated status. You do not need to manually mark findings as fixed. If the fix is reverted in a later change, the finding will re-open.

"Is ThreatWeaver's Cloud Security module a replacement for a dedicated CNAPP?"

No, and we are transparent about this. ThreatWeaver's Cloud Security module provides CSPM (configuration posture management). It does not provide Cloud Workload Protection (CWPP), runtime threat detection, container image scanning from registries, Kubernetes admission control, or infrastructure-as-code scanning. Organizations with mature cloud programs may use a dedicated CNAPP alongside ThreatWeaver. In that scenario, ThreatWeaver's value is as the unified exposure management layer that aggregates risk signals from multiple specialized tools.

"Can ThreatWeaver scan our private cloud or data center resources?"

Not through the Cloud Security module. Cloud Security is specifically for AWS, Azure, and GCP managed services. On-premises infrastructure is addressed through the Exposure Management module (Tenable.io sync) and the AppSec Scanner module for web applications.

---

Module Limitations

Understanding what ThreatWeaver Cloud Security does not do is as important as understanding what it does. Be direct about these limitations with customers.

Limitation	Detail
No real-time monitoring	Cloud resource scans run on a polling schedule (minimum 1 hour). A misconfiguration that is created and fixed between scan cycles will not appear in findings. For real-time detection, consider AWS Security Hub or Azure Defender, which receive event-driven notifications
No auto-remediation	ThreatWeaver identifies problems but does not fix them. All remediation is manual or through external automation (e.g., Lambda functions triggered by findings via webhook)
No IaC scanning	Terraform, CloudFormation, Bicep, and Pulumi templates are not analyzed. Only deployed runtime configurations are assessed. IaC scanning requires a separate tool (e.g., Checkov, tfsec)
No container image registry scanning	ThreatWeaver surfaces vulnerability data from cloud-provider image scanning (where enabled), but does not independently scan images in ECR, ACR, or Artifact Registry
No runtime threat detection	ThreatWeaver does not analyze runtime behavior (network traffic, system calls, process activity). It is a configuration scanner, not a threat detection platform
No Kubernetes admission control	ThreatWeaver cannot enforce security policies at pod admission time. It assesses existing cluster configurations but does not prevent non-compliant workloads from being deployed
No multi-account AWS org native support	Each AWS account requires a separate connector. Bulk organization-wide registration is manual (or scriptable) but not yet automated through AWS Organizations APIs
Single-subscription Azure	Each Azure connector covers one subscription. Management Group-level scanning requires registering each subscription individually
Compliance frameworks limited to CIS and SOC 2	PCI DSS, HIPAA, ISO 27001, FedRAMP, and NIST 800-53 are not currently mapped. Organizations with these compliance requirements need to cross-reference CIS findings manually or use a dedicated GRC tool

---

Related Pages

• AWS Setup Guide — Detailed step-by-step AWS connector setup with IAM policies and troubleshooting
• WeaverScore — How cloud findings feed into the overall risk score
• Exposure Management Overview — The main vulnerability management module
• Identity Security — Identity risk and attack path analysis