-
Notifications
You must be signed in to change notification settings - Fork 585
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
197b847
commit eb169a4
Showing
329 changed files
with
11,227 additions
and
989 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
40 changes: 40 additions & 0 deletions
40
docs/versioned_docs/version-v2.3/architecture/cloudscanner.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| --- | ||
| title: Cloud Scanner task | ||
| --- | ||
|
|
||
| # Cloud Scanner Overview | ||
|
|
||
| ThreatMapper performs Compliance Posture Scanning to: | ||
|
|
||
| * Build an inventory of cloud assets, such as network security groups, storage objects, key management services. The types of assets discovered are specific to each cloud platform. | ||
| * Perform 'posture scanning', where ThreatMapper matches infrastructure configuration against a set of best-practice benchmarks, such as CIS, PCI-DSS and HIPAA. The benchmarks that are supported are specific to each cloud platform. | ||
|
|
||
| ThreatMapper then summarises the results in a 'Threat Graph' visualization, to help you to prioritize compliance issues that pose the greatest risk of exploit. | ||
|
|
||
| ## Implementation | ||
|
|
||
| * Compliance Posture Scanning for **Clouds** requires access (typically read-only) to the cloud platform APIs, and uses the Cloud Scanner task | ||
| * Compliance Posture Scanning for **Hosts** requires direct access to the host, and uses the Sensor Agent. | ||
|
|
||
| ### Compliance Posture Scanning for Clouds | ||
|
|
||
| The ThreatMapper Console does not access the cloud platform APIs directly; there is no need to open the APIs up for remote access. Instead, you deploy a 'Cloud Scanner' task which acts as a local relay, taking instructions from the remote ThreatMapper console and performing local API calls from within your cloud infrastructure. | ||
|
|
||
| Each Cloud Scanner task runs in your cloud environment, gathering inventory and compliance information for the assets deployed in that environment. It submits that information to your ThreatMapper console. You can deploy as many Cloud Scanner tasks as are required by your security policy and any restrictions in place that affect API access. | ||
|
|
||
| Cloud Scanner tasks are deployed using the appropriate Terraform module for each cloud, and are configured with the address and API key of your management console. They 'phone home' to your management console and take instructions on demand; they do not listen for remote connections or control. | ||
|
|
||
| :::info | ||
| Refer to the Installation Documentation to [Learn how to install Cloud Scanner tasks](/docs/cloudscanner) | ||
| ::: | ||
|
|
||
|
|
||
| ### Compliance Posture Scanning for Hosts | ||
|
|
||
| ThreatMapper can perform compliance posture scanning on linux hosts and Kubernetes master and worker nodes. | ||
|
|
||
| Scanning is done directly, using a local [Sensor Agent](sensors) rather than by using the Cloud Scanner task employed by the cloud platform integrations. | ||
|
|
||
|
|
||
|
|
||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| --- | ||
| title: Management Console | ||
| --- | ||
|
|
||
| # The ThreatMapper Management Console | ||
|
|
||
| The ThreatMapper Management Console ("Console") is a standalone application, implemented as a fleet of containers. It should be deployed on either a single docker host, or (for larger deployments) a dedicated Kubernetes cluster. The console is self-contained, and exposes an HTTPS interface for administration and API automation. | ||
|
|
||
| The console allows you to: | ||
|
|
||
| * Manage the users who can access the console. | ||
| * Configure Infrastructure API access and interrogate platform configurations. | ||
| * Visualize and drill down into Kubernetes clusters, virtual machines, containers and images, running processes, and network connections in near real time. | ||
| * Invoke vulnerability scans on running containers and applications and review the results, ranked by risk-of-exploit. | ||
| * Invoke compliance scans on infrastructure configuration ('agentless') and on infrastructure hosts ('agent-based'), manually or automatically when they are added to a cluster. | ||
| * Scan container registries for vulnerabilities, to review workloads before they are deployed. | ||
| * Scan image builds during the CI/CD pipeline, supporting CircleCI, Jenkins, and GitLab. | ||
| * Scan containers and host filesystems for unprotected secrets, including access tokens, keys and passwords. | ||
| * Configure integrations with external notification, SIEM and ticketing systems, including Slack, PagerDuty, Jira, Splunk, ELK, Sumo Logic, and AWS S3. | ||
| ThreatMapper supports multiple production deployments simultaneously, so that you can visualize and scan workloads across a large production estate. | ||
|
|
||
| ### ThreatMapper Compliance Posture Scanning | ||
|
|
||
| ThreatMapper performs compliance posture scanning for cloud platforms by querying the infrastructure APIs for these platforms. | ||
|
|
||
| This is achieved using a **cloud scanner** task that is deployed within each cloud instance using a terraform module. The cloud scanner is granted appropriate access to the local APIs, and operates under instruction from the remote ThreatMapper console. | ||
|
|
||
| ### ThreatMapper Registry Scanning | ||
|
|
||
| The ThreatMapper console can scan container images at rest in a wide range of supported registries. | ||
|
|
||
| This is achieved by providing appropriate credentials to the ThreatMapper console so that it can discover and download assets directly from these registries. | ||
|
|
||
| ### ThreatMapper Vulnerability, Secret and Local Compliance Scanning | ||
|
|
||
| ThreatMapper performs vulnerability and secret scanning directly on production and non-production hosts using a **sensor agent** container. | ||
|
|
||
| The sensor agent is also used for local compliance scanning (Kubernetes and Linux posture) where it has access to configuration and assets that are not exposed through an API. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| --- | ||
| title: ThreatMapper Architecture | ||
| --- | ||
|
|
||
| # ThreatMapper Architecture | ||
|
|
||
| The ThreatMapper product consists of a Management Console, and multiple Sensor Agents and Cloud Scanner tasks that are deployed within your production platform(s). | ||
|
|
||
|  | ||
|
|
||
| The Management Console is deployed first. The Management console generates an API key and a URL which you will need when you install the Sensor containers and Cloud Scanner tasks. | ||
|
|
||
| The Management Console is managed over TLS (port 443), used for administrative traffic (web browser and API) and for sensor traffic. You should firewall or secure access to this port so that only authorised admin users and remote production platforms are able to connect. | ||
|
|
||
| # Agent-Less and Agent-Based operation | ||
|
|
||
| ThreatMapper uses both agent-less and agent-based operations to discover the widest-possible range of threats and render them in 'Threat Graphs' and 'Threat Maps'. You can use either or both operations, and can configure their access to your production and non-production systems in line with your own security posture. | ||
|
|
||
| | | Agent-Less (Cloud Connector) | Agent-Based (Sensor Agent) | | ||
| |----------------|----------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------| | ||
| | Implementation | Direct access to infrastructure APIs, using a secured **Cloud Connector** task, deployed local to the cloud instance | Lightweight, privileged **sensor agent** container with access to local resources on the host | | ||
| | Visibility | Cloud configuration and assets, as exposed through cloud or infrastructure API | Local assets, including filesystem, process list, local containers and pods, and kernel interfaces | | ||
| | Capability | Identifies deviation from good practice configuration ("Compliance Scanning") for cloud platforms | Identifies network flows and performs vulnerability, secret and local host (Linux/Kubernetes) compliance scanning | | ||
| | Output | Agent-less data is reported in the 'Threat Graph', which shows compliance-related issues | Agent-based data is reported in the Threat Map (for vulnerabilities, secrets etc) and Threat Graph (for compliance issues) | | ||
|
|
||
|
|
||
|
|
||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| --- | ||
| title: Sensor Agent | ||
| --- | ||
|
|
||
| # Sensor Agent | ||
|
|
||
| ThreatMapper Sensors are deployed on your production platforms, directly on each production host. They are deployed in the form of a privileged container (the 'Sensor Agent'). They communicate securely with your ThreatMapper Management Console, taking instructions to retrieve SBOMs and run scans, and forwarding telemetry data. | ||
|
|
||
| The sensors support the following production platforms: | ||
|
|
||
| * **Kubernetes:** The sensors are deployed as a daemonset, similar to other kubernetes services. | ||
| * **Docker:** The sensor is deployed as a docker container on each docker host. | ||
| * **Bare metal and VM-based platforms:** Sensors are deployed as a Docker container on each Linux operating system instance, using a Docker runtime. Linux instances are supported; Windows Server is not supported, although an experimental implementation is available. | ||
| * **AWS Fargate** The sensor is deployed as a daemon service alongside each serverless instance. | ||
|
|
||
| :::info | ||
| Refer to the Installation Documentation to [Learn how to install Sensor Agents](/docs/sensors) | ||
| ::: |
Oops, something went wrong.