Skip to content

docs: update Infrastructure Discovery to match current product scope #2085

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
masteredd wants to merge 1 commit into from
Closed

docs: update Infrastructure Discovery to match current product scope #2085

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 10 additions & 5 deletions docs/latest/infrastructure-discovery/exploring.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,22 +26,22 @@ Click any row to open the resource detail view, which collects everything Infras

### Findings

A **finding** is a security issue Wallarm spotted on one of your resources — for example, an EC2 instance with a public IP, an SSH port open to the world, or an EKS cluster with a public API endpoint.
A **finding** is a security issue spotted on one of your resources — for example, an EC2 instance with a public IP, an SSH port open to the world, or an EKS cluster with a public API endpoint.

Each finding tells you what the issue is, how serious it is (Critical to Info), which resource it affects, and how to fix it. Findings from AWS Security Hub appear in the same list, alongside Wallarm's own.
Each finding tells you what the issue is, how serious it is (Critical to Info), which resource it affects, and how to fix it. Findings come from multiple sources: Wallarm's own built-in rules, AWS Security Hub, Amazon GuardDuty, Amazon Inspector, and IAM Access Analyzer. Each finding carries a **source** badge so you can tell where it originated.

The **Findings** sub-tab is where you browse them. Filter by severity, status, or source. Switch between **by finding** and **by rule** views to look at the issues themselves or at the rules producing them.

![Findings sub-tab](../images/infrastructure-discovery/findings.png)

!!! info "AWS Security Hub findings"
If you use AWS Security Hub, Infrastructure Discovery imports its findings and correlates them with the resources it has discovered. Imported findings keep their original product attribution and appear alongside Wallarm's own findings. No extra configuration is required beyond the [Security Hub permissions](setup.md#required-aws-permissions) in the connected account's policy.
!!! info "AWS security service findings"
Infrastructure Discovery imports findings from **AWS Security Hub**, **Amazon GuardDuty**, **Amazon Inspector**, and **IAM Access Analyzer**, and correlates them with discovered resources. Imported findings keep their original product attribution and appear alongside Wallarm's own findings. No extra configuration is required beyond the [read-only permissions](setup.md#required-aws-permissions) in the connected account's policy — Infrastructure Discovery detects which services are enabled in your account and pulls findings automatically.

#### Finding details and blast radius

Click any finding to open its detail view, which shows:

* The **severity**, the **source** (and the AWS Security Hub product, if imported), a plain-language **explanation**, and a recommended **fix**
* The **severity**, the **source** (Wallarm, Security Hub, GuardDuty, Inspector, or Access Analyzer), a plain-language **explanation**, and a recommended **fix**
* The **rule** that produced the finding
* The **affected asset** — name, type, service, region, account, and ARN
* **Connections** — the resources directly related to the affected asset, with their relationship types (for example, `associated_with_eni`)
Expand Down Expand Up @@ -91,6 +91,11 @@ Built-in rules check for common issues such as:
* Internet-facing load balancers
* Load balancer listeners that serve HTTP without redirecting to HTTPS
* EKS clusters with a public API endpoint or without secrets encryption
* S3 buckets with public access or without encryption
* RDS instances without encryption at rest or with public accessibility
* KMS keys with overly permissive policies or disabled rotation
* Secrets Manager secrets without rotation configured
* IAM users and roles with overly permissive policies
* Deletion of critical infrastructure resources
* Misconfigured or stale Amazon Bedrock resources, such as agents without instructions or knowledge bases without storage

Expand Down
29 changes: 25 additions & 4 deletions docs/latest/infrastructure-discovery/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ Modern cloud environments grow organically: teams spin up resources across multi
* **Relationship mapping** — a graph view showing how resources connect to each other (e.g. which EC2 instances sit behind which load balancers, which security groups are attached to which ENIs).
* **Exposure detection** — automatically flags resources reachable from the internet: instances and load balancers with public IPs, security groups with sensitive ports open to `0.0.0.0/0`, EKS clusters with public API endpoints, and similar patterns.
* **Security posture analysis** — built-in rules that automatically evaluate resource configurations against security best practices, flag vulnerable setups, and surface findings with severity levels. Policies let you tune how findings are handled for your environment.
* **AWS-native finding aggregation** — imports AWS Security Hub findings (Amazon GuardDuty, Amazon Inspector, IAM Access Analyzer, and more) and correlates them with discovered resources, so all findings live in one place.
* **AWS-native finding aggregation** — imports findings from AWS Security Hub, Amazon GuardDuty, Amazon Inspector, and IAM Access Analyzer and correlates them with discovered resources, so all security signals live in one place.
* **Impact analysis** — a blast radius view for each finding that shows which connected resources could be affected, helping you prioritize remediation.
* **Change tracking** — comparison of successive scans highlighting created, updated, and deleted resources so you can spot unintended configuration changes.
* **Creator attribution** — for each asset, Infrastructure Discovery looks up the IAM principal that created it from your CloudTrail history, so every asset record carries an answer to "who made this change?".
Expand All @@ -40,19 +40,40 @@ Infrastructure Discovery inventories resources from the following AWS services:

| AWS service | Examples of discovered resources |
| --- | --- |
| **EC2** | Instances |
| **VPC networking** | VPCs, subnets, route tables, internet gateways, NAT gateways, security groups, network interfaces (ENIs), elastic IPs, VPC peering connections, transit gateways |
| **EC2** | Instances, volumes, snapshots, network interfaces (ENIs) |
| **VPC networking** | VPCs, subnets, route tables, internet gateways, NAT gateways, security groups, elastic IPs, VPC peering connections, transit gateways and attachments |
| **Elastic Load Balancing** | Application, Network, and Gateway Load Balancers; target groups; listeners and listener rules |
| **EKS** | Clusters, node groups, Fargate profiles |
| **Lambda** | Functions, layers |
| **API Gateway** | REST APIs, HTTP APIs, stages, VPC links |
| **Route53** | Public and private hosted zones, record sets |
| **CloudFront** | Distributions |
| **S3** | Buckets (metadata, policies, encryption and access settings — no object-level access) |
| **RDS** | DB instances, DB clusters, DB snapshots, DB cluster snapshots |
| **DynamoDB** | Tables |
| **ElastiCache** | Cache clusters, replication groups |
| **Redshift** | Clusters, snapshots |
| **ECS** | Clusters, services, tasks, task definitions |
| **ECR** | Repositories |
| **EFS** | File systems |
| **IAM** | Roles, users, groups, policies, access keys |
| **KMS** | Keys (metadata and rotation status — no access to key material) |
| **Secrets Manager** | Secrets (metadata and resource policies — no access to secret values) |
| **ACM** | Certificates |
| **SSM** | Documents, managed instances |
| **SNS** | Topics |
| **SQS** | Queues |
| **WAF** | Web ACLs (WAFv2 regional and CloudFront scopes) |
| **Amazon Bedrock** | Foundation models, custom models, provisioned throughput, agents, knowledge bases |

For each discovered asset, Infrastructure Discovery also queries **AWS CloudTrail** to find the earliest recorded event and surface the IAM principal that created the resource.

In addition to inventorying resources, Infrastructure Discovery imports existing **AWS Security Hub** findings and correlates them with the resources it discovers, so that third-party security signals appear alongside Wallarm's own findings.
In addition to inventorying resources, Infrastructure Discovery imports findings from the following AWS security services and correlates them with discovered resources, so that all security signals appear in one place:

* **AWS Security Hub** — aggregated ASFF findings from all enabled integrations
* **Amazon GuardDuty** — threat intelligence findings
* **Amazon Inspector** — vulnerability findings
* **IAM Access Analyzer** — external access findings

!!! info "Expanding coverage"
The list of supported services and cloud providers is expanding. If you need coverage for a service not listed here, contact [Wallarm Sales](mailto:sales@wallarm.com).
Expand Down
70 changes: 18 additions & 52 deletions docs/latest/infrastructure-discovery/setup.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,60 +49,26 @@ Both methods use the same read-only permissions and produce the same inventory.

#### Required AWS permissions

The following read-only IAM policy covers all supported resource types. With the [IAM Role method](#setup-with-iam-role), the CloudFormation template applies it automatically. With the [Access Key method](#setup-with-access-key), you need to attach this policy to the IAM user manually.


```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "WallarmInfraDiscoveryReadOnly",
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"elasticloadbalancing:Describe*",
"eks:List*",
"eks:Describe*",
"lambda:List*",
"lambda:GetFunction",
"lambda:GetPolicy",
"apigateway:GET",
"route53:List*",
"route53:Get*",
"iam:List*",
"iam:Get*",
"bedrock:List*",
"bedrock:Get*",
"cloudtrail:List*",
"cloudtrail:Get*",
"cloudtrail:Describe*",
"cloudtrail:LookupEvents",
"securityhub:GetFindings",
"securityhub:ListFindingAggregators",
"sts:GetCallerIdentity"
],
"Resource": "*"
}
]
}
```

For [multi-account setup](#multi-account-setup) via AWS Organizations, add the following permission to the management account role:

```json
{
"Sid": "WallarmInfraDiscoveryOrganizations",
"Effect": "Allow",
"Action": [
"organizations:ListAccounts"
],
"Resource": "*"
}
```
With the [IAM Role method](#setup-with-iam-role), the CloudFormation template creates the role and attaches all required policies automatically. With the [Access Key method](#setup-with-access-key), you need to attach these policies to the IAM user manually.

The CloudFormation template creates six managed policies grouped by area. Each policy grants read-only access and includes explicit **Deny** statements that block mutations and data-plane operations. The table below summarizes the permissions by area:

| Policy area | AWS services | Key actions |
| --- | --- | --- |
| **Compute** | API Gateway, EC2, ECR, ECS, EKS, Elastic Beanstalk, Lambda | `apigateway:GET`, `ec2:Describe*`, `ecr:Describe*`/`List*`/`Get*Policy`, `ecs:List*`/`Describe*`, `eks:List*`/`Describe*`, `elasticbeanstalk:Describe*`/`List*`, `lambda:List*`/`Get*` |
| **Database** | DynamoDB, ElastiCache, RDS, Redshift | `dynamodb:List*`/`Describe*`, `elasticache:Describe*`/`List*`, `rds:Describe*`/`ListTagsForResource`, `redshift:Describe*` |
| **Management** | Bedrock, CloudFormation, CloudTrail, CloudWatch, Config, EventBridge, Organizations, SNS, SQS, SSM, Step Functions, Tagging | `bedrock:List*`/`Get*`, `bedrock-agent:List*`/`Get*`, `cloudtrail:List*`/`Get*`/`Describe*`/`LookupEvents`, `organizations:List*`/`Describe*`, `sns:List*`/`Get*`, `sqs:List*`/`Get*`, `ssm:Describe*`/`List*`/`Get*`, `tag:Get*` |
| **Networking** | CloudFront, Elastic Load Balancing, Route53 | `cloudfront:List*`/`Get*`, `elasticloadbalancing:Describe*`, `route53:List*`/`Get*` |
| **Security** | Access Analyzer, ACM, GuardDuty, IAM, Inspector, KMS, Secrets Manager, Security Hub, Shield, WAF | `access-analyzer:List*`/`Get*`, `acm:List*`/`Describe*`/`Get*`, `guardduty:List*`/`Get*`/`Describe*`, `iam:List*`/`Get*`, `inspector2:List*`/`Get*`/`BatchGet*`/`Describe*`, `kms:List*`/`Describe*`/`GetKeyPolicy`/`GetKeyRotationStatus`, `secretsmanager:List*`/`Describe*`/`GetResourcePolicy`, `securityhub:Get*`/`List*`/`Describe*`, `wafv2:List*`/`Get*` |
| **Storage** | Backup, EFS, FSx, Glacier, S3 | `backup:List*`/`Describe*`/`Get*`, `elasticfilesystem:Describe*`, `s3:ListAllMyBuckets`/`GetBucket*`/`GetEncryptionConfiguration` |

Additionally, `sts:GetCallerIdentity` is used for account verification.

??? note "Full IAM policy JSON for manual setup"
If you prefer to create a single consolidated policy manually instead of using the CloudFormation template, include all read-only actions listed in the table above. The CloudFormation template is the recommended approach as it also sets up the trust policy and explicit Deny statements automatically.

!!! warning "No data-plane access"
Infrastructure Discovery does **not** request data-plane permissions. It will never access your data: no `s3:GetObject`, no `rds:*Data`, no log-reading, no `kms:Decrypt`. All collected information is resource metadata only (IDs, configurations, tags, relationships). All actions are read-only.
Infrastructure Discovery does **not** request data-plane permissions. It will never access your data: no `s3:GetObject`, no `rds:*Data`, no `kms:Decrypt`, no `secretsmanager:GetSecretValue`, no log-reading. The CloudFormation template includes explicit Deny statements blocking all mutation and data-plane operations. All collected information is resource metadata only (IDs, configurations, tags, relationships).

#### Setup with IAM Role

Expand Down