# What is Radiant Security? Radiant Security automates alert triage, investigation, and response so SOC teams can scale coverage without scaling headcount. Radiant is an AI-powered SOC platform that delivers deep, automated triage and response across your entire security stack, including the complex, multi-stage attacks that span multiple alerts and tools and that other solutions cannot handle. Radiant ingests alerts from your existing security tooling, runs them through an automated triage pipeline, and produces a verdict with full investigative context for analyst review. Radiant sits as an intelligent layer between your security tooling and your analysts. Alerts flow in from your SIEM, EDR, identity, cloud, and network sources. Radiant extracts the artifacts inside each alert, executes a structured triage plan, and assigns one of three verdicts: Recommended Benign, Likely Benign, or Recommended Malicious. Analysts review the verdict, accept or reject it, and create cases for the alerts that warrant further investigation and response. This article covers the [core architecture](#core-architecture), [how Radiant fits into your security stack](#how-radiant-fits-into-your-stack), the [integrations](#integrations) that connect Radiant to your existing tools, and [who uses Radiant](#who-uses-radiant). ### Core architecture Radiant is built around three integrated components: {% stepper %} {% step %} #### Agentic AI triage Radiant's AI triage and research agents investigate every incoming alert, with the depth and reasoning of a seasoned analyst. Every alert receives a complete investigation that produces a transparent, reviewable verdict, not just a score, and not a sampled subset of the queue. For a complete walkthrough of how alerts move through the pipeline, see [The Radiant Data Pipeline](https://help.radiantsecurity.ai/radiant-connectors/section-overview/the-radiant-data-pipeline). {% endstep %} {% step %} #### Integrated response Radiant includes a built-in case management layer where analysts review verdicts, group related alerts into cases, and execute response actions on the artifacts surfaced during triage — all without leaving the platform. Available response actions are determined by the tenant's active connectors and the artifact types involved. {% endstep %} {% step %} #### Log management Radiant includes a built-in security data lake that stores, indexes, and queries all your security logs in one place. Log Management is fully integrated with the triage pipeline (e.g., queries executed during Enrichment and Execution can pull from your indexed log data alongside data retrieved from connected tools), and remains available to analysts as a standalone search interface for investigation, threat hunting, and historical analysis. {% endstep %} {% endstepper %} ### How Radiant fits into your stack Radiant operates alongside your existing tools. The typical data flow: 1. Your SIEM, EDR, identity, network, and other security tools generate alerts as they normally would. 2. Radiant ingests those alerts in real time through connectors that support API pull, query APIs, webhooks, syslog, S3, and the [Radiant Security Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent). 3. Each alert enters the triage pipeline, where Radiant extracts artifacts, executes a plan against your connected tools and external threat intelligence sources, and assigns a verdict. 4. Verdicts are surfaced to analysts with the full triage record attached, including every task, question, and query that informed the verdict. 5. Analysts accept or reject the verdict, group related alerts into cases where appropriate, and trigger response actions. 6. Alerts assigned a benign verdict are documented with the reasoning that produced the verdict, preserving a complete audit trail. ### Integrations Radiant connects to your security stack through a broad library of connectors. Connectors support multiple ingestion methods, so Radiant can adapt to whatever your source systems already emit. See [Integrations](https://radiantsecurity.ai/integrations/) for the full catalog, or contact your customer success manager to request a new connector. ### Who uses Radiant Radiant is deployed by in-house SOC teams and MSSPs that need to scale their triage and response capacity without scaling headcount in proportion to alert volume. Common environments include: * SOC teams where alert volume exceeds the team's capacity to investigate manually. * Security organizations operating multiple point tools that fragment investigation and response work across separate consoles. * Teams whose SIEM ingestion costs are limiting the data they can collect or the retention windows they can maintain. * SOCs where analyst capacity is consumed by triaging benign alerts rather than responding to confirmed threats. * SOC teams that want a triage system that adapts and improves based on analyst feedback over time. # Key Differentiators How Radiant compares to other AI SOC platforms and legacy SIEM solutions across alert coverage, response, and log management. Radiant is built on a different premise than the tools most security teams rely on today. Legacy SIEM tools generate alerts and stop there. Most AI SOC platforms cover a fixed set of pre-trained scenarios. Radiant triages every alert across your connected sources: known threats, unknown threats, and everything in between, and produces a verdict for each one. This page compares Radiant against two categories of tools across three dimensions: alert coverage, response, and log management. ### Radiant versus other AI SOC platforms Most AI SOC platforms are trained on a fixed set of common alert scenarios. Outside those scenarios, they cannot investigate, and alerts either go unprocessed or fall back to analysts. Radiant takes a different architectural approach: rather than matching alerts to pre-built templates, the triage pipeline dynamically generates a plan for every alert, including alert types it has never seen before. | Capability | Other AI SOC platforms | Radiant | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Alert coverage | :xmark: Limited to 6–8 common pre-trained scenarios. | :check: Triages alerts from all connected sources. | | Novel threats | :xmark: Require retraining; cannot handle unknown attack patterns. | :check: Generates a new plan for any alert type, including ones not seen before. | | Platform consolidation | :xmark: Separate tools for triage, response, and log management. | :check: Unified platform for triage, response, and log management. | | Response actions | :xmark: Manual workflows across multiple tools. | :check: Single-click and fully automated response actions built into the platform. | | Pricing model | :xmark: Usage-based pricing produces unpredictable costs. | :check: Priced by security use case for predictable, transparent billing. | | Log storage cost | :xmark: Logs stored on the vendor's infrastructure with vendor-set pricing. | :check: Customers store logs in their own AWS S3 bucket and pay AWS directly, with no storage markup from Radiant. | ### Radiant versus traditional SIEM solutions Legacy SIEMs were designed to collect and correlate logs, not to investigate or respond to threats. They surface alerts through rule-based correlation and hand those alerts to analysts for manual triage. As environments grow, volume-based pricing forces teams to restrict data ingestion to control costs, which creates coverage gaps. The result is a platform that produces alert noise, constrains visibility, and requires additional tooling to finish workflows it was never built to complete. | Capability | Legacy SIEM solutions | Radiant | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Alert triage | :xmark: Manual triage of rule-based correlations that require ongoing tuning. | :check: Triages alerts automatically and produces a verdict with full investigative context. | | Data storage and retention | :xmark: Per-GB ingestion fees force data sampling and short retention windows. | :check: Customers store logs in their own AWS S3 bucket and pay AWS directly, with no storage markup from Radiant. See Bring your own bucket for Log Management. | | Response actions | :xmark: Alert generation only. Response requires separate tools and manual workflows. | :check: Single-click and fully automated response actions built into the platform. | | Adaptation to new threats | :xmark: Static rules require manual updates for new threat patterns. | :check: Generates new plans dynamically without retraining or rule updates. | | Security outcomes | :xmark: High false-positive rates and missed threats despite significant investment. | :check: Resolves benign alerts automatically and surfaces likely-malicious alerts to analysts, reducing mean time to respond (MTTR). | To learn how the triage pipeline produces a verdict for each alert, see the [Triage pipeline stages](/welcome-to-radiant/what-is-radiant-security/the-radiant-data-pipeline#triage-pipeline-stages). # The Radiant Data Pipeline A comprehensive overview of how security data flows through Radiant. The Radiant Data Pipeline is the engine behind Radiant's AI SOC Analyst, purpose-built to ensure 100% of security alerts are investigated, enriched, and triaged automatically. Every piece of security data ingested flows through a structured series of stages designed to eliminate noise and deliver only actionable signals to the security team. Radiant sits between your existing security tools and your analyst team. Rather than replacing your stack, it connects to it, ingesting alerts from every source, automatically investigating them with AI agents, and surfacing only confirmed threats to analysts for review and response. ### Pipeline architecture Radiant ingests 100% of security data from across the environment: alerts, events, and contextual information from every connected source. Every piece of this data remains fully accessible throughout the pipeline, giving the AI SOC Analyst the complete context needed to triage alerts with the same depth and rigor as a seasoned human analyst. #### Data Flow Stages There are four major functional stages of the Radiant pipeline, as well as the supported sub stages. Data flows from left to right, from your existing security tools through ingestion, processing, and AI-driven analysis, to response actions taken by your team.
{% stepper %} {% step %} #### **Data Connectors** * **Data ingestion:** Collection of security data via multiple integration methods, feeding it into the pipeline for AI triage. {% endstep %} {% step %} #### Data Fabric * **Data processing:** Minimal parsing to append Radiant-specific fields; syslog undergoes enhanced processing to optimize log structure for AI query and ensure the data is consistently structured for AI triage. * **Data indexing and storage:** Organization into purpose-built indexes for fast search, compliance, and AI triage availability. * **Alert filtering:** Definition of custom criteria (e.g., source/destination IP, hostname, username) to automatically exclude known benign or low-fidelity alerts from triage. * **Alert deduplication:** Contextual correlation to identify duplicate alerts and reduce noise. {% endstep %} {% step %} #### **Alert Triage** * **AI SOC Analyst:** Automated triage of every incoming alert, combining raw alert data, artifact enrichment, threat intelligence, dynamic plan execution and **human-in-the-loop** tuning into a contextualized, reviewable verdict. {% endstep %} {% step %} #### **Response** * **Case management:** Case creation to track, assign, and manage complex investigations that require deeper analysis beyond automated triage. * **Threat containment and response:** Active threats containment and remediation directly from a case with response actions. {% endstep %} {% endstepper %} ## Data Connectors ### Data ingestion Radiant Security ingests security telemetry and contextual data through a unified integration framework called [Data Connectors](/radiant-connectors/data-connectors), supporting 100+ plug-and-play connectors across diverse security infrastructure—from cloud-native APIs to on-premises syslog forwarders—with no custom parsers or manual configuration required for supported integrations. #### Security telemetry Alerts, event logs, and raw security data are ingested from your connected security tools and infrastructure. Each data connector method is optimized for specific use cases and data sources:
Persist APIs
TypeDescriptionStorage Behavior
PullDirect integrations that pull data from vendor API endpoints on an ongoing basis to retrieve logs, alerts, or contextual informationStored in Radiant-managed storage or customer S3 (BYOB)
Query APIs
TypeDescriptionStorage Behavior
PullAPI integrations that query for relevant data at the time of triage, retrieving information on-demandNot stored in Log Management; queried in real-time
Syslog
TypeDescriptionStorage Behavior
PushStandard protocol (UDP/TCP) used by systems and network devices to stream real-time log messages to RadiantStored in Radiant-managed storage or customer S3 (BYOB)
Webhooks
TypeDescriptionStorage Behavior
PushVendor-initiated HTTP callbacks that push events to Radiant instantly whenever new activity occursStored in Radiant-managed storage or customer S3 (BYOB)
Generic S3 Bucket
TypeDescriptionStorage Behavior
Push/PullS3-compatible cloud storage location where customers deposit raw log files that Radiant periodically retrieves and ingestsStored in Radiant-managed storage or customer S3 (BYOB)
Radiant Security Agent
TypeDescriptionStorage Behavior
PushLightweight software agent installed in customer environments to collect and forward raw logs from on-premises systems securelyStored in Radiant-managed storage or customer S3 (BYOB)
#### Contextual data Contextual data is ingested alongside security telemetry from the start of the pipeline, ensuring it is available when alerts reach the triage stage. Radiant draws from three categories of contextual data: 1. **Threat intelligence services** - external services queried during triage to determine whether an extracted artifact is known malicious or confirmed good, including file hashes, URLs, domains, and IPs. Sources include Malware Bazaar, Google WebRisk, FireHOL, Cisco Umbrella, and NSRL, among others. 2. **Context lists** - curated lists of artifacts classified as malicious or benign, maintained by Radiant's research team and retrieved during triage. Customers can also maintain their own lists via [Settings → Mapping → Allow/Deny](https://app.radiantsecurity.ai/settings/mapping/allow) to reflect environment-specific trusted or blocked artifacts. 3. **Alert history** - past threat associations surfaced during triage, giving AI agents historical context about artifacts previously seen across your environment. {% hint style="info" %} **Note:** For details on how **contextual data** is used during alert triage, see [Alert triage pipeline](#alert-triage-pipeline). {% endhint %} ## Data Fabric ### Data processing #### Raw log preservation philosophy Unlike traditional SIEM architectures that transform ingested data into a normalized Common Information Model (CIM) or Elastic Common Schema (ECS), Radiant takes a fundamentally different approach to log processing. The Radiant pipeline retains logs in their original, vendor-defined raw format. This approach maintains data fidelity and prevents information loss that can occur when aggressive schema transformations are applied. Rather than forcing logs into a predefined structure, Radiant appends only a minimal set of metadata fields required for internal pipeline operations and standardization. Some fields are appended to every event, while others vary based on the connector type and event category:
Core fields (present in all events)
Field nameDescription
rs_timestampStandardized timestamp extracted from the original log.
rs_receivedTimestamp when Radiant received the log.
rs_indexedTimestamp when the log was indexed in Radiant.
rs_connectorTypeIdentifies the source connector that ingested the data (e.g., microsoft_windows_security).
Radiant Agent specific fields
Field nameDescription
rs_sc_hostRadiant Agent host identifier.
rs_sc_tagRadiant Agent tag for log categorization (e.g., winlog.security_events).
rs_src_hostRadiant Agent source hostname where the event originated.
rs_src_ipSource IP address where the event originated.
Alert-specific fields
Field nameDescription
rs_alertIDUnique identifier for the alert.
rs_parentAlertIDReference to the originally triaged alert when deduplication occurs.
rs_filterRuleIdentifier for alerts that were suppressed.
All ingested data remains queryable in its native format through Log Management, which is built on [Quickwit's search API](https://quickwit.io/docs/reference/rest-api), allowing analysts to access vendor-specific fields, nested JSON structures, and proprietary log formats without schema constraints. ### Data indexing and storage Radiant processes and organizes all ingested data into a structured, queryable format for the AI Engine. It also houses Radiant's integrated log management capability: Log Management. Log Management stores all ingested security data directly from your existing infrastructure, offering flexible retention and eliminating vendor lock-in.\ \ For detailed guidance on storage configuration and retention policies, see [Storage and Retention](/log-management/storage-and-retention). All ingested data is organized into four purpose-built indexes based on processing status and data type:
IndexContentsPurpose
Parsed eventsAll alerts and events successfully processed with Radiant metadata fields appended (e.g., rs_timestamp, rs_connectorType)Primary queryable log repository; includes filtered alerts for compliance
Unparsed eventsAll alerts and events that generated parsing errors and could not be successfully processed.Error handling, troubleshooting, and connector configuration issues
AlertsAll initial and duplicate alerts (excluding filtered alerts) that passed filtering and are eligible for triageActive alert investigation and triage workflows
Audit LogsDetailed record of user actions within the Radiant applicationCompliance tracking, change management, and internal security monitoring
#### Access indexes in Log Management All indexes are accessible and fully searchable directly within the Log Management interface, regardless of your storage configuration. To switch between indexes, navigate to **Log Management** and click the square **Index Selector** button to the left of the **Run** button. A drop-down menu will display the four available indexes: `Parsed Events`, `Unparsed Events`, `Alerts`, and `Audit Logs` - allowing customers to scope their search to the relevant dataset.
#### Query on demand For detailed guidance on crafting search queries, see [Craft Search Queries in Log Management](https://help.radiantsecurity.ai/log-management/log-search-and-query/craft-search-queries-in-log-management). ### Alert filtering Third-party security vendors generate a high volume of alerts, many of which are low-fidelity or redundant. Without filtering, this noise pollutes the alert queue and overwhelms security teams, even with AI triage in place. Alert filtering ensures that analysts focus on critical threats by suppressing known non-actionable alerts before they reach the triage pipeline, reducing both noise and the storage and compute costs associated with processing low-fidelity data. Radiant applies two types of filter rules sequentially during ingestion: * **Default Rules** - Out-of-the-box rules created and maintained by Radiant, targeting known false positive patterns and low fidelity signals. * **Custom Rules** - Customer-defined rules that further narrow the suppression scope of a default rule to address environment-specific noise. Filtered alerts are never deleted - they remain available in [Log Management](/log-management/audit-logs) for compliance, forensic investigation, and historical analysis. For detailed guidance on configuring and managing alert filter rules, see [Alert Filters](/manage-radiant/alert-filters). ### Alert deduplication Security vendors, particularly network (IDS/IPS) and DLP tools, frequently generate large volumes of near-identical alerts for the same underlying event or repeated occurrences within a short time window. Without deduplication, these redundant alerts clutter the alert queue, waste analyst time, and create performance bottlenecks in the triage pipeline. Radiant addresses this by applying a deduplication step *after* alert filtering and *before* AI triage, collapsing duplicate alerts from the same data feed into a single primary alert without losing the fidelity of the original data.
#### How deduplication works When a new alert arrives from a connector, it goes through the normal triage process and becomes the **Initial alert.** Any subsequent alerts from the same source that match the same criteria are recognized as duplicates and consolidated under that initial alert rather than creating separate entries. This grouping window stays active for 3 days, and any additional matching alerts that arrive during that period continue to be consolidated under that same initial alert. Both the deduplication logic and time window can be customized with the help of the Radiant Success team. For more information about deduplication, see [Alert Deduplication](/radiant-alerts/radiant-alerts/alert-deduplication). For more details on reviewing and managing deduplicated alerts, see [The Duplicate Alerts Panel](https://help.radiantsecurity.ai/radiant-alerts/radiant-alerts#the-duplicate-alerts-panel). ## Alert Triage The core of the Radiant platform; our AI SOC Analyst receives every alert, dynamically builds and executes a triage and investigation plan, and assigns each a verdict of **Recommended Benign**, **Likely Benign**, or **Recommended Malicious**. \ \ The pipeline operates through five stages, in this order: **Classification**, **Enrichment**, **Planning**, **Execution**, and **Verdict and Human-in-the-Loop**. Understanding how these stages work together helps you understand how Radiant approaches each alert in your environment. #### Triage pipeline stages {% stepper %} {% step %} #### Alert classification Alert classification is the first stage of the triage pipeline. When an alert arrives, Radiant analyzes its raw data to build a structured understanding of what the alert is about and whether similar alerts have been seen in your environment before. This interpretation captures the essential characteristics of the alert, such as: * What was detected and why it is suspicious * The specific processes, files, commands, or behaviors involved * The environment and systems where the detection occurred This structured classification serves two purposes: it gives Radiant a meaningful, human-readable summary of the alert, and it provides the foundation for determining whether a new triage plan needs to be created or whether a previously successful plan can be reused. {% endstep %} {% step %} #### Alert enrichment Once the alert is classified, Radiant extracts all entities, indicators of compromise (IOCs), and relevant artifacts from the raw alert fields. These are enriched in a single consolidated step using all available data sources, including connected security tools, internal and external threat intelligence feeds, IAM data, and asset inventories, so that all subsequent pipeline steps can leverage these findings. {% endstep %} {% step %} #### Plan generation If an alert is the first of its kind in your environment, Radiant generates a net-new triage plan tailored to that alert. A **Plan** is a structured, reusable set of tasks and questions designed to guide the investigation of an alert toward a classification of benign or malicious. Plans are built dynamically based on Radiant's expert knowledge, knowledge of your environment and your active integrations - meaning Radiant is not limited to a fixed library of questions or predefined alert types its able to triage. Plans are composed of two building blocks: **Tasks** A task is a discrete triage objective that must be completed to support the classification of an alert. Each task represents a focused area of investigation, such as verifying the legitimacy of a process, assessing whether a behavior matches known attack patterns, or determining whether a user's activity is expected given their role. **Questions** A question is a specific, answerable inquiry that operationalizes its parent task by defining exactly what information needs to be gathered and how. Questions translate task goals into concrete data retrieval queries that can be executed against your security tools, data sources, or threat intelligence platforms. Together, tasks define *what* needs to be investigated and *why*, while questions define *what information* must be obtained and *how* to get it. **Plan reuse** Radiant avoids redundant work by reusing triage plans across alerts that share the same nature and context. Rather than generating a new plan for every incoming alert, Radiant evaluates whether a plan already exists that is applicable to the new alert. When a new alert arrives, Radiant compares it against previously triaged alerts in your environment. If the new alert is sufficiently similar to one Radiant has seen before, the existing plan is reused. If no comparable alert exists, Radiant generates a new plan from scratch. {% endstep %} {% step %} #### Plan execution Once a plan has been generated or retrieved through reuse, Radiant executes it by working through the plan's tasks, and questions. For each question, Radiant queries the required data sources, tools, or threat intelligence platforms to retrieve the information needed. As questions are answered, their parent tasks are progressively completed, and the accumulated findings across all tasks drive Radiant toward a final verdict. {% endstep %} {% step %} #### Verdict and human-in-the-loop tuning Once all tasks are complete, a final reasoning layer reviews the previous outputs, including the original alert, the research document, and all task results, It then delivers a verdict of **recommended benign, likely benign, or recommended malicious**, along with a summary of the conclusion and key findings. The report explains the AI’s reasoning in a transparent way and gives analysts the context they need to understand and validate the recommendation. Analysts can accept or reject the verdict. Once reviewed, alerts can be grouped into cases to create a unified view of a threat and support further action from a single place. {% endstep %} {% endstepper %}
VerdictDescription
Recommended MaliciousThe AI found sufficient evidence to suggest the alert represents a genuine threat
Recommended BenignThe AI found sufficient evidence to conclude the alert is not a genuine threat
Likely Benign (Inconclusive)The AI could not reach a confident conclusion with the available data
MaliciousConfirmed malicious verdict (email use case)
BenignConfirmed benign verdict (email use case)
## Response ### Case management Once an alert has been triaged by Radiant's AI pipeline, analysts can manually escalate it into a Case for deeper investigation and response. Cases provide a centralized workspace for tracking complex threats, grouping related alerts, assigning ownership, and executing response actions-- bridging the gap between automated triage and human-led investigation. From a pipeline perspective, Cases represent the final stage of the data flow: raw security data that was ingested, filtered, deduplicated, and triaged has now surfaced a signal that warrants structured investigation. A Case can contain alerts of any verdict, including benign alerts that, when grouped with other signals, reveal a broader threat pattern. Cases are where SOC analysts interact manually with the platform. Incidents arrive here with a full investigation context: root cause, affected systems, and a recommended remediation plan, so analysts can act immediately without having to re-investigate from scratch. The AI Engine recommends but does not automatically escalate alerts into Cases, ensuring analysts retain full control over which threats receive formal investigation and response. All response activity is recorded in a full audit trail, making it straightforward to document incidents for compliance, post-incident review, or internal reporting. For a complete guide on creating and managing Cases, including escalation workflows, artifact consolidation, and investigation lifecycle management, see [Radiant Cases](/radiant-cases/radiant-cases). ### Threat containment and response When a case is escalated, Radiant enables analysts to take direct remediation action on the key artifacts associated with an attack, such as blocking URLs, disabling compromised user accounts, or isolating affected endpoints, without leaving the platform. Auto-generated, incident-specific response plans are ready for one-click execution, and an optional analyst review step can be configured before any automated action runs. Response actions available include disabling users, isolating hosts, blocking IPs, and more. All response activity is recorded in a full audit trail. For guidance on how to execute, verify, and reverse response actions, see [Response Actions in Cases](https://help.radiantsecurity.ai/radiant-cases/radiant-cases/response-actions-in-cases). For a complete list of available response actions, see [Radiant Response Actions](https://help.radiantsecurity.ai/radiant-cases/radiant-cases/radiant-response-actions). # Platform Architecture A high-level overview of the Radiant platform architecture. Radiant is a cloud-hosted AI SOC platform that sits between your existing security tools and your analyst team. Rather than replacing your stack, it connects to it—ingesting alerts from every source, automatically investigating them with AI agents, and surfacing only confirmed threats to analysts for review and response. ## Architecture Diagram The diagram below shows the four major functional layers of the Radiant platform, as well as the supporting services that power the AI engine. Data flows from left to right, from your existing security tools through ingestion, processing, and AI-driven analysis, to response actions taken by your team.
## Core platform components The Radiant platform is organized into four functional layers, each responsible for a distinct stage of the security operations workflow. Two supporting services underpin the AI engine at the platform's core. {% stepper %} {% step %} ### Connector Hub The entry point for all data entering Radiant. It is responsible for connecting to your existing security tools and ingesting alerts and logs in real time. Radiant connects via plug-and-play API connectors across 100+ sources. No custom parsers or manual configuration are required for supported integrations. * **API query connectors:** Poll external SIEMs, EDRs, identity platforms, and cloud environments for alerts and log data. * **Webhooks:** Receive real-time event streams pushed from your tools. * **Syslog collection:** Ingest raw log feeds from network devices, firewalls, and other infrastructure. * **Log management feed:** Pull structured log data stored in Radiant's integrated log store. {% endstep %} {% step %} ### Data Fabric The data fabric processes and organizes all ingested data into a structured, queryable format that the AI Engine can work with. It also houses Radiant's integrated log management capability, a significant differentiator that allows customers to consolidate log storage without a separate SIEM. * **Raw data store:** Durable, tenant-isolated storage of ingested security events. * **ETL and normalization:** Parses and transforms logs into a consistent schema regardless of source format. * **ML feature builder:** Extracts behavioral and contextual features to enrich AI analysis. * **Alert generation:** Surfaces structured alerts from log anomalies and detection rules. {% endstep %} {% step %} ### AI Engine This is the core of the Radiant platform. The AI Engine receives every alert, dynamically builds and executes a triage and investigation plan, then renders a verdict. Critically, it handles *all* alert types, not just a predefined set, by reasoning about each alert's context at runtime. * **Alert router:** Classifies and routes incoming alerts to the appropriate pipeline. * **Triage pipeline:** Executes configurable pipeline steps and AI agents to assess alert severity. * **Investigation pipeline:** Performs deeper, multi-step investigation for escalated alerts, driven by AI agents. * **Pipeline execution trace:** Captures a full, human-readable log of every decision the AI made, for transparency and auditability. * **Verdict and escalation:** Closes false positives automatically; escalates confirmed threats with a complete investigation summary. {% endstep %} {% step %} ### Response This is where your analysts interact with the platform. Escalated incidents arrive here with a full investigation context: root cause, affected systems, and a recommended remediation plan, so analysts can act immediately without having to re-investigate from scratch. All response activity is recorded in a full audit trail, making it straightforward to document incidents for compliance, post-incident review, or internal reporting. * **Case management:** A unified queue of escalated incidents, each with investigation context attached. * **Response workflows:** Auto-generated, incident-specific response plans ready for one-click execution. * **Response action library:** A catalog of pre-built remediation actions (disable user, isolate host, block IP, etc.) that execute directly from the console. * **Review and approval workflow:** Optional analyst review step before automated actions execute. {% endstep %} {% endstepper %} # Get Started Use this guide to find the right starting point based on your role. The Radiant Knowledge Base contains in-depth documentation, best practices, and workflows across the entire platform. This section is organized to get you productive as quickly as possible - follow the Admin Quickstart if you are responsible for platform setup, or jump straight to the User Quickstart if your environment is already configured and you are ready to triage. If you need help at any point, see [Get Help](/welcome-to-radiant/support/get-help). ### What is Radiant? Radiant is an AI-powered SOC platform that automates alert triage, investigation, and response across your entire security stack. It ingests alerts from every connected source, runs a structured triage pipeline against each one, and delivers a verdict with full investigation context attached - so your analysts spend time on confirmed threats, not alert queues. For a full description of the platform and how it works, see [Platform Overview](/). ### Who is this guide for? This guide is for two audiences: * **Platform admins** - responsible for connecting data sources, configuring SSO and user access, and preparing the environment before analysts begin work. * **Security analysts** - responsible for reviewing triage results, accepting or overriding verdicts, escalating alerts to cases, and executing response actions. Each quickstart below is scoped to one audience. Start with the one that matches your role. ### Choose your path
TitleDescription
Admin QuickstartConnect your data sources, configure SSO, and invite your team./pages/8dyaoo3KAYBDvI7ekk1F
User QuickstartLog in, configure notifications, triage your first alert, and escalate to a case./pages/aGSZ8JxlbYnWHdcIiRuf
### Explore the knowledge base The knowledge base is organized into the following sections: * [Welcome to Radiant](/welcome-to-radiant/get-started) - Platform overview, quickstarts, release notes, and support resources. * [Radiant Connectors](/radiant-connectors/connectors-and-data-ingestion) - Data Connectors for ingesting alerts, logs, and telemetry from your existing security stack, and Action Connectors for executing response actions directly from a case. * [Log Management](/log-management/audit-logs) - Bring your own S3 bucket, manage log retention, and control parsing and access within Radiant. * [Radiant Alerts](/radiant-alerts/radiant-alerts) - Full reference for the Alerts page, including verdict labels, the Overview tab, the Triage Results tab, and the Duplicate Alerts panel. * [Radiant Cases](/radiant-cases/radiant-cases) - Create and manage cases, assign ownership, track investigation lifecycle, and execute response actions. * [Manage Radiant](/manage-radiant/security-operations-insights) - User management, SSO and MFA configuration, notification preferences, and alert suppression rules. ### Tell us what you think Look for the feedback widget on the right side of each article. Use it to rate your experience and leave comments. Whether your feedback is positive, neutral, or negative, we welcome your insights. Let us know what you liked or where we can do better; your input guides our content updates and helps us serve you more effectively.
# Admin Quickstart Plan for approximately 30 minutes to complete all steps. Radiant is up and running! Now it's time to configure it for your team. This guide walks you through the essential setup steps every administrator should complete before your analysts begin investigating alerts. Follow these steps in order to ensure your environment is fully operational from day one. {% hint style="warning" %} **Important:** Radiant requires an AWS S3 bucket to store ingested logs. If you have not yet configured your bucket, complete [Bring Your Own Bucket](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management) before continuing. Your environment will not be operational until that setup is in place. {% endhint %} ### Before you begin Make sure you have the following before starting setup: * Administrator access to your Radiant tenant * A configured AWS S3 bucket. See [Bring Your Own Bucket](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management) if you have not completed this yet * SSO provider credentials if you are configuring Okta, Microsoft Entra, or Google as your identity provider * A list of analysts you need to add to the platform ### Step 1: Configure SSO and MFA Set up your identity provider and enforce multi-factor authentication to the platform. For detailed configuration instructions, see [Set Up Single Sign-On (SSO)](/manage-radiant/organization-settings/security/set-up-single-sign-on-sso). {% hint style="info" %} **Note:** Configure SSO before inviting users. Accounts created before SSO is enabled may require migration. {% endhint %} ### Step 2: Add users With SSO and MFA in place, invite your analysts to Radiant. 1. Navigate to **Settings > Organization > Users**. 2. Click **+** **Add user**. 3. Enter the user's name and email address. 4. Click **Send invite**. Radiant sends the user an email invitation. The invitation link expires after 24 hours. Repeat for each user you need to add. If a user does not receive the invitation email, ask them to check their spam folder. {% hint style="info" %} **Note:** Role-based access control (RBAC) is not yet available. All users currently receive full administrator access regardless of their role in your organization. {% endhint %} ### Step 3: Connect notification channels Connect Radiant to your organization's communication platforms so your analysts can receive notifications. Email is available to all users by default. To enable Slack or Microsoft Teams, integrate those platforms using the dedicated setup guides below. 1. Navigate to **Settings > Credentials** in the left navigation panel. 2. Select Slack or Microsoft Teams. 3. Follow the setup instructions for your chosen platform: * [Connect Slack to Radiant](/radiant-connectors/communication-tools/slack) * [Connect Microsoft Teams to Radiant](/radiant-connectors/communication-tools/microsoft-teams) {% hint style="info" %} **Note:** Once a platform is integrated, each user controls their own notification preferences from their account settings. {% endhint %} ### Step 4: Connect your first data source With storage, access, and notifications configured, Radiant is ready to receive data. Connect your primary alert source, typically your IAM or EDR, to begin triaging alerts. 1. Navigate to [Connector Library](/radiant-connectors/connectors-and-data-ingestion) in the left navigation panel. 2. Select your data source and follow the connector-specific setup instructions. 3. Verify data is flowing into Radiant. To do this: * Navigate to **Log Management** in the left navigation panel. * Run a `*` query and confirm your data is returned and correctly parsed in the Parsed Events index. {% hint style="warning" %} **Important:** Radiant cannot triage alerts until at least one data connector is active and the ingestion test succeeds. {% endhint %} For a full list of supported connectors and setup instructions, see the [Connector Library](/radiant-connectors/data-connectors). ### Next steps Your Radiant environment is configured and ready. Share the [User Quickstart](/welcome-to-radiant/get-started/user-quickstart) with your SOC team so they can start triaging alerts. ### Related articles * [Bring Your Own Bucket for Log Management](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management) * [Set Up Single-Sign On (SSO)](/manage-radiant/organization-settings/security/set-up-single-sign-on-sso) * [User Management](/manage-radiant/organization-settings/user-management) * [Connector Library](/radiant-connectors/connectors-and-data-ingestion) * [User Quickstart](/welcome-to-radiant/get-started/user-quickstart) # User Quickstart Get oriented in Radiant and start triaging alerts in minutes. Radiant is an AI-powered security operations platform that automatically triages every ingested alert, classifying it, enriching its artifacts, executing an investigation plan, and assigning a verdict, so your team focuses on threats that require human action. \ \ This guide covers the four tasks every analyst should complete when they first access Radiant: * [Log in to Radiant](https://app.radiantsecurity.ai/) * [Configure your notifications](/manage-radiant/user-settings/account-notifications) * [Triage your first alert](/radiant-alerts/radiant-alerts) * [Escalate an alert to a case](/radiant-cases/radiant-cases/escalate-and-manage-cases) ### Prerequisites Before you begin, confirm the following: * [ ] Your administrator has created your account and sent you an invitation email. The invitation link expires after 24 hours. If yours has expired, contact your administrator to resend it. * [ ] Your organization's SSO and MFA are configured. You will need your SSO credentials to log in. ### Log in to Radiant 1. Open the invitation email from Radiant Security and click the activation link. 2. Complete MFA enrollment as prompted. 3. Log in at Radiant Security using your SSO credentials. {% hint style="info" %} **Note:** If you experience login issues, confirm with your administrator that SSO is configured for your organization and that your account has been provisioned. {% endhint %} ### Configure your notifications Before you begin working through your alert queue, configure your notification preferences. Radiant notifies you by email when alerts are triaged, when you are assigned to a case, and when you are mentioned in a case note. 1. In the left navigation, click the **Settings** (gear) icon. 2. Under **Account Settings**, click **Notifications**. 3. In the **Email notifications** row, use the drop-down menu to set your preferred delivery frequency: **Instantly**, **Daily**, or **Weekly**. 4. To control which events trigger notifications, click the arrow icon beside the drop-down and use the toggles on the configuration page. For a full description of each notification event and how to configure them, see [Account Notifications](https://help.radiantsecurity.ai/manage-radiant/user-settings/account-notifications). ### Triage your first alert The **Alerts** page is where Radiant's alert triage results become visible. Every alert displayed here has already passed through the full triage pipeline and been assigned a verdict. Your role is to review that verdict, assess the reasoning behind it, and confirm or override it. For a full reference of the Alerts page, including the Duplicate Alerts panel and the Triage Results tab, see [Radiant Alerts](https://help.radiantsecurity.ai/radiant-alerts/radiant-alerts). #### Understand the verdict When you open an alert, the first thing to read is the **verdict badge** at the top of the page. This is Radiant's assessment: * **Recommended Malicious:** Radiant found sufficient evidence that the alert represents a genuine threat. * **Likely Benign:** Radiant could not reach a confident conclusion with the available data. * **Recommended Benign:** Radiant found sufficient evidence that the alert is not a genuine threat. The **Overview** tab below the header is designed to be scanned. Use it to orient before you investigate. It surfaces the critical triage fields you need for most L1 decisions without reading the full alert first. The left panel gives you a standardized breakdown of the alert: What was detected, where it originated, what action was taken, and how the vendor responded. The center panel contains Radiant's plain-language conclusion and the key findings that support it. The right panel lists the artifacts extracted from the alert, organized by type. #### Validate the reasoning When you want to understand or challenge the evidence behind the verdict, open the **Triage Results** tab. This tab shows the complete investigation: every task Radiant executed, the finding from each task, and the queries run against your connected data sources. Task rows are color-coded to indicate their individual finding: red for malicious, yellow for inconclusive, green for benign. #### Confirm or override the verdict Radiant automatically recommends a verdict for every alert, but the final call is yours. Use the verdict controls to confirm Radiant's recommendation when you agree, or override it when your investigation leads you to a different conclusion. Every decision you record, confirmation or override, is logged and used to improve future triage accuracy for your organization. After reviewing the alert, record your decision using the controls in the top-right corner. The layout reflects Radiant's confidence level: the primary button always surfaces the recommendation, and the overflow menu provides the override. Clicking either control opens a confirmation showing the verdict change: * Confirming the recommendation reinforces the current verdict. * Overriding the recommendation shows the verdict switching from Radiant's suggestion to your own. Both include a note field; use it to document your reasoning for teammates or for the record. | Verdict | Primary button | Three-dot menu | | --------------------- | --------------------------- | --------------------------- | | Recommended Malicious | Mark Malicious | Mark Benign, Add to Case | | Recommended Benign | Mark Benign | Mark Malicious, Add to Case | | Likely Benign | Mark Malicious, Mark Benign | Add to Case | Once you act, the "Recommended" qualifier is removed and the alert status reflects your decision: **Malicious** or **Benign**. If you need to reverse a decision, the same controls remain available. ### Escalate an alert to a case When an alert requires deeper investigation, formal ownership, or coordinated response across your team, escalate it to a case. A case is a dedicated workspace where you can group related alerts, assign an owner, track the investigation lifecycle, and execute response actions on specific artifacts. Radiant does not automatically escalate alerts to cases. That decision belongs to you. To escalate an alert to a case: 1. Open the alert you want to escalate. 2. Click the overflow menu in the top-right corner of the alert page. 3. Select **Add to Case**. 4. Choose to create a new case or add the alert to an existing one. For a complete walkthrough of case creation, assignment, severity levels, case notes, and lifecycle management, see [Escalate and Manage Cases](https://help.radiantsecurity.ai/radiant-cases/radiant-cases/escalate-and-manage-cases). ### Next steps The following articles are recommended reading as you build familiarity with the platform: * [Key Concepts and Glossary](https://help.radiantsecurity.ai/welcome-to-radiant/get-started/user-quickstart/key-concepts-and-glossary) - Definitions of the core terms and objects you will encounter in Radiant. * [Radiant Alerts](https://help.radiantsecurity.ai/radiant-alerts/radiant-alerts) - Full reference for the Alerts page, the Duplicate Alerts panel, and the Triage Results tab. * [Radiant Cases](https://help.radiantsecurity.ai/radiant-cases/radiant-cases) - Overview of the case lifecycle, capabilities, and when to use cases versus the Alerts feed. * [Escalate and Manage Cases](https://help.radiantsecurity.ai/radiant-cases/radiant-cases/escalate-and-manage-cases) - Step-by-step guide for case creation, assignment, and lifecycle management. * [Response Actions in Cases](https://help.radiantsecurity.ai/radiant-cases/radiant-cases/response-actions-in-cases) - How to execute response actions directly from an active investigation. # Key Concepts and Glossary Key terms used throughout the Radiant Security platform and its documentation. Intended for security analysts, team leads, and administrators. ### A #### AI-generated case title A max-10-word title generated from the full alert set, structured around threat type, affected entity, and key indicator. #### AI-generated case summary A 3–4 sentence incident narrative covering the threat, shared artifacts, attack vector, and current status. #### Artifact Any security-relevant entity in an alert or case: users, devices, IPs, domains, file hashes, URLs, email addresses. #### Artifact Response Action A single-click or automated step within a case or workflow. Actions execute a response measure such as blocking access or isolating a device. #### Artifact Tag The interactive inline UI element representing an artifact reference. Clicking opens the enriched side panel. #### Account Notifications Per-user settings that control which platform events trigger a notification. Configurable events include new alerts, case assignments, investigation completions, and scheduled activity reports. #### Account Settings The section of Settings where individual users configure personal preferences, including account notification subscriptions. #### Action Connector A connector that sends commands from Radiant back to a connected security tool. Action connectors are required to execute response actions from within a case. #### AI Triage The end-to-end pipeline process by which Radiant receives and evaluates alerts and assigns a verdict. #### AI Verdict A machine-generated assessment of an alert displayed as a color-coded badge, such as Recommended Malicious or Recommended Benign. The verdict appears when the alert is opened. #### Alert A security alert generated by an external tool and ingested into Radiant. Each alert passes through the Radiant data pipeline - filtered, deduplicated, and triaged by AI - before appearing on the [Alerts page](/radiant-alerts/radiant-alerts). #### Alert at a Glance A structured summary panel on each alert that displays five fields: Focus, Source, Action, Target, and Vendor Response. The format is consistent across all connected tools regardless of the originating vendor. #### Alert List A list view of processed alerts that displays status, verdict, severity, and detection time. You can filter and search the feed by event type, time range, and other criteria. #### Alert Filter A rule that suppresses non-actionable or low value alerts before they reach the triage pipeline. [Alert filters](/manage-radiant/alert-filters) are applied after ingestion and are defined using Quickwit syntax. #### Allow List A customer-managed list of entities that the platform treats as known and trusted. Categories include Trusted Domains, Trusted IPs, Trusted Senders, Shared Accounts, Public Object Storage, and Trusted Applications. #### Anomaly Detection The identification of activity that deviates significantly from an established baseline. The platform uses anomaly detection to flag unusual behavior and influence triage verdicts. #### Artifact A specific piece of evidence extracted from an alert, such as a URL, file, IP address, email attachment, or user identity. [Artifacts](/radiant-cases/radiant-cases/artifact-reference-guide) are enriched and organized into named categories on each alert and case. #### Artifact anchoring Grouping alerts by shared artifacts (devices, identities, IPs) rather than by alert type or attack category. #### Artifact enrichment Querying external intelligence sources to add context to a security artifact (IP, domain, file hash, URL) encountered during investigation. #### Assignment The association of a specific analyst with a case. Assigning ownership prevents duplicate work and ensures every active threat has a named owner. #### Audit Log A specialized index within Log Management that records operations performed within the Radiant platform, such as response actions, configuration changes, and user management events. [Audit logs](/log-management/audit-logs) are distinct from security alerts, which track detected external threats. #### Auto Escalation The automatic promotion of a triaged malicious alert to a case, by creating a new case or attaching to an existing one, based on entity overlap. #### Auto Execute A setting on an response action that removes the manual intervention and allows the action to run automatically when triggered from a workflow. ### B #### Benign A verdict classification confirmed by the user indicating that an alert represents non-threatening activity. No response action is required for alerts classified as benign. #### Bring Your Own Bucket (BYOB) A storage configuration in which log data is stored in the customer's own AWS S3 bucket rather than Radiant-managed infrastructure. [BYOB](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management) gives the customer full data ownership, custom retention control, and compliance flexibility. It is recommended for all production environments. #### Bring Your Own Threat Intelligence Service (BYO-TIS) Bring Your Own Threat Intelligence. Connects a customer's own TI licenses to Radiant for use in enrichment and triage. #### Business Email Compromise (BEC) An attack type in which a malicious actor compromises or impersonates a business email account to commit fraud, steal data, or manipulate employees. Radiant includes dedicated triage workflows for BEC alerts. ### C #### **Case** A centralized workspace that groups related alerts, artifacts, notes, and response actions for a single investigation. [Cases](/radiant-cases/radiant-cases) are used for threats that require formal ownership, long-term tracking, and coordinated response. #### Case Severity A rating that indicates the potential impact of an alert or case. Valid severity levels are Critical, High, Medium, Low, and None. Severity can be assigned to cases manually to support prioritization. #### Case Status The lifecycle state of a case. Valid statuses are Open, Pending, False Positive, and Closed. Status is updated manually by the analyst as the investigation progresses. #### Case Notes Free-text and image entries added to a case by analysts to record findings, hypotheses, or hand-off context. Notes persist for the life of the case and are visible to all assigned team members. #### Citation A numbered footnote attached to a finding, indicating its source. #### Citation Tooltip The hover state on a citation number revealing source type, description, and data reference. #### Communication Tools Integrations with [Microsoft Teams](/radiant-connectors/communication-tools/microsoft-teams) and [Slack](/radiant-connectors/communication-tools/slack) that route workflow notifications and interactive approval requests to external collaboration platforms. Email notifications are enabled by default for all workflows and require no additional setup. #### Conclusion A paragraph written by the AI triage pipeline that summarizes what happened, what was investigated, and whether the alert represents a real threat. It appears at the top of the alert Overview tab. #### Connector An integration that links Radiant to a third-party security tool such as an EDR, SIEM, email gateway, firewall, or identity provider. #### Context List A collective term for customer-managed allow lists, deny lists, and other custom lists that modify triage logic to fit the specific environment. Context lists reduce false positives and ensure relevant threats are surfaced. #### Custom Filter Rule A customer-defined alert filter rule scoped to a specific [Default Filter Rule](#default-filter-rule). It is applied on top of the parent rule using an AND NOT operator to exclude specific alerts from the triage pipeline. ### D #### Data Connector A connector that ingests security telemetry, alerts, event logs, and contextual data from a security vendor into Radiant for storage, correlation, enrichment, and triage. #### Data Source Any system or tool that sends security event data to Radiant. Common data sources include endpoint detection tools, firewalls, email security gateways, and identity platforms. #### Deduplication The process of grouping repeated or near-identical alerts under a single parent alert. The parent alert displays a tag showing the total number of grouped duplicates. You can review the full deduplication activity in the [Duplicate Alerts Panel](/radiant-alerts/radiant-alerts/alert-deduplication). #### Deduplication Window The time period during which incoming alerts that match defined criteria are grouped under an initial alert rather than surfaced as separate events. The default window is 3 days. You can contact your Customer Success representative to configure custom window durations. #### Default Filter Rule The base alert filter query created and maintained by Radiant that defines which alerts from a given connector are eligible for triage. Default rules cannot be modified or deleted. You can narrow their scope by adding a [Custom Filter Rule](#custom-filter-rule). #### Deny List A customer-managed list of entities known to be malicious. Entries are flagged as bad during artifact enrichment and triage. Categories include Malicious Domains, Malicious IPs, and Malicious Senders. Deny list rules override allow list rules when both match the same entity. #### Domain Monitoring A configuration that enables Radiant to triage phishing emails targeting specific organizational domains. Domains are synchronized from the connected email provider and enabled individually. #### Duplicate Alerts Panel A side panel that displays the deduplication logic applied to a parent alert, a visual timeline of when duplicates were received, and the raw body of each grouped alert. You open it by clicking the duplicate count tag on an alert. ### E #### Email Forwarding A method of delivering phishing reports and suspicious emails directly to Radiant for automated triage by routing them from a connected email platform. Supported sources include Microsoft 365, Google Workspace, Darktrace, KnowBe4, and Proofpoint. #### Enrichment The automatic retrieval of additional context about an artifact from threat intelligence, context lists and other log sources. Examples include resolving whether an IP address is associated with malicious activity, a known proxy, or a specific geographic location. #### Escalation The act of promoting an alert to a case for formal investigation and response tracking. Escalation is used when an alert involves a confirmed threat or requires analysis beyond the initial triage. ### F #### False Positive An alert that was flagged as suspicious but represents normal, expected activity. You can mark an alert as benign to record the correct verdict and provide feedback for future triage accuracy. #### FQDN (Fully Qualified Domain Name) A complete domain name that uniquely identifies a host, such as `malware.badactor.com`. FQDNs are extracted as artifacts from alerts and tracked across case investigations. #### Filter Query The exclusion query at the core of a Custom Rule, written in Quickwit syntax, that defines which alerts within a connector's ingestion scope are suppressed from triage. You can test a Filter Query against historical data using the Test Rule button before applying it to the live pipeline. #### Focus The attacker's core goal or intent, giving analysts the "why" behind the alert immediately (e.g. `Exploit a public-facing application to gain unauthorized system access)`. ### G #### Geolocation The resolution of an IP address to a geographic location, including city and country. Geolocation is applied automatically during artifact enrichment and displayed in the artifact detail panel. #### Grafana Plug-in An optional integration that connects Radiant log data to Grafana dashboards. It lets you query and visualize log data outside the native Log Management interface. ### I #### Indicator of Compromise (IOC) A piece of evidence - such as a file hash, IP address, or domain name - that indicates a system may have been attacked or breached. The platform checks artifacts against known IOC databases during enrichment. #### Insights Dashboard The main overview screen in Radiant. It displays a summary of recent alert activity, open cases, and key security metrics. #### Interactive Action A workflow step that presents a response action to an analyst as an approval button. Interactive actions require one-click interactions by a user. You can configure them to execute automatically using the Auto Execute setting in Workflows. ### K #### Key Findings A scannable list of bullet points identifying the specific facts most directly supporting the AI verdict. Key Findings appear in the center panel of the alert Overview tab. ### L #### Likely Benign A verdict classification assigned when insufficient evidence exists to make a definitive determination. Inconclusive alerts may be escalated for human review. #### Look-back window The configurable 48-hour period within which Radiant evaluates existing cases for alert attachment. #### Log A recorded entry of activity from a system or application. Radiant ingests, stores, and indexes logs from connected sources so they can be stored, searched and queried during investigations. #### Log Management The platform module for storing, searching, and querying raw log data from connected sources. Log Management supports investigations, alert filter validation, and compliance reporting. #### Log Search and Query The capability to run structured queries against ingested log data. Log Management uses Quickwit syntax, which supports keyword search, field-specific filtering, Boolean logic, range queries, wildcards, and proximity searches. ### M #### Malicious A verdict indicating that an alert represents a confirmed security threat. Malicious alerts are candidates for escalation to a case or immediate response action. #### Multi-Factor Authentication (MFA) An authentication requirement that users verify their identity using two or more methods at login. MFA enforcement is configured in Settings and can be applied to all users in a tenant. ### N #### Notification An automated message sent to a user when a platform event occurs. Notification channels include email, Slack, and Microsoft Teams. Notification preferences are configured per user in User Settings. #### Notification Template A predefined message format used by workflows to generate consistent notifications for recurring event types, such as new alerts, case assignments, or investigation completions. ### O #### Organization Settings The section of Settings that covers phishing configuration, security policies such as SSO and MFA enforcement, and user management. #### Outgoing Webhook A mechanism that delivers alert data, enrichment results, AI conclusions, and key findings from Radiant to an external system in real time. #### Out-of-the-box feeds The eight TI sources Radiant ships enabled by default, requiring no customer configuration. #### Overview Tab The default view when opening an alert. It displays the Alert at a Glance panel, Conclusion and Key Findings, and the Artifacts panel side by side. It is designed for rapid orientation and first-line verdict assessment. ### P #### Parsed Logs Index The searchable index within Log Management that retains all ingested alerts regardless of their filtering status. Filtered alerts are stored here and remain available for forensic and compliance review. #### Phishing An attack type in which a deceptive email or link is used to trick a user into revealing credentials or installing malware. The phishing use case in Radiant requires an email connector and domain monitoring configuration. #### Phishing Simulation A controlled exercise in which fake phishing emails are sent to employees to test security awareness. You can configure Radiant to exclude known simulation vendors from triage so their test emails do not generate real alerts. #### Pipeline The ordered sequence of automated stages an alert passes through from initial ingestion to final verdict and response. See also: Radiant Data Pipeline. ### Q #### Quickwit Syntax The query language used in Radiant's Log Management interface and alert filter rule definitions. It is similar to Lucene and supports field-specific searches, Boolean operators (AND, OR, NOT), range queries, and wildcard expressions. ### R #### Radiant Security Agent A [docker-based collector](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) installed on a host or VM. Listens on connector ports and sends compressed logs to Radiant’s S3 environment. #### Radiant Data Pipeline The end-to-end automated sequence by which security data is ingested, filtered, deduplicated, enriched, and triaged before appearing on the [Alerts](/radiant-alerts/radiant-alerts) page. See the Radiant Data Pipeline documentation for a full overview. #### Radiant-Managed Storage A storage configuration in which Radiant hosts and manages log data on the customer's behalf. Radiant-Managed Storage is intended for proof-of-concept and testing environments only. #### Raw Alert The unprocessed alert body as received from the vendor tool. It is accessible from within any triaged alert regardless of the originating source. #### Recommended Benign The benign outcome assigned to an alert after AI triage. This recommended state can be manually confirmed or denied by users of the platform. #### Recommended Malicious The malicious outcome assigned to an alert after AI triage. This recommended state can be manually confirmed or denied by users of the platform. #### Response Action A discrete remediation step taken to contain or resolve a threat. Examples include blocking an IP address, quarantining a device, disabling a user account, and deleting a malicious email. Response actions are executed from the case view and recorded in the audit log. #### Retention A setting that defines how long data in a specific Log Management index is kept. BYOB customers retain full ownership of their data, control their own retention policies, and are not dependent on Radiant's storage infrastructure. #### Role A set of permissions assigned to a user that governs which features and data they can access. All users invited to Radiant are assigned the Admin role by default. #### Root Cause Analysis (RCA) An investigation that identifies the original source or entry point of a security incident - for example, the process or user action that initiated a chain of malicious events. ### S #### **Search** The query interface for locating alerts, and cases. You can filter results by date, severity, verdict, entity type, and additional criteria. #### Settings The [configuration area](/manage-radiant/organization-settings) of the platform. From Settings, administrators manage users, configure connectors, define alert filters, create workflows, manage allow and deny lists, and control security policies including MFA, SSO, and phishing domain monitoring. #### Shared Account An email or account entry on an Allow List recognized as a legitimate shared or service account. Activity from shared accounts does not trigger impossible travel alerts. #### Side Panel The drawer that opens on artifact tag click, displaying enriched context without navigating away. #### Single Sign-On (SSO) An authentication method that allows users to log in to Radiant using credentials from an external identity provider such as Microsoft Entra ID, Google, or Okta. #### Source Type The category of a citation: (1) vendor alert, (2) third-party enrichment, or (3) AI triage reasoning. ### T #### Target An asset or resource that was affected or accessed - the "where" of the alert (e.g. `AWS Security Group sg-3349180977d3f5545`) #### Task An individual action item within a case or workflow. Tasks can be assigned to team members, set to require manual approval, or configured to execute automatically. #### Telemetry Raw event and activity data streamed from connected security tools such as EDRs, firewalls, identity platforms, and cloud services. #### Tenant A distinct organizational account within the platform. Each tenant has its own isolated data, users, connectors, settings, and configuration. #### Threat Intelligence Curated information about known threats, malicious actors, and attack techniques. The platform applies threat intelligence during artifact enrichment to assess the reputation of IPs, URLs, domains, and file hashes. #### Threat intelligence feed An external data source providing information about known threats, malicious infrastructure, or suspicious indicators, queried during triage to enrich artifacts. #### Threat Intelligence Hub The combined capability: out-of-the-box feeds plus BYO-TIS extensibility, surfaced as a unified enrichment layer within Radiant. #### Triage The automated process of evaluating an alert to determine whether it represents a real threat, benign activity, or an inconclusive result. Radiant performs triage using AI on every ingested alert. #### Triage Outline The complete set of tasks and questions that structured the AI investigation for a specific alert. It is viewable from the Triage Results tab and identifies every area the AI chose to investigate and why. #### Triage Result The output of Radiant's AI triage process: verdict, findings, and next step recommendations. #### Triage Results Tab The alert detail tab that displays every task executed, every finding produced, and every query run during an AI investigation. It is designed for L2 and L3 analysts who want to validate the reasoning behind a verdict. #### Trusted Domain A domain entry on an Allow List recognized as belonging to or approved by the organization. Emails and traffic from trusted domains bypass certain phishing detection checks. #### Trusted IP An IP address entry on an Allow List recognized as known or internal. Network connections from trusted IPs may be excluded from threat analysis. #### Trusted Sender An email address entry on an Allow List recognized as a legitimate sender. Emails from trusted senders bypass email security screening. ### U #### User-edited field A title or summary field modified by an analyst. Protected from AI regeneration regardless of alert set changes. #### User Management The [Settings area](/manage-radiant/user-settings) for creating, editing, disabling, enabling, and deleting user accounts. You can disable a user to prevent login while preserving their account history and settings. ### V #### Verdict The outcome assigned to an alert after AI triage. Verdicts are classified as Recommended Malicious, Recommended Benign, or Likely Benign (Inconclusive). Users can modify a verdict manually. #### VIP User A user designation that flags an account for enhanced monitoring and prioritized incident response. VIP status is assigned in Settings and all changes to VIP designations are recorded in the audit log. ### W #### Workflow A configurable sequence of steps that automates how the platform handles notifications, and response actions. A workflow consists of a trigger and one or more steps, which can be interactive tasks or directly executed. #### Workflow Trigger The event or condition that initiates a workflow, such as an alert reaching a specific verdict or a case being created. Each workflow has exactly one trigger.
# Support # Get Help Access support resources, submit feedback, and reach the Radiant Security team directly from within the platform. Radiant provides several channels for getting help, submitting feedback, and escalating issues. Use the channel that best matches the urgency and nature of your request: * [Online resources](#online-resources) * [Open a support case](#open-a-support-case) ### Online resources All customer support reference materials can be found in our [knowledge base](/welcome-to-radiant/get-started): * Search, access, and view common usages, workarounds, and solutions. * Keep up with the latest information regarding Radiant Security product updates. * View and subscribe to the [status page](https://status.radiantsecurity.ai/) to get an accurate, up-to-date status on the Radiant Security platform. ### Open a support case If you cannot resolve your issue using the online resources, you can open a support case through any of the following channels: * [Support email](#support-email) * [In-product feedback button](#in-product-feedback-button) * [Your dedicated support channel](#support-channel) (Slack or Teams) * [Phone call](#phone-call) (for critical incidents only) Providing relevant details upfront minimizes back-and-forth and reduces time to resolution. When opening a case, include diagnostic information and any additional context in your initial submission. #### Support email Use this address () to reach the broader Radiant Security support team. Messages sent here are visible to multiple stakeholders across the organization, which helps us: * Quickly align on the urgency of your request * Route your issue to the right team * Take immediate action when needed #### **Help and feedback button** The **Help and feedback** button is available in the left navigation of the Radiant Security platform. Clicking it opens a flyout menu with four options: * **Contact us** - Submit a support request to the Radiant Security team. * **Report an issue** - Report a platform bug or unexpected behavior. * **Docs** - Opens the Radiant Security knowledge base in a new tab. * **Radiant status** - Opens the Radiant Security status page in a new tab.
To submit a support request or report an issue from within the platform: 1. [Log in](https://app.radiantsecurity.ai/) to the Radiant Security platform. 2. Click **Help and feedback** in the left navigation. 3. Select **Contact us** or **Report an issue**. 4. Complete and submit the form. Submitting through either option captures session context automatically and routes your submission to the right team. #### Support channel For questions, guidance, or anything that does not require a formal support case, reach your Radiant Success representative directly through your dedicated Slack or Teams channel. Use it for quick questions, status check-ins, and informal guidance. #### Phone call {% hint style="danger" %} For **urgent or critical incidents** requiring immediate assistance, contact support at +**1 (800) 917-4652.** Use this number only for production-down or business-critical issues that cannot wait for a response through standard channels. {% endhint %} If our engineers are busy helping other customers, please leave a message indicating a brief problem description and the severity level. All calls will be returned based upon the service level agreement response times. # Connectors and Data Ingestion Connect your security stack to Radiant, ingest alerts and threat intelligence, and configure storage for your security logs. ### Connect Your Data Radiant requires visibility across your security environment to triage alerts automatically. This section covers everything needed to establish and manage that visibility: how your security tools connect to Radiant, how ingested data flows through the platform, and how to configure storage for your security logs. Before connecting your first data source, read [The Radiant Data Pipeline](/welcome-to-radiant/what-is-radiant-security/the-radiant-data-pipeline) to understand how data moves from ingestion through indexing and into alert triage. If you have multiple source types and are unsure which connection method to use, see [Choose the Right Connection Method](/radiant-connectors/connectors-and-data-ingestion/choose-the-right-connection-method). ### Data Connectors The **Data Connectors** page in Radiant is where you add, manage, and monitor every active integration, including data connectors, action connectors, and threat intelligence feeds. For instructions on navigating the page and adding a connector, see [Data Connectors](/radiant-connectors/data-connectors). ### Phishing email forwarding Radiant ingests user-reported phishing and business email compromise (BEC) reports through direct forwarding integrations with major email platforms and phishing reporting tools. * [Phishing email forwarding overview](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview): prerequisites, phishing configuration in Radiant, and how to choose a forwarding method for your environment. ### Storage and retention Radiant Log Management stores all ingested security data with flexible retention options. You can store data in Radiant-managed infrastructure or in your own AWS S3 bucket (BYOB). Radiant recommends BYOB for all production environments. * [Storage and Retention](/log-management/storage-and-retention): storage configuration options, retention policies, and how to choose between Radiant-managed storage and BYOB. * [Bring Your Own Bucket for Log Management](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management): configure an AWS S3 bucket as your primary log storage. * [Bring Your Own Bucket for Log Management with Terraform](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management-with-terraform): provision and configure your BYOB storage using Terraform. # Choose the Right Connection Method Compare Radiant Security ingestion methods (Agent, API connector, webhook, Syslog, AWS S3) and pick the right one for each data source. Compare Radiant's five ingestion methods and select the right fit for each data source in your stack. Radiant supports multiple methods for connecting your security tools and log sources. Each method targets a different environment and a different set of trade-offs. Choosing correctly during onboarding ensures every data source reaches the Radiant AI engine reliably, with the depth and coverage required for accurate alert triage. ### Ingestion methods at a glance Radiant supports five primary ingestion methods. The table below summarizes when each one applies; detailed guidance follows in the next section. | Method | Best for | How it works | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | [Radiant Security Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) | On-premises sources with no public-facing API | A Docker container deployed in your environment collects logs locally and forwards them to Radiant. | | API connector | Cloud-hosted tools that expose a vendor API | Radiant pulls alerts, events, and metadata directly from the vendor API on demand. | | Webhook | Sources that support outbound HTTP event push | The source pushes events to a Radiant webhook endpoint as they occur. | | Syslog | On-premises devices that support outbound log streaming | The device streams logs to Radiant over TLS on port 6514. | | [AWS S3 (BYOB)](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management) | High-volume log pipelines already consolidated in S3 | Radiant reads from a customer-owned S3 bucket, triggered by SNS notifications. | ### Method details {% tabs %} {% tab title="Radiant Security Agent" %} The Radiant Security Agent is a lightweight Docker container deployed in your environment, either on-premises or in a private cloud. It collects logs from local services and forwards them to Radiant. **Best for:** On-premises network devices and servers that are not internet-facing and cannot send data directly to a cloud service. Examples include Cisco, Fortinet, and Palo Alto firewalls. **Why use it:** The Radiant Security Agent is the right choice when a source cannot expose data over a vendor API, either because no API exists or because the available API is too limited to support reliable triage. **Trade-offs:** The Radiant Security Agent requires installation and configuration in your environment, which adds setup overhead compared to an API connector. Use the Radiant Security Agent when it is the only path to the data. If a vendor API exists, use that first. For setup instructions, see [Install the Radiant Security Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent). {% hint style="info" %} **Radiant Security Agent vs. Syslog.** If your on-premises device supports Syslog, the Radiant Security Agent is still the preferred approach. The Radiant Security Agent provides a managed, reliable forwarding mechanism with stronger operational guarantees. Syslog remains available when the Radiant Security Agent is not suitable for your environment. {% endhint %} {% endtab %} {% tab title="API connector" %} Use an API connector for any tool that exposes a vendor API. Radiant uses purpose-built connectors to pull alerts, events, and metadata directly from your security tools. **Best for:** Cloud-hosted tools with a vendor API. Common examples include Microsoft, CrowdStrike Falcon, Okta, and SentinelOne. **Why use it:** Vendor APIs are built for programmatic access and include mechanisms for scaling, throttling, and error handling. The connection is more reliable and feature-rich than a log stream, and Radiant can request exactly the data it needs, when it needs it, without over-ingesting. **Trade-offs:** Some vendor APIs impose rate limits or caps on query frequency. If your tool has restrictive API limits, ingesting the source data into Radiant Log Management may be a better fit. Radiant can then query its own copy of the data without external constraints. Your Radiant team can help you evaluate this during onboarding. {% endtab %} {% tab title="Webhook" %} Webhooks let your tools push events to Radiant as they occur, rather than waiting to be polled. **Best for:** Sources that support outbound HTTP event notifications but do not expose a queryable API. Common examples include Check Point Avanan, Elastic SIEM, Salt Security, and Vicarius. Webhooks also support custom internal solutions and custom correlation rules through Radiant's Custom Webhook Events and Custom Webhook Alerts connectors, which accept logs from any source that meets the required field and format prerequisites. **Why use it:** Webhooks are quick to set up and deliver events with low latency. They are a good fit when an API connector is not available and the source can reliably push the data Radiant needs. **Trade-offs:** Webhooks are less reliable and less feature-rich than API connectors. There is no built-in error handling, retry logic, or request-level context. You receive the raw event stream and nothing more. For sources where data completeness matters, prefer an API connector or the Radiant Security Agent. {% endtab %} {% tab title="Syslog" %} Syslog is a push-based forwarding option for on-premises devices that support outbound log streaming. **Best for:** On-premises network devices or security tools that support Syslog where you need a lightweight setup without deploying the Radiant Security Agent. **Why use it:** Syslog is faster to configure than the Radiant Security Agent and works well for sources where you do not need the full reliability and feature set of an API connector or managed forwarder. **Trade-offs:** Syslog has no built-in error handling, retry logic, or request-level context. For data sources where completeness matters, the Radiant Security Agent is the stronger choice. {% hint style="info" %} Syslog connections to Radiant require TLS on port 6514 for secure transport over the internet. {% endhint %} {% endtab %} {% tab title="AWS S3 (BYOB)" %} With Bring Your Own Bucket (BYOB), Radiant ingests data directly from an S3 bucket you own and manage. When new logs land in the bucket, an SNS notification triggers Radiant to process the data, typically within minutes. **Best for:** High-volume log pipelines, compliance-driven retention requirements, and environments where you consolidate data in S3 before forwarding to Radiant. BYOB also fits sources that lack a real-time API but can export to S3. **Why use it:** BYOB lets you retain full ownership and long-term storage of raw logs outside of Radiant while still feeding Radiant the data it needs for triage. **Trade-offs:** BYOB reads from your bucket at a controlled pace and does not impact your storage performance. Setup is lightweight and requires no infrastructure on your end beyond the S3 bucket itself. For setup instructions, see [Bring Your Own Bucket (BYOB)](/log-management/bring-your-own-bucket-byob/bring-your-own-bucket-for-log-management). {% endtab %} {% endtabs %} ### Decision guide Work through these questions in order. Stop at the first match and use that ingestion method.
Does the source expose a vendor API? Use an **API connector**. This is the default for cloud-hosted tools and the most feature-rich option, with built-in handling for scaling, throttling, and error recovery.
Is the source on-premises with no internet-facing API? Use the **Radiant Security Agent**. The Agent is the most reliable way to collect and forward data from environments that cannot expose a vendor API.
Does the source push events over HTTP? Use a **webhook** when an API connector is not available. Webhooks are quick to set up and deliver events with low latency, but offer fewer reliability guarantees than an API connector.
Is the source on-premises and Syslog-capable, but the Radiant Security Agent is not viable? Use **Syslog** as a fallback. Syslog is faster to configure than the Radiant Security Agent but lacks the same operational guarantees.
Are you ingesting high-volume logs already consolidated in S3, or do you need to retain ownership of the raw log archive? Use **AWS S3 with a customer-managed bucket (BYOB)**. BYOB is purpose-built for high-volume pipelines and lets you keep full ownership of your raw log archive.
### Ingest into Log Management or query on demand Not every source needs to be fully ingested into Radiant Log Management. For some sources, Radiant can query data on demand rather than indexing and storing all of it. This reduces ingestion volume and avoids retaining data you may not need in Radiant. The trade-off is that on-demand querying leaves your data in two places: the original SIEM or external platform, and Radiant. If you want a single search surface across all of your security data, ingesting into Log Management gives you that unified view. External platforms also impose their own limits on API calls and data lake queries. Ingesting into Log Management removes that dependency. Radiant controls its own query layer without being subject to third-party rate limits. Your Radiant team can help you decide what makes sense for each source during onboarding. # Phishing email forwarding overview Set up phishing and BEC report forwarding from Microsoft 365, Google Workspace, KnowBe4, or Proofpoint PhishAlarm into Radiant Security. Radiant triages user-reported phishing and business email compromise (BEC) reports as part of its alert triage pipeline. To begin triaging these reports, you forward them from your email platform or phishing reporting tool into a Radiant-managed mailbox. This article covers the prerequisites that apply to every forwarding method, the phishing configuration settings in Radiant, and how to choose the right forwarding method for your environment. The phishing use case requires a few setup steps that other connectors do not. Most importantly, enabling the domains you want Radiant to monitor and choosing whether to triage junk and spam reports. Complete the steps in this article in order. ### Prerequisites Before you configure phishing email forwarding, confirm the following: * [ ] Admin access to the email platform or reporting tool you plan to use for forwarding. * [ ] An **Email Data Connector** (Microsoft 365 or Google Workspace) is configured and tested end-to-end. Radiant must be ingesting your email logs before you forward phishing reports. * [ ] The **Microsoft Entra ID Data Connector** is configured. This feed provides the list of domains your organization owns, which Radiant uses to determine which reports to triage. {% hint style="warning" %} **Important note:** The Microsoft Entra ID data feed is required for the phishing use case to work. Without it, Radiant cannot determine which domains belong to your organization and will not triage forwarded reports. {% endhint %} An **Email Action Connector** is recommended but not required. Without one, Radiant ingests and triages phishing reports but cannot execute response actions such as quarantining messages or disabling forwarding rules. ### Configure phishing settings in Radiant Phishing configuration in Radiant has two tabs: **Monitored Domains**, where you enable the domains Radiant should triage reports for, and **Phishing Triage Tuning**, where you choose whether to triage junk and spam reports alongside phishing reports. To open the page, sign in to [Radiant Security](https://app.radiantsecurity.ai/) and go to **Settings > Organization > Phishing Configuration**. #### Enable monitored domains Radiant only triages reports for domains you explicitly enable. This prevents triage of reports unrelated to your organization, such as messages forwarded from personal accounts. {% stepper %} {% step %} #### Open the Monitored Domains tab On the Phishing Configuration page, select the **Monitored Domains** tab. The tab lists every domain synchronized from your Microsoft Entra ID data feed, along with the user count and the source data connector.
{% endstep %} {% step %} #### Toggle on each domain you want monitored For each domain you want Radiant to monitor, toggle **Monitor domain** on. {% hint style="success" %} **Tip:** Only enable domains that send or receive email relevant to your organization’s security posture. {% endhint %} {% endstep %} {% endstepper %} #### Choose how to handle junk and spam reports The **Triage junk/spam emails** toggle controls whether Radiant triages junk and spam reports alongside phishing reports. By default, this setting is enabled. {% stepper %} {% step %} #### Open the Phishing Triage Tuning tab On the Phishing Configuration page, select the **Phishing Triage Tuning** tab.
{% endstep %} {% step %} #### Set the Triage junk/spam emails toggle * Toggle **on** to triage all forwarded reports, including junk and spam. * Toggle **off** to exclude junk and spam reports from triage. Radiant will only triage messages a user explicitly flagged as phishing. {% endstep %} {% endstepper %} {% hint style="info" %} **Note:** This setting applies regardless of email platform. You do not need to also configure your email platform to suppress junk or spam forwarding — the Radiant toggle is the canonical control. {% endhint %} ### Choose a forwarding method Choose one method based on your email platform and reporting tool. You only need to configure one of the following.
MethodUse this ifTarget
Microsoft 365You use Microsoft 365 with the built-in Report Phishing button./pages/SrUTEK5X0ewEw8wtuFhD
Outlook on the webYou need per-mailbox conditional forwarding without changing tenant-wide policy./pages/9nTEGwqNPGcAJGjVPSPO
Google WorkspaceYour organization runs on Google Workspace./pages/TKNiHf30MPZZUSkreFOe
KnowBe4 PhishERYour users report phishing through the KnowBe4 Phish Alert Button./pages/9U5LMbtoQKDn7B5QdZFo
Proofpoint PhishAlarmYour users report phishing through the Proofpoint PhishAlarm button./pages/7ROTAzrRgelbahdAe9SZ
{% hint style="info" %} **Note:** Microsoft 365 customers using KnowBe4 have two options — the native Microsoft 365 path and the KnowBe4 path. Use the KnowBe4 path if the Phish Alert Button is your standard reporting tool. Use the native Microsoft 365 path if users report through the built-in Microsoft Report Phishing button. {% endhint %} ### Verify ingestion After you complete a forwarding setup, confirm Radiant is ingesting and triaging reports correctly: 1. Send a test message to a mailbox in your organization and report it as phishing using your standard reporting tool. 2. Sign in to [Radiant Security](https://app.radiantsecurity.ai/) and check the **Alerts** and **Cases** tabs for the triaged report. If the report does not appear, see the troubleshooting guidance in your platform-specific forwarding article. # Forward phishing emails from Outlook on the web Use Outlook on the web inbox rules to forward user-reported phishing emails to Radiant Security from a single mailbox without changing tenant-wide forwarding policy. In this article, you create an inbox rule in Outlook on the web that forwards messages from a single mailbox to Radiant Security based on conditions you define. Inbox rules let you forward a subset of messages (e.g, reports from a specific group of users or messages matching a subject pattern) without changing tenant-wide forwarding policy. ### Prerequisites Before you create the inbox rule, confirm the following: * [ ] You have completed the steps in the [phishing email forwarding overview](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview), including enabling your monitored domains. * [ ] You have access to the mailbox that receives phishing reports from end users (for example, `phishing@example.com`). * [ ] You can sign in to Outlook on the web as the owner of that mailbox or with delegated access that allows rule management. ### Create the conditional forwarding rule {% stepper %} {% step %} #### Open the rule manager Sign in to Outlook on the web as the owner of the mailbox that receives phishing reports. Click **Rules > Manage Rules** to open the rule manager.
{% endstep %} {% step %} #### Add a new rule Click **+ Add new rule**.
{% endstep %} {% step %} #### Configure the rule name, condition, and action Set the following: * **Name:** `Forward to Radiant Security` * **Condition:** From the **Add a condition** dropdown, select the condition that matches the messages you want to forward. The example below uses **From** to match messages from specific senders. * **Action:** From the **Add an action** dropdown, select **Redirect**, then enter `alerts@report.radiantsecurity.ai`. {% hint style="info" %} **Note:** **From** is one of several conditions available. Choose the condition that best matches the messages you need to forward (e.g., **Subject includes** for messages with a specific phishing report tag, or **To** for messages sent to a particular alias). Adding multiple conditions combines them with AND. {% endhint %} {% endstep %} {% step %} #### Stop processing more rules Select the **Stop processing more rules** checkbox. This prevents other rules from acting on a message after it has been redirected to Radiant. {% hint style="warning" %} **Important note:** Outlook processes inbox rules top to bottom and applies the first matching rule. If you have other rules that should run before the forwarding rule, move them higher in the rule list and leave **Stop processing more rules** disabled on those rules. {% endhint %} {% endstep %} {% step %} #### Save the rule Click **Save** to create the rule. {% endstep %} {% endstepper %} ### Verify the integration After you save the rule, confirm reports are reaching Radiant: 1. Send a message to the mailbox where you created the rule. The message must match the condition you set (e.g., if you used **From**, send the test message from one of the listed sender addresses). 2. Sign in to [Radiant Security](https://app.radiantsecurity.ai/) and check the **Alerts** and **Cases** tabs for the triaged report. If the report does not appear, confirm the following: * The rule's condition matches the test message you sent. * The redirect action is set to exactly `alerts@report.radiantsecurity.ai`. * The forwarding rule is positioned above any other rule that might process the message first. * The mailbox owner's domain is enabled in [Radiant's Monitored Domains](https://app.radiantsecurity.ai/settings/organization/phishing-configuration) tab. # Forward phishing emails from Gmail Configure Gmail or Google Workspace to forward user-reported phishing emails to Radiant Security using a group, a dedicated inbox, or a default route. In this article, you configure Gmail to automatically forward user-reported phishing emails to Radiant Security. Three methods are available depending on how your phishing reporting mailbox is set up. Choose the method that best matches your environment. ### Prerequisites * [ ] Admin access to Google Workspace, or access to the phishing account's inbox and settings (depending on the method you choose) * [ ] You have completed the steps in the [phishing email forwarding overview](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview), including enabling your monitored domains. ### Choose a forwarding method Three methods are available. Choose one based on how your organization currently receives phishing reports. {% tabs %} {% tab title="Google Workspace group" %} Use this method if your users currently report phishing emails to a Google Workspace group. In this phase, you add the Radiant Security alerts alias to the existing phishing group so that Radiant receives a copy of every user report. 1. Open the [Google Workspace admin portal](https://admin.google.com/). 2. Click **Directory**, then **Groups**. 3. Find the phishing group in the list. 4. Click **Add members**. 5. Add the Radiant Security alias: `alerts@report.radiantsecurity.ai` to the group. {% endtab %} {% tab title="Dedicated phishing inbox" %} Use this method if you have a dedicated Google Workspace phishing account with its own inbox. {% hint style="info" %} **Note:** This method requires you to have access to the phishing account inbox and settings. {% endhint %} In this phase, you add a forwarding rule on the dedicated phishing account that forwards every received message to Radiant. 1. Sign in to the phishing account and open the Gmail inbox. 2. Click the settings icon, then click **See all settings**. 3. Select **Forwarding and POP/IMAP**. 4. Use **Add a forwarding address** to add the Radiant Security alias: `alerts@report.radiantsecurity.ai`. 5. Set **Forward a copy of incoming mail to** to the added email address and click **Save**. {% hint style="info" %} **Note:** If you are already forwarding a copy to another destination, you may have to add this second destination as a mail rule instead. {% endhint %} {% endtab %} {% tab title="Default route with an additional recipient" %} Use this method if you have either a group-based or a dedicated phishing account setup. It works for both. In this phase, you add a Gmail default route that adds the Radiant Security reporting email as an additional recipient of messages sent to the phishing alias. 1. Open the [Google Workspace admin portal](https://admin.google.com/). 2. Go to **Apps > Google Workspace > Gmail**. 3. Open the **Default** routing page. 4. Click **Add another rule**. 5. In the **Specify envelope recipients to match** section, enter the email address of your phishing inbox.
6. In the **If the envelope recipient matches the above, do the following** section, select the **Also deliver to > Add more recipients** checkbox. 7. In the **Envelope recipient** section, click **Replace recipient** and enter the Radiant Security email: `alerts@report.radiantsecurity.ai`. {% hint style="warning" %} **Important note:** Unselect the **Do not deliver spam to this recipient** option, as it may prevent phishing emails from being properly forwarded. {% endhint %}
8. Under **Options**, select **Perform this action on non-recognized and recognized addresses**.
9. Click **Save**. {% endtab %} {% endtabs %} ### Verify the integration After you complete the forwarding setup, confirm reports are reaching Radiant. 1. From any mailbox in your organization, send a test message to the phishing reporting destination (group, dedicated inbox, or alias) you configured above. 2. Sign in to [Radiant Security](https://app.radiantsecurity.ai/) and check the **Alerts** and **Cases** tabs for the triaged report. If the report does not appear, confirm the following: * The Radiant Security alias is exactly `alerts@report.radiantsecurity.ai`. * The forwarding configuration matches the method you chose: alias added to the group, forwarding rule on the dedicated inbox, or default route with an additional recipient. * For the default route method, **Do not deliver spam to this recipient** is unselected. * The reporter's domain is enabled in [Radiant's Monitored Domains](https://app.radiantsecurity.ai/settings/organization/phishing-configuration) tab. # Forward phishing emails from KnowBe4 Configure the KnowBe4 Phish Alert Button to forward user-reported phishing emails to Radiant Security on Microsoft 365 or via the Chrome extension. In this article, you configure the KnowBe4 Phish Alert Button (PAB) to forward user-reported phishing emails to Radiant Security. PAB configuration is the same regardless of how you deploy it. After you set the forwarding address in KnowBe4, you complete the deployment-specific steps for your environment. ### Prerequisites Before you configure KnowBe4 forwarding, confirm the following: * [ ] Admin access to KnowBe4 * [ ] You have completed the steps in the [phishing email forwarding overview](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview), including enabling your monitored domains. * [ ] The KnowBe4 Phish Alert Button is already deployed to your users on either Microsoft 365 or Chrome. If you have not deployed PAB yet, follow [KnowBe4's documentation](https://support.knowbe4.com/hc/en-us/articles/208969608-Phish-Alert-Button-PAB-Product-Manual#iv_01H8CHZ6DE0JZC4DB92E8X7X2N) before continuing. ### Configure the Phish Alert Button In this step, you set the Radiant Security mailbox as the forwarding destination for non-simulated phishing reports. This configuration applies to every PAB deployment in your KnowBe4 account. {% stepper %} {% step %} #### Open the Phish Alert settings In KnowBe4, go to **Account Integrations > Phish Alert**. {% endstep %} {% step %} #### Add the Radiant Security mailbox Edit the PAB configuration for **Send Non-Simulated Emails to** and add the Radiant Security address: `alerts@report.radiantsecurity.ai` {% endstep %} {% step %} #### Save your changes Click **Save Phish Alert Settings**. {% hint style="info" %} **Note:** New PAB configuration takes time to propagate across your users' inboxes. {% endhint %} {% endstep %} {% endstepper %} ### Apply deployment-specific configuration PAB configuration in KnowBe4 is the same for every deployment, but the Chrome extension requires an additional configuration file. Choose the tab that matches your deployment. {% tabs %} {% tab title="Microsoft 365" %} No additional configuration is required. Your changes to **Send Non-Simulated Emails to** propagate automatically to users with the Microsoft 365 add-in installed. {% endtab %} {% tab title="Chrome extension" %} The Chrome extension requires a configuration file generated by KnowBe4 to apply the new forwarding address. {% stepper %} {% step %} **Download the Chrome extension config file** In the Phish Alert settings, download the **Chrome Extension PAB config file** (`phish_alert_configuration.json`). {% endstep %} {% step %} **Distribute the config file to your users** Follow KnowBe4's documentation to deploy the updated config file: [Google Workspace Phish Alert Button (PAB) Product Manual](https://support.knowbe4.com/hc/en-us/articles/115004304108). {% endstep %} {% endstepper %} {% endtab %} {% endtabs %} ### Verify the integration After you complete the deployment, confirm reports are reaching Radiant: 1. Send a test message to a mailbox in your organization. 2. Use the Phish Alert Button to report the test message as phishing. 3. Sign in to [Radiant Security](https://app.radiantsecurity.ai/) and check the **Alerts** and **Cases** tabs for the triaged report. If the report does not appear, confirm the following: * The forwarding address in **Send Non-Simulated Emails to** is exactly `alerts@report.radiantsecurity.ai`. * The user who reported the test message has the latest PAB configuration (KnowBe4 propagation may take time). * The reporter's domain is enabled in [Radiant's Monitored Domains](https://app.radiantsecurity.ai/settings/organization/phishing-configuration) tab. # Forward phishing emails from Microsoft 365 Configure Microsoft 365 to forward user-reported phishing emails to Radiant Security using the built-in Report Phishing button. In this article, you configure Microsoft 365 to automatically forward user-reported phishing emails to Radiant Security. Radiant needs access to the original reported message for analysis, which is done by forwarding emails from your dedicated in-house phishing reporting mailbox to a Radiant-managed mailbox for triage and investigation. This is the recommended path for Microsoft 365 customers using Microsoft's built-in Report Phishing button.
The setup has six phases. Complete them in order. When all six phases are complete, [report a test email](#report-a-test-email) to confirm the integration is working. ### Prerequisites * [ ] Admin access to Microsoft 365, including the Exchange admin center and Microsoft Defender portal * [ ] You have completed the steps in the [phishing email forwarding overview](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview), including enabling your monitored domains. ### Create a dedicated phishing reporting mailbox {% hint style="info" %} **Note:** If your organization already has a phishing reporting mailbox, skip to [Enable the Report Phishing button](#enable-the-report-phishing-button). {% endhint %} In this phase, you create a dedicated phishing reporting mailbox for your organization. 1. Sign in to the [Exchange admin center](https://admin.exchange.microsoft.com/) and go to **Recipients > Mailboxes**.
2. Click **+ Add a shared mailbox**. 3. Set the following: * **Display name:** `Phishing Mailbox` * **Email address:** `phishing` * **Select domain:** select your domain. 4. Click **Create** to save the new mailbox. ### Add Radiant Security as a remote domain In this phase, you enable forwarding emails from your domain to Radiant's external domain. 1. In the [Exchange admin center](https://admin.exchange.microsoft.com/#/remotedomains), go to **Mail flow > Remote domains**. 2. Click **+ Add a remote domain** and configure: * **Name:** `Radiant Security` * **Remote domain:** `report.radiantsecurity.ai` Click **Next**. 3. On the **Email reply types** page, confirm that **Allow automatic forwarding** is enabled.
4. Keep all default settings unchanged and click **Next**. Click **Next** again to skip the **Message reporting** and **Text and character set** pages, leaving them with the default settings. Click **Save** to add the external domain, then click **Done**. ### Add Radiant Security as a contact In this phase, you add Radiant Security as a contact so that Radiant receives the forwarded phishing emails to a mailbox on its side. 1. In the [Exchange admin center](https://admin.exchange.microsoft.com/#/contacts), go to **Recipients > Contacts**. 2. Click **Add a mail contact**. 3. Set the following contact details: * **Display name:** `Radiant Security Alerts` * **Alias:** `radiant-security-alerts` * **Email address:** `alerts@report.radiantsecurity.ai` 4. Leave the remaining fields blank and click **Next**. Skip the optional information page and click **Create** to finish the process. ### Configure auto-forwarding from the phishing reporting mailbox In this phase, you configure Microsoft 365 to automatically forward all suspected phishing emails to the Radiant Security Alerts contact created in the previous phase. 1. In the [Exchange admin center](https://admin.exchange.microsoft.com/#/mailboxes), go to **Recipients > Mailboxes**. Locate the **Phishing Mailbox** you created in the first phase and click its row. 2. In the pop-out menu, click the **Mailbox** tab, then click **Manage email forwarding**.
3. Enable the **Forward all emails sent to this mailbox** option, then click **Forward to an internal email address > Search email**.
4. Search for and select the **Radiant Security Alerts** contact created in the previous phase, click **Add**, then click **Save**. 5. On the mailbox configuration menu, click **Manage message size restriction** and set: * **Sent messages maximum size (KB):** `153600` * **Received messages maximum size (KB):** `153600` 6. Click **Save**. ### Allow external forwarding through the anti-spam outbound policy In this phase, you create an outbound anti-spam policy for the phishing reporting mailbox so that messages from that mailbox can be forwarded externally. 1. Sign in to the [Microsoft Defender portal](https://security.microsoft.com/) and go to the [Anti-spam policies](https://security.microsoft.com/antispam) page. You can also navigate from the left menu: **Email & Collaboration > Policies & rules > Threat policies > Anti-spam policies**. 2. Click **+ Create policy** and select **Outbound**. 3. Set the following: * **Name:** `Forwarding alerts to Radiant Security` * **Description:** `Policy used to forward possible phishing mails from the internal phishing@ mailbox to Radiant Security` Click **Next**. 4. Under **Users, groups, and domains**, in the **Users** field, select the `Phishing Mailbox` you created in the first phase. Leave **Groups** and **Domains** blank. 5. Under **Protection settings**, in the **Forwarding rules** field, set **Automatic forwarding rules** to **On - Forwarding is enabled**. Leave all other defaults unchanged.
6. Click **Next** to review the policy, then click **Create** to save the forward rule. Click **Done** to exit the page. ### Enable the Report Phishing button In this phase, you enable the Microsoft 365 right-click action which allows a user to report suspected phishing emails to the dedicated phishing reporting mailbox you created in the previous phase. 1. In the [Microsoft Defender portal](https://security.microsoft.com/), go to the [User reported settings](https://security.microsoft.com/securitysettings/userSubmission) page. You can also navigate from the left menu: **Investigation & Response > Actions & Submissions > Submissions**, then click the gear icon.
2. Select the **Monitor reported messages in Outlook** checkbox. 3. For **Select an Outlook report button configuration**, select **Use the built-in Report button in Outlook**. 4. For **When a user reports an email**, select both: * **Ask the user to confirm before reporting** * **Show a success message after the message is reported**
5. For **Reported message destinations**, select **Microsoft and my reporting mailbox** from the dropdown.
6. For **Add an Exchange Online mailbox to send reported messages to**, enter and select the mailbox you created in the [Create a dedicated phishing reporting mailbox](#create-a-dedicated-phishing-reporting-mailbox) phase. It should appear as a suggested contact. 7. Leave all other default settings unchanged and click **Save**. ### Manage Not Junk reports Microsoft Defender enables the forwarding of "Not Junk" user reports by default. If your team does not want these specific reports to be triaged by Radiant, administrators can disable these notifications under **Email & collaboration > Policies & rules > Alert policy** in the [Microsoft Defender portal](https://security.microsoft.com/alertpoliciesv2). {% hint style="info" %} **Note:** You can also control whether Radiant triages junk and spam reports alongside phishing reports using the **Triage junk/spam emails** toggle on the Phishing Configuration page in Radiant. See [Configure phishing settings in Radiant](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview#configure-phishing-settings-in-radiant) on the overview article. {% endhint %} ### Report a test email In this phase, you report an email to confirm the integration is working and verify there is organizational knowledge on how to report phishing emails end-to-end. 1. From any mailbox in your organization, send a test message to yourself, then click on that email message. 2. Report the test message as phishing: * If you have configured the Report Phishing button, use it to report the test message as phishing. * If you have not configured the Report Phishing button, click the `…` icon and choose **Other reply actions > Forward as attachment**. In the **To** field, enter the dedicated phishing reporting mailbox address within your organization and send the email.
3. Sign in to [Radiant Security](https://app.radiantsecurity.ai/) and check the **Alerts** and **Cases** tabs for the triaged report. If the report does not appear, confirm the following: * The remote domain `report.radiantsecurity.ai` has **Allow automatic forwarding** enabled. * The auto-forwarding rule on the phishing reporting mailbox is set to forward to the **Radiant Security Alerts** contact. * The anti-spam outbound policy is applied to the phishing reporting mailbox and has **Automatic forwarding rules** set to **On**. * The Report Phishing button is configured to send reports to the phishing reporting mailbox. * The reporter's domain is enabled in [Radiant's Monitored Domains](https://app.radiantsecurity.ai/settings/organization/phishing-configuration) tab. # Forward phishing emails from Proofpoint PhishAlarm Configure the Proofpoint PhishAlarm button to forward user-reported phishing emails to Radiant Security. In this article, you configure the Proofpoint PhishAlarm button to automatically forward user-reported emails to a Radiant Security mailbox. To analyze these emails, Radiant requires copies of the originals, which are obtained by forwarding them from your environment to a designated Radiant address. PhishAlarm lets you choose which address receives these messages, such as a SOC mailbox or Radiant, for each email category, including simulated phish, potential phish, safelisted messages, and training emails. ### Prerequisites * [ ] Admin access to the Proofpoint Security Education Platform * [ ] You have completed the steps in the [phishing email forwarding overview](/radiant-connectors/connectors-and-data-ingestion/phishing-email-forwarding-overview), including enabling your monitored domains. ### Enable auto-forwarding to Radiant Security In this phase, you configure PhishAlarm to forward potential phishing reports to Radiant Security and ensure the original message attachments are included. 1. Sign in to the [Proofpoint Security Education Platform](https://login.threatsim.com/users/sign_in). 2. From the left side menu, go to **PhishAlarm > Settings**. 3. In the **Reported Email Handling** section, under **Potential phishing email handling**, toggle on the **Forward to the following email addresses** setting and add the Radiant Security mailbox address: `alerts@report.radiantsecurity.ai` 4. Scroll down to the **File Delivery Settings** section. 5. Select **Forward the included attachments in the reported email**.
6. Click **Save Changes**. ### Verify the integration After you save your changes, confirm reports are reaching Radiant. 1. From any mailbox in your organization, send a test message to yourself. 2. Use the PhishAlarm button to report the test message as phishing. 3. Sign in to [Radiant Security](https://app.radiantsecurity.ai/) and check the **Alerts** and **Cases** tabs for the triaged report. If the report does not appear, confirm the following: * The forwarding address in **Forward to the following email addresses** is exactly `alerts@report.radiantsecurity.ai`. * **Forward the included attachments in the reported email** is enabled in the **File Delivery Settings** section. * The reporter's domain is enabled in [Radiant's Monitored Domains](https://app.radiantsecurity.ai/settings/organization/phishing-configuration) tab. # Threat Intelligence Hub Radiant's unified enrichment layer combining Radiant built-in feeds (rTIS) and customer-supplied threat intelligence (cTIS) for AI triage. The Threat Intelligence Hub is the set of threat intelligence feeds Radiant queries during the Enrichment stage of AI triage. It combines two tiers: Radiant TIS (rTIS), built-in feeds that run on every tenant by default, and client TIS (cTIS), which lets you connect your own subscriptions into the same enrichment pass. ### How the Hub fits into triage Enrichment is the second stage of the AI triage pipeline, which sits inside the broader [Radiant data pipeline](/welcome-to-radiant/what-is-radiant-security/the-radiant-data-pipeline). During Enrichment, Radiant extracts artifacts from the alert (file hashes, IP addresses, URLs, domains, email addresses, hostnames, user identities, process names) and queries every feed applicable to each artifact type in parallel. The results flow into Planning and Execution and become citable sources on each artifact. ### Two tiers of feeds
#### Radiant TIS (rTIS) A curated set of commercial and community threat intelligence feeds that Radiant queries on your behalf. Enabled by default on every tenant, with no configuration required. See [Built-in threat intelligence feeds](/radiant-connectors/threat-intelligence-hub/built-in-threat-intelligence-feeds) for what rTIS covers and how its results appear in the artifact panel. #### Client TIS (cTIS) cTIS lets you connect threat intelligence subscriptions your team already holds. Once a credential is saved, the feed is queried automatically on every relevant triage alongside rTIS, with results attributed to your tenant. Radiant currently supports cTIS for VirusTotal. To connect it, see [VirusTotal](/radiant-connectors/threat-intelligence-hub/connect-your-own-threat-intelligence/virustotal). ### How enrichment results appear to analysts Threat intelligence results appear as cards in the **Reputation and threat intel** section of the artifact panel. The section can contain four card types: Radiant TIS, client TIS, Allow List, and Deny List. For details on each card type and how to read them, see [Built-in threat intelligence feeds](/radiant-connectors/threat-intelligence-hub/built-in-threat-intelligence-feeds). ### Availability The Threat Intelligence Hub is available to all Radiant tenants. rTIS is enabled by default. cTIS is opt-in per provider; configure it from the Credentials page in Settings.
TopicTarget
Built-in threat intelligence feeds/pages/qVYic2jYT1WQCMZG9CSq
Connect your own threat intelligence/pages/qGsOUyuCojSYaTSu1TvK
# Built-in threat intelligence feeds How Radiant TIS (rTIS) enriches every alert by default. Radiant TIS (rTIS) is the set of threat intelligence feeds Radiant queries on every tenant's behalf during the Enrichment stage of AI triage. This article explains what rTIS is, how its results appear in the artifact panel, and what other cards you may see alongside rTIS results. ### What rTIS covers rTIS is a curated set of commercial and community threat intelligence feeds covering domain, IP, URL, file hash, proxy, DNS, and geolocation intelligence. When an alert is triaged, Radiant extracts every artifact from the raw alert and queries every applicable rTIS feed in parallel. Verdicts feed into Planning and Execution and become citable sources on each artifact. {% hint style="success" %} rTIS is **always on**. Feeds are queried dynamically at the moment an artifact is enriched, not at alert ingestion. No customer configuration is required. {% endhint %} ### Feed reference Radiant currently queries the following built-in feeds:
FeedProviderArtifact typeWhat it covers
BinaryEdgeBinaryEdgeIP addressThreat feed covering scanner infrastructure and IPs observed engaging in malicious or suspicious activity.
Cisco UmbrellaCiscoDomainDomain reputation categorization across security categories (malware, phishing, command-and-control) and content categories.
FireHOLFireHOL communityIP addressAggregated community blocklists (Levels 1–4) of IPs associated with botnets, scanners, brute-force activity, and other attacker infrastructure.
Google Web RiskGoogleURLURL classification for malware, social engineering (phishing), and unwanted software.
MalwareBazaarabuse.chFile hashKnown-malicious file hashes with malware family labels, threat type tags, and first-seen timestamps.
MISPMISP communityIP address, DomainCurated indicators used primarily to suppress false positives, flagging IPs and domains belonging to major service providers (e.g., Microsoft 365, Windows 10 connection endpoints) so legitimate traffic isn't misclassified.
NSRLNISTFile hashKnown-good file hashes from the National Software Reference Library. Used to confirm legitimate system and application binaries and short-circuit triage when an actor is verified clean.
NVDNISTCVEVulnerability descriptions, CVSS scores, severity, and affected-product metadata from the National Vulnerability Database.
WHOISWhoisXMLDomainDomain registration metadata: registrar, creation date, registrant, name servers, and expiry. Used to surface signals like newly-registered or recently-transferred domains.
### Where rTIS appears in the artifact panel rTIS results surface in the **Reputation and threat intel** section of the artifact panel. To find it: 1. Open any alert and select an artifact (an IP address, file hash, URL, domain, or other artifact type) to open the artifact panel. 2. Scroll to the **Reputation and threat intel** section, which appears below the **Attributes** section. 3. The section is collapsible. Expand it to see every result Radiant retrieved for the artifact.
Cards only appear when there is a result to display. An artifact that produced no matches will show an empty or absent Reputation and threat intel section. This is expected and does not indicate a failure. ### How to read an rTIS card Each rTIS card shows: * The feed's vendor logo and feed name (e.g., Malware Bazaar or Google Web Risk). * **Radiant Security** as the sub-label. * A status pill colored by severity, showing the vendor's verbatim verdict (e.g., **Harmless**, **Found**, **Flagged**, **Neutral**). Radiant does not translate the wording. * The execution timestamp. * An icon in the top-right corner that opens a sub-drawer with the raw request and response (see [Inspect raw request and response data](#inspect-raw-request-and-response-data)).
### Inspect raw request and response data Click the icon in the top-right corner of any rTIS card to open a sub-drawer with: * **Request**: the query Radiant sent to the feed, with the execution timestamp. * **Response**: the raw vendor response, rendered as a searchable JSON tree. The raw request and response are useful for validating a verdict, troubleshooting an unexpected result, or escalating a finding with the original source data intact.
{% hint style="info" %} The **Reputation and threat intel** section reflects the results of a single enrichment pass. Cards represent the data that was available at the time the artifact was enriched. {% endhint %} ### Other cards in the same section Three other card types appear in the Reputation and threat intel section alongside rTIS cards: | Card type | Sub-label | Verdict | Appears when | | ----------------- | --------------------------- | ------------------------- | ----------------------------------------------- | | client TIS (cTIS) | Your tenant name | Vendor's verbatim verdict | A feed your team connected returns a result | | Allow List | Radiant Security Allow List | Always **Found** (green) | An artifact matches a Radiant-curated allowlist | | Deny List | Radiant Security Deny List | Always **Found** (pink) | An artifact matches a Radiant-curated denylist | Allow List and Deny List cards have no data-driven verdict; the match itself is the finding. To connect a cTIS provider, see [Connect your own threat intelligence](/radiant-connectors/threat-intelligence-hub/connect-your-own-threat-intelligence). # Connect your own threat intelligence How Client TIS (cTIS) lets you connect your own threat intelligence subscriptions to Radiant alongside Radiant's built-in feeds. ### How cTIS works When you connect a cTIS provider, Radiant queries that feed during Enrichment for every applicable artifact, in parallel with rTIS. There is no per-alert-type configuration, and prior triages do not need to be re-run. cTIS results surface as cards in the **Reputation and threat intel** section of the artifact panel. A cTIS card shows your tenant name on the sub-label line, which distinguishes it from rTIS cards (sub-label: **Radiant Security**). See [Built-in threat intelligence feeds](/radiant-connectors/threat-intelligence-hub/built-in-threat-intelligence-feeds) for the full card-reading guide. ### Supported providers Radiant currently supports cTIS for the following provider. See the connector guide for step-by-step setup instructions.
ProviderWhat it coversConnector guideCover image
VirusTotalFile, URL, domain, and IP reputation across 70+ antivirus engines./pages/0bgWzHYz9K7IJH9Gw2m7/files/CzzIG5I9c5ESwu1lh1rB
### Verify threat intel is active After connecting a provider, the feed is queried on the next triage that contains an applicable artifact. To confirm cTIS is contributing to enrichment: 1. Open any alert triaged after you saved the credential. 2. Select an applicable artifact (e.g., an IP address for AbuseIPDB or a file hash for VirusTotal). 3. In the artifact panel, scroll to the **Reputation and threat intel** section.
# VirusTotal Connect VirusTotal to Radiant as client TIS (cTIS) so file, URL, domain, and IP results enrich every alert. {% hint style="info" %} VirusTotal is a client TIS (cTIS) provider. Connecting it adds VirusTotal results to the **Reputation and threat intel** section of the artifact panel during Radiant AI triage. See [Connect your own threat intelligence](/radiant-connectors/threat-intelligence-hub/connect-your-own-threat-intelligence) for background on cTIS. {% endhint %} VirusTotal is a multi-engine threat intelligence service that analyzes files, URLs, domains, and IPs against 70+ antivirus engines. Once connected, VirusTotal enriches file hash, URL, domain, and IP artifacts during Enrichment. ### Prerequisites * [ ] You have an active VirusTotal account. * [ ] You know which VirusTotal license tier your account uses (public or premium). ### Create an API key To create a VirusTotal API key: 1. Sign in to [VirusTotal](https://www.virustotal.com/gui/sign-in). 2. Open your profile menu in the top-right corner and select **API key**.
3. Reveal and copy the API key (it may be masked by default; click the eye icon to display it). You will paste it into Radiant in the next section.
### Add VirusTotal to Radiant {% stepper %} {% step %} #### Open the Credentials page In Radiant, go to **Settings → Credentials**. {% endstep %} {% step %} #### Add a new credential Click **+ Add Credential**. The Add Credential modal opens to the **Credential Type** step. {% endstep %} {% step %} #### Select VirusTotal In the **Credential Type** step, select **VirusTotal**. The modal advances to the **Configure** step. {% endstep %} {% step %} #### Configure the credential Fill in the three fields: * **Credential Name**: a descriptive name. Use something that identifies the credential's owner or purpose if your team will manage more than one. * **API Key**: paste the API key you copied above. * **License Type**: select **public** for free-tier keys or **premium** for paid subscriptions. The info icon next to each option describes what each tier covers. {% endstep %} {% step %} #### Save the credential Save the credential. From this point, every triage automatically includes VirusTotal results alongside Radiant's rTIS built-in feeds. {% endstep %} {% endstepper %} ### Verify VirusTotal is active After connecting, the feed is queried on the next triage with an applicable artifact. To confirm: 1. Open any alert triaged after you saved the credential. 2. Select an applicable artifact (e.g., a file hash). 3. In the artifact panel, scroll to the **Reputation and threat intel** section. Results from VirusTotal appear as cards with your tenant name on the sub-label line.
Click the icon in the top-right corner of a VirusTotal card to open the sub-drawer, which includes a **View in VirusTotal** button that opens the matching report on the provider's site. For more on the card types and how to read them, see [Built-in threat intelligence feeds](/radiant-connectors/threat-intelligence-hub/built-in-threat-intelligence-feeds). # Data Connectors Welcome to data connectors documentation. Radiant Security ingests telemetry, alerts, event logs, and contextual data, such as identities, domains, and assets, directly from your security stack via each vendor’s native APIs. As soon as data arrives, our pipeline automatically correlates and enriches every record: user accounts are linked to host IPs, geolocation services resolve network addresses, and threat intelligence feeds layer in reputation and risk scores. This end-to-end enrichment fills any gaps left by the original feeds and ensures you see a single, coherent view of activity across your environment. ### The Data Connectors page To add data to Radiant Security or view all supported Data Connectors: 1. Click the **Settings** (gear) icon in the navigation menu. 2. Click **Data Connector**. 3. Click **+ Add Connector** to select the data source you'd like to connect from the available list.
# Cloud & Infrastructure # AWS # AWS API Connect Radiant to your AWS account via the AWS API connector to query live resource configurations during Enrichment. The AWS API connector lets Radiant query your AWS account directly during the Enrichment stage of alert triage. Unlike [AWS CloudTrail](/radiant-connectors/cloud-and-infrastructure/aws/aws-cloudtrail-and-guardduty), which records past API activity, the AWS API connector returns the current state of resources at investigation time. This includes active S3 bucket permissions, IAM policy attachments, EC2 security group rules, and GuardDuty findings. Configuring this connector takes three phases: create a credential in Radiant, add the data connector, and create an IAM role in AWS that Radiant can assume. You can create the IAM role manually or deploy it across multiple accounts with a CloudFormation StackSet. ### Prerequisites * [ ] AWS account access with permission to create IAM policies and IAM roles * [ ] If you use AWS Organizations and plan to deploy with a StackSet, permission to create StackSets in your management account * [ ] If your organization requires change request approval before modifying AWS configurations, initiate that process before you begin ### Add the credential in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings > Credentials** and click + **Add Credential**. 3. Select **Amazon Web Services API** from the list and click **Configure Credential**. 4. Under **Credential Name**, give the credential an identifiable name (e.g. `AWS API Credentials`). 5. Under **AWS Accounts**, choose one of the following: * **AWS Organizations users**: export a `.csv` file containing all your AWS account IDs by following the [AWS Organizations export instructions](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_export.html), then drag and drop the file into the upload box. * **All other users**: click **+ Add Manually** and enter each account ID. 6. Click **Add Credential** to save the changes. ### Add the AWS API data connector in Radiant Security 1. From the navigation menu, select **Settings > Data Connectors** and click **+ Add Connector**. 2. Search for and select the **Amazon Web Services API** option and then click **Data Feeds**. 3. Under Select your data feeds, select **AWS HTTP API** and click **Credentials**. 4. From the drop-down menu, select the **Amazon Web Services API** credential that you created in the previous section. 5. Click **Add Connector** to save the changes. 6. In the **Data Connectors** page, find the AWS API connector and click **View Details**. 7. Copy the **AWS External Role ID**. You'll use this value for the creation of the IAM role in the upcoming steps. {% hint style="info" %} If you use **AWS Organizations**, [configure the IAM role with a StackSet](#configure-the-iam-role-using-stacksets) to deploy it across all member accounts in one operation. For a single account or a small number of accounts, [configure the role manually](#configure-the-iam-role-manually). {% endhint %} ### Configure the IAM Role manually 1. Sign in to the **AWS Management Console** on your main account and navigate to **IAM > Policies > Create Policy**. 2. Under **Specify permissions**, select the JSON format and paste the following: {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "S3Api", "Effect": "Allow", "Action": [ "s3:GetBucketAcl", "s3:GetEncryptionConfiguration", "s3:GetBucketLogging", "s3:GetBucketPolicy", "s3:GetBucketPolicyStatus", "s3:GetBucketTagging", "s3:GetBucketWebsite", "s3:GetObjectAcl", "s3:GetObjectAttributes", "s3:GetAccountPublicAccessBlock", "s3:GetBucketPublicAccessBlock", "s3:GetObject", "s3:ListAllMyBuckets", "s3:ListBucket" ], "Resource": ["arn:aws:s3:::*", "arn:aws:s3:::*/*"] }, { "Sid": "EC2Api", "Effect": "Allow", "Action": [ "ec2:DescribeAddresses", "ec2:DescribeImageAttribute", "ec2:DescribeImages", "ec2:DescribeInstanceStatus", "ec2:DescribeInstances", "ec2:DescribeSecurityGroupRules", "ec2:DescribeSecurityGroups", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumeStatus", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications" ], "Resource": ["*"] }, { "Sid": "GuarddutyApi", "Effect": "Allow", "Action": ["guardduty:ListFindings", "guardduty:GetFindings"], "Resource": ["arn:*:guardduty:*:*:*"] }, { "Sid": "IAMApi", "Effect": "Allow", "Action": [ "iam:GetAccessKeyLastUsed", "iam:GetAccountAuthorizationDetails", "iam:GetAccountSummary", "iam:GetGroup", "iam:GetGroupPolicy", "iam:GetInstanceProfile", "iam:GetLoginProfile", "iam:GetMFADevice", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRole", "iam:GetRolePolicy", "iam:GetSAMLProvider", "iam:GetServiceLastAccessedDetails", "iam:GetServiceLastAccessedDetailsWithEntities", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAccessKeys", "iam:ListAccountAliases", "iam:ListAttachedGroupPolicies", "iam:ListAttachedRolePolicies", "iam:ListAttachedUserPolicies", "iam:ListEntitiesForPolicy", "iam:ListGroupPolicies", "iam:ListGroups", "iam:ListGroupsForUser", "iam:ListInstanceProfileTags", "iam:ListInstanceProfiles", "iam:ListInstanceProfilesForRole", "iam:ListPolicies", "iam:ListPoliciesGrantingServiceAccess", "iam:ListPolicyVersions", "iam:ListRolePolicies", "iam:ListRoles", "iam:ListUserPolicies", "iam:ListUserTags", "iam:ListUsers", "iam:ListVirtualMFADevices" ], "Resource": [ "arn:aws:iam::*:role/*", "arn:aws:iam::*:saml-provider/*", "arn:aws:iam::*:instance-profile/*", "arn:aws:iam::*:user/*", "arn:aws:iam::*:group/*", "arn:aws:iam::*:policy/*" ] }, { "Sid": "AccountApi", "Effect": "Allow", "Action": [ "account:GetAccountInformation" ], "Resource": ["*"] } ] } ``` {% endcode %} 5. Enter a policy name, review the settings, and click **Create policy**. #### Create the IAM role 6. Navigate to **Roles > Create role**. 7. For **Trusted entity type**, select **Custom trust policy**. Paste the following JSON into the text box: {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "${RS_CREDENTIAL_ID}" } } } ] } ``` {% endcode %} {% hint style="info" %} Replace `${RS_CREDENTIAL_ID}` with the **AWS External Role ID** you copied from the Radiant connector details page. {% endhint %} #### Attach the policy 8. On the **Add permissions** page, find and select the policy you created in step 1. #### Name and create the role 9. Set the role name to `radiant-aws-api-access-role`, review the settings, and click **Create role**. ### Configure the IAM Role using StackSets Use this method to deploy the IAM role across multiple AWS accounts in a single operation. This is the recommended approach for AWS Organizations. 1. In your main AWS Organization account, navigate to **CloudFormation > StackSets** and click **Create StackSet**. 2. Download the CloudFormation template: {% file src="/files/3NkwLX3iSDNoz0cGuaWU" %} 3. Open the file and replace `${RS_CREDENTIAL_ID}` with the **AWS External Role ID** you copied from the Radiant connector details page. 4. In the **Permissions** section, select **Service-managed permissions**. 5. In the **Prerequisite - Prepare template** section, select **Template is ready**. 6. In **Specify template**, click **Upload a template file** and upload your edited CloudFormation file. 7. In the **StackSet name** section, enter a name for the StackSet. 8. In the **Capabilities** section, acknowledge that IAM resources will be created.
#### Choose deployment targets 9. In **Deployment targets**, choose one of the following: * To deploy to all accounts in your organization, select **Deploy to organization**. * To deploy to specific accounts, select **Deploy to organizational units (OUs)**. Enter the **AWS OU IDs** for the target accounts, then select the **Intersection** filter and add the account numbers.
#### Specify regions and submit 10. In **Specify regions**, enter all regions where the StackSet should deploy. Review the configuration and click **Submit**. ### Verify ingestion After AWS API begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"aws_http_api_read"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # AWS CloudTrail Set up the AWS CloudTrail connector. In this guide, you will configure AWS CloudTrail to forward events and alerts to Radiant Security. CloudTrail logs API activity across your AWS environment. This guide assumes a clean slate: the service is currently not enabled. If your environment already uses CloudTrail, you can skip some steps. However, make sure to review all **Important note** callouts to ensure your configuration meets Radiant’s integration requirements. {% hint style="warning" %} **Important note:** These highlight important configuration details necessary for the setup to function properly. Adjust your environment accordingly. {% endhint %} ### Prerequisites This configuration requires the following: * [ ] AWS user permissions to create and update the following resources: IAM, CloudTrail, SNS, and KMS * [ ] Group all CloudTrail Logs into one account for event collection ### Configuration in AWS Before [configuring the connector on the Radiant Security](#create-the-credentials-and-enable-the-data-connector) app, you must set up CloudTrail and create an IAM Role on AWS. ### **Create and configure AWS CloudTrail** Amazon CloudTrail is a service provided by AWS that allows you to enable logging of AWS API calls. This is useful for auditing, compliance, and security purposes. Below are the general steps for creating and configuring AWS CloudTrail. {% hint style="info" %} **Note**: The ARN of S3, SNS, and KMS (if enabled) will be used when configuring the IAM role and the Radiant Security connector. Be sure to copy and store those values. {% endhint %} {% hint style="info" %} **Note**: You need to perform this step using the **Management Account** for the AWS Organizations or use an account that is **Delegated Administrator for AWS Organizations.** Otherwise the checkbox **Enable for all accounts in my organization** won't be available. {% endhint %} 1. Sign in to the **AWS Management Console**. 2. Navigate to **CloudTrail**. 3. On the CloudTrail service home page, select **Create trail.** 4. In the **Choose trail attributes** page, configure the trail with the following required settings: * Enter a name for your trail. We suggest `management-events`. * Select the **Enable for all accounts in my organization** checkbox. This will gather logs from all accounts. This option is available only to administrator accounts. * For **Storage location**, choose where to store the logs. You can create a new S3 bucket or use an existing bucket. * Optionally, if you'd like to enable log encryption select the checkbox for **Log file SSE-KMS encryption**. Choose to set a **New** KMS alias. We suggest naming it: `cloudtrail-log-encryption`. * Under **Additional** **settings**, enable the **SNS** notification delivery by selecting the checkbox. Choose to use a **New** **SNS**.
{% hint style="warning" %} **Important note**: Ensure that the checkbox titled **Enable for all accounts in my organization** is selected and enabled. If you choose to use an existing S3 bucket, KMS or SNS topic, make sure that they have the correct policies set to allow CloudTrail to perform necessary actions such as encrypting S3 files and publishing to the SNS topic. By creating those resources during this configuration, AWS will take care of those permissions. {% endhint %} 5. Now, you'll need to configure the log events: * On the **Choose log events** page, under **Events** select the **Management events** and **Data events** checkboxes. While selecting **Data events** is optional, we recommend enabling it to improve RCA/Investigation.
* For **Management events,** under **API activity** select the **Read** and **Write** checkboxes.
* For **Data events,** Under **Data event type** select **S3** from the drop-down. In the **Log selector template** select **Log all events** from the drop-down. Alternatively, you can select the specific events from S3 you want to monitor.
6. Review the settings you've chosen for your trail. When you're ready to create your trail, click **Create trail.** {% hint style="success" %} **Tip:** For more details on how to create a trail, you can review the AWS documentation on [creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html). {% endhint %} ### **Create the credentials and enable the data connector** Next, you'll add the necessary credentials and enable the AWS data connector so that Radiant Security can automatically subscribe to the SNS topic and collect the CloudTrail. The following steps outline how to add the credentials and enable the data connector. 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. Navigate to **Settings** on the sidebar. 3. From the navigation menu, click **Settings** > **Services** > **Credentials**. 4. Click **+** **Add Credential**. 5. From the list of credentials, select **Amazon Web Services** and click **Credentials**. 6. Enter a **Credential Name** and fill in all of the fields with the respective values. Add the following values you saved from the previous steps: * **SNS Topic Name for CloudTrail** 7. Return to the **Settings** page and click **Data Connectors**. 8. Click **+ Add Connector**. 9. Search for and select the **Amazon Web Services** option and then click **Data** **Feeds**. 10. Select **Amazon Web Services CloudTrail.** 11. Select the credentials of this vendor from the drop-down. 12. Click **Add** **Connector** to save the connector. 13. Return to the **Settings** page. In **Data Connectors**, search for **Amazon Web Services**. 14. Click **View Details** and copy the **AWS External Role ID**. You'll use this value for the creation of the IAM role in the upcoming steps. {% hint style="info" %} **Note:** Save the **AWS External Role ID** to use in the upcoming steps for IAM roles. You'll replace the variable **${RS\_CREDENTIAL\_ID}** on the Custom trust policy with this ID. {% endhint %} ### Create and configure the IAM roles Finally, you’ll create and configure an Identity and Access Management (IAM) role in AWS roles to grant permissions to Radiant Security to access AWS resources. The following steps outline how to create and configure an IAM role. {% hint style="info" %} **Note:** The main account role must be configured on the account that will centralize the logs. {% endhint %} {% hint style="info" %} **Note:** Only add the KMS keys used for encryption in the last part. We must remove the last object if we do not use any KMS in the resources. {% endhint %} {% hint style="info" %} **Note:** For each account grouped under this main account, you must create and add an Arn Role to the last statement. Instructions for creating these roles are described in the next step [Create and configure an IAM Role (Other accounts)](https://help.radiantsecurity.ai/set-up-aws-connectors#other-accounts). {% endhint %} 1. Sign in to the **AWS Management Console** on the main account. 2. Navigate to **IAM**. 3. Select **Policies** and click **Create Policy**. 4. For **Specify Permission**, select the JSON format and use the JSON below: ``` {     "Version": "2012-10-17",     "Statement": [     {         "Sid": "AllowListAndGetAllLogFiles",         "Effect": "Allow",         "Action": [             "s3:Get*",             "s3:List*"         ],         "Resource": [             "arn:aws:s3:::*",             "arn:aws:s3:::*/*"         ]     },     {         "Sid": "AllowManagingSNSTopicSubscriptions",         "Effect": "Allow",         "Action": [             "sns:Subscribe",             "sns:Unsubscribe",             "sns:ConfirmSubscription"         ],         "Resource": [             "arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME_CLOUD_TRAIL}",         ]     },     {         "Sid": "EnableCrossAccountLogDecryption",         "Effect": "Allow",         "Action": [             "kms:Decrypt"         ],         "Resource": [             "arn:aws:kms:${REGION}:${AWS_ACCOUNT_ID}:key/${KMS_KEY_CLOUD_TRAIL}",         ]     },     {         "Sid": "AllowAssumeARoleInAnotherOrganizationAccount",         "Effect": "Allow",         "Action": [             "sts:AssumeRole"         ],         "Resource": [             "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ROLES_NAME}",             ...,             ...         ]     },   {             "Sid": "Statement5",             "Effect": "Allow",             "Action": [                 "organizations:ListPolicies",                 "organizations:DescribePolicy",                 "organizations:ListPoliciesForTarget",                 "organizations:DescribeResourcePolicy",                 "organizations:DescribeOrganization"             ],             "Resource": [                 "*"             ]         }     ] } ``` {% hint style="warning" %} **Important Note:** Replace all the variables with the ARN values that you copied and saved throughout the onboarding. {% endhint %} 5. Enter a **Policy name,** review the settings, and create the policy.
6. On the **Roles** page, and click **Create role**. 7. On the **Select trusted entity** page, select the following: * For **Trusted entity type**, select **Custom trust policy** to allow Radiant Security to use this role to access the account.
* For **Custom trust policy**, in the text box, add the following JSON, making sure to replace `${RS_CREDENTIAL_ID}` with the value provided in Radiant Security connector’s page: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRadiantSecurity", "Effect": "Allow", "Principal": { "AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "${RS_CREDENTIAL_ID}" } } } ] } ``` This line: `"AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security"` might be highlighted as an error in the AWS console. However, you can still save and use this policy. 8. On the **Add permissions** page, find and select the policy for the role.
9. Set the name to be `radiant-aws-access-role`, review and save the role.
{% hint style="info" %} **Note:** Our platform enforces that role name. This is for enhanced security. {% endhint %} ### Permissions | S3 | s3:Get\* | All | CloudTrail | Allows access to files and information from buckets. | | --- | ----------------------- | ---- | ---------- | ------------------------------------------------------------ | | S3 | s3:List\* | All | CloudTrail | Allow a list of all buckets and files. | | SNS | sns:Subscribe | Main | CloudTrail | Allow our queue to subscribe on SNS. | | SNS | sns:Unsubscribe | Main | CloudTrail | Allow our queue to unsubscribe on SNS. | | SNS | sns:ConfirmSubscription | Main | CloudTrail | Allow your system to confirm the subscription. | | KMS | kms:Decrypt | Main | CloudTrail | Allow to get the key and decrypt log files. | | STS | sts:AssumeRole | Main | CloudTrail | Allow assuming a role in other accounts in the organization. | ### Verify ingestion After AWS CloudTrail begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"aws_cloudtrail"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # AWS CloudTrail and GuardDuty Set up AWS CloudTrail and GuardDuty connectors. In this guide, you will configure AWS CloudTrail and GuardDuty to forward events and alerts to Radiant Security. CloudTrail logs API activity across your AWS environment, while GuardDuty detects suspicious behavior and potential threats. This guide assumes a clean slate: neither service is currently enabled. If your environment already uses CloudTrail or GuardDuty, you can skip some steps. However, make sure to review all **Important note** callouts to ensure your configuration meets Radiant’s integration requirements. {% hint style="warning" %} **Important note:** These highlight important configuration details necessary for the setup to function properly. Adjust your environment accordingly. {% endhint %} ### Prerequisites This configuration requires the following: * [ ] AWS user permissions to create and update the following resources: IAM, CloudTrail, GuardDuty, SNS, and KMS * [ ] Group all CloudTrail Logs into one account for event collection * [ ] Place all GuardDuty alerts across all of the monitored accounts into a single S3 bucket. For more information on how to manage multiple accounts in Amazon GuardDuty, please visit [this page](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html) ### Configuration in AWS Before configuring the connector on the Radiant Security app, you must set up CloudTrail and GuardDuty and create an IAM Role on AWS. ### **Create and configure AWS CloudTrail** Amazon CloudTrail is a service provided by AWS that allows you to enable logging of AWS API calls. This is useful for auditing, compliance, and security purposes. Below are the general steps for creating and configuring AWS CloudTrail. {% hint style="info" %} **Note**: The ARN of S3, SNS, and KMS (if enabled) will be used when configuring the IAM role and the Radiant Security connector. Be sure to copy and store those values. {% endhint %} {% hint style="info" %} **Note**: You need to perform this step using the **Management Account** for the AWS Organizations or use an account that is **Delegated Administrator for AWS Organizations.** Otherwise the checkbox **Enable for all accounts in my organization** won't be available. {% endhint %} 1. Sign in to the **AWS Management Console**. 2. Navigate to **CloudTrail**. 3. On the CloudTrail service home page, select **Create trail.** 4. In the **Choose trail attributes** page, configure the trail with the following required settings: * Enter a name for your trail. We suggest `management-events`. * Select the **Enable for all accounts in my organization** checkbox. This will gather logs from all accounts. This option is available only to administrator accounts. * For **Storage location**, choose where to store the logs. You can create a new S3 bucket or use an existing bucket. * Optionally, if you'd like to enable log encryption select the checkbox for **Log file SSE-KMS encryption**. Choose to set a **New** KMS alias. We suggest naming it: `cloudtrail-log-encryption`. * Under **Additional** **settings**, enable the **SNS** notification delivery by selecting the checkbox. Choose to use a **New** **SNS**.
{% hint style="warning" %} **Important note**: Ensure that the checkbox titled **Enable for all accounts in my organization** is selected and enabled. If you choose to use an existing S3 bucket, KMS or SNS topic, make sure that they have the correct policies set to allow CloudTrail to perform necessary actions such as encrypting S3 files and publishing to the SNS topic. By creating those resources during this configuration, AWS will take care of those permissions. {% endhint %} 5. Now, you'll need to configure the log events: * On the **Choose log events** page, under **Events** select the **Management events** and **Data events** checkboxes. While selecting **Data events** is optional, we recommend enabling it to improve RCA/Investigation.
* For **Management events,** under **API activity** select the **Read** and **Write** checkboxes.
* For **Data events,** Under **Data event type** select **S3** from the drop-down. In the **Log selector template** select **Log all events** from the drop-down. Alternatively, you can select the specific events from S3 you want to monitor.
6. Review the settings you've chosen for your trail. When you're ready to create your trail, click **Create trail.** {% hint style="success" %} **Tip:** For more details on how to create a trail, you can review the AWS documentation on [creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html). {% endhint %} ### **Create and configure Amazon GuardDuty** Amazon GuardDuty is a managed threat detection service that continuously monitors malicious or unauthorized activities in your AWS environment. The following steps outline how to create and configure Amazon GuardDuty. {% hint style="info" %} **Note:** Remember to copy and store all the **ARNs** created during the following steps as you will need them. {% endhint %} 1. Sign in to the **AWS Management Console**. 2. Navigate to S3 and create a bucket to store all logs ([AWS Tutorial](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html)). Store the S3 ARN as you will use in GuardsDuty settings. We suggest creating a **General purpose** bucket leaving the default settings unchanged. We also suggest naming the bucket: `{your_company_name}-guardduty-radiantsecurity`.
3. Navigate to KMS and create a key to cipher all logs ([AWS Tutorial](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)). Store the KMS key ARN as you will use in GuardsDuty settings. We suggest the default configurations with `guardduty-s3-radiantsecurity` as the **Alias** name. We will come back to this resource later to attach a policy allowing GuardDuty to use this key.
4. Navigate to **GuardDuty**. 5. Click **Enable GuardDuty**.
6. In the navigation pane, click **S3 Protection** and choose **Enable** to enable S3 monitoring.
7. Navigate to **Settings** to configure the **Findings export options**. * For **Edit frequency to publish updated findings**, select **15 minutes**. Click **Save changes**.
* For the **Edit** **S3 bucket**, add the S3 bucket ARN and the KMS key ARN created in the previous steps. GuardDuty enforces log encryption using KMS. Follow the AWS instructions to attach the policy to the S3 bucket and KMS key described in the second box on this page.
8. Still on GuardDuty settings, go to the **Delegated Administrator** section, fill your current account ID and click **Delegate**. {% hint style="info" %} **Note:** This section might be grayed out if the account you’re logged into does not have organization admin rights. If that is the case and you only want to monitor your current account, you can skip steps 15-18. {% endhint %}
9. On the left side menu, click **Accounts**. You should see a list of all the available accounts in your organization. 10. We recommend checking all accounts. You might want to uncheck those used for tests or without external exposure. On the **Actions** drop-down menu, click **Add** **member**.
11. Update the page and select all the previously selected accounts again. **On the Edit Protection Plans** Drop-down menu, for each option (Except 'Runtime Monitoring - Automated agent configuration'), click **Enable for `N` selected Accounts**.
Now that we have configured GuardDuty, we must configure event an event notification for when the findings are created. 12. Navigate to SNS and create a new **Topic** with **Standard** type. ([AWS Tutorial for creating an SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html)). We suggest naming it: `guardduty-s3-radiantsecurity`
13. On the topic page, you must configure the **Access Policy** to allow the S3 to publish the events on the SNS. * This is an example of the policy: {% hint style="warning" %} **Important Note:** Replace `arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME}` with the SNS arn and `${AWS_ACCOUNT_ID}` with your Account ID. {% endhint %} ``` { "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__default_statement_ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "SNS:Publish", "SNS:RemovePermission", "SNS:SetTopicAttributes", "SNS:DeleteTopic", "SNS:ListSubscriptionsByTopic", "SNS:GetTopicAttributes", "SNS:AddPermission", "SNS:Subscribe" ], "Resource": "arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME}", "Condition": { "StringEquals": { "AWS:SourceOwner": "${AWS_ACCOUNT_ID}" } } }, { "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "sns:Publish", "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "${AWS_ACCOUNT_ID}" }, "ArnLike": { "aws:SourceArn": "arn:aws:s3:::*" } } } ] } ``` 14. Navigate to **S3** and open the bucket configured on **GuardDuty**. 15. Navigate to the bucket **properties**. 16. Find the **Event notifications** section and click **Create event notification**.
17. On the **Create event notification** page, configure the notification with the following settings: * For **Event name**, enter a name for the event notification. We suggest `guardduty-new-finding` * For **Event** **types**, under **Object** **creation**, select **All object create events**.
18. For **Destination,** select the **SNS topic** and add the SNS topic that was created.
19. Review and save the settings you've chosen. ### **Create the credentials and enable the data connector** Next, you'll add the necessary credentials and enable the AWS data connector so that Radiant Security can automatically subscribe to both SNS topics and collect the CloudTrail and GuardDuty logs. The following steps outline how to add the credentials and enable the data connector. 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. Navigate to **Settings** on the sidebar. 3. From the navigation menu, click **Settings** > **Services** > **Credentials**. 4. Click **+** **Add Credential**. 5. From the list of credentials, select **Amazon Web Services** and click **Credentials**. 6. Enter a **Credential Name** and fill in all of the fields with the respective values. Add the following values you saved from the previous steps: * **SNS Topic Name for GuardDuty** * **SNS Topic Name for CloudTrail** 7. Return to the **Settings** page and click **Data Connectors**. 8. Click **+ Add Connector**. 9. Search for and select the **Amazon Web Services** option and then click **Data** **Feeds**. 10. Select **Amazon Web Services CloudTrail** and **Amazon Web Services GuardDuty.** 11. Select the credentials of this vendor from the drop-down. 12. Click **Add** **Connector** to save the connector. 13. Return to the **Settings** page. In **Data Connectors**, search for **Amazon Web Services**. 14. Click **View Details** and copy the **AWS External Role ID**. You'll use this value for the creation of the IAM role in the upcoming steps. {% hint style="info" %} **Note:** Save the **AWS External Role ID** to use in the upcoming steps for IAM roles. You'll replace the variable **${RS\_CREDENTIAL\_ID}** on the Custom trust policy with this ID. {% endhint %} ### Create an configure the IAM roles Finally, you’ll create and configure an Identity and Access Management (IAM) role in AWS roles to grant permissions to Radiant Security to access AWS resources. The following steps outline how to create and configure an IAM role. {% hint style="info" %} **Note:** The main account role must be configured on the account that will centralize the logs. {% endhint %} {% hint style="info" %} **Note:** Only add the KMS keys used for encryption in the last part. We must remove the last object if we do not use any KMS in the resources. {% endhint %} 1. Sign in to the **AWS Management Console** on the main account. 2. Navigate to **IAM**. 3. Select **Policies** and click **Create Policy**. 4. For **Specify Permission**, select the JSON format and use the JSON below replacing your ARN values for the resources created. {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowListAndGetAllLogFiles", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "", "/*", "", "/*" ] }, { "Sid": "AllowManagingSNSTopicSubscriptions", "Effect": "Allow", "Action": [ "sns:Subscribe", "sns:Unsubscribe", "sns:ConfirmSubscription" ], "Resource": [ "", "" ] }, { "Sid": "EnableCrossAccountLogDecryption", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "", "" ] } ] } ``` {% endcode %} 5. Enter a **Policy name,** review the settings, and create the policy.
6. On the **Roles** page, and click **Create role**. 7. On the **Select trusted entity** page, select the following: * For **Trusted entity type**, select **Custom trust policy** to allow Radiant Security to use this role to access the account.
* For **Custom trust policy**, in the text box, add the following JSON, making sure to replace `${RS_CREDENTIAL_ID}` with the value provided in Radiant Security connector’s page: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRadiantSecurity", "Effect": "Allow", "Principal": { "AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "${RS_CREDENTIAL_ID}" } } } ] } ``` This line: `"AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security"` might be highlighted as an error in the AWS console. However, you can still save and use this policy. 8. On the **Add permissions** page, find and select the policy for the role.
9. Set the name to be `radiant-aws-access-role`, review and save the role.
{% hint style="info" %} **Note:** Our platform enforces that role name. This is for enhanced security. {% endhint %} ### Permissions | S3 | s3:Get\* | All | CloudTrail, GuardDuty | Allows access to files and information from buckets. | | --- | ----------------------- | ---- | --------------------- | ------------------------------------------------------------ | | S3 | s3:List\* | All | CloudTrail, GuardDuty | Allow a list of all buckets and files. | | SNS | sns:Subscribe | Main | CloudTrail, GuardDuty | Allow our queue to subscribe on SNS. | | SNS | sns:Unsubscribe | Main | CloudTrail, GuardDuty | Allow our queue to unsubscribe on SNS. | | SNS | sns:ConfirmSubscription | Main | CloudTrail, GuardDuty | Allow your system to confirm the subscription. | | KMS | kms:Decrypt | Main | CloudTrail, GuardDuty | Allow to get the key and decrypt log files. | | STS | sts:AssumeRole | Main | CloudTrail, GuardDuty | Allow assuming a role in other accounts in the organization. | ### Optional: Export GuardDuty logs to the main account bucket In this section, you’ll export GuardDuty logs to the main account bucket. This section is marked as optional because you may have already done this. 1. For each sub account with its own GuardDuty, extract the detector identifier for each account. This is found on the **GuardDuty** > **Settings** page. 2. In the main account S3 bucket, edit the **Bucket** **policy** and add the following permissions, filling in the **SourceARN** for each GuardDuty detector: ``` {     "Sid": "Allow PutObject All GuardDuty",     "Effect": "Allow",     "Principal": {         "Service": "guardduty.amazonaws.com"     },     "Action": "s3:PutObject",     "Resource": "arn:aws:s3:::/*",     "Condition": {         "ForAnyValue:StringEquals": {             "aws:SourceArn": [                 "arn:aws:guardduty:::detector/",                 "arn:aws:guardduty:::detector/",                 ...             ]         }     } }, {     "Sid": "Allow GetBucketLocation All GuardDuty",     "Effect": "Allow",     "Principal": {         "Service": "guardduty.amazonaws.com"     },     "Action": "s3:GetBucketLocation",     "Resource": "arn:aws:s3:::/*",     "Condition": {         "ForAnyValue:StringEquals": {             "aws:SourceArn": [                 "arn:aws:guardduty:::detector/",                 "arn:aws:guardduty:::detector/",                 ...             ]         }     } } ``` 3. In the main KMS account, edit the permissions for the KMS configured to encrypt the S3 bucket files. Add the following, filling in the ARN for each GuardDuty detector: ``` {   "Sid": "Allow GuardDuty to encrypt findings All Accounts",   "Effect": "Allow",   "Principal": {     "Service": "guardduty.amazonaws.com"   },   "Action": "kms:GenerateDataKey",   "Resource": "*",   "Condition": {     "ForAnyValue:StringEquals": {       "aws:SourceArn": [                 "arn:aws:guardduty:::detector/",                 "arn:aws:guardduty:::detector/",                 ...       ]     }   } } ``` 4. After the permissions are set, execute the following command within each AWS account context (go to the AWS Console and execute it in the CloudShell): ``` aws guardduty create-publishing-destination --detector-id 0 --destination-type S3 --destination-properties DestinationArn=0,KmsKeyArn=0 --region 0 ``` 5. This command should finalize with the **DestinationID**: ``` {   "DestinationID": "xxx" } ``` 6. If the command fails and finalizes with the following message, then the permissions that were added in the previous steps were not correctly set up: ``` The command does not have proper permissions for the given KMS or destination ``` ### Recommended: Test GuardDuty integration with Radiant Security Since this is a lengthy integration that involves multiple AWS accounts, we highly recommend testing the integration from end-to-end. Refer to the [Test GuardDuty’s Integration with Radiant Security](/radiant-connectors/cloud-and-infrastructure/aws/aws-cloudtrail-and-guardduty/test-guarddutys-integration-with-radiant) guide to help you test GuardDuty integration. ### Verify ingestion After AWS CloudTrail and AWS GuardDuty begin forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by the `rs_connectorType` for each data feed you enabled:
Data feedFilter
Amazon Web Services CloudTrailrs_connectorType:"aws_cloudtrail"
Amazon Web Services GuardDutyrs_connectorType:"aws_guardduty"
3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Test GuardDuty’s integration with Radiant Test your AWS integration with a GuardDuty automation script. To test your AWS integration with Radiant Security, use the provided script to generate sample GuardDuty findings. After running the script, contact your Radiant Security representative to confirm that findings were successfully received from all connected AWS accounts. The following script is designed to automate the one-time generation of AWS GuardDuty sample findings across multiple AWS accounts and regions. It logs messages and errors, fetches enabled regions, and processes GuardDuty operations by creating sample findings. Use this guide to understand the script’s components and functionality. ### Prerequisites * [ ] AWS CLI installed and configured * [ ] Proper AWS IAM permissions to perform the following CLI calls: * `aws ec2 describe-regions` (in order to know which regions to run) * `aws guardduty list-detectors` * `aws guardduty create-sample-findings` * [ ] Access to a bash environment to run the script ### Bash script {% code overflow="wrap" %} ```bash #!/bin/bash # Path to the credentials file CREDENTIALS_FILE="credentials.txt" # Path to the log file LOG_FILE="results.log" # Function to log messages log_message() { echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" | tee -a "$LOG_FILE" } # Function to log errors log_error() { echo "$(date '+%Y-%m-%d %H:%M:%S') - ERROR: $1" >> "$LOG_FILE" } # Function to fetch enabled regions for the organization fetch_enabled_regions() { echo $(aws ec2 describe-regions --query "Regions[*].RegionName" --output text) } # Function to process each account's GuardDuty operations function process_guardduty_for_account() { local account_id="$1" local key_id="$2" local access_key="$3" local session_token="$4" local region="$5" log_message "Processing for Account ID $account_id in region $region..." # Fetch the first GuardDuty detector ID in the region local output output=$(AWS_ACCESS_KEY_ID="$key_id" AWS_SECRET_ACCESS_KEY="$access_key" AWS_SESSION_TOKEN="$session_token" AWS_DEFAULT_REGION="$region" aws guardduty list-detectors --query "DetectorIds[0]" --output text --region "$region" 2>&1) local status=$? if [ "$status" -ne 0 ]; then log_error "Failed to list detectors for Account ID $account_id in region $region: $output" return elif [ "$output" == "None" ]; then log_message "No GuardDuty detectors found for Account ID $account_id in region $region." return fi local detector_id="$output" log_message "Generating sample findings for Detector ID $detector_id..." output=$(AWS_ACCESS_KEY_ID="$key_id" AWS_SECRET_ACCESS_KEY="$access_key" AWS_SESSION_TOKEN="$session_token" AWS_DEFAULT_REGION="$region" aws guardduty create-sample-findings --detector-id "$detector_id" --finding-types 'UnauthorizedAccess:EC2/SSHBruteForce' --region "$region" 2>&1) status=$? if [ "$status" -ne 0 ]; then log_error "Failed to create sample findings for Account ID $account_id: $output" else log_message "Sample findings generated for Account ID: $account_id in region $region." fi } # Main function to initiate processing function main() { log_message "Starting GuardDuty operations..." # Assigns the first argument to credentials_path, or defaults to $CREDENTIALS_FILE if not provided. local credentials_path="$1" if [ -z "$credentials_path" ]; then credentials_path="$CREDENTIALS_FILE" fi # Assigns the second argument to accounts_list, or defaults to all accounts if not provided. local accounts_list=(${@:2}) local enabled_regions=($(fetch_enabled_regions)) local current_account_id local aws_access_key_id local aws_secret_access_key local aws_session_token while IFS= read -r line || [[ -n "$line" ]]; do case "$line" in \[*\]*) # Process the previous account if all data is available if [[ -n "$current_account_id" ]]; then if [ ${#accounts_list[@]} -eq 0 ] || [[ " ${accounts_list[*]} " =~ " $current_account_id " ]]; then for region in "${enabled_regions[@]}"; do process_guardduty_for_account "$current_account_id" "$aws_access_key_id" "$aws_secret_access_key" "$aws_session_token" "$region" done fi fi # Start new account block current_account_id=$(echo "$line" | sed -e 's/\[\(.*\)_.*\]/\1/') aws_access_key_id="" aws_secret_access_key="" aws_session_token="" ;; aws_access_key_id=*) aws_access_key_id="${line#*=}" ;; aws_secret_access_key=*) aws_secret_access_key="${line#*=}" ;; aws_session_token=*) aws_session_token="${line#*=}" ;; esac done < "$credentials_path" # Process the last account if all data is available if [[ -n "$current_account_id" ]] && [ ${#accounts_list[@]} -eq 0 ] || [[ " ${accounts_list[*]} " =~ " $current_account_id " ]]; then for region in "${enabled_regions[@]}"; do process_guardduty_for_account "$current_account_id" "$aws_access_key_id" "$aws_secret_access_key" "$aws_session_token" "$region" done fi log_message "GuardDuty operations completed." } # If no arguments are provided, the script will use the default credentials file and process all accounts. main "$@" ``` {% endcode %} ### Script components | **Variable** | **Description** | | ------------------ | --------------------------------------------------------- | | `CREDENTIALS_FILE` | Path to the credentials file. | | `LOG_FILE` | Path to the log file where all operations will be logged. | | **Function** | **Description** | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `log_message()` | Logs error messages with a timestamp into the log file. | | `log_error()` | Path to the log file where all operations will be logged. | | `fetch_enabled_regions()` | Returns a list of AWS regions where services are enabled for the organization. | | `process_guardduty_for_account()` | Processes GuardDuty operations for a specific account in a given region using the account's AWS credentials. It fetches the first GuardDuty detector and generates sample findings. | | `main()` | Main function that initiates the processing. It reads the credentials file, determines the list of accounts to process (all or specified ones), and iterates over each account and enabled region to process GuardDuty operations. | ### **Script operation** 1. **Logging:** The script maintains a detailed log of all operations, including errors, in **`results.log`**. 2. **Credentials Handling:** The script reads AWS credentials from a specified local file. It expects credentials to be in a specific format, where each account's credentials are separated by headers like **`[account_id_region]`**. Consult the example in this guide for more detail. 3. **Region Handling:** The script fetches the list of enabled AWS regions and processes each account for those regions. 4. **GuardDuty Processing:** For each account and each enabled region, the script attempts to list and create sample findings for GuardDuty detectors. ### Configuration **Credentials file** * Store AWS credentials in `credentials.txt` by default. * The format should be as follows for each account: ``` [account_id_1_name] aws_access_key_id=YOUR_ACCESS_KEY_1 aws_secret_access_key=YOUR_SECRET_KEY_1 aws_session_token=YOUR_SESSION_TOKEN_1 [account_id_2_name] aws_access_key_id=YOUR_ACCESS_KEY_2 aws_secret_access_key=YOUR_SECRET_KEY_2 aws_session_token=YOUR_SESSION_TOKEN_2 ``` **Log File** * All operations are logged in `results.log`. ### Usage Run the script by using the following command in the terminal: ``` ./generate_guardduty_findings.sh [credentials_file_path] [account_id1 account_id2 ...] ``` * **`credentials_file_path`**: Optional. Specify the path to your credentials file. Defaults to **`credentials.txt`**. * **`account_id1 account_id2 ...`**: Optional. Specify the list of account IDs to process. If omitted, the script processes all accounts listed in the credentials file. ### **Example** To process all accounts with the default credentials file, simply run: ```bash ./generate_guardduty_findings.sh ``` To process specific accounts (e.g., 123456789012 and 987654321098), use: ```bash ./generate_guardduty_findings.sh credentials.txt 123456789012 987654321098 ``` # Azure Activities Connect Azure Activities to Radiant Security to forward subscription-level events for AI triage. Azure Activities are the subscription-level resource events generated by Microsoft Azure, covering provisioning changes, role assignments, policy updates, and other administrative actions. Enabling the **Azure Activities** data feed on your existing Microsoft O365 connector forwards these events to Radiant Security. For background on Azure activity logging, see [Azure activity log](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log) in the Microsoft documentation. The Microsoft O365 connector already holds the **Application (client) ID**, **Directory (tenant) ID**, and **Client Secret Value** from initial onboarding. This article walks through the additional Azure-side configuration required for Azure Activities and the **Subscription IDs** you provide to Radiant when enabling the data feed. ### Prerequisites * [ ] Admin access to Azure * [ ] An existing [Microsoft O365](https://help.radiantsecurity.ai/radiant-connectors/data-connectors/microsoft-o365) connector in Radiant Security ### Register the application in Microsoft Entra ID 1. Sign in to the [Microsoft Azure Portal](https://portal.azure.com/#home). 2. From the left side menu, navigate to **Microsoft Entra ID**. 3. From the left menu, navigate to **App Registrations**. 4. Click **+ New Registration**.
5. Set the application **Name** to `radiantsecurity-connector` and leave all default settings unchanged.
6. Click **Register** to save the changes. 7. On the newly registered application page, copy the following values: * **Application (client) ID** * **Directory (tenant) ID**
8. On the same page, click the link for **Add a certificate or secret**.
9. In the **Certificates & secrets** pane, click **+ New client secret**. 10. Set the client secret as follows: * **Description**: `Radiant Security Connector` * **Expires**: `12 months`
11. Click **Add**. 12. On the client secrets page that opens, copy the **Value** (not the **Secret ID** field).
{% hint style="warning" %} Copy the **Client Secret Value** now. It cannot be retrieved later. {% endhint %} ### Grant API permissions to the registered application 1. On the left sidebar menu, click **API Permissions**. 2. Click **+ Add a permission**. 3. From the pop-out menu, select **Azure Service Management**.
4. Select the **user\_impersonation** permission.
5. Click **Add permissions**. ### Assign the Reader role for each subscription Each Azure subscription that should be monitored requires its own Reader role assignment for the registered application. Repeat the steps below for each subscription. 1. Open the **Subscriptions** page and select the subscription to configure.
2. From the left menu, click **Access control (IAM)**. 3. Click **+ Add**, then select **Add role assignment**.
4. On the **Role** page, search for and select **Reader**. Click **Next**.
5. On the **Members** page, click **+ Select members** and search for `radiantsecurity-connector`.
6. Select the application, then click **Select** at the bottom of the pane. 7. Click **Next**, then click **Review + Assign** to confirm the role. ### Enable the Azure Activities data feed in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**. 3. Click **View Details** on the Microsoft O365 data connector. 4. Under **Optional - Azure subscription IDs (comma separated)**, enter each subscription ID from your Azure Reader role assignments, separated by commas with no spaces after the commas. 5. Locate the row for the **Azure Activities** data feed under your existing **Microsoft O365** connector. 6. On the right side of the row, click **Enable**.
### Verify ingestion After Azure Activities begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"ms365_azure_activity"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # CrowdStrike Falcon CSPM Configure Radiant Security to sync CrowdStrike CSPM alerts. In this guide, you will create an API client with read-only credentials for CrowdStrike OAuth2 and use those to configure a data connector with Radiant Security. At the end of this configuration, you will provide Radiant Security with the following values: * **Client ID** * **Secret** * **Base URL** ### Prerequisites * [ ] Admin access to CrowdStrike Falcon ### **Create the credentials in CrowdStrike Falcon** 1. Sign in to [CrowdStrike Falcon](https://falcon.us-2.crowdstrike.com/login/) with an admin account. 2. Expand the side menu and click **Support and resources**. 3. Under **Resources** **and** **tools**, click **API clients and keys.**
4. Click **Create API**. 5. Enter a **Client** **Name** to help identify the credential.
6. Under **Scope**, select **CSPM Registration - Read**. 7. Click **Create.** 8. Copy and store the **Client ID,** **Secret**, and **Base URL** values.
### Create the data connector in Radiant Security 1. Log into [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **Crowdstrike OAuth2** option from the list and then click **Data Feeds**. 4. Under **Select your data feeds**, select **Falcon CSPM Alerts** and click **Credentials**. 5. In case you had already created credentials, select them from the drop-down and continue. If you haven’t created credentials yet, create one by giving the credential an identifiable name (e.g. `Crowdstrike Falcon CSPM Credentials`). Then, paste the values (**Base URL**, **Client** **ID**, and **Client** **Secret** **Key**) that you copied from the **Create the credentials in CrowdStrike Falcon** section. Leave the **Prefix** field empty. 6. Click **Add Connector** to save the changes. ### Verify ingestion After CrowdStrike Falcon CSPM begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"crowdstrike_cspm"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Generate CrowdStrike Falcon CSPM Read-Only Credentials Create CrowdStrike Falcon CSPM read-only credentials and forward them to Radiant Security securely. In this guide, you will create an API client with read-only credentials for Crowdstrike OAuth2. \ \ At the end of this configuration, you will provide Radiant Security with the following values: * **Client ID** * **Secret** * **Base URL** ### Prerequisites * [ ] Admin access to CrowdStrike Falcon ### **Create the credentials in CrowdStrike Falcon** 1. Sign in to [CrowdStrike Falcon](https://falcon.us-2.crowdstrike.com/login/) with an admin account. 2. Expand the side menu and click **Support and resources**. 3. Under **Resources** **and** **tools**, click **API clients and keys.** 4. Click **Create API**. 5. Enter a **Client** **Name** to help identify the credential. 6. Under **Scope**, select **CSPM Registration - Read**. 7. Click **Create.** 8. Copy and store the **Client ID,** **Secret**, and **Base URL** values. ### Share the credentials with Radiant Security 1. Log into [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Credentials** and click **+ Add Credential**. 3. Select the **Crowdstrike OAuth2** credential type from the list and click **Configure Credential**. 4. Give the credential an identifiable name (e.g. `Crowdstrike Falcon CSPM Credentials`) and paste the values (**Client** **ID**, **Client** **Secret** **Key**, and **Base URL**) that you copied from the **Create the credentials in CrowdStrike Falcon** section. Leave the **Prefix** value empty. 5. Click **Add Credential** to save the changes. # Google Cloud # GCP Audit Logs Connect GCP Audit Logs to Radiant Security to forward Google Cloud activity logs for AI triage. Google Cloud Audit Logs record administrative and data-access activity across your Google Cloud organization, capturing the user, service, and resource behind every API call. Connecting GCP Audit Logs forwards these logs to Radiant Security through a BigQuery sink that Radiant polls for new records. Radiant uses GCP audit activity during the Enrichment stage to attribute alerts to specific principals, projects, and resources, giving analysts a verifiable trail of who did what in your cloud environment. {% hint style="warning" %} GCP Audit Logs record every access made by users and services in your environment, which can drive unexpected costs for both Cloud Logging and BigQuery storage. Review the [Cloud Logging pricing guide](https://cloud.google.com/stackdriver/pricing) and the [Bigtable audit log cost guide](https://cloud.google.com/bigtable/docs/audit-log-estimate-costs) before enabling, and monitor Logging Storage usage under **Monitoring > Logs Storage** after rollout. {% endhint %} ### Prerequisites * [ ] Owner or Editor role on your Google Cloud organization * [ ] Logging Admin role at the organization level * [ ] BigQuery Admin role in the target project ### Enable audit logs As previously noted, some services may generate high volumes of logs, potentially increasing your billing costs. We recommend enabling logging for all services by following **steps 4** and **5**. If you later find that specific services are generating excessive logs, you can disable logging for them. To disable a specific log, follow **step 6**. 1. Open the [Google Cloud console](https://console.cloud.google.com/). 2. At the top of the page, set the scope to your **Organization**. 3. From the navigation menu, go to **IAM & Admin > Audit Logs**. 4. At the bottom of the page, set rows per page to **200** so every service is visible on one screen.
5. Select the checkbox in the column header to select all services. In the panel that appears, under **Permission Types**, select **Admin Read**, **Data Read**, and **Data Write**, then click **Save**.
6. (Optional) To disable logging for a specific service (e.g., Bigtable): * Search for and select the service. * In the panel that appears, under **Permission Types**, clear all log types and click **Save**.
### Create a service account The service account must live in the same project as the BigQuery dataset you will create in the next section. If you already have a service account for the GCP Security Command Center (SCC) connector in that project, you can reuse it and skip ahead to Create a BigQuery dataset. 1. Go to **IAM & Admin > Service Accounts**. 2. Click **Create Service Account**.
3. Enter the following: * **Service account name**: `radiant-audit-logs-connector` * **Service account description**: a description that identifies the account's purpose 4. Copy the **Email address** generated for the account. You will need it in a later step.
5. Click **Create and Continue**. 6. Under **Grant this service account access to project**, add both of the following roles: * **Log Viewer** * **BigQuery Admin**
7. Click **Continue**, then click **Done**. ### Create service account keys 1. On the **Service Accounts** page, click the account you created in the previous section. 2. Open the **Keys** tab, then click **Add Key > Create New Key**.
3. Select **JSON** and click **Create**. 4. The JSON file downloads automatically. Save it in a secure location. You will upload it to Radiant in the final step. ### Create a BigQuery dataset 1. From the navigation menu, open **BigQuery**. 2. In the **Explorer** panel, open the menu next to your project and click **Create dataset**.
3. Enter the following: * **Dataset ID**: `radiant_connector` * **Default maximum table age**: `30 Days`
4. Click **Create Dataset**. {% hint style="info" %} Double-check the spelling of the **Dataset ID**. You will reference this exact value when configuring the log sink in the next section. {% endhint %} ### Create a log sink {% hint style="warning" %} Confirm the scope at the top of the page is set to your **Organization** before continuing. The sink must capture logs from the entire organization, not a single project. {% endhint %} 1. Go to **Logging > Log Router**. 2. Click **Create sink**. 3. Enter the following: * **Sink name**: `radiant_audit_logs` * **Sink description**: a description that identifies the sink's purpose 4. Click **Next**.
5. Under **Select sink service**, select **BigQuery**. 6. For **Sink destination**, select **Use a BigQuery dataset in a project**. GCP auto-populates the destination as `bigquery.googleapis.com/projects/[PROJECT_ID]/datasets/[DATASET_ID]`. Replace `[PROJECT_ID]` with the ID of the project that holds the dataset, and `[DATASET_ID]` with `radiant_connector`.
7. Leave **Use partitioned tables** unselected and click **Next**. 8. Select **Include logs ingested by this organization and all child resources**. Leave **Build inclusion filter** empty and click **Next**.
9. Leave **Build exclusion filter** empty and click **Create Sink**. {% hint style="info" %} If GCP returns a **Permission Denied** error, confirm you hold the **Logging Admin** role at the organization level. The **Organization Admin** role alone is not sufficient. {% endhint %} ### Verify logs in BigQuery 1. Return to **BigQuery**. 2. Open the `radiant_connector` dataset. 3. Confirm that new tables appear and contain recent rows. The first tables typically appear within a few minutes of sink creation. ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings > Data Connectors**, then click **+ Add Connector**. 3. Search for and select **GCP Audit Logs**, then click **Data Feeds**. 4. Under **Select your data feeds**, select the **GCP Cloud Audit Logs** feed and click **Credentials**. 5. Under **Credential Name**, enter an identifiable name (e.g., `GCP Audit Logs Credentials`). 6. Under **Required Credentials**, in the **GCP project ID** field, enter the ID of the project that holds the `radiant_connector` dataset. 7. Under **Upload JSON File**, drag and drop the service account JSON key you downloaded earlier, or click **browse file** to select it. 8. Click **Add Connector**. ### Verify ingestion After GCP Audit Logs begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"gcp_audit_logs"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Google Cloud Security Command Center (SCC) Connect Google Cloud Security Command Center to Radiant Security to ingest GCP security alerts for AI triage. Google Cloud Security Command Center (SCC) aggregates vulnerability, misconfiguration, and threat findings across your GCP resources. Connecting SCC to Radiant Security streams these findings in as alerts for Radiant AI triage. SCC can be scoped two ways, and each requires a different setup path: * **Organization-wide.** SCC monitors all projects in your GCP organization. * **Project-wide.** SCC monitors a single GCP project. The setup steps in this article cover both scopes. Differences are called out where they apply. At the end of setup, you will provide Radiant with the following values: | Value | Organization-wide | Project-wide | | --------------------------- | :---------------: | :----------: | | ADC credentials (JSON file) | ✓ | ✓ | | Organization ID | ✓ | ✓ | | Project ID | | ✓ | ### Prerequisites * [ ] You have **Organization Admin** access in Google Cloud * [ ] You can access the GCP project where the service account will be created ### Enable the SCC API 1. In the Google Cloud console, open the [Enable access to API](https://console.cloud.google.com/flows/enableapi?apiid=securitycenter.googleapis.com) page. 2. Select the correct project: 1. If SCC is scoped to a project, select that project. 2. If SCC is scoped **organization-wide**, select any project in which you can create a service account. The location of the service account does not affect the connector. 3. Click **Next**, then click **Enable**. ### Create a service account Create a service account in the project where you enabled the API. This account retrieves findings from the SCC API. 1. In the [Google Cloud console](https://console.cloud.google.com/),, go to **IAM & Admin > Service Accounts**.
2. Confirm the project from the previous step is selected. 3. Click **+ Create service account** and enter the following: * **Service account name**: `Radiant-Connector` * **Service account ID**: `radiant-connector` (auto-generated) * **Service account description**: `Account used to retrieve security findings from SCC` 4. Copy the service account **Email address**. You will need it in a later step. 5. Click **Create and Continue**. 6. Under **Grant this service account access to project**, open the **Select a role** drop-down. Search for and select **Security Center Admin Viewer**. 7. Skip the optional third step and click **Done**. ### Create a service account key 1. On the **Service Accounts** page, click the newly created account. 2. Open the **Keys** tab, then click **Add Key > Create new key**. 3. For **Key type**, select **JSON**, then click **Create**. 4. The JSON file downloads automatically. Save it in a secure location. You will upload it to Radiant in the final step. ### Grant organization-wide access {% hint style="info" %} Skip this section if SCC is scoped to a single project. {% endhint %} 1. In the [Google Cloud console](https://console.cloud.google.com/), go to **IAM & Admin** and switch to the **organization** scope. 2. Click **+ Grant Access**. 3. Under **Add principals**, paste the service account email address you copied earlier into the **New principals** field. 4. Under **Assign roles**, open the **Role** drop-down. Search for and select **Security Center Admin Viewer**. 5. Click **Save**. ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings > Data Connectors**, then click **+ Add Connector**. 3. Search for and select **GCP Security Command Center (SCC)**, then click **Data Feeds**. 4. Under **Select your data feeds**, select the **GCP Security Command Center (SCC)** feed and click **Credentials**. 5. Under **Credential Name**, enter an identifiable name (e.g., `GCP Radiant Credentials`). 6. Enter the GCP **organization ID**. 7. If you are using project-wide scope, enter the GCP **project ID**. 8. Under **Upload JSON File**, upload the GCP credentials JSON file you downloaded earlier. 9. Click **Add Connector**. ### Verify ingestion After Google Cloud Security Command Center begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"gcp_scc"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Palo Alto Networks Prisma Cloud Connect Palo Alto Networks Prisma Cloud to Radiant Security to forward cloud security alerts for AI triage. Palo Alto Networks Prisma Cloud is a cloud-native application protection platform that secures cloud accounts, workloads, and services against misconfigurations, threats, and compliance gaps. Connecting Prisma Cloud forwards its security alerts to Radiant Security through the Prisma Cloud API. Radiant uses the alert data to triage these alerts in context, giving analysts faster verdicts on whether a flagged cloud resource or activity is a real risk or expected behavior. At the end of this configuration, you provide Radiant Security with the following values: * **API URL** * **Access Key ID** * **Secret Access Key** * **Prisma ID** (optional) ### Prerequisites * [ ] System Admin access to Prisma Cloud ### Generate API credentials in Prisma Cloud 1. On the Prisma Cloud Console, select **Settings** > **Access Control** > **Access Keys**, then select **Add** > **Access Key**. 2. Enter a **Name** for the key (e.g., `Radiant Security Integration`). 3. Select **Enable Expiration** and set an expiry term that meets your compliance standards. Without expiration, the key never expires. Radiant recommends a one-year term. 4. Click **Save**. {% hint style="info" %} Copy and store the Access Key ID and Secret Access Key now. They cannot be retrieved later. {% endhint %} ### Get your API URL and Prisma ID **API URL** Your console URL changes by region. Find your region and copy the matching API URL from [Prisma Cloud's API URLs reference](https://pan.dev/prisma-cloud/api/cspm/api-urls/). {% hint style="warning" %} Copy the Prisma Cloud API URL, not the Prisma Cloud admin console URL. {% endhint %} **Prisma ID** (optional) Provide the Prisma ID only in a multi-tenant environment. 1. From the console, select **Settings** > **License Information** or **Account Settings**. 2. On the **License** page, find the **Prisma ID** value and copy it. ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors**, then click **+ Add Connector** 3. Select **Palo Alto Prisma Cloud** from the list, then click **Credentials**. 4. Under **Credential Name**, enter an identifiable name (e.g., `Prisma Cloud API`). 5. Under **Required Credentials**, enter the values you collected: * **API URL** * **Access Key ID** * **Secret Access Key** * **Prisma ID** (optional) 6. Click **Add Connector** to save the configuration. ### Verify ingestion After Palo Alto Networks Prisma Cloud begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"pan_prisma"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Data Security & Insider Threat # Adaptive Shield Connect Adaptive Shield to Radiant Security to forward SaaS security posture alerts for AI triage. Adaptive Shield is a SaaS Security Posture Management (SSPM) platform that monitors SaaS applications for misconfigurations, identity risks, and threat activity that can lead to account takeover, data exposure, and unauthorized access. Connecting Adaptive Shield forwards SaaS security and audit alerts to Radiant Security via webhook, using Adaptive Shield's Splunk HTTP Event Collector (HEC) event destination. Radiant uses these alerts to surface SaaS-layer threats during AI triage, correlating posture and identity signals with endpoint, network, and email activity already in the pipeline. ### Prerequisites * [ ] Admin access to Adaptive Shield ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Adaptive Shield Webhook**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Adaptive Shield Webhook** and click **Credentials**. 5. In the **Credential Name** field, enter an identifiable name (e.g., `Adaptive Shield webhook credentials`). 6. In the **Connector tag** field, enter any string. Radiant uses this value as salt when generating the authentication token for your connector. 7. Click **Add Connector**. 8. On the **Data Connectors** page, find the new connector and click **View Details**. Under **Vendor Configuration**, copy and save the **Webhook URL** and **Token**. You will paste both into the Adaptive Shield console in the next section. ### Configure Adaptive Shield to forward security events 1. Log in to the Adaptive Shield console. 2. Navigate to **Settings** > **Event Destination**. 3. Click **Add a New Event Destination**. 4. Select **Splunk**. 5. Enter a name for the integration (e.g., `RadiantSecurityConnector`). 6. Enter the following details: * **HEC URL**: Paste the **Webhook URL** you copied from Radiant Security. * **Token**: Paste the **Token** you copied from Radiant Security.
7. Click **Next**, then click **Test the connection**. 8. Click **Finish**. ### Verify ingestion After Adaptive Shield begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"adaptive_shield_webhook"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Airlock Digital Connect Airlock Digital to Radiant Security to forward execution telemetry and sensor information for AI triage. Airlock Digital is an application allowlisting and execution control platform that prevents unauthorized binaries and scripts from running on endpoints. Connecting Airlock Digital forwards execution history and sensor information to Radiant Security through the Airlock REST API. Radiant uses this telemetry to investigate suspicious or blocked executions, attributing endpoint activity to specific users and hosts during AI triage. Configuration is a one-time setup performed in the Airlock Digital console and Radiant Security. At the end of this configuration, you provide Radiant Security with the following values: * **Base URL** * **API key** ### Prerequisites * [ ] Admin access to Airlock Digital ### Create a group and generate an API key in Airlock Digital For vendor instructions, refer to the [Airlock Digital REST API documentation](https://api.airlockdigital.com/). In Airlock Digital, API keys are tied to a user account, and the user inherits API permissions from the groups they belong to. The steps below create a dedicated group for Radiant, add the required REST API roles, assign your user to the group, and generate the key. To reuse an existing group, add the same three roles to that group and skip ahead to generating the key. {% stepper %} {% step %} #### Create the user group In the Airlock Digital console, navigate to **Settings** and select the **Users** tab. Under **User Group Management**, click **+ Create**. In the **Add User Group** window, enter a descriptive name (e.g., `Radiant API Access`). {% endstep %} {% step %} #### Assign the required REST API roles Scroll to the **Rest APIs Roles** section and select the following roles: * `agent/find` * `logging/exechistories` * `logging/svractivities`
Click the **>>** button to move the selected roles into the **Current Roles** list, then click **Save**. {% endstep %} {% step %} #### Add your user to the group Navigate to your user profile in the Airlock Digital console.
Select the group you just created and click the **>** button to move it into your **Current User Groups** list.
{% endstep %} {% step %} #### Generate the API key Click **Generate API Key**. Copy the key to a secure location. {% hint style="warning" %} The API key is shown only once. If it is lost, you must generate a new one. {% endhint %} {% endstep %} {% endstepper %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Airlock Digital**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Airlock Digital Execution History** and **Airlock Digital Sensor Info**, then click **Credentials**. 5. Under **Credential Name**, enter a descriptive name (e.g., `Airlock-Credentials`). 6. Under **Required Credentials**, enter the values you copied from Airlock Digital: * **Base URL**: your Airlock Digital console URL with the REST API port appended, in the format `https://.managedwhitelisting.com:3129`. Port `3129` is the Airlock REST API default; if your deployment uses a different port, substitute it here. * **API Key**: the API key you generated in the previous section. 7. Click **Add Connector** to save the configuration. ### Verify ingestion After Airlock Digital begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"airlock_digital_exec_history"` and `rs_connectorType:"airlock_digital_sensor_info"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # GitHub Enterprise Configure GitHub Enterprise audit log streaming to forward audit and Git events to Radiant Security via Amazon S3. In this guide, you will configure GitHub Enterprise audit log streaming to forward audit and Git events to Radiant Security via Amazon S3. GitHub Enterprise's audit log records security-relevant activity across your enterprise, including sign-ins, repository actions, organization and team changes, branch protection changes, and OAuth and personal access token activity, and can stream these events to an S3 bucket in near-real time. This integration covers both **GitHub Enterprise Cloud** and **GitHub Enterprise Server**. ### Prerequisites * [ ] AWS account with permissions to create or modify S3 buckets, SNS topics, and IAM policies * [ ] Owner (enterprise administrator) access to GitHub Enterprise * [ ] An S3 bucket where GitHub will store logs (follow this AWS guide to create one: [Create an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)) * [ ] One of the following authentication methods for GitHub to write to your bucket: * **OpenID Connect (recommended)**. An IAM role and an IAM identity provider for GitHub's audit-log OIDC issuer. No long-lived credentials are stored on GitHub * **Access keys**. An IAM user with an Access Key ID and Secret Access Key that has `s3:PutObject` permission on the bucket ### Configure GitHub Enterprise #### **Prepare the AWS side** Ensure that you have your S3 bucket information at hand. Block all public access on the bucket. GitHub writes audit log files into your bucket as gzipped JSON-line files with the extension `.json.log.gz`. Radiant decompresses these on ingestion. For full vendor instructions, refer to GitHub's documentation on [Streaming the audit log for your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise). Choose one of the following authentication methods. {% tabs %} {% tab title="OpenID Connect (recommended)" %} 1. In the AWS IAM console, create a new **OpenID Connect identity provider** with the following values: * **Provider URL**: `https://oidc-configuration.audit-log.githubusercontent.com` * **Audience**: `sts.amazonaws.com` 2. Create an IAM role that trusts the OIDC provider you just created, scoped to your GitHub enterprise. Use the trust policy template provided in [GitHub's documentation](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise). 3. Attach a policy to the role that allows `s3:PutObject` on your bucket: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGitHubAuditLogPutObject", "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::/*" } ] } ``` 4. Replace `` with the bucket you created. Save the **Role ARN**. You will need it when configuring GitHub. {% endtab %} {% tab title="Access keys" %} 1. Create an IAM user dedicated to this integration (for example, `github-audit-log-streaming`). 2. Attach a policy to the user that allows `s3:PutObject` on your bucket: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGitHubAuditLogPutObject", "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::/*" } ] } ``` 3. Replace `` with the bucket you created. 4. Generate an **Access Key ID** and **Secret Access Key** for the user. Store both securely. You will need them when configuring GitHub. {% endtab %} {% endtabs %} #### **Configure audit log streaming in GitHub** For detailed vendor instructions, refer to [Streaming the audit log for your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise). 1. Sign in to GitHub as an enterprise owner and navigate to your enterprise. 2. On the top menu bar, click **Settings**. 3. In the left sidebar, click **Audit log**, then click **Log streaming**. 4. Click **Configure stream** and select **Amazon S3**. 5. Configure the connection: * **Bucket**: your S3 bucket name (for example, `radiant-github-audit-logs`) * **Region**: the AWS region where your bucket is located * **Authentication**: * If using OpenID Connect, select **OpenID Connect** and enter the **Role ARN** from Step 1. * If using access keys, select **Access keys** and enter the **Access Key ID** and **Secret Access Key** from Step 1. 6. Click **Check endpoint** to verify GitHub can connect and write to the bucket. 7. Once the check succeeds, click **Save**. #### **Confirm logs are arriving** Wait a few minutes, then open your S3 bucket. You should see GitHub-written objects with names ending in `.json.log.gz` accumulating in your bucket. {% hint style="info" %} If no objects appear within approximately 10 minutes, return to **Audit log** > **Log streaming** in GitHub and re-run **Check endpoint**. {% endhint %} #### **Note your configuration details** Save the following information. You will need it for the next steps. * S3 bucket name * S3 bucket path or prefix (for GitHub Enterprise this is typically the bucket root, unless you scoped the role to a sub-prefix) * AWS region where your bucket is located ### Configure S3 and add the data connector in Radiant Security Now that GitHub is writing audit logs to your S3 bucket, complete the setup by following the [Configure Amazon S3 to forward logs to Radiant Security](/radiant-connectors/ingestion-methods/configure-amazon-s3-to-forward-logs-to-radiant-security) guide. That guide walks through: 1. Configuring the bucket policy and creating an SNS topic. 2. Adding the **Amazon Web Services S3** data connector in Radiant Security. 3. Configuring S3 event notifications so new objects trigger ingestion. When working through that guide, use the following GitHub-specific values: * **Data feed**: select **GitHub Enterprise**. * **Expected file extension**: `.json.log.gz`. Logs written by GitHub already match this format. * **Event notification prefix**: match the location where GitHub is writing in your bucket. For most GitHub Enterprise configurations this is the bucket root, unless you scoped the IAM role or access key to a sub-prefix. ### Verify ingestion After GitHub Enterprise begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"github_enterprise"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Salt Security Connect Salt Security to Radiant Security to forward API attacker and remediation events for AI triage. Salt Security is an API security platform that detects attackers probing and abusing production APIs, including credential abuse, scraping, business logic abuse, and exploitation of unauthenticated endpoints. Connecting Salt Security forwards Attackers and Remediations events to Radiant Security via webhook. Radiant uses this telemetry to surface anomalous API behavior, correlate it with identity and endpoint activity, and prioritize the alerts that warrant analyst attention. ### Prerequisites * [ ] Admin access to Salt Security ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Salt Security**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Salt Security (Webhook)**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the credential (e.g., `Salt-Credentials`). To reuse an existing credential, select it from the drop-down menu. 6. Under **Required Credentials**, enter a value in the **Connector tag** field. This can be any string. Radiant uses this value as salt when generating the authentication token for your connector. 7. Click **Add Connector**. 8. Open the newly created connector. Under **Vendor Configuration**, copy and save the `Webhook URL` and `Token` values. You will need both when configuring Salt Security. 9. Click **Done** to save your changes. {% hint style="warning" %} Treat the `Token` value as a secret. Anyone with access to this token can post events to your connector. Do not expose it in client-side code, version control, or shared logs. {% endhint %} ### Configure the Custom Webhook integration in Salt Security Salt Security forwards events to Radiant through two Custom Webhook integrations: one for **Attackers** events and one for **Remediations** events. Configure each integration separately, reusing the same `Webhook URL` and `Token` you copied from Radiant. {% hint style="info" %} For deployment assistance, work with your Salt Security Solutions Engineer. {% endhint %} ### Configure the Custom Webhook integration in Salt Security Salt Security forwards events to Radiant through two Custom Webhook integrations: one for **Attackers** events and one for **Remediations** events. Configure each integration separately, reusing the same `Webhook URL` and `Token` you copied from Radiant. {% hint style="info" %} For deployment assistance, work with your Salt Security Solutions Engineer. {% endhint %} {% stepper %} {% step %} #### **Install the Custom Webhook integration** Sign in to the Salt Security platform as a Customer Admin and navigate to **Settings** > **Deployment** > **Integrations**. In the **Available for Installation** list, locate **Custom Webhook** and click **Install**. {% endstep %} {% step %} #### **Configure the Attackers webhook** Click **Setup** on the newly installed Custom Webhook integration and enter the following parameters: * **Integration Nickname:** `Radiant Security Webhook Integration - Attackers` * **URL:** the `Webhook URL` you copied from Radiant. * **Event Type:** `Attackers` * **Method:** `POST` * **Custom header:** name `x-rs-token`, value the `Token` you copied from Radiant. * Select **Trigger Automatically**. Click **Install**, then click **Test Integration** to verify connectivity. {% endstep %} {% step %} #### **Configure the Remediations webhook** Repeat the previous step to install a second Custom Webhook integration for the **Remediations** event type. Use the same `Webhook URL` and `Token` values, and set: * **Integration Nickname:** `Radiant Security Webhook Integration - Remediations` * **Event Type:** `Remediations` {% endstep %} {% endstepper %} ### Verify ingestion After saving each Custom Webhook integration in Salt Security, confirm that events are reaching Radiant: 1. In Radiant Security, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Search for events with the connector type `salt_webhook` (`rs_connectorType:"salt_webhook"`). 3. Confirm test events from both the Attackers and Remediations integrations appear in the parsed index. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. Events that fail parsing appear in the unparsed index. {% endhint %} ### Verify ingestion After Salt Security begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"salt_webhook"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Varonis DatAlert Connect Varonis DatAlert to Radiant Security to forward alerts for AI triage. Varonis DatAlert is a data security platform that detects insider threats, ransomware, and unauthorized access to file shares, email systems, and other data stores. Connecting Varonis DatAlert forwards alerts to Radiant Security over syslog. Varonis DatAlert can forward alerts to Radiant Security in two ways: * **Through the Radiant Agent (recommended).** Forward to a Radiant Agent deployed in your environment. * **Direct to Radiant Security.** Forward over TLS to the Radiant syslog cluster. Use only when a Radiant Agent is not available. ### Prerequisites * [ ] Admin access to Varonis DatAlert * [ ] For the Radiant Agent path: a deployed [Radiant Agent](https://help.radiantsecurity.ai/radiant-connectors/data-connectors/install-the-radiant-security-agent) reachable from the Varonis DatAlert server * [ ] For the direct path: network egress from the Varonis DatAlert server to `cluster.syslog.radiantsecurity.ai` on TCP port `6514` ### Add the data connector in Radiant Security {% tabs %} {% tab title="Radiant Agent (recommended)" %} 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Varonis DatAlert**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent Integration`). To reuse an existing Radiant Agent credential, select it from the drop-down menu. 6. Click **Add Connector**. {% endtab %} {% tab title="Direct syslog" %} 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Varonis DatAlert (syslog)**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Varonis DatAlert (syslog)**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for this credential (e.g., `Varonis`). To reuse an existing credential, select it from the drop-down menu. 6. In the **Connector tag** field, enter a random value. This value acts as the salt to randomize the Token generated for your connector. 7. Click **Add Connector**. 8. Click **Done** to save your changes. {% endtab %} {% endtabs %} ### Configure Varonis DatAlert to forward syslog through the Radiant Agent Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Varonis data. If you do not know the port, contact your Customer Success representative. 1. Sign in to **Varonis**. 2. In **Data Advantage**, select **Tools** > **DatAlert**. 3. In the menu, click **Configuration**. 4. In **Syslog Message Forwarding**, enter the following: * **Syslog Server**: the IP address of the Radiant Agent. * **Port**: the port configured on the Radiant Agent to receive Varonis data. * **Facility Name**: `1 - user-level messages` 5. Click **OK**. 6. In the menu, click **Alert Templates**. 7. Select **Varonis LEEF Template**, then click **Edit Alert Template**.
8. Under **Apply to alert methods**, select **Syslog message**.
9. Click **OK**. ### Configure Varonis DatAlert to forward syslog directly to Radiant Security Use this path only when a Radiant Agent is not available. 1. Sign in to **Varonis**. 2. In **Data Advantage**, select **Tools** > **DatAlert**. 3. In the menu, click **Configuration**. 4. In **Syslog Message Forwarding**, enter the following: * **Syslog Server**: `cluster.syslog.radiantsecurity.ai` * **Port**: `6514` * **Facility Name**: `1 - user-level messages` 5. Click **OK**. 6. In the menu, click **Alert Templates**. 7. Select **Varonis LEEF Template**, then click **Edit Alert Template**. 8. Under **Apply to alert methods**, select **Syslog message**. 9. Click **OK**. ### Apply syslog forwarding to DatAlert rules 1. In Varonis, open the **DatAlert** rules table. 2. Select the rules to forward, then click **Edit Rule**. 3. On the left menu, select **Alerts Method**. 4. Click the **Edit** icon, then select the **Syslog message** checkbox.
5. Click **OK.** ### Verify ingestion After Varonis begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"varonis_datalert"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Email & Collaboration # Barracuda Email Gateway Defense Connect Barracuda Email Gateway Defense to Radiant Security to forward email security logs for AI triage. Barracuda Email Gateway Defense (EGD) is a cloud-based email security gateway that filters inbound mail for spam, malware, phishing, business email compromise, and zero-day threats before delivery to user mailboxes. Connecting Barracuda EGD forwards email security alerts and message metadata to Radiant Security through the Radiant Agent via syslog. Radiant uses this data to triage email-borne threats and correlate them with endpoint, identity, and network activity, giving analysts a complete view of how a malicious message moved through the environment. ### Prerequisites * [ ] Admin access to Barracuda Email Gateway Defense * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from Barracuda Email Gateway Defense ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Barracuda Email Gateway Defense**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent integration`). To reuse an existing Radiant Agent credential, select it from the drop-down menu. 6. Click **Add Connector**. ### Configure Barracuda Email Gateway Defense to forward syslog Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Barracuda EGD data. If you do not know the port, contact your Customer Success representative. 1. Sign in to the **Barracuda Email Gateway Defense** console. 2. Select the **Account Management** tab. 3. Under **Syslog Integration**, enter the following: * **IP Address / Hostname**: the IP address or hostname of the Radiant Agent. * **Port**: the TCP port configured on the Radiant Agent to receive Barracuda EGD data. 4. Click **Add**. 5. Under **Actions**, click **Test** to send a test message and confirm connectivity to the Radiant Agent.
### Verify ingestion After Barracuda Email Gateway Defense begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"barracuda_egd"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Check Point Avanan Connect Check Point Avanan to Radiant Security to forward email security alerts for AI triage. Check Point Avanan is a cloud email and collaboration security platform that protects Microsoft 365, Google Workspace, and connected SaaS apps against phishing, business email compromise, malware, and account takeover. Connecting Check Point Avanan forwards email security alerts to Radiant Security via webhook. Radiant uses these alerts to surface user-targeted attacks during AI triage, correlating mailbox activity with identity, endpoint, and network signals already in the pipeline. ### Prerequisites * [ ] Admin access to Check Point Avanan ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Checkpoint Avanan Webhook**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Checkpoint Avanan webhook** and click **Credentials**. 5. In the **Credential Name** field, enter an identifiable name (e.g., `Avanan webhook credentials`). 6. In the **Connector tag** field, enter any string. Radiant uses this value as salt when generating the authentication token for your connector. 7. Click **Add Connector**. 8. On the **Data Connectors** page, find the new connector and click **View Details**. Under **Vendor Configuration**, copy and save the **Webhook URL**. You will paste it into the Avanan Portal in the next section. ### Configure Check Point Avanan to forward security events 1. Log in to the Avanan Portal. 2. Navigate to **Security Settings** > **Security Engines**. 3. Under **SIEM Integration**, click **Configure**. 4. Under **Transport Method**, select **HTTP Collector**. 5. In the URL field, paste the **Webhook URL** you copied from Radiant Security. 6. Under **Log Format**, select **JSON**. 7. Click **Save**. ### Verify ingestion After Check Point Avanan begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"avanan_webhook"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Darktrace Email Connect Darktrace Email to Radiant Security to forward email alerts for AI triage. Darktrace Email is an AI-driven email security product that detects phishing, account takeover attempts, and other email-borne threats. Connecting Darktrace Email forwards email alerts to Radiant Security via the Darktrace API. At the end of this configuration, you provide Radiant Security with the following values: * **Darktrace URL** * **Public Token** * **Private Token** * **Anomaly Score Threshold** ### Prerequisites * [ ] Admin access to Darktrace ### Create a local user Darktrace API tokens are user-specific and available only for local users created directly within the Darktrace Threat Visualizer. API tokens are not supported for users authenticated via LDAP or SAML SSO. If you already have a local Admin user, use that account to generate API tokens. Otherwise, follow the steps below to create one. {% stepper %} {% step %} #### **Open the Permissions Admin** On the Threat Visualizer of the instance from which you want to request data, click **Menu**, then click **Admin** > **Permissions Admin**.
{% endstep %} {% step %} #### **Start a new user** Click the **Created Accounts** tab, then on the left side click **Create new user**.
{% endstep %} {% step %} #### **Enter user details** Give the user a recognizable **Username** (e.g., `radiant_connector`) and a **Password**, then click **User Templates**.
{% endstep %} {% step %} #### **Apply the Administrator template** For **Select a user template**, select **Administrator**, then click **Threat Tray Behavior Categories** to continue. {% endstep %} {% step %} #### **Continue past the default behavior categories** Keep all default settings for **Threat Tray Behavior Categories** unchanged, then click **Flags**.
{% endstep %} {% step %} #### **Enable API access** Toggle the **API Access** selector to **Yes**.
{% hint style="warning" %} If this selector cannot be changed, keep proceeding with the user creation and refer to Troubleshoot users with no API access after you finish. {% endhint %} {% endstep %} {% step %} #### **Add the user to the Admins group** Add this user to the **Darktrace Admins Group**, then click **Add Threat Visualizer permissions**.
{% endstep %} {% step %} #### **Save the user** Leave the remaining setup steps unchanged by clicking the proceeding buttons. On the **Summary** page, click **Update user** to save changes. {% endstep %} {% endstepper %} ### Troubleshoot users with no API access If you were not able to toggle the **API Access** selector to **Yes**, contact Darktrace support. In most cases this happens because the API has never been used on the instance and can be quickly resolved. After Darktrace support enables the API, all icons in the **Flags** column should be green for the new user.
### Generate the API token {% stepper %} {% step %} #### **Sign in as the new user** Sign in to the Darktrace Threat Visualizer with the user created in the previous section. {% endstep %} {% step %} #### **Open Account Settings** Click **Account Settings** from the main menu.
{% endstep %} {% step %} #### **Open API Access** Click the **API Access** button.
{% endstep %} {% step %} #### **Generate the tokens** In the pop-up, click **New**. A **Public Token** and **Private Token** appear.
{% hint style="warning" %} Copy both token values now. The **Private Token** cannot be retrieved later. You will provide these values to Radiant Security in the next section. {% endhint %} {% endstep %} {% endstepper %} ### Add the credentials in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Credentials** and click **+ Add Credential**. 3. Search for and select **Darktrace API** from the list, then click **Configure Credential**. 4. Enter an identifiable name for the credential (e.g., `Darktrace API Tokens`) and complete the required fields: * **Tenant URL**: your Darktrace Console URL, in the format `https://xxxxxx.cloud.darktrace.com`. * **Public Token**: the 40-digit Public Token copied in the previous section. * **Private Token**: the 40-digit Private Token copied in the previous section. * **Anomaly Score Threshold**: a value from 0 to 100 representing the Antigena Email Score Darktrace assigns to each analyzed email. A threshold of 0 sends every email for triage; a threshold of 100 sends only emails Darktrace deems highly likely to be malicious. A starting value of 80 avoids triaging every email while ensuring those with lower Darktrace confidence scores still undergo further analysis. ### Add the data connector in Radiant Security 1. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 2. Search for and select **Darktrace API**, then click **Data Feeds**. 3. Select **Darktrace Email Alerts**, then click **Credentials**. 4. Select the credential created in the previous section, then click **Add Connector**. ### Verify ingestion After Darktrace Email begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"darktrace_email"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Google Workspace Connect Google Workspace to Radiant Security to ingest email, authentication, and IAM activity for AI triage. Radiant connects to Google Workspace to ingest email activity, authentication activity, and user and group IAM information. The connector uses a Google Cloud service account with domain-wide delegation, and reads Workspace activity logs from BigQuery. Configuration is a one-time setup performed in Google Cloud, Google Admin, and Radiant Security. If you do not have Google BigQuery, use [Google Workspace IAM only](/radiant-connectors/identity-and-access/google-workspace-iam-only) to enable just the IAM and email data feeds. At the end of this configuration, you provide Radiant Security with the following values: * **BigQuery Project ID** * **BigQuery Dataset Name** * **Delegate User Email** * **Service account JSON key file** ### Prerequisites The Google Workspace account must have one of the following plans for email activity log collection: * [ ] Enterprise * [ ] Education Standard * [ ] Education Plus {% hint style="info" %} To verify your current license plan, sign in to an account with admin access and visit [`https://admin.google.com/ac/billing/subscriptions`](https://admin.google.com/ac/billing/subscriptions). {% endhint %} The user performing this configuration must hold the following permissions and roles: * [ ] Role: `Super Administrator` (Google Workspace) * [ ] Role: `roles/resourcemanager.projectIamAdmin` (Google Cloud) * [ ] Permission: `resourcemanager.projects.create` (Google Cloud) ### Create a project in Google Cloud 1. Sign in to the [Google Cloud console](https://console.cloud.google.com/). 2. From the **Select organization** drop-down at the top of the page, click **New project**. 3. In the **Project name** field, enter a descriptive name. Radiant recommends `{your organization's name}-workspace-logs`. For details on project naming and identifiers, see Google's [Creating and managing projects](https://docs.cloud.google.com/resource-manager/docs/creating-managing-projects). 4. The Google Cloud console generates a **Project ID** from the project name. To customize it, click **Edit** next to the Project ID. The Project ID is permanent after the project is created. 5. Copy the **Project ID** for later use. 6. Click **Create**. 7. Select the newly created project from the drop-down at the top of the page. 8. From the navigation menu, select **APIs & Services** > **Library.**
9. In the API Library, search for and enable the following APIs, one at a time: * Admin SDK API * Cloud Identity * Gmail API * Google Calendar API * Google Workspace Alert Center API
10. Open the OAuth consent screen for your project. From the navigation menu, select **APIs & Services** > **OAuth consent screen**. With the project selected, Google routes you to the **Google Auth Platform**. 11. Configure the consent screen. The path depends on whether the Google Auth Platform is already configured for this project: **If you see the message "Google Auth platform not configured yet":** click **Get Started** and complete the wizard: 1. Under **App Information**, enter the following: * **App name**: `radiant-security-workspace-logs` * **User support email**: select the appropriate user. 2. Click **Next**. 3. Under **Audience**, select **Internal** as the user type. 4. Click **Next**. 5. Under **Contact Information**, enter an email address where Google can notify you about changes to your project. 6. Click **Next**. 7. Under **Finish**, review the Google API Services User Data Policy, select **I agree to the Google API Services: User Data Policy**, and click **Continue**. 8. Click **Create**. **If the Google Auth Platform is already configured:** verify the existing configuration in the left navigation: * **Branding**: confirm **App name** is `radiant-security-workspace-logs` and that **User support email** and **Developer contact information** are populated. * **Audience**: confirm **User type** is **Internal**. If it shows **External**, contact your Google Workspace administrator before continuing. ### Create a service account A dedicated service account in Google Cloud ingests the data. The service account holds the permissions required to read the data fed into Radiant Security. 1. In the Google Cloud console, navigate to **IAM & Admin** > **Service Accounts**.
2. Click **+ Create service account** and enter the **Service account name**: `radiant-security-connector`. 3. Optional: Enter a description of the service account. 4. Click **Create and Continue**. 5. Under **Grant this service account access to project**, assign the following roles. Click **+ Add another role** to add the second role: * **BigQuery Data Viewer** * **BigQuery Read Session User** 6. Click **Done**. 7. Click the `radiant-security-connector` service account to open it. 8. On the **Service Accounts** page, click the email address of the `radiant-security-connector` service account. 9. Click the **Keys** tab. 10. Click **Add key** and select **Create new key**. 11. Select **JSON** as the **Key type** and click **Create**. The JSON key file downloads automatically. {% hint style="warning" %} The downloaded JSON key file is the only copy. Store it securely. You upload this file to Radiant Security at the end of this guide. For guidance, see Google's [Best practices for managing service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys). {% endhint %} ### Grant access to the service account To call APIs in Google Workspace, the service account must be granted domain-wide delegation of authority in the Google Workspace Admin console by a super administrator. For background, see Google's [Delegating domain-wide authority to a service account](https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority). 1. On the **Service Accounts** page in Google Cloud, click the `radiant-security-connector` service account. 2. On the **Details** tab, expand **Advanced settings** and copy the **Client ID**. 3. Click **View Google Workspace Admin Console**. 4. Navigate to **Security** > **Access and data control** > **API controls**. 5. Click **Manage Domain Wide Controls**. 6. Click **Add new** and paste the Client ID you copied in step 2. 7. In the **OAuth Scopes** field, copy and paste the following permissions: ```bash https://www.googleapis.com/auth/admin.directory.domain.readonly, https://www.googleapis.com/auth/admin.directory.group.readonly, https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly, https://www.googleapis.com/auth/admin.directory.user.readonly, https://www.googleapis.com/auth/admin.reports.audit.readonly, https://www.googleapis.com/auth/admin.reports.usage.readonly, https://www.googleapis.com/auth/gmail.settings.basic, https://www.googleapis.com/auth/apps.alerts, https://www.googleapis.com/auth/bigquery, https://www.googleapis.com/auth/gmail.readonly, https://www.googleapis.com/auth/gmail.modify, https://mail.google.com, https://www.googleapis.com/auth/calendar.readonly, https://www.googleapis.com/auth/calendar.events.readonly ``` 8. The specific permissions for each Google OAuth scope are listed in the following table: | OAuth Scope | Functionality | | ---------------------------------------------- | --------------------------------------------------------------------------- | | admin.directory.domain.readonly | Get users on the domain | | admin.directory.group.readonly | Get user group memberships | | admin.directory.rolemanagement.readonly | Get user roles | | admin.directory.user.readonly | Get user profile information | | admin.reports.usage.readonly | Get usage status (Account status, MFA enablement, etc) | | admin.reports.audit.readonly | Get user audit activity (Google services accessed, login times, etc) | | gmail.settings.basic | Mailbox settings - Get and Set email forwarding rules - Block sender action | | apps.alerts | Get phishing alert reports from google | | bigquery | Read BigQuery tables (Workspace activity) | | gmail.readonly | Get Email raw body (Mail reports Based on Google alerts) | | gmail.modify | Soft Delete email action | | mail.google.com | Hard Delete email action | | calendar.readonly and calendar.events.readonly | Get user calendar events - Out Of Office events | 9. Click **Authorize**. {% hint style="info" %} Two of the scopes grant write access and support automated response actions in Radiant Security: * `https://www.googleapis.com/auth/gmail.modify` — soft-delete an email from a user's mailbox. * `https://mail.google.com` — hard-delete an email from a user's mailbox. To configure the Google Workspace action connector that uses these scopes, see [Execute response actions with Google Workspace](/radiant-connectors/email-and-collaboration/google-workspace/execute-response-actions-with-google-workspace). {% endhint %} ### Enable BigQuery export 1. Sign in to the [Google Workspace Admin console](https://admin.google.com/). 2. Navigate to **Reporting** > **Data Integrations** > **BigQuery Export**. 3. Click on the export box and fill the required fields: * Project ID: the Project ID you copied when creating the Google Cloud project. * In the **New dataset within project field**, enter a name for the dataset: `google_workspace_log` 4. Click **Save**. ### Create a Google Workspace read-only admin role and delegated user {% hint style="warning" %} The Google Workspace APIs require a delegate Google Workspace account that holds all privileges needed by the APIs. This is an account inside the Google Workspace environment and is distinct from the Google Cloud service account created earlier. For background, see Google's [Delegating domain-wide authority to the service account](https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority). {% endhint %} Radiant recommends creating a dedicated, named user account in Google Workspace for this purpose (for example, `radiant-delegate@yourdomain.com`) rather than reusing a personal admin account. 1. Sign in to the [Google Workspace Admin console](https://admin.google.com/). 2. Navigate to **Account > Admin Roles**. 3. Click on **Create new role**. 4. Name the role **`Radiant Security Read Only`** and click **Continue**. 5. Select the following privileges: * `Organizational Units` > `Read` * `Users` > `Read` * `Alert Center` > `View Access` * `Reports` * `Groups` > `Read` * `DLP` > `View DLP rule` * `Security Center` > `Activity Rules` > `View` 6. On the review screen, click **Create Role**. #### **Assign the role to a delegate user** 1. In the Google Workspace Admin console, create a dedicated user account if one does not already exist. For guidance, see Google's [Add an account for a new user](https://support.google.com/a/answer/33310). 2. On the **Admin Roles** page, open the `Radiant Security Read Only` role. 3. Click **Assign members** and assign the role to the delegate user account created in step 1. 4. Record the delegate user's email address. You enter this value as the **Delegate User Email** in the final section of this guide. ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings > Data Connectors** and click **+ Add Connector**. 3. Search for and select the **Google Workspace** option and then click **Data Feeds**. 4. Add the following values from the previous steps: * **BigQuery Project ID**: the Project ID of the Google Cloud project you created. * **BigQuery Dataset Name**: `google_workspace_log` * **Delegate User Email**: the email address of the dedicated Workspace user account assigned the **Radiant Security Read Only** role. * **JSON File**: upload the service account JSON key file 5. Click **Add Connector** to save the connector configuration. ### Verify ingestion After Google Workspace begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by the `rs_connectorType` for each data feed you enabled:
Data feedFilter
Authentication Logsrs_connectorType:"google_logs_authentication"
Email Logsrs_connectorType:"google_logs_email"
User Activity Logsrs_connectorType:"google_logs_user_accounts"
Google IAMrs_connectorType:"google_iam"
Google Email Alertsrs_connectorType:"google_alerts"
Google Identity Alertsrs_connectorType:"google_identity_alerts"
Google Workspace Alertsrs_connectorType:"google_workspace_alerts"
3. Confirm recent alerts and events appear for each enabled feed. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Execute Response Actions with Google Workspace Configure the action connector for Google Workspace. In this guide, you'll configure the integration between Google Workspace and Radiant to automatically run containment and remediation actions after phishing attacks.
:bolt-lightning: Available actions The following actions are available after you set up the Google Workspace action connector. Keep in mind, additional permissions are required. * Find and soft delete emails * Find and hard delete emails * Block sender
To be able to add the action connector, you will need to provide Radiant Security with the following values, from the data connector onboarding: * **BigQuery Project Id** * **BigQuery Dataset Name** * **Delegate User Email** * **JSON File containing the API key previously downloaded from your Google Workspace project** If you haven't configured the Google Workspace data connector yet, check out the [Google Workspace](/radiant-connectors/email-and-collaboration/google-workspace) guide. ### Add the action connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings > Action Connectors** and click **+ Add Connector**. 3. Select **Google Workspace** and click **Credentials**. 4. Add the following values from the previous steps: * **BigQuery Project ID**: `{customer name}-workspace-logs` * **BigQuery Dataset Name**: `google_workspace_log` * **Delegate User Email**: The service account that has the **Radiant Security Read Only** admin role * **Upload the JSON File** 5. Click **Add Connector** to save the connector configuration. # KnowBe4 # Execute Response Actions with KnowBe4 Configure the action connector for KnowBe4. In this guide, you'll configure the integration between KnowBe4 and Radiant to automatically enroll users in additional training after simulated phishing attacks. Users who clicked on malicious links or downloaded malicious files will be added to a KnowBe4 smart group and enrolled in remedial phishing training.
:bolt-lightning: Available actions The following action is available after you set up the KnowBe4 action connector. Keep in mind, additional permissions are required. * Enroll in phishing training
### Prerequisites This configuration requires the following: * [ ] Admin access to KnowBe4 * [ ] Platinum or Diamond-level license to use the smart groups functionality ### **Create a Product API Token in KnowBe4** Create the Product API token to share with Radiant Security. The token will allow the app to authenticate to KnowBe4. 1. Login to your KMSAT console, click your email address at the top-right corner of the page and select **Account** **Settings** 2. Navigate to **Account** **Integrations** > **API**
3. Click **User Event API** 4. On the **Create New API Token** page, fill in the **Name** field with `Radiant Security App` 5. Click **Create Token** 6. Under **Key**, click the copy icon to copy the API token you just created
{% hint style="info" %} **Note:** Be sure to save the API token as it will be needed in the next section. {% endhint %} ### **Add the action connector in Radiant Security** Add the new action connector to Radiant Security. 1. Login to [Radiant Security](https://app.radiantsecurity.ai/) 2. From the navigation menu, select **Settings** > **Action Connectors** 3. Click **+ Add Connector** 4. Select **KnowBe4** from the menu and click **Credentials** 5. Under **Required Credentials**, add the following: * **User Event API**: The Product API Token that you copied from the KMSAT console. * **Base URL**: Select the appropriate base URL depending on where your KnowBe4 account is located. From the drop-down, choose from the following options: * US server (located at [training.knowbe4.com](https://training.knowbe4.com/)): `https://api.events.knowbe4.com/` * EU server (located at [eu.knowbe4.com](https://eu.knowbe4.com/)): `https://api-eu.events.knowbe4.com/` 6. Click **Add Connector** to save the connector configuration ### Create a smart group from custom event criteria Create a smart group in KnowBe4. When users match the custom event criteria, they will be automatically added to this smart group. {% hint style="info" %} **Note**: It may take up to 1 hour from an event publish until the user is added to the smart group. This is dependent on KnowBe4’s background processing and is not configurable. {% endhint %} 1. Log in to your KMSAT console and navigate to **Users** > **Groups**. 2. Click the **+ Create New Group** button at the top-right corner of the page. 3. Enter a group name in the **Group Name:** `Radiant Security Impacted User` 4. Select the **Make this a Smart Group** checkbox. 5. Click **Create Group**. When you click this button, the Smart Group’s overview page will open. 6. From this page, click the **Smart Group Criteria** drop-down menu and select the criteria type **Custom Event Criteria**. 7. Fill in the criteria using the information below: * **Condition**: `Must` * **Event Type**: `Radiant Security Impacted Users` * **Event Source** (optional): `` * **Event External Id** (optional): `` * **Description** (optional): `Radiant Security enrolled user in training` * **Matcher**: `Greater than` * **Count**: `0` * **Time Frame**: `Any` ### Create a remedial training campaign Finally, add the newly created smart group to a new or existing remedial training campaign. Follow the [KnowBe4 documentation](https://support.knowbe4.com/hc/en-us/articles/206280728-How-to-Set-Up-a-Remedial-Training-Campaign) to complete these steps. # Microsoft O365 Onboard the Microsoft O365 data connector. In this guide, you will set up a trusted relationship between Radiant and your Microsoft account to allow Radiant to retrieve user and group data related to your organization, including authentication activity and audit activity events. At the end of this configuration, you will provide Radiant Security with these values: * **Application (client) ID** * **Directory (tenant) ID** * **Client Secret Value** * **Azure Subscription ID (only needed for the Azure Activities feed)**
:bolt-lightning: Available actions The following actions are available after you set up the Microsoft O365 data connector. Keep in mind, additional permissions are required. * Find and hard delete emails * Block files * Block domains * Isolate device * Disable users and terminate active sessions * Terminate active sessions * Disable all forward rules * Delete external email forward rules * Enable User * Block IP address (Identity) * Block IP address (Endpoint) * Release devices from isolation
### Prerequisites * [ ] Admin access to Microsoft 365 ### Register the application with Microsoft Entra ID In this step, you'll register a new application with Microsoft Entra ID. The application will pull user and group data on a semi-regular basis. {% hint style="info" %} **Note**: Make sure to save the **Application (client) ID** and **Directory (tenant) ID** values. You will need to provide them to Radiant Security at the end of the configuration. {% endhint %} 1. Log in to the [Microsoft Azure Portal](https://portal.azure.com/#home). 2. From the left side menu, navigate to **Microsoft Entra ID**. 3. From the left menu, navigate to **App Registrations**. 4. Click **+** **New Registration**.\
5. Update the application **Name** to `radiantsecurity-connector` and leave all default settings unchanged.\
6. Click **Register** to save the changes. 7. On the newly registered application page, copy the following values: * **Application (client) ID** * **Directory (tenant) ID**
8. On the same page, click the link for **Add a certificate or secret**.
9. In the **Add a client** window, click **+ New Client Secret**. 10. Set the client secret as: * **Description**: `Radiant Security Connector` * **Expires**: `12 months`
11. Click **Add**. 12. The client secrets page will automatically open. 13. Copy the **Value** (not the **Secret ID** field).\
{% hint style="warning" %} **Important note**: Ensure you copy the **Client secret** value now as you won't be able to look it up again later. You will need to provide it to Radiant Security at the end of the configuration. {% endhint %} ### Grant the newly registered application the appropriate permissions 1. On the left sidebar menu, click **API Permissions**. 2. Click + **Add a permission**. 3. From the pop-out menu, select **Microsoft Graph APIs**.\
4. Then click **Application permissions** to open the permission list.
5. Select the following permissions: {% hint style="danger" %} **Important Note:** Before proceeding with the permissions below, if you plan on onboarding the Email use case, please follow [this Microsoft documentation](https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/graph-api-message-trace) to provision a service principal before granting the **ExchangeMessageTrace.Read.All** permission. {% endhint %} | **API / Service** | **Permission name** | **Required for Data Ingestion?** | **Use Case** | **Details** | | ---------------------------- | ------------------------------------------------- | -------------------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Microsoft Graph | Application.Read.All | Yes | Email, Identity, Endpoint | **Task**: Block IP Address | | Microsoft Graph | AuditLog.Read.All | Yes | Email, Identity | Collect user authentication events for investigating abnormal authentication to applications | | Microsoft Graph | Directory.Read.All | Yes | All | Permission to read users’ profiles | | Microsoft Graph | IdentityRiskEvent.Read.All | Yes | Identity | Collect identity-based risks/alerts Entra ID Identity Protection | | Microsoft Graph | IdentityRiskyUser.Read.All | Yes | Identity | Collect identity-based risks/alerts Entra ID Identity Protection | | Microsoft Graph | Mail.ReadWrite | No | Email | **Task**: Find & Delete Emails | | Microsoft Graph | MailboxSettings.Read | No | Identity | Collect the out-of-office status of the user from Microsoft to help influence identity alert triage outcomes | | Microsoft Graph | MailboxSettings.ReadWrite | No | Email | **Task**: Disable all email forward rules, Delete external email forward rules | | Microsoft Graph | Policy.Read.All | No | Identity, Endpoint | **Task**: Block IP Address | | Microsoft Graph | Policy.ReadWrite.ConditionalAccess | No | Identity, Endpoint | **Task**: Block IP Address | | Microsoft Graph | User.Read.All | Yes | All | Permissions to read users’ profiles | | Microsoft Graph | SecurityAlert.Read.All | Yes | Microsoft Defender for Cloud feed | Permissions to read security alerts | | Microsoft Graph | User.ManageIdentities.All | No | Email, Identity, Endpoint | **Tasks**: Reset User Password, Disable User | | Microsoft Graph | User.EnableDisableAccount.All | No | Email, Identity, Endpoint | **Tasks**: Reset User Password, Disable User, Enable User | | Microsoft Graph | Directory.AccessAsUser.All (delegated permission) | No | Email, Identity, Endpoint | **Tasks**: Reset User Password, Disable User | | Microsoft Graph | ExchangeMessageTrace.Read.All | Yes | Email | Collect [exchangeMessageTrace](https://learn.microsoft.com/en-us/graph/api/resources/exchangemessagetrace?view=graph-rest-1.0) objects to triage email reports | | Microsoft Cloud App Security | Investigation.Read | Yes | Microsoft Defender for Cloud Apps feed | Permissions to read the Cloud Apps alerts and the related events | 1. Click **Add permissions** to save the changes. 2. Click **+ Add a permission** and select the tab **APIs my organization uses,** then select the **Office 365 Exchange Online** option.\
3. Select **Application permissions** and add the permissions outlined in the table below: | **API / Service** | **Permission name** | **Required for Data Ingestion?** | **Use Case** | **Details** | | ------------------------------------------------------ | ---------------------------- | -------------------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Office 365 Exchange Online (APIs my organization uses) | Exchange.ManageAsApp | Yes | Email |

Tasks: Block Sender, Block URL - required for actions that can only be done over PowerShell
Data: Email traces.

| | Office 365 Exchange Online | User.RevokeSessions.All | No | Email and Identity | Task: Terminate Active Sessions | | (APIs my organization uses) | ReportingWebService.Read.All | Yes | Email | Permission to enrich message trace events | 4. Click **Add permissions** to save the changes. 5. Click on **+ Add a permission** again, on the Microsoft APIs tab, select **Office 365 Microsoft Management API**.\
6. Select **Application permissions** and add the permissions outlined in the table below: | **API / Service** | **Permission name** | **Required for Data Ingestion?** | **Use Case** | **Details** | | -------------------------- | -------------------- | -------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------- | | Office 365 Management APIs | ActivityFeed.Read | Yes | Email, Identity | Collect user authentication events for investigating abnormal authentication to applications | | Office 365 Management APIs | ActivityFeed.ReadDlp | Yes | Email | Permission to identify impacted users with inbox rules that were newly created or modified to exfiltrate emails | 7. Click **Add permissions** to save the changes. ### Add permissions in Azure Follow [these](/radiant-connectors/cloud-and-infrastructure/azure-activities) instructions only if you have Azure enabled in your environment. ### Add assigned role In this step, you will assign the newly registered application with the necessary roles. 1. On the left sidebar menu, click **Roles and Administrators**. 2. On the roles and Administrators page, click **here**.\
3. From the search bar, search for `global reader` and select the row (do not select the checkbox).
4. On the active assignments page, click **+ Add assignment**. 5. On the **Add assignments** page, under **Select member(s)**, click on **No member selected** and add `radiantsecurity-connector` on the side panel.\
6. Click **Next** and under **Enter justification** type the justification in the text box: `Grant Radiant Security access to message trace events` 7. Click **Assign** to save the changes. 8. Repeat steps 1-7 for the **Exchange Administrator role** and for the **Privileged Authentication Administrator role** or **Authentication Administrator role.** 1. The **Privileged Authentication Administrator role** allows the application to run actions such as reset user password on all user accounts in the environment, no matter their groups or roles. 2. The **Authentication Administrator role** allows the application to run the same actions as the **Privileged** version, but it limits the scope of access so that the application can't run actions against user accounts with high privilege levels such as **Global Admins**, **Group Admins** or even users who own or are members of role-assignable group. For more information about the two roles, refer to ### Specific configurations Some data feeds require additional configuration before adding the connector to Radiant Security. Please refer to the following articles if applicable: * Add Microsoft Defender Permissions * Microsoft Safe Links * Onboarding Hosts to Defender ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **Microsoft O365** option and then click **Data Feeds**. 4. Add the following values you saved from the previous steps: * **Application (client) ID** * **Directory (tenant) ID** * **Client Secret Value** {% hint style="warning" %} **Important Note:** For the **Azure Activites data connector**, add a comma-separated list of the subscription IDs that must be monitored. {% endhint %} 5. Click **Add Connector** to save the connector configuration. ### Verify ingestion After Microsoft 365 begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by the `rs_connectorType` for each data feed you enabled:
Data feedFilter
Audit Logs Exchange Onliners_connectorType:"ms365_audit_exchange"
Azure Activitiesrs_connectorType:"ms365_azure_activity"
Microsoft Defender for Cloudrs_connectorType:"ms365_defender_cloud"
Microsoft Defender for Cloud Appsrs_connectorType:"ms365_defender_cloud_apps"
Microsoft Defender for Endpointrs_connectorType:"ms365_defender"
Microsoft Defender for Endpoint via Event Hubrs_connectorType:"ms365_defender_eventhub"
Microsoft Defender for Officers_connectorType:"ms365_defender_for_office"
Microsoft Entra ID Audit Logsrs_connectorType:"ms365_sign_ins"
Microsoft Entra ID IAMrs_connectorType:"ms365_activedirectory"
Microsoft Entra ID Non-Interactive Sign-Insrs_connectorType:"ms365_noninteractive_sign_ins"
Microsoft Entra ID Protectionrs_connectorType:"ms365_identity_risk"
Microsoft Sentinel Alertsrs_connectorType:"ms365_sentinel_alerts"
Office 365 Exchange Online (via Graph API)rs_connectorType:"ms365_office_exchange_online_v2"
SafeLinksrs_connectorType:"ms365_safe_links"
3. Confirm recent alerts and events appear for each enabled feed. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Microsoft Safe Links Connect Microsoft Safe Links to Radiant Security to forward click events for AI triage. Microsoft Safe Links is a Microsoft Defender for Office 365 capability that rewrites URLs in inbound email and performs time-of-click verification to block users from reaching malicious links. Enabling the **Safe Links** data feed on your existing Microsoft O365 connector forwards click events to Radiant Security. Radiant uses these events for AI triage, giving analysts visibility into phishing links accessed from unmanaged devices and identifying users who clicked from personal machines. For background on the feature, see [Safe Links in Microsoft Defender for Office 365](https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/safe-links). ### Prerequisites * [ ] Admin access to Microsoft 365 * [ ] An existing [Microsoft O365](https://help.radiantsecurity.ai/radiant-connectors/data-connectors/microsoft-o365) connector in Radiant Security, configured with message trace permissions ### Enable Safe Links in Microsoft 365 1. Sign in to the [Microsoft Defender portal](https://security.microsoft.com/). 2. In the left sidebar, navigate to **Email & collaboration** > **Policies & Rules**. 3. Click **Threat policies**, then select **Safe Links**. 4. Click **+ Create** to add a new policy and add all users, groups, or domains to monitor. The screenshot below shows the mandatory and preferred settings: * Mandatory settings (outlined in red): * **On: Safe Links checks a list of known, malicious links when users click links in email. URLs are rewritten by default.** * **Apply Safe Links to email messages sent within the organization** * Preferred settings (outlined in blue): * **Track user clicks** * **Let users click through to the original URL**
5. Leave all other settings unchanged, then click **Submit**. {% hint style="info" %} Once enabled, Microsoft rewrites all email links with the Safe Links prefix `https://nam01.safelinks.protection.outlook.com`. {% endhint %} ### Enable the Safe Links data feed in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**. 3. Locate the row for the **Safe Links** data feed under your existing **Microsoft O365** connector. 4. On the right side of the row, click **Enable**. ### Verify ingestion After Safe Links begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"ms365_safe_links"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Microsoft O365 Expired Client Secret Key Update your expired client secret key. ### Prerequisites * [ ] Admin access to Microsoft 365 ### Create a new client secret key in Microsoft 1. Log in to the [Microsoft Azure Portal](https://portal.azure.com/). 2. From the left menu, navigate to **Microsoft Entra ID** and then select **App Registrations**. 3. Click the **All Applications** tab and search for and open the `radiantsecurity-connector`. 4. On the left sidebar menu, click **Certificates & Secret**. 5. Click + **New client secret**, click **Add**, and enter the following: * **Description**: `Radiant Security Connector` * **Expires**: `12 months` 6. Copy the **Value** (*not* the Secret ID field)**.** {% hint style="warning" %} **Important note:** Ensure you copy the **Client Secret value** now, as you won't be able to look it up again later. It will be provided to Radiant Security at the end of this configuration. {% endhint %} ### Update client secret key in Radiant Security 1. Login to [Radiant Security](https://app.radiantsecurity.ai/). 2. Use the left navigation bar to open **Settings > Credentials.** 3. Locate the **Microsoft O365** credential to update. 4. Hover over the credential and click the icon that appears on the right side . 5. In the right-side menu that appears, click **Actions** and select **Edit Credentials**. 6. Update the **Client Secret Value**. 7. Click **Apply Update**. * All other fields can remain unchanged. # Execute Response Actions with Microsoft O365 (certificate) Configure the action connector for Microsoft O365 (certificate). In this guide, you'll onboard the [Microsoft O365 (certificate)](https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps) action connector. This configuration will establish a trusted relationship between Radiant Security and your Azure application to authenticate with the Exchange Online Management PowerShell module. With the action connector, you can execute PowerShell commands from the Radiant Security application with one click.
:bolt-lightning: Available actions The following actions are available after you set up the Microsoft O365 action connector. Keep in mind, additional permissions are required. * Block sender * Block sender domain * Block URLs
At the end of this configuration, you will provide Radiant Security with the following: * **Private Certificate File** * **Private Certificate Password** * **Application ID** * **Organization Name** ### Prerequisites * [ ] Admin access to Microsoft 365 ### Generate the self-signed certificate Choose to either generate the certificate on [Windows](#windows-powershell-certificate-generation) or [MacOS/Linux](#macos-linux-openssl-certificate-generation). #### Windows: PowerShell certificate generation 1. In PowerShell, update the DnsName to reflect your organization by executing the following commands: {% hint style="info" %} If you are an E.U. tenant, replace `app.radiantsecurity.ai` by `app.eu1.radiantsecurity.ai` {% endhint %} {% code overflow="wrap" %} ```json # Create certificate $mycert = New-SelfSignedCertificate -DnsName "app.radiantsecurity.ai" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(10) -KeySpec KeyExchange # Export certificate to .pfx file $mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password # Export certificate to .cer file $mycert | Export-Certificate -FilePath mycert.cer ``` {% endcode %} {% hint style="info" %} **Note**: Save the **.cer file** to upload to Azure at a later step. Save the **.pfx file** to upload to Radiant Security at a later step. Save the **password** to upload to Radiant Security at a later step. {% endhint %} #### MacOS/Linux: OpenSSL certificate generation 1. In the command line, generate a private key for signing this request: ```json openssl genrsa -out key.pem 2048 ``` 2. Create certificate signing request using user input for certificate details: ```json openssl req -new -sha256 -key key.pem -out csr.csr ``` 3. Sign the certificate signing request using the private key: ```json openssl x509 -req -in csr.csr -signkey key.pem -out certificate.pem -days 3650 -sha256 ``` 4. Convert the **pem** certificate to a **pfx** certificate file. This is required for the PowerShell exchange online authentication. ```json openssl pkcs12 -inkey key.pem -in certificate.pem -export -out cert.pfx ``` {% hint style="info" %} **Note**: Ensure you provide an input for the CN (common name) as it identifies the certificate. {% endhint %} {% hint style="info" %} **Note**: Save the **.pem file** to upload to Azure at a later step. Save the **.pfx file** to upload to Radiant Security at a later step. Save the **password** to upload to Radiant Security at a later step. {% endhint %} ### Update the Azure app manifest 1. Log in to [Azure](https://portal.azure.com/#home). 2. From the left side menu, navigate to Microsoft Entra ID. 3. From the left menu, navigate to **App Registrations**. 4. Under **All applications** search for `Radiant Security`. 5. Click to open the application and copy the **Application (client) ID**. {% hint style="info" %} **Note**: Be sure to save the Application (client) ID as it will be needed at a later step. {% endhint %} ### Upload the certificate 1. From the left side menu, click **Certificates & secrets** then, click the **Certificates** tab, and choose **Upload certificate**. 2. Upload the certificate `.pem` or `.cer` file that you saved from the previous step. ### Copy the primary domain 1. From the [Entra ID Home menu](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Overview), copy the **Primary domain**. ### Create the action connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Credentials** and click **+ Add Credential**. 3. Search for and select **Microsoft O365 (certificate)** and click **Configure Credential**. 4. Enter a **Credential Name**. 5. Under **Required Credentials**, provide the following information that you obtained from the previous steps: * **Private Certificate (pfx) File Upload**: `the .pfx file downloaded` * **Private Certificate Password**: `the password associated with the .pfx file` * **Application (client) ID**: `the Application (client) ID you copied from Azure` * **Primary Domain**: `the Primary Domain you copied from Azure` # Mimecast API 2.0 Configure the Mimecast API 2.0 data connector. In this guide, you'll configure the integration between Radiant and Mimecast. Adding this data connector gives your organization visibility into phishing links accessed from unmanaged devices. With this data, Radiant Security can detect users who clicked on malicious links from personal devices, enabling deeper investigations and uncovering the full scope of an incident. At the end of this configuration, you will provide Radiant Security with these values: * **Client ID** * **Client Secret**
:bolt-lightning: Available actions The following actions are available after you set up the Mimecast data connector. Keep in mind, additional permissions are required. * Block Sender * Block URLs
### Prerequisites Admin access to Mimecast, with a Role that grants: * [ ] Read and Edit API Application Permissions under the Service Menu * [ ] Security Permissions setting must permit the Management of Application Roles ### Create the custom role 1. Log in to your [Mimecast console](https://login-us.mimecast.com/administration/app/) with an admin account. 2. In the menu, click **Account**, then select **Roles**. 3. Click **New Role,** set the **Name** and **Description** as **Radiant Security API 2.0**. 4. On **Security Permissions,** select **Cannot Manage Roles**. 5. On **Application Permissions**, leave the following settings enabled: * Account Menu | Logs | Read * Gateway Menu | Policies | All * Gateway Menu | Managed Senders | All * Services Menu | URL Protection | All * Directories | Groups | All * Monitoring Menu | URL Protection | All * Directories Menu | Managed Senders | All *(in case it exists on the UI)* 6. Click **Save and Exit**. ### Configure the Mimecast API 1. Log in to your [Mimecast](https://login-us.mimecast.com/administration/app/) console with an admin account.
2. In the administration menu, click **Services,** then select **API and Platform Integrations.** 3. Under **Mimecast API 2.0,** click **Generate Keys.**
4. On **Application Details**, fill the form with the following values: * **Application Name:** `Radiant Security API 2.0` * **Category:** `Others` * **Products:** Select the following entries: * Email Security Cloud Gateway * Policy Management * Threat Management * Audit Events * Security Events * User and Group Management * **Application Role:** `Radiant Security API 2.0` * **Description:** `Radiant Security API 2.0 Connector`
5. Click **Next.** 6. Fill in the following values: * **Technical Point of Contact:** `` * **Email:** `` 7. Click **Next.** 8. Confirm the values in the summary. 9. The wizard completes and displays a pop-up window including your **Client ID** and **Client Secret,** where you can copy and save the credentials for the API application.
10. Copy the application values for: * **Client ID** * **Client Secret** {% hint style="warning" %} **Important note:** Be sure to document and store the **Client ID** and **Client Secret** carefully, as they cannot be retrieved later. Also, remember to label which is which, as these will need to be provided to Radiant Security later. {% endhint %} ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connector** and click **+ Add Connector**. 3. Search for and select the **Mimecast** option from the list and then click **Data Feeds.** 4. Under **Select your data feeds**, select the **URL Protection** click **Credentials.** 5. Under **Credential Name**, give the credential an identifiable name (e.g. `Mimecast Credentials`). 6. Under **Required** **Credentials**, add the **Client ID** and the **Client Secret Token** that you copied from the previous section. 7. Click **Add Connector** to save the changes. ### Add the action connector in Radiant Security 1. From the navigation menu, select **Settings** > **Action Connectors** and click **+ Add Connector** to create a new action connector. 2. Select the **Mimecast API 2.0** connector and click **Credentials**. 3. Select the credential for the data connector that you created previously from the drop-down menu. 4. Click **Add Connector** to save your changes. ### Verify ingestion After Mimecast begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"mimecast_url_protection_api_v2"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Proofpoint TAP Connect Proofpoint TAP to Radiant Security to forward URL Defense click events for AI triage. Proofpoint TAP is an email security product that detects and blocks phishing, malware, and credential-theft threats delivered through email. Connecting Proofpoint TAP forwards URL Defense click events to Radiant Security via the Proofpoint API. Radiant uses these events for AI triage, giving analysts visibility into phishing links accessed from unmanaged devices and identifying users who clicked from personal machines. {% hint style="info" %} Looking for the response action connector? See [Execute Response Actions with Proofpoint TAP](https://help.radiantsecurity.ai/radiant-connectors/data-connectors/proofpoint-tap/execute-response-actions-with-proofpoint-tap). {% endhint %} At the end of this configuration, you provide Radiant Security with the following values: * **Service Principal** * **Secret** * **API Base URL** ### Prerequisites * [ ] Admin access to Proofpoint TAP ### Generate Proofpoint TAP service credentials 1. Sign in to the [TAP dashboard](https://threatinsight.proofpoint.com/). 2. Navigate to **Settings** > **Connected Applications**. 3. Click **Create New Credential**. 4. Enter a name for the new credential, then click **Generate**. 5. Copy the **Service Principal** and **Secret** values from the prompt. You will provide these values to Radiant Security in the next section. {% hint style="warning" %} Copy the **Secret** value now. It cannot be retrieved later. {% endhint %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Proofpoint API v2**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **URL Defense**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for this credential (e.g., `Proofpoint Credentials`). 6. Under **Required Credentials**, enter the following: * **Service Principal**: the value copied in the previous section. * **Secret**: the value copied in the previous section. * **API Base URL**: the URL of your Proofpoint TAP dashboard. 7. Click **Add Connector** to save the configuration. ### Verify ingestion After Proofpoint TAP begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"proofpoint_url_defense"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Execute Response Actions with Proofpoint TAP Configure the action connector for Proofpoint. In this guide, you will create new credentials for the Proofpoint API in order to enable containment and remediation tasks.
:bolt-lightning: Available actions The following action is available after you set up the Proofpoint action connector. Keep in mind, additional permissions are required. * Block sender
At the end of this configuration, you will provide Radiant Security with the following values: * **Username** * **Password** * **API Base URL** * **Domain** To configure the Proofpoint data connector, check out the [Proofpoint](/radiant-connectors/email-and-collaboration/proofpoint-tap) guide. ### Prerequisites * [ ] Admin access to Proofpoint TAP ### Create credentials for the Proofpoint API 1. Sign in to the [TAP dashboard](https://threatinsight.proofpoint.com/). 2. Navigate to **Administration > User Management > Users**. 3. Click **Add a User**. 4. Fill in the required information: * **First Name:** Enter any name that identifies this credential as the Radiant Security Action Connector credential * **Email Address:** Enter any valid email address * **Role:** Organization Admin 5. Click **Save**. 6. Check the inbox of the email address used to create the user account and look for the **Welcome** email sent by Proofpoint. Click on the link provided in this email to set the password and activate the account. ### Add the action connector in Radiant Security 1. Login to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Action Connectors** and click **+ Add Connector**. 3. Select the **Proofpoint API V1** vendor and click **Credentials**. 4. Enter the credential values used to create the Proofpoint API credentials in the previous section: * **User** * **Password** * **API Base URL**: the ssame URL used to log into Proofpoint console * **Domain**: the domain configured on Proofpoint 5. Click **Add Connector** to save the connector configuration. # Endpoint # Cisco # Cisco Secure Endpoint Connect Cisco Secure Endpoint to Radiant Security to forward endpoint alerts for AI triage. Cisco Secure Endpoint (formerly Cisco AMP for Endpoints) is an endpoint detection and response platform that monitors files, processes, and network activity on managed hosts to surface malware, fileless attacks, and lateral movement. Connecting Cisco Secure Endpoint forwards alerts to Radiant Security through the Secure Endpoint REST API. Radiant uses these alerts for AI triage, giving analysts endpoint context to assess suspicious host activity without pivoting to the Cisco console. At the end of this configuration, you provide Radiant Security with the following values: * **Client ID** * **Client secret** * **Cloud region** (North America or Europe) ### Prerequisites * [ ] Admin access to Cisco Secure Endpoint or Cisco XDR * [ ] Cisco Secure Endpoint agents deployed on the endpoints you want to monitor ### Create API credentials in Cisco Secure Endpoint For vendor instructions, see [Secure Endpoint API authentication](https://developer.cisco.com/docs/secure-endpoint/authentication/) in the Cisco DevNet documentation. 1. Sign in to **Cisco Secure Endpoint** or **Cisco XDR** with an admin account. 2. Navigate to **Administration** > **API Clients**. 3. Click **Generate API Client**. 4. Enter a **Client Name** to identify the credential (e.g., `Radiant_Security_Secure_Endpoint`). 5. Under **Scope**, select at least one Secure Endpoint scope that grants read access to alerts and events. 6. Optionally enter a **Description**, then click **Add New Client**. 7. Copy and store the **Client ID** and **Client Password** (client secret). {% hint style="warning" %} The client password is shown only once and cannot be recovered. If it is lost, you must generate a new API client. {% endhint %} {% hint style="info" %} If you also plan to enable [Cisco Orbital Query](/radiant-connectors/endpoint/cisco/cisco-orbital-query) for live endpoint queries during investigation, include the **Orbital** scope when creating this API client. Both feeds use the same credential. {% endhint %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Cisco Secure Endpoint REST API**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco Secure Endpoint Alerts**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name (e.g., `Cisco Secure Endpoint Credentials`). To reuse existing credentials, select them from the drop-down menu. 6. Under **Required Credentials**, enter the following: * **Client ID**: Paste the client ID from Cisco Secure Endpoint. * **Client secret**: Paste the client password from Cisco Secure Endpoint. * **Cloud region**: Select **North America** or **Europe** to match your Secure Endpoint tenant. 7. Click **Add Connector**. ### Verify ingestion After Cisco Secure Endpoint begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cisco_secure_endpoint_alerts"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Cisco Orbital Query Connect Cisco Orbital Query to Radiant Security for on-demand endpoint queries during AI triage and investigation. Cisco Orbital is a live osquery engine built into the Cisco Secure Endpoint agent that executes ad hoc SQL queries against endpoint processes, files, users, and network state in real time. Connecting Cisco Orbital Query gives Radiant Security on-demand query access to this endpoint state through the Secure Endpoint REST API. Radiant executes these queries during AI triage and investigation, giving analysts live host context to confirm the scope of suspicious activity. {% hint style="info" %} Cisco Orbital Query works alongside [Cisco Secure Endpoint Alerts](/radiant-connectors/endpoint/cisco/cisco-secure-endpoint). Secure Endpoint Alerts provides the alert stream Radiant triages; Orbital Query provides live endpoint telemetry when Radiant needs to confirm scope during investigation. {% endhint %} At the end of this configuration, you provide Radiant Security with the following values: * **Client ID** * **Client secret** * **Cloud region** (North America or Europe) ### Prerequisites * [ ] Admin access to Cisco Secure Endpoint or Cisco XDR * [ ] Cisco Secure Endpoint agents deployed and reporting on the endpoints you want to query ### Create API credentials in Cisco Secure Endpoint If you already created credentials for Cisco Secure Endpoint Alerts and included the **Orbital** scope, skip to Add the data connector in Radiant Security. For vendor instructions, see [Secure Endpoint API authentication](https://developer.cisco.com/docs/secure-endpoint/authentication/) in the Cisco DevNet documentation. 1. Sign in to **Cisco Secure Endpoint** or **Cisco XDR** with an admin account. 2. Navigate to **Administration** > **API Clients**. 3. Click **Generate API Client**. 4. Enter a **Client Name** to identify the credential (e.g., `Radiant_Security_Orbital`). 5. Under **Scope**, select **Orbital**. To reuse this client for the [Cisco Secure Endpoint Alerts](https://help.radiantsecurity.ai/radiant-connectors/endpoint/cisco/cisco-secure-endpoint-alerts) feed, also select the scope that grants read access to alerts. 6. Optionally enter a **Description**, then click **Add New Client**. 7. Copy and store the **Client ID** and **Client Password** (client secret). {% hint style="warning" %} The client password is shown only once and cannot be recovered. If it is lost, you must generate a new API client. {% endhint %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Cisco Secure Endpoint REST API**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco Orbital Query**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name (e.g., `Cisco Secure Endpoint Credentials`). To reuse credentials created for Secure Endpoint Alerts, select them from the drop-down menu. 6. Under **Required Credentials**, enter the following: * **Cloud region**: Select **North America** or **Europe** to match your Secure Endpoint tenant. * **Client ID**: Paste the client ID from Cisco Secure Endpoint. * **Client secret**: Paste the client password from Cisco Secure Endpoint. 7. Click **Add Connector**. ### How Orbital Query collects data Orbital Query does not continuously ingest logs. Radiant executes live osquery statements against targeted endpoints during investigation when additional endpoint context is needed. Queries target endpoints using node identifiers such as `amp:`, where the connector GUID is the Secure Endpoint agent identifier for the host. ### Verify the connector Because Orbital Query operates on demand, there is no continuous log stream to verify in Log Management. Confirm the connector is enabled and the credentials are valid: 1. In Radiant, navigate to **Settings** > **Data Connectors**. 2. Locate **Cisco Orbital Query** and confirm the connector status is healthy. Once the status is healthy, Radiant can execute Orbital queries against the affected endpoint when it investigates a Cisco Secure Endpoint alert. {% hint style="info" %} If queries fail with an authentication error, confirm the API client includes the **Orbital** scope and that the **Cloud region** matches your tenant (North America or Europe). {% endhint %} # Crowdstrike FDR Pull Crowdstrike FDR endpoint data. In this guide, you will create new credentials for Crowdstrike FDR in order to pull endpoint events, alerts, incidents, and host details. This endpoint data is used to identify impacted identities who have clicked on malicious links and impacted devices in which malicious files were downloaded, as well as collect rich details about the impacted devices. At the end of this configuration, you will provide Radiant Security with the following values: * **AWS Client ID** * **AWS Secret Key** * **SQS URL** ### **Prerequisites** To complete the configuration, you will need the following: * [ ] Admin access to CrowdStrike Falcon * [ ] License: `Falcon Insight and Falcon Data Replicator` * [ ] An active subscription to Falcon Data Replicator—must be enabled in Crowdstrike {% hint style="warning" %} **Important note**: If you are a customer that's already using FDR, please note that Crowdstrike will create two AWS S3 buckets and up to two AWS SQS queues per bucket for a maximum of four feeds. One of the S3 buckets must be reserved for Radiant Security. {% endhint %} ### Create credentials for Crowdstrike FDR 1. Sign in to [CrowdStrike Falcon](https://falcon.us-2.crowdstrike.com/login/) with an admin account. 2. From the upper left corner, click the **Menu** icon. 3. Click **Support and resources**, then click **Falcon data replicator**.\ ![image (15)](https://20705827.fs1.hubspotusercontent-na1.net/hubfs/20705827/Knowledge%20Base%20Articles/Crowdstrike%20FDR/image%20\(15\).png) 4. In the top right, click on the **Create feed** button. 5. On the **Create** **feed** page, enter a **Feed name**, set the feed status to **On**. Keep the default settings selected.\ ![image (16)](https://20705827.fs1.hubspotusercontent-na1.net/hubfs/20705827/Knowledge%20Base%20Articles/Crowdstrike%20FDR/image%20\(16\).png) 6. Click **Next** to proceed. 7. On the next page, keep the default settings unchanged and click **Next**.\ ![image (17)](https://20705827.fs1.hubspotusercontent-na1.net/hubfs/20705827/Knowledge%20Base%20Articles/Crowdstrike%20FDR/image%20\(17\).png) 8. Click the **Create feed** button. 9. Copy the **Client ID**, **Secret**, and **Notifications URL** for the next steps.\ ![image (18)](https://20705827.fs1.hubspotusercontent-na1.net/hubfs/20705827/Knowledge%20Base%20Articles/Crowdstrike%20FDR/image%20\(18\).png) {% hint style="warning" %} **Important note**: Be sure to document and store the **Secret Key** carefully as it cannot be retrieved later. {% endhint %} ### Add the credentials in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Credentials** and click **+ Add Credential**. 3. Select the correct vendor from the list and click **Configure** **Credential**. 4. Under **Credential** **Name**, give the credential an identifiable name like `Crowdstrike_FDR_Credentials` and fill in the **Required Credentials** fields with the values you copied from the previous step: * **AWS Client ID** * **AWS Secret Key** * The **SQS URL** should have a format like: `https://sqs.us-east-2.amazonaws.com/` 5. Click **Add** **Credential** to save the changes. ### Add the data connector in Radiant Security 1. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector** to create a new data connector. 2. Select the correct vendor from the list and click **Data Feeds**. 3. Select the applicable data feed and click **Credentials**. 4. From the drop-down, select the credential, or click **+ Add New Credential** to add a new credential if it doesn’t already exist. 5. Click **Add Connector** to finish creating the new data connector. # CrowdStrike OAuth2 Configure Radiant Security to sync CrowdStrike data. In this guide, you'll configure the integration between Radiant Security and CrowdStrike so that your alerts and data can be triaged and leveraged by Radiant's AI. At the end of this configuration, you will provide Radiant Security with the following values: * **Client ID** * **Secret** * **Base URL** ### Prerequisites * [ ] Admin access to CrowdStrike Falcon ### Create the credentials in CrowdStrike Falcon 1. Sign in to [CrowdStrike Falcon](https://falcon.us-2.crowdstrike.com/login/) with an admin account. 2. Expand the side menu and click **Support and resources**. 3. Under **Resources** **and** **tools**, click **API clients and keys.**\ ![](/files/XXTvL3zJkoT8NHRyabzT) 4. Click **Create API**. 5. Enter a **Client** **Name** to help identify the credential (e.g. `Radiant_Security_CrowdStrike`).\ ![](/files/859jgBzd2ETfiZG8Cz1S) 6. Under **Scope**, select **Alerts: Read**, **Alerts: Write**, **NGSIEM: Read**, **NGSIEM: Write**, **CSPM Registration - Read** (this last one is needed if you want Radiant to handle CSPM alerts.) 7. Click **Create.** 8. Copy and store the **Client ID,** **Secret**, and **Base URL** values. ![](/files/391CWBL7wCOqxPlxW7KR) ### Add the data connectors in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **CrowdStrike OAuth2** option from the list and then click **Data Feeds.** 4. **Select the data feeds you want to ingest** and click **Credentials**. 5. In case you had already created credentials, select them from the drop-down and continue. If you haven’t created credentials yet, create one by giving the credential an identifiable name (e.g. `CrowdStrike OAuth2 Credentials`). Then, paste the values (**Base URL**, **Client ID**, and **Client Secret Key**) that you copied from the **Create the credentials in CrowdStrike Falcon** section. Leave the **Prefix** field empty. 6. Click **Add Connector** to save the changes. ### Verify ingestion After CrowdStrike Falcon begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by the `rs_connectorType` for each data feed you enabled:
Data feedFilter
CSPM Alertsrs_connectorType:"crowdstrike_cspm"
Falcon Alertsrs_connectorType:"crowdstrike_alerts"
Next-Gen SIEM Detections & Incidentsrs_connectorType:"crowdstrike_ngsiem_alerts"
Next-Gen SIEM Eventsrs_connectorType:"crowdstrike_ngsiem_events"
3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Execute Response Actions with Crowdstrike OAuth2 Configure the action connector for Crowdstrike OAuth2. In this guide, you will create new credentials for Crowdstrike OAuth2 in order to enable containment and remediation tasks.
:bolt-lightning: Available actions The following actions are available after you set up the Crowdstrike OAuth2 action connector. Keep in mind, additional permissions are required. * Block files * Isolate device * Release devices from isolation
At the end of this configuration, you will provide Radiant Security with these values: * **Client ID** * **Secret** * **Base URL** ### Prerequisites * [ ] Admin access to CrowdStrike Falcon * [ ] License: Falcon Insight ### Create credentials for Crowdstrike Oauth 1. Sign in to [CrowdStrike Falcon](https://falcon.us-2.crowdstrike.com/login/) with an admin account. 2. From the upper left corner, click the **Menu** **icon**. 3. Click **Support and Resource**, then select **API Clients and Keys**. 4. Click **Add new API client** under the **OAuth2 API Clients** section. 5. Add the following information: * Name: `Radiant Security API Access` * Description: `Enable Radiant Security to take containment and remediation actions.` * Permissions:
PermissionReadWriteUse Case
HostsXXEndpoint telemetry, endpoint device context, endpoint actions
IndicatorsXXEndpoint telemetry, endpoint actions
6. Click **Add**. 7. Copy the Client ID, Secret ID, and Base URL for the next steps. * `Client ID` * `Client Secret Key` * `Base URL`\ \ ![CS SSD](https://20705827.fs1.hubspotusercontent-na1.net/hubfs/20705827/Knowledge%20Base%20Articles/Action%20Connector%20-%20Crowdstrike%20OAuth2/CS%20SSD.jpg) {% hint style="warning" %} **Important note:** Be sure to document and store the **Secret** carefully, as it cannot be retrieved later. {% endhint %} ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connector** and click **+ Add Connector**. 3. Select the **Crowdstrike OAuth2** vendor from the list and click **Data Feeds.** 4. Under **Select your data feeds,** select **SSD** and **Crowdstrike** **API** and click **Credentials.** 5. Under **Credential Name**, give the credential an identifiable name (e.g.`Crowdstrike Credentials`). 6. Under **Required** **Credentials**, add the **API** **Base** **URL** and the **API Token** that you copied from the previous section. 7. Click **Add Connector** to save the changes.
### Add an action connector 1. From the navigation menu, select **Settings** > **Action Connectors** and click **+ Add Connector** to create a new action connector. 2. Select the correct vendor from the list. 3. Confirm that the selected credentials are correct. 4. Click **Add Connector** to finish creating the new action connector.\
# FireEye HX Connect FireEye HX (now Trellix Endpoint Security HX) to Radiant Security to forward alerts and host data through Cribl Stream for AI triage. FireEye HX (now Trellix Endpoint Security HX) is an endpoint detection and response product that detects intrusions, malware, lateral movement, and credential theft on managed hosts. Connecting through Cribl Stream forwards FireEye HX alerts and host data to Radiant Security over a webhook. Radiant uses these alerts for AI triage, classifying and enriching each before it reaches an analyst. ### Prerequisites * [ ] Admin access to Cribl Stream * [ ] FireEye HX alert and host data configured as a source in Cribl Stream ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **FireEye HX**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **FireEye HX**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for this credential. 6. Under **Required Credentials**, enter a **Webhook Auth Token**. Use a long, randomly generated value, and rotate it periodically. 7. Click **Add Connector**. 8. Open the newly created connector. Under **Vendor Configuration**, copy and save the **Webhook URL**. You will need it in the Create a webhook destination in Cribl Stream section. ### Create a webhook destination in Cribl Stream 1. Sign in to Cribl. 2. Navigate to **Stream**. 3. Use the top navigation to open **Manage** > **Groups**. 4. From the list of groups, click the group that has the FireEye HX data as a **Source**. 5. Use the top navigation to open **Data** > **Destinations**. 6. Filter the Destinations and click **Webhook**. 7. Click **Add Destination**. 8. Under **General Settings**, configure the following: * **Output ID**: `rs-cribl-fireeye-hx` * **URL**: the **Webhook URL** copied from Radiant Security.
9. Click **Authentication** and configure the following: * **Authentication** **type**: `Auth Token` * **Token**: the **Webhook Auth Token** configured in Radiant Security.
10. Click **Save**. 11. Use the top navigation to open **Routing** > **Data Routes**. 12. Click **Add Route**. 13. Configure the route to send FireEye HX data (Hosts and Alerts) to a Pipeline that outputs to the `rs-cribl-fireeye-hx` Destination. For details on configuring Routes and Pipelines, see the [Cribl Stream Routing documentation](https://docs.cribl.io/stream/routes/). ### Verify ingestion After Cribl Stream begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cribl_webhook_hx"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Microsoft Defender for Endpoint # Add Microsoft Defender Permissions Add the Microsoft Defender data connector. In this guide, you will set up a trusted relationship between Radiant and your Microsoft Defender account to allow Radiant to collect endpoint events, alerts, actions, and activity. ### Prerequisites * [ ] Admin access to Azure ### **Grant the registered application the appropriate permissions** 1. Log in to [Azure Admin](https://portal.azure.com/#home) portal. 2. From the left side menu, click **Microsoft Entra ID,** then click **App Registration**. 3. Under **All applications**, search for `radiantsecurity-connector` and open the app. 4. On the left side menu, click **API Permissions**. 5. Click + **Add a permission**. 6. From the pop-out menu, select **APIs my organization uses**.
7. Select **WindowsDefenderATP** and then select **Application permissions**.
8. Select the following permissions: | **API** | **Permission name** | **Required for Data Ingestion?** | **Use Case** | | ------------------ | ---------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------- | | WindowsDefenderATP | AdvancedQuery.Read.All | Yes | Collect endpoint events | | WindowsDefenderATP | Alert.Read.All | Yes | Collect endpoint alerts | | WindowsDefenderATP | File.Read.All | Yes | Collect additional info on files | | WindowsDefenderATP | Ip.Read.All | Yes | Endpoint activity—give the application permissions to collect additional info on IPs | | WindowsDefenderATP | Machine.Isolate | No | Endpoint actions—allow the app to isolate compromised hosts (either automatically or through one-click) | | WindowsDefenderATP | Machine.Read.All | Yes | Endpoint activity—give the application permissions to collect additional info on users involved | | WindowsDefenderATP |

Ti.ReadWrite,
Ti.ReadWrite.All

| No | Endpoint actions—allow the app to allow/deny IOCs (either automatically or through one-click) | | WindowsDefenderATP | URL.Read.All | Yes | Endpoint activity—give the application permissions to collect additional info on domains | | WindowsDefenderATP | User.Read.All | Yes | Endpoint activity—give the application permissions to collect additional info on users involved | 9. Click **Add permissions** to save your changes. 10. Notice that the new permissions have been added. However, there is a warning message that admin consent is missing.
11. To resolve this, click **Grant admin consent** **for the Defender API.**
12. Click **Yes** in the confirmation pop-up window. The warnings have now been resolved.
### Enable the data feed in Radiant Security 1. Log in to [Radiant Security.](https://app.radiantsecurity.ai/) 2. From the navigation menu, click **Settings** > **Data Connectors**. 3. Under the **Data Connectors** page, find **Microsoft O365**. 4. Hover over the connector and click **Enable** to enable data ingestion from Defender. # Defender for Endpoint via Event Hub Add the Microsoft Defender via Event Hub data connector. In this guide, you will configure Microsoft Defender for Endpoint to send events and alerts to Radiant Security using an Event Hub. This setup requires establishing a trusted connection between your Microsoft tenant and Radiant. At the end of this configuration, you will provide Radiant Security with these values: * **Application (client) ID** * **Directory (tenant) ID** * **Client Secret Value** * **Event Hub name** * **Event Hub namespace (URL)** ### Prerequisites * [ ] Admin access to Azure ### Register the application with Microsoft Entra ID {% hint style="info" %} **Note:** You might already have an application configure for other radiant Integrations, it’s okay to reuse it. {% endhint %} In this step, you’ll register a new application with **Microsoft Entra ID**. 1. Sign in to [Azure](https://portal.azure.com/#home). 2. From the left side menu, navigate to **Microsoft Entra ID.** 3. From the left menu, navigate to **App Registrations.** 4. Click **+ New Registration.**
5. Update the application **Name** to `radiantsecurity-connector` and leave all default settings unchanged.
6. Click **Register** to save the changes. 7. On the newly registered application page, copy the following values: * **Application (client) ID** * **Directory (tenant) ID**
8. On the same page, click the link for **Add a certificate or secret.**
9. In the **Add a client** window, click **+ New Client Secret.** 10. Set the client secret as: * **Description**: `Radiant Security Connector` * **Expires**: `12 months`
11. Click **Add.** 12. The client secrets page will automatically open. 13. Copy the **Value** (not the **Secret ID** field).
{% hint style="warning" %} **Important note:** Ensure you copy the **Client secret** value now as you won't be able to look it up again later. You will need to provide it to Radiant Security at the end of the configuration. {% endhint %} ### Create an Event Hub 1. Log in to **Azure Portal.** 2. Navigate to the **Event Hubs** service.
3. Click **Create.** 4. Select the subscription and resource group where the **Event Hubs Namespace** must be created. 5. Enter a unique name for the **Namespace.**
6. Select the **region.** 7. Click **Next.** 8. Choose **Basic** for the pricing tier. 9. Leave the **throughput units** or **processing units** as default. 10. Click **Review** 11. After the deployment is complete, click on **Go to resource.** 12. On the **Overview** page, get the Host Name value, as it will be used on the next section.
13. Click on **+ Event Hub** to create a new Event Hub on the newly created **Namespace.** 14. Enter a name for your event hub, then click **Review + Create.** 15. In the EventHub page, go to **Access Control (IAM)** and click **Add + → Add role assignment.**
16. Select the role **Azure Event Hubs Data Receiver.** 17. Click **Next** and on **Members**, click **+ Select Members.** 18. Select the Azure Application created in the previous section and click **Review + assign.** ### Configure Azure Streaming API on Microsoft Defender 1. Log in to **Microsoft Defender Portal.** 2. Navigate to **Settings > Microsoft Defender XDR > Streaming API** and select **Forward events to Event Hub.** 3. Enter the **Event Hub Resource ID** and the **Event Hub** name obtained previously. 4. Select all **Event Types** within the **Device** and **Alerts & behaviors** categories.
5. Click **Submit.** ### Add the connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for From the list of connectors, select **Microsoft Defender for Endpoint via Event Hub**. 4. Add the following values you saved from the previous steps: * Application (client) ID * Directory (tenant) ID * Client Secret Value * Event Hub name * Event Hub namespace URL 5. Click **Add Connector** to save the connector configuration. ### Verify ingestion After Microsoft Defender via Event Hub begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"ms365_defender_eventhub"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Onboard Hosts to Microsoft Defender for Endpoint Obtain the list of assets that do not require onboarding to Defender for Endpoint. In this guide, you'll gather a list of devices that are already onboarded to Microsoft Defender for Endpoint, as well as those currently managed by your organization through Azure Entra ID, Intune, or Active Directory. This comparison helps ensure full coverage and identify any unmanaged or unmonitored endpoints. ### Prerequisites * [ ] Global Admin or Security Administrator access to Microsoft 365 {% hint style="info" %} **Note**: Skip this step if this is your first time onboarding devices to Defender. {% endhint %} 1. Access the [Microsoft Security](https://www.security.microsoft.com) portal. 2. On the left menu, click **Devices**. 3. On the **Computers & Mobiles** tab, you will see a list of the devices already registered on Defender for Endpoints. 4. Click the **Export** button to export the current view in order to compare with the list of managed devices in the organization. ### List devices registered on the organization If the devices are registered on Azure Entra ID (Azure AD), then complete the following steps: 1. Log in to the [Microsoft Azure Portal](https://portal.azure.com/#home). 2. On the left menu, click on **Microsoft Entra ID**. 3. Click **Devices**, then click **All Devices**. 4. This page provides the list of devices registered on the domain.
5. Click **Download Devices** to export the current view in order to compare with the list of devices onboarded to Defender for Endpoint.
### Devices managed by Intune If the devices are managed by Intune, then complete the following steps: 1. Access the [www.security.microsoft.com](http://security.microsoft.com/) portal. 2. On the left menu, click **Devices**, then click **All devices**. 3. This page provides the list of devices managed by Intune. 4. Click the **Export** button to export the current view in order to compare with the list of devices onboarded into Defender for Endpoint. In case your organization has an on-premises Active Directory, get the list of registered computers by running the following command via Powershell on the AD: ``` Get-ADComputer -Filter * -Properties  * | Select Name, DistinguishedName ``` ### Requirements for onboarding devices to Defender for Endpoint There are some requirements for onboarding devices to the Defender for Endpoint service: * [ ] For information on software requirements, check out [Microsoft documentation.](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/minimum-requirements?view=o365-worldwide#supported-windows-versions) * [ ] Access to a global admin or security administrator account * [ ] List of devices to onboard from previous step For Windows devices we have the following onboarding methods available: * [ ] Local script (up to 10 devices) * [ ] Group Policy * [ ] Microsoft Intune * [ ] Mobile Device Manager * [ ] Microsoft Configuration Manager * [ ] VDI Scripts Since some methods are heavily dependent on an organization's architecture and configuration, we'll only cover the first two onboarding methods: **local script** and **group policy.** For more detailed information on the other methods, please refer to the [Microsoft documentation](https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/deployment-strategy?view=o365-worldwide#step-2-select-deployment-method). ### Local script This is usually used to test the onboarding process and to onboard test devices. 1. Access the [www.security.microsoft.com](http://security.microsoft.com/) portal. 2. On the left menu, select **Settings** > **Endpoints** > **Device** **management** > **Onboarding**.
3. In the **Select** **the operating system** drop-down, select the operating system. 4. In the **Deployment** **Method** drop-down, select **Local** **Script** and then click **Download onboarding package**.
5. Save the file and extract its content on the device you want to onboard. You should have a file named `WindowsDefenderATPLocalOnboardingScript.cmd`. 6. Hit the **Windows Key** and type **CMD,** then click on **Run as administrator**. 7. Type the path to the extract file with `WindowsDefenderATPLocalOnboardingScript.cmd` at the end to run the script. 8. Wait until the script finishes the onboarding process and then access the security portal and check if the device is listed under **Assets** > **Devices**. ### Group policy This method uses a group policy to deploy and run the onboarding script on the selected devices. 1. Access the [www.security.microsoft.com](http://security.microsoft.com/) portal. 2. On the left menu, select **Settings** > **Endpoints** > **Device** **management** > **Onboarding**.
3. In the **Select** **the operating system** drop-down, select the operating system. 4. In the **Deployment** **Method** drop-down, select **Group Policy** and then click **Download onboarding package**.
5. Click **Download onboarding package** and save the .zip file. 6. Extract the contents of the .zip file to a shared, read-only location that can be accessed by the devices being onboarded. You should have a folder named `OptionalParamsPolicy` and the file **`WindowsDefenderATPOnboardingScript.cmd`.** 7. To create a new GPO, access your **Active Directory and** open the **Group Policy Management Console (GPMC)**, right-click **Group Policy Objects** you want to configure and click **New**. Enter the name of the new GPO in the dialogue box and click **OK**. 8. Open the **Group Policy Management Console (GPMC)**, right-click the **Group Policy Object (GPO)** you want to configure and click **Edit.** 9. In the **Group Policy Management Editor**, go to **Computer configuration**, then **Preferences**, and then **Control panel settings.** 10. Right-click **Scheduled tasks**, point to **New**, and then click **Immediate Task.** 11. In the Task window, go to the **General** tab. 1. Under **Security** **options** click **Change User or Group** and type **SYSTEM**. 2. Click **Check Names** then click **OK**. **NT AUTHORITY\SYSTEM** appears as the user account that the task will run as. 12. Select **Run** **whether user is logged on or not** and select the **Run with highest privileges** checkbox. 13. In the **Name** field, enter an appropriate name for the scheduled task (for example, Defender for Endpoint Deployment). 14. Go to the **Actions** tab and select **New.** 1. Ensure that **Start a program** is selected in the **Action** field. 2. Enter the **UNC path** using the file server's fully qualified domain name (FQDN), along with the full path to the **WindowsDefenderATPOnboardingScript.cmd** file.\ Example: `\\\\Server2.mydomain\\Share\\Test\\WindowsDefenderATPOnboardingScript.cmd` 15. Select **OK** and close any open GPMC windows. 16. To link the GPO to an Organization Unit (OU), right-click and select **Link** **an existing GPO**. 1. In the dialogue box that is displayed, select the **Group Policy Object** that you wish to link. Click **OK**. # SentinelOne # SentinelOne Cloud Funnel Connect SentinelOne Cloud Funnel to Radiant Security to forward EDR telemetry for AI triage. In this guide, you will integrate SentinelOne Cloud Funnel with Radiant in order to sync SentinelOne EDR telemetry. {% hint style="warning" %} Unless you have specific needs to sync all your EDR telemetry data into Radiant Log Management, it is recommended to use the [SentinelOne Singularity Data Lake integration](/radiant-connectors/endpoint/sentinelone/sentinelone-singularity-data-lake) instead of SentinelOne Cloud Funnel. {% endhint %} {% hint style="info" %} This connector brings EDR telemetry but no alerts nor sensors info. For syncing alerts and sensors info, please also integrate with [SentinelOne Deep Visibility](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility). {% endhint %} At the end of this configuration, you will provide Radiant Security with the following values: * **Queue URL** ### Prerequisites * [ ] Admin access to SentinelOne ### Create a destination S3 bucket {% hint style="info" %} **Note:** If you are already exporting Cloud Funnel logs to an existing bucket, or if Radiant Security is providing a bucket for you, you can skip this section. {% endhint %} 1. From the AWS console, select the S3 service. 2. Click **Create bucket** to create a new bucket. 3. Select your preferred region and give the destination bucket a unique name. Note this name down for later. 4. Under **Object Ownership**, select the **ACLs enabled** option. 5. Click **Create bucket** to complete the bucket creation. ### Configure the destination S3 bucket {% hint style="info" %} **Note:** If Radiant Security is providing a bucket for you, you can skip this section and the **Create and configure a notification queue for the S3 bucket** section. {% endhint %} 1. Select the bucket from the list of S3 buckets. 2. Click the **Permissions** tab. 3. Edit the bucket policy and paste in the following, making sure to replace `` with the name of the bucket containing the Cloud Funnel logs: {% hint style="info" %} If you are an E.U. tenant, replace `649384204969` in the statement below by `076657324990` {% endhint %} {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::649384204969:root" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::/*" } ] } ``` {% endcode %} 4. Click **Save changes**. 5. Configure the permission needed for SentinelOne Cloud Funnel to write files to your bucket. On the **Permissions** tab of your bucket, scroll down to **Access Control List (ACL)** and click **Edit**.
6. Click **Add grantee.** 7. Enter SentinelOne’s canonical ID: `c768943f39940f1a079ee0948ab692883824dcb6049cdf3d7725691bf4f31cbb` 8. Select the checkboxes for **List** and **Write** objects, and click **Save changes.**
{% hint style="warning" %} **Important note:** For FedRAMP environments, use this canonical ID instead: `3b40642cbf594ff39a8a280afad55c79b098dce84031ed23f3e104dc983eede2` {% endhint %} ### Create and configure a notification queue for the S3 bucket {% hint style="warning" %} **Important note**: Make sure that the queue name conforms to the format provided; otherwise, the integration will not work. {% endhint %} 1. Select **SQS** from the list of AWS services. 2. Click **Create** **queue**. 3. Give the queue the name: `radiant-security-cloud-funnel-connector-` and replace `` with your organization name. 4. Ensure that the **Configuration** values match the following: * **Visibility timeout:** `11 Minutes` * **Delivery delay:** `0 Seconds` * **Receive message wait time:** `0 Seconds` * **Message retention period:** `4 Days` * **Maximum message size:** `256 KB`
5. In the **Access** **policy** section, copy the **Resource** value and save it. 6. Replace the **Access** **policy** with the following, be sure to replace each **``** value with the **Resource** value you copied from step 5: {% hint style="info" %} If you are an E.U. tenant, replace `649384204969` in the statement below by `076657324990` {% endhint %} {% code overflow="wrap" %} ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "SQS:SendMessage", "Resource": "", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::*" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::649384204969:root" }, "Action": [ "SQS:ReceiveMessage", "SQS:DeleteMessage", "SQS:GetQueueAttributes" ], "Resource": "" } ] } ``` {% endcode %} 7. Click **Create** **queue** to create the queue. 8. Copy the value in the **URL** section of the queue page and store it for later use. This will be the **Queue** **URL** that you’ll provide to Radiant Security when you create the credential for the SentinelOne Cloud Funnel connector. 9. Return to the S3 service and select the bucket from the list of S3 buckets. 10. Click the **Properties** tab and scroll down to **Event** **notifications**. 11. Click **Create** **event** **notification**. 12. In the **Name** field enter: `radiant-security-cloud-funnel-connector` 13. In the **Event types** section, select the **All object create events** checkbox. 14. In the **Destination** section, select **SQS queue** and select your created queue from the drop-down or, copy the ARN/resource ID that you previously saved. 15. Click **Save** **changes** to submit the changes. ### Enable Cloud Funnel 1. Make note of the name of the S3 bucket destination for Cloud Funnel. 2. Log into your SentinelOne console with an admin account. 3. Hover your cursor over the SentinelOne logo to open the navigation pane. 4. Select **Settings** and then click the **INTEGRATIONS** tab. 5. In the navigation pane, select **Cloud Funnel**. 6. From the **Cloud Providers** drop-down, select **AWS (Amazon Web Services).** 7. In the **S3 bucket name** field, paste the destination S3 bucket name that you noted in step 1. 8. Click **Validate** to ensure SentinelOne has access to the bucket. 9. Select the **Enable Telemetry** **Streaming** checkbox. 10. Add the query filter `endpoint.name = *` to the filter box. 11. Click the **Validate** button to ensure the query is valid. 12. Click the **Save** button. ### Add the Cloud Funnel data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **SentinelOne CloudFunnel** option from the list and then click **Data Feeds**. 4. Click **Credentials.** 5. Give the credential an identifiable name (e.g. `SentinelOne Cloud Funnel Credentials`). 6. Under **Required** **Credentials**, paste in the **Queue URL** that you copied from the previous section. 7. Click **Add Connector** to save the changes. #### What data Cloud Funnel collects Cloud Funnel collects telemetry data *only*. To collect alerts and sensors information, you must pair Cloud Funnel with a [SentinelOne Deep Visibility integration](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility). {% hint style="info" %} :plug: To add the **action connector** in Radiant, please refer to the specific guide: [SentinelOne](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility/execute-response-actions-with-sentinelone). {% endhint %} ### Verify ingestion After SentinelOne Cloud Funnel begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"sentinelone_cloudfunnel"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # SentinelOne Deep Visibility Connect SentinelOne Deep Visibility to Radiant Security to forward EDR alerts and sensor information for AI triage. SentinelOne Deep Visibility is an endpoint detection and response platform that monitors process, file, network, and user activity to surface threats such as malware, ransomware, fileless attacks, and lateral movement. Connecting Deep Visibility forwards EDR alerts and sensor information to Radiant Security via the SentinelOne API. Radiant delivers a verdict on whether the alert reflects a real compromise on the affected endpoint. {% hint style="info" %} For the EDR alerts to be triaged by our AI, Radiant also needs access to EDR telemetry. In order to give Radiant access to EDR telemetry data, the Deep Visibility integration needs to exist alongside either [SentinelOne Singularity Data Lake integration](/radiant-connectors/endpoint/sentinelone/sentinelone-singularity-data-lake) (recommended) or [SentinelOne Cloud Funnel](/radiant-connectors/endpoint/sentinelone/sentinelone-cloud-funnel). {% endhint %} At the end of this configuration, you will provide Radiant Security with the following values: * **API Token** * **API Base URL (console URL).** For example: `https://usea1-swprd1.sentinelone.net` ### Prerequisites * [ ] Admin access to SentinelOne ### Create a service user in SentinelOne 1. Log into your SentinelOne console with an admin account. 2. Hover your cursor over the SentinelOne logo to open the navigation pane. 3. Select **Settings** and then click the **USERS** tab. 4. In the navigation pane, select **Service Users**. 5. From the **Actions** drop-down list, select **Create New Service User**. ![](/files/x26RiLNtNZAWKP7Fgs1i) 6. In the dialog box, fill in the service account information with the following: * **Name:** `radiant_api_service` * **Description:** `Radiant Security API Service Account` * **Expiration Date:** `1 Years` 7. Click **Next.** 8. If you manage multiple customers: * Under **Select Scope of Access**, click **Site**. * Select the site that belongs to the customer that you are configuring monitoring for. 9. If you do not manage multiple customers: * Under **Select Scope of Access**, click **Account**. * Select the account that the user should have access to. 10. From the role type drop-down list, select **Viewer**. 11. Click **Create User** to save the newly created user. 12. In the API Token dialog box, copy the **API Token** value to provide to Radiant Security. {% hint style="warning" %} **Important note**: Be sure to document and store the API token value carefully, as it cannot be retrieved later. This will be provided to Radiant Security in the next section. {% endhint %} ### Create a role and add the necessary permissions 1. Log into your SentinelOne console with an admin account. 2. Hover your cursor over the SentinelOne logo to open the navigation pane. 3. Select **Settings** and then click the **USERS** tab. 4. In the navigation pane, select **Roles**. 5. From the **Actions** drop-down menu, select **New Role**. 6. In the dialog box, fill in the following information: * **Role Name**: `Radiant Security Service Role` * **Description**: `Radiant Security API Service Role` 7. Find and add the following permissions to give Radiant Security access to read data: * **Endpoints**: `View`, `View Threats`, and `Search on Deep Visibility` * **Endpoint** **Threats**: `View` * **SDL** **Data**: `View` and `View EDR` * **SDL Search (Formerly Skylight)**: `View` * This step is *optional*. Find and add the following permission to give Radiant Security access to the Custom STAR cloud detection alerts created in SentinelOne: * **Custom Alerts:** `View` 8. This step is *optional*. Find and add the following permissions to give Radiant Security access to take certain actions in your environment: * **Endpoints**: `Disconnect from Network` , `Reconnect to Network` , `Initiate Scan` and `Abort Scan` * **Blocklist**: `View`, `Edit`, `Delete`, and `Create` 9. Click **Save**. ### Create a service user and generate the API token 1. Log into your SentinelOne console with an admin account. 2. Hover your cursor over the SentinelOne logo to open the navigation pane. 3. Select **Settings** and then click the **USERS** tab. 4. In the navigation pane, select **Service Users**. 5. From the **Actions** drop-down menu, select **Create New Service User**. 6. In the dialog box, fill in the service account information: * **Name:** `radiant_api_service` * **Description:** `Radiant Security API Service Account` * **Expiration Date:** `1 Years` 7. Click **Next**. 8. If you manage multiple customers: * Under **Select Scope of Access**, click **Site**. * Select the site that belongs to the customer that you are configuring monitoring for. 9. If you *do not* manage multiple customers: * Under **Select Scope of Access**, click **Account**. * Select the account that the user should have access to. 10. From the role type drop-down menu, select the **Radiant Security Service Role** created in the previous steps. 11. Click **Create User** to save the newly created user. 12. In the **API Token** dialog box, copy the **API Token** value to provide to Radiant Security. {% hint style="warning" %} **Important note:** Be sure to copy and store the API token value carefully, as it cannot be retrieved later. This will be provided to Radiant Security in the next section. {% endhint %} ### Add the credentials in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Credentials** and click **+ Add Credential**. 3. Select **SentinelOne Deep Visibility** from the list and click **Configure Credential.** 4. Under **Credential** **Name**, give the credential an identifiable name (e.g. `SentinelOne Deep Visibility Credentials`). 5. Under **API Base URL**, paste in your SentinelOne console base URL in the format `https://.sentinelone.net` 6. Under **API** **Token**, paste the token that you copied in a previous step. 7. Click **Add Credential** to save the changes. ### Add the Deep Visibility data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **SentinelOne** option from the list and then click **Data Feeds**. 4. Select *only* the **SentinelOne Alerts & Sensor Info** data feed and click **Credentials.** 5. From the drop-down menu, select the **SentinelOne Deep Visibility** credential that you created in the previous section. 6. Click **Add Connector** to save the changes. {% hint style="info" %} To add the **action connector** in Radiant, please refer to the specific guide: [SentinelOne](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility/execute-response-actions-with-sentinelone). {% endhint %} ### Verify ingestion After SentinelOne Deep Visibility begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"sentinelone_alert_source"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # SentinelOne Deep Visibility: Set the API Key Expiry Generate new credentials for the SentinelOne connector. ### Prerequisites * [ ] Admin access to SentinelOne ### Create a new Service User in SentinelOne 1. Log into your SentinelOne console with an **Admin** role account. 2. On the left side, hover your cursor under the SentinelOne logo to open the navigation pane. 3. Select **Settings** and then click the **USERS** tab. 4. In the navigation pane, select **Service Users**. 5. From the list of service accounts, find and click the account previously created for Radiant Security named `radiant_api_service`. 6. From the action menu, click **Copy User**. 7. In the dialog box, update the service account information: 1. **Name:** `radiant_api_service_2` 2. **Description:** `Radiant Security API Service Account` 3. **Expiration Date:** `1 Year` 8. Click **Next**. 9. The correct scopes should be automatically selected. If not, configure them with the following settings: 1. If you manage multiple customers: 1. Under **Select Scope of Access**, click **Site**. 2. Select the customer's site you are configuring monitoring for. 2. If you *do not* manage multiple customers: 1. Under **Select Scope of Access**, click **Account**. 2. Select the account that the user should have access to. 10. Click **Create User** to save the newly created user. 11. In the API Token dialog box, copy the **API Token** value to provide to Radiant Security. {% hint style="warning" %} **Important note:** Document and store the **API token value** carefully, as it cannot be retrieved later. This will be provided to Radiant in the next step. {% endhint %} ### Update API token credentials in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** and then click **Credentials.** 3. Locate the **SentinelOne** credential to update. 4. Hover over the credential and click the icon that appears on the right side. 5. In the right-side menu that appears, click **Actions** and select **Edit Credentials**. 6. Update the **API token**. 7. Click **Apply Updates**. # Execute Response Actions with SentinelOne Configure the action connector for SentinelOne. In this guide, you'll configure the integration between SentinelOne and Radiant to automatically run containment and remediation actions after endpoint attacks.
:bolt-lightning: Available actions The following actions are available after you set up the SentinelOne action connector. Keep in mind, additional permissions are required. * Isolate devices * Release devices from isolation * Block files * Run full disk scan
To be able to add the action connector, you will need to provide Radiant Security with the following values, from the data connector onboarding: * **API Base URL (console URL).** For example: `https://usea1-swprd1.sentinelone.net` * **API Token** {% hint style="info" %} :plug: If you haven't configured the SentinelOne **data connectors** yet, check out the [SentinelOne Deep Visibility](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility) and [SentinelOne Singularity Data Lake](/radiant-connectors/endpoint/sentinelone/sentinelone-singularity-data-lake) guides. {% endhint %} ### Prerequisites * [ ] Admin access to SentinelOne ### Add the action connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings > Action Connectors** and click **+ Add Connector**. 3. Select **SentinelOne** from the menu and click **Credentials.** 4. Add the following values from the previous section: * **API Base URL (console URL).** For example: `https://usea1-swprd1.sentinelone.net` * **API Token** 5. Click **Add Connector** to save the connector configuration. # SentinelOne Singularity Data Lake Connect SentinelOne Singularity Data Lake to Radiant Security to query endpoint telemetry during AI triage. SentinelOne Singularity Data Lake stores endpoint, identity, and cloud telemetry from SentinelOne sensors and third-party sources at the core of the SentinelOne Singularity platform. Connecting Singularity Data Lake gives Radiant Security on-demand query access to endpoint telemetry via the SDL API. Radiant uses this telemetry to enrich SentinelOne alerts with the process, file, network, and login activity an analyst needs to confirm scope. {% hint style="warning" %} **Important note:** This connector is used alongside the SentinelOne Deep Visibility Alerts connector to collect in triage alerts. In order to enable Radiant to collect alerts, configuration of the other connector is required. {% endhint %} At the end of this configuration, you will provide the following values: * **API Token** * **API Base URL** for example: `https://xdr.us1.sentinelone.net` ### Prerequisites * [ ] Admin access to SentinelOne ### Create the API Key 1. Log into your SentinelOne console with an admin account. 2. Hover your cursor over the SentinelOne logo to open the navigation pane. 3. Select **Visibility** to access **Singularity Data Lake**, this will redirect to a new console. Copy the URL of the SDL console as the value for the **API Base URL**. 4. In the top right corner, click on your username, and then click **API Keys**. 5. In the **Log Access Keys** section, click **Add Key** and **Add Read Key** to generate a new key. 6. Use the **Copy to Clipboard** button next to the key, or the **Show Keys** button to copy the key. You will need to provide this value to Radiant Security at the end of the configuration. ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **SentinelOne Singularity Data Lake** option from the list and then click **Data Feeds**. 4. Click **Credentials**. 5. Give the credential an identifiable name (e.g. `SentinelOne SDL Credentials`). 6. Under **API Base URL**, paste in your SentinelOne that you copied in step 3 of [Create the API Key](#create-api-key) section. 7. Under **API** **Token**, paste the token key that you copied in step 6 of [Create the API Key](#create-api-key) section. ### What data Singularity Data Lake collects Singularity Data Lake collects telemetry data *only*. To collect alerts and sensors information, you must pair Singularity Data Lake with the SentinelOne Deep Visibility integration by following [this guide](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility). {% hint style="info" %} :plug: To add the **action connector** in Radiant, please refer to the specific guide: [SentinelOne](/radiant-connectors/endpoint/sentinelone/sentinelone-deep-visibility/execute-response-actions-with-sentinelone). {% endhint %} ### Verify ingestion After SentinelOne Singularity Data Lake begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"sentinelone_sdl"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Sophos Intercept X Connect Sophos Intercept X to Radiant Security to ingest endpoint alerts from Sophos Central for AI triage. Create API credentials in Sophos Central and use them to connect Sophos Intercept X (Sophos Endpoint) to Radiant Security. Once connected, Radiant ingests Sophos endpoint alerts and runs them through the AI triage pipeline. At the end of this configuration, you will provide Radiant Security with the following values: * **Client ID** * **Client Secret** ### Prerequisites * [ ] Enterprise Super Admin access to Sophos Central ### Create credentials in Sophos Central {% stepper %} {% step %} #### Log in to Sophos Central Log in to your [Sophos Central Admin](https://central.sophos.com) account as an **Enterprise Super Admin**. {% endstep %} {% step %} #### Open API Credentials Management Go to **My Products** > **General Settings** > **API Credentials Management**. {% endstep %} {% step %} #### Add the credential In the **Add Credential** dialog, enter the following: * A name for the credential (e.g., `Radiant Integration`) * A description for the credential * For **Role**, select **Service Principal Forensics**
Click **Add**. {% endstep %} {% step %} #### Copy the Client ID and Client Secret Copy the **Client ID** and **Client Secret** and store them securely. {% hint style="warning" %} The **Client Secret** is displayed only once. Copy it immediately. If you lose it, you must generate a new credential. {% endhint %} {% endstep %} {% endstepper %} ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connector** and click **+ Add Connector**. 3. Search for and select the **Sophos API** data feed option, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Sophos Intercept X** and click **Credentials**. 5. Under **Credential Name**, give the credential an identifiable name (e.g., `Sophos Forensics`). 6. Under **Required Credentials**, paste the **Client ID** and **Client Secret** values copied from Sophos Central. 7. Click **Add Connector**. ### Verify ingestion After Sophos Intercept X begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"sophos_intercept_x"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Trend Micro # Trend Micro Apex Central Configure the Trend Micro Apex Central syslog connector in Radiant Security to forward Apex Central logs for AI triage. Connect Trend Micro Apex Central to Radiant Security over syslog to forward Apex Central logs for AI triage. This guide covers adding the data connector in Radiant and configuring Apex Central to forward logs to a Radiant Security Agent. ### Prerequisites * [ ] Admin access to Trend Micro Apex Central * [ ] A deployed Radiant Security Agent reachable from Apex Central. See [Install the Radiant Security Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors,** then click **+ Add Connector**. 3. Search for and select **Trend Micro Apex Central (syslog)**, click **Data Feeds**, then click **Credentials**. 4. In **Credential Name**, enter an identifiable name (e.g., `Trend Micro Apex Central Credentials`). 5. In **Connector tag**, enter any value. This value salts the token generated in the next step. 6. Click **Add Connector.** 7. Copy the **Token** value or download the token file. You need this token to complete the syslog configuration in Apex Central. 8. Click **Done** to save your changes. ### Configure Apex Central to forward logs {% stepper %} {% step %} #### Open syslog settings 1. Log in to the Apex Central console. 2. Go to **Administration** > **Settings** > **Syslog Settings**. {% endstep %} {% step %} #### Enable syslog forwarding Click **Enable syslog forwarding**. {% endstep %} {% step %} #### Configure the syslog destination Under **Syslog Settings**, enter the following values: * **Server Address**: `{the IP address configured for the Radiant Security Agent}`. * **Port**: `{the port configured for the Radiant Security Agent}`. * **Protocol**: `SSL/TLS`. * **Use server certificate**: clear this option if it is selected. * **Format**: `CEF`. * **Frequency**: `0` hours, `1` minute. * **Log Type**: select **Security Logs** from the drop-down, then select all checkboxes. {% hint style="info" %} If you do not know which IP address or port to use, contact your Radiant Security customer success representative. {% endhint %}
{% endstep %} {% step %} #### Save the configuration Click **Done**. {% endstep %} {% endstepper %} ### Verify ingestion After Trend Micro Apex Central begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"trendmicro_apex_central"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Trend Vision One Configure the Trend Vision One data connector in Radiant Security to ingest alerts and telemetry for AI triage. Connect Trend Vision One to Radiant Security to ingest alerts, observed attack techniques, and search data for AI triage. This guide covers generating the API key in Trend Vision One and adding the data connector in Radiant. ### Prerequisites * [ ] Admin access to Trend Vision One * [ ] A user role in Trend Vision One with the permissions listed in [Required permissions](#required-permissions) ### Required permissions The user role assigned to the API key must grant the following permissions. | API Category | App | Permissions | | -------------------------- | -------------------------- | ------------------------ | | Alerts / Workbench | Workbench | View, filter, and search | | Observed Attack Techniques | Observed Attack Techniques | View, filter, and search | | Search | Search | View, filter, and search | | API Keys | IAM | View | {% hint style="info" %} The **API Keys: View** permission lets Radiant read API key metadata only, not key values. Radiant uses this metadata to track your credential's expiration date. {% endhint %} ### Generate the Trend Vision One API key 1. In the Trend Vision One console, go to **Administration** > **API Keys**. 2. Click **Add API key**. 3. In **Name**, enter `RADIANT_SECURITY_API_KEY`. 4. In **Role**, select a role that grants the permissions listed in Required permissions. 5. In **Expiration time**, set how long the key remains valid. The default is one year. 6. Confirm that **Status** is enabled and add a description in **Details** if needed. 7. Click **Add**. 8. Copy the API key and store it in a secure location. {% hint style="warning" %} The **Name** value must be exactly `RADIANT_SECURITY_API_KEY`. Radiant uses this name to identify the credential and track its expiration date. {% endhint %} ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select the **Trend Micro Vision One API** option, click **Data** **Feeds** 4. Click on all data feeds to select them and click **Credentials**. 5. Under **Credential Name**, give the credential an identifiable name (e.g. `Trend Vision One Integration`). 6. Enter your **API Base URL** and **API Key**. 7. Click **Add Connector** ### Verify ingestion After Trend Vision One begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by the `rs_connectorType` for each data feed you enabled:
Data feedFilter
Trend Micro Vision One Alertsrs_connectorType:"trendmicro_vision_one_alerts"
Trend Micro Vision One Sensor Infors_connectorType:"trendmicro_vision_one_sensor_info"
Trend Micro Vision One Queryrs_connectorType:"trendmicro_vision_one_query"
3. Confirm recent alerts and events appear for each enabled feed. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Create a Trend Micro Vision One API Token Learn how to create a Trend Micro Vision One API Token. ### Prerequisites * [ ] Admin access to Trend Vision One ### **Obtain authentication tokens** Generate authentication tokens in the Trend Vision One console to access the APIs. 1. On the Trend Micro Vision One console, go to **Administration** > **API Keys**. 2. Generate a new authentication token. 3. Click **Add API key**. 4. Specify the settings of the new API key**:** 1. **Name**: Enter a meaningful name that can help you identify the API key (Example: `RadiantSecurity_API_Token`). 2. **Role**: The user role assigned to the key. The assigned role must have the following permissions: | API Category | App | Permissions | | -------------------------- | -------------------------- | ------------------------ | | Alerts / Workbench | Workbench | View, filter, and search | | Observed Attack Techniques | Observed Attack Techniques | View, filter, and search | | Search | Search | View, filter, and search | 3. **Expiration time**: The time the API key remains valid. By default, authentication tokens expire one year after creation. However, a master administrator can delete and regenerate tokens at any time. 1. **Status**: Provides information about whether the API key is enabled. 2. **Details**: Provides additional information about the API key. 5. Click **Add**. 6. Copy and store the authentication token in a secure location. 7. Log into your Radiant account and go to **Settings** > **Credentials** > **+ Add Credential**
8. Select the credential of type **Secrets Sharing Credential.** 9. Click **Configure credential.**
10. Give it a descriptive name, and add the token in the **Free text** field. 11. Click **Add Credential**.
# Identity & Access # 1Password Connect 1Password to Radiant Security to forward sign-in attempts, item usage, and audit events for AI triage. 1Password is a password manager and enterprise credential vault that protects against credential theft, account takeover, and shadow IT. Connecting 1Password forwards sign-in attempts, item usage events, and audit events to Radiant Security via the 1Password Events API. Radiant uses this telemetry to surface credential misuse, anomalous vault access, and risky sign-in patterns during AI triage. ### Prerequisites * [ ] Admin or Owner access to 1Password ### Issue an Events API token in 1Password For vendor instructions, refer to 1Password's [Events API documentation](https://developer.1password.com/docs/events-api/). {% stepper %} {% step %} #### Open the Integrations page Sign in to the 1Password web app as an Owner or Admin. In the left sidebar, click **Integrations**. In the **Integrations** list, select **Other**. {% endstep %} {% step %} #### Add an integration and name the token Click **Add Integration**. Enter an identifiable name for the integration (e.g., `RadiantSecurity`), then enter an identifiable name for the token (e.g., `RadiantSecurityDataConnector`). {% endstep %} {% step %} #### Grant event permissions Grant the token permission to access the following event types: * `auditevents` * `itemUsages` * `sign-in attempts` {% endstep %} {% step %} #### Issue and save the token Click **Issue Token**, then click **Save in 1Password** and choose a vault to store the token in. Copy the token value: you will paste it into Radiant in the next section. {% hint style="warning" %} The token is shown only once at issuance. Save it to a 1Password vault before leaving this page. {% endhint %} Note the **Base URL** for your 1Password environment. You will need it in the next section. | 1Password environment | Base URL | | -------------------------- | ---------------------------------- | | 1Password.com (Business) | `https://events.1password.com` | | 1Password.com (Enterprise) | `https://events.ent.1password.com` | | 1Password.ca | `https://events.1password.ca` | | 1Password.eu | `https://events.1password.eu` | | {% endstep %} | | | {% endstepper %} | | ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **1Password**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **1Password** and click **Credentials**. 5. Under **Credential Name**, enter a descriptive name (e.g., `1Password API`). 6. In the **Base URL** field, enter the URL that corresponds to your 1Password environment. 7. In the **API Token** field, paste the token you issued in 1Password. 8. Click **Add Connector** to save the configuration. ### Verify ingestion After 1Password begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"onepassword_api"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # ADAudit Plus Connect ManageEngine ADAudit Plus to Radiant Security to forward Active Directory audit events for AI triage. ManageEngine ADAudit Plus is an Active Directory auditing and reporting tool that detects insider threats, privilege misuse, and unauthorized changes across AD, Azure AD, file servers, and Windows endpoints. Connecting ADAudit Plus forwards logon activity, account management changes, and policy change events to Radiant Security via Radiant's HTTPS webhook endpoint. Radiant uses these events to enrich alerts during AI triage, giving analysts visibility into the directory-layer context behind a suspicious sign-in or privilege change. ### Prerequisites * [ ] Admin access to ADAudit Plus ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **ADAudit Plus Webhook**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **ADAudit Plus Webhook** and click **Credentials**. 5. In the **Credential Name** field, enter an identifiable name for this credential (e.g., `ADAudit Plus Integration`). 6. Under **Required Credentials**, enter a value in the **Connector tag** field. This can be any string. Radiant uses this value as salt when generating the authentication token for your connector. 7. Click **Add Connector**. 8. Open the newly created connector. Under **Vendor Configuration**, copy and save the `Webhook URL` and `Token` values. You will need both in the next section. {% hint style="warning" %} **Important Note:** Treat the `Token` value as a secret. Anyone with access to this token can post alerts to your connector. Do not expose it in client-side code, version control, or shared logs. {% endhint %} ### Configure ADAudit Plus to forward events via HTTPS ADAudit Plus's Splunk HTTP Event Collector forwarder is compatible with Radiant's webhook endpoint. Configure it with the `Webhook URL` and `Token` you copied from Radiant. 1. In the ADAudit Plus Control Panel, click the **Admin** tab. 2. In the side panel, select **Configuration** > **SIEM Integration**. 3. Select the **Enable forwarding of ADAuditPlus Data** checkbox. 4. Click the **Splunk HTTP** tab and enter the following values: * **Splunk Server**: the `Webhook URL` value copied from Radiant. * **HTTP Event Collector port**: `443` * **SSL Enabled**: `True` * **Authentication Token**: the `Token` value copied from Radiant. * **Folder size threshold**: `5 GB` * Leave **Enable Log forwarding of ADAudit Plus application logs** unselected. * Select **Yes, I agree that it is compliant**. 5. Click **Save**. 6. On the right side, click **Choose Categories to forward**. 7. Select all categories except **AzureAD Logon Reports** and **AzureAD Management Reports**. 8. Click **Save**. ### Verify ingestion After ADAudit Plus begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"ad_audit_webhook"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Cisco Duo Connect Cisco Duo to ingest MFA and authentication activity into Radiant for AI triage. Radiant connects to Cisco Duo through the Duo Admin API to ingest authentication telemetry, including successful and failed multi-factor authentication attempts. Configuration is a one-time setup performed in the Duo Admin Panel and Radiant Security. At the end of this configuration, you provide Radiant Security with the following values: * **API hostname** * **Integration key** * **Secret key** ### Prerequisites * [ ] Owner role in the Cisco Duo Admin Panel ### Generate Admin API credentials in Cisco Duo For vendor instructions, refer to Cisco Duo's [Admin API documentation](https://duo.com/docs/adminapi). {% stepper %} {% step %} #### Open the Admin API application Sign in to the [Duo Admin Panel](https://admin.duosecurity.com/) as an Owner. In the left sidebar, click **Applications**, then click **Protect an Application**. Locate **Admin API** in the list and click **Protect** on that row.
{% endstep %} {% step %} #### Copy the credentials The Admin API configuration page displays the three values Radiant needs. Copy and store each one securely: * **Integration key** * **Secret key** * **API hostname**
{% hint style="warning" %} The Secret key is shown only at this page and cannot be retrieved later. If it is lost, you must reset the integration to generate a new one. {% endhint %} {% endstep %} {% step %} #### Grant the Read log permission and save On the same page, scroll to **Permissions** and select **Grant read log**. Click **Save** at the bottom of the page. {% endstep %} {% endstepper %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Cisco Duo**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco Duo** and click **Credentials**. 5. Under **Credential Name**, enter a descriptive name (e.g., `Duo-Credentials`). 6. Under **Required Credentials**, enter the values you copied from Cisco Duo: * **API hostname**: enter without the `https://` prefix, in the format `api-XXXXXXXX.duosecurity.com`. * **Integration key** * **Secret key** 7. Click **Add Connector** to save the configuration. ### Verify ingestion After Cisco Duo begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cisco_duo"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Google Workspace IAM only Onboard the Google Workspace IAM and Email data connectors. In this guide, you will set up a trusted relationship between Radiant and your Google Workspace account to allow Radiant to retrieve user and group IAM information and email activity. At the end of this configuration, you will provide Radiant Security with the following information: * **Delegate User Email** * **API key (in JSON file format)** ### License Requirements To collect only IAM information, the account will need to have ***one*** of the following Google Workspace plans: * Enterprise * Education Standard * Education Plus * Business Plus To verify your current license plan, visit [`https://admin.google.com/ac/billing/subscriptions`](https://admin.google.com/ac/billing/subscriptions) from an account with admin-level access. ### Prerequisites To complete the steps below, the logged-in user must have the following permissions/roles: * [ ] Role: `Super Administrator` * [ ] Role: `roles/resourcemanager.projectIamAdmin` * [ ] Permission: `resourcemanager.projects.create` ### Create a new project in Google Cloud 1. Access the Google Cloud console. 2. On the **Select organization** drop-down list at the top of the page, click **New** **project** to create a new project. * **Project name**: `{your organization's name}-iam-logs` 3. Ensure other fields are correctly defined. 4. Copy the **Project ID**. 5. Click **Create**. 6. Select the newly created project from the drop-down list at the top of the page. 7. From the left side menu, navigate to **APIs & Services** > **Library** and enter `Admin SDK API` in the search bar. Alternatively, you can use the top search bar to navigate to the Library page. 8. Select **Admin SDK API** and click **Enable.** 9. Return to the Library (**APIs & Services** > **Library)** and search for `Cloud Identity`. 10. Select **Cloud Identity** and click **Enable.** 11. From the left side menu, navigate to **APIs & Services** > **OAuth Consent Screen** 12. Click **Get Started** 13. Define the app with the following fields: * **App name**: `radiant-iam-logs` * **User support email**: `` 14. Click **Create** ### Create a new service account You must provide a dedicated Service account in your Google Cloud to ingest the data. The service account should have the permission(s) required to read the data you want to feed into Radiant Security. 1. While still in the Google Cloud console, navigate to **IAM & Admin** > **Service Accounts.** Alternatively, you can use the top search bar to navigate to the Service Accounts page. 2. Click + **Create service account** and add the following information: * **Service account name**: `radiant-connector` 3. Click **Create and Continue**. 4. Click **Done** to save the user. 5. Click on the newly created service account `radiant-connector` to edit it. 6. Navigate to **Keys** > + **Add key** > **Create new key**. 7. Select **JSON** and then click **Create**. 8. The API key is automatically downloaded. {% hint style="info" %} **Note**: Your new public/private key pair is generated and downloaded to your machine as a new file. This file is the only copy of this key. This file will be uploaded to Radiant Security at the end of the guide. For information about how to store your key securely, see [Managing service account keys](https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys). {% endhint %} ### Grant access to the service account To call APIs in a Google Workspace, the new service account needs to be granted domain-wide delegation of authority in the Google Workspace Admin console by a super administrator account. For more information, see [Delegating domain-wide authority to a service account](https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority). 1. On the **Service** **Accounts** page, click on the newly created service account `radiant-connector` to edit it. 2. On the **Details** tab, expand **Advanced settings** section and copy the `Client ID`. 3. Click **View Google Workspace Admin Console**. 4. From the left side menu, navigate to **Security** > **Access and data control** > **API Controls**. 5. Click **Manage Domain-wide Delegation**. 6. Click **Add new** and paste the `Client ID` you copied from step 2. 7. In the **OAuth Scopes** field, copy and paste the following permissions: ```bash https://www.googleapis.com/auth/admin.directory.domain.readonly, https://www.googleapis.com/auth/admin.directory.group.readonly, https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly, https://www.googleapis.com/auth/admin.directory.user.readonly, ``` 8. The specific permissions for each Google OAuth scope are listed in the following table: | OAuth Scope | Functionality | | --------------------------------------- | ---------------------------- | | admin.directory.domain.readonly | Get users on the domain | | admin.directory.group.readonly | Get user group memberships | | admin.directory.rolemanagement.readonly | Get user roles | | admin.directory.user.readonly | Get user profile information | 9. Click **Authorize**. ### Create a Google Workspace read-only admin role and delegated user {% hint style="warning" %} **Important note:** In order for the Google Workspace APIs to be used by the service account, a delegate Google Workspace account that has all of the privileges needed by the APIs is required. This is an account within the Google Workspace environment, and is not the same as the service account created previously. For more information check out [Delegating domain-wide authority to the service account](https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority). {% endhint %} 1. Log in to the **Google Admin** console. 2. From the left side menu, navigate to **Account > Admin Roles**. 3. Click on **Create new role**. 4. Give the role the name **Radiant Read Only** and select **Continue**. 5. Scroll down to **Admin API privileges** 6. Select the following privileges: * **`Organizational Units -> Read`** * **`Users -> Read`** * **`Groups -> Read`** 7. On the review screen, verify that all permissions are present and click **Create Role**. 8. Once the role's created, it needs to be assigned to a new or existing Google Workspace account. On the **Roles** page for the new role, click **Assign members** to assign this role to a service account that will be used for the Radiant Security Delegate User Email. ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings > Data Connectors** and click **+ Add Connector**. 3. Search for and select the **Google Workspace** option and then click **Data Feeds**. 4. Select **Google IAM**. 5. Add the following values from the previous steps: * **BigQuery Project ID**: `{your organization's name}-iam-logs` * **BigQuery Dataset Name**: `-` * **Delegate User Email**: The service account that has the **Radiant Security Read Only** admin role * **Upload the JSON File** 6. Click **Add Connector** to save the connector configuration. ### Verify ingestion After Google Workspace begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"google_iam"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Keycloak Connect Keycloak to Radiant Security to forward authentication activity for AI triage. Keycloak is an open-source identity and access management (IAM) platform that controls authentication, single sign-on, and authorization for applications and services. Connecting Keycloak forwards authentication activity to Radiant Security through the Radiant Agent over syslog. Radiant uses this activity during AI triage, giving analysts the identity context to separate routine access from suspicious sign-in activity. ### Prerequisites * [ ] A running Keycloak deployment * [ ] Access to the Keycloak configuration file (`keycloak.conf`) * [ ] A deployed [Radiant Agent](https://help.radiantsecurity.ai/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from Keycloak ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Keycloak**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent integration`). 6. Click **Add Connector**. ### Configure log forwarding in Keycloak Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Keycloak data. If you do not know the port, contact your Customer Success representative. Use either method below to forward Keycloak logs to the Radiant Agent. #### **Edit the Keycloak configuration file (recommended)** 1. On the Keycloak server, open the configuration file (`keycloak.conf`). 2. Add the following lines, replacing `` and `` with the IP address and port of the Radiant Agent: {% code overflow="wrap" %} ```bash # Enable the syslog handler. Use log=console,syslog to enable both console and syslog. log=syslog # Set the syslog endpoint (IP and port) log-syslog-endpoint=: # Enable JSON output format log-syslog-output=json # Set the log level for specific categories log-syslog-level=org.keycloak.events:INFO ``` {% endcode %} 3. Restart Keycloak. #### **Start Keycloak with logging options** Alternatively, pass the logging options when you start Keycloak: {% code overflow="wrap" %} ```bash bin/kc.sh start --log="console,syslog" --log-syslog-endpoint=: --log-syslog-output=json --log-syslog-level="org.keycloak.events:INFO" ``` {% endcode %} For more information about the logging options, refer to the [Keycloak documentation](https://www.keycloak.org/server/logging#_centralized_logging_using_syslog). #### Verify ingestion After Keycloak begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"keycloak"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Okta Connect Okta to Radiant Security to forward authentication and admin activity logs for AI triage, and enable identity response actions. - Okta is an identity and access management (IAM) platform that authenticates workforce and customer users across web, mobile, and on-premises applications, defending against credential theft, account takeover, and unauthorized access. Connecting Okta forwards System Log records to Radiant Security via the Okta API, and enables identity response actions through the same connection. Radiant uses Okta authentication and admin telemetry to surface anomalous logins, MFA failures, and privilege changes, giving analysts the identity context needed to triage account-compromise alerts. At the end of this configuration, you provide Radiant Security with the following values: * **Okta domain**, in the form `https://my-org.okta.com` * **API token** ### Prerequisites * [ ] Super Admin access to Okta (service account recommended) {% hint style="info" %} The token is used for both data ingestion and Okta response actions. Response actions require write scopes on users, sessions, and network zones, so generate the token from a Super Admin service account. A [read-only admin](https://help.okta.com/en/prod/Content/Topics/Security/administrators-read-only-admin.htm) is sufficient only if you do not plan to enable response actions. {% endhint %} {% hint style="warning" %} API tokens are valid only while the user who created them remains active. Tokens issued by deactivated users are rejected. Use a service account that will not be deactivated and whose permissions will not change. See [Okta's API token management guidance](https://help.okta.com/oie/en-us/Content/Topics/Security/API.htm) for details. {% endhint %} ### Generate the API token in Okta {% stepper %} {% step %} #### **Open the Okta Admin Console** Sign in to Okta with the admin account you intend to use for the token. In the upper right corner, click **Admin** to open the Admin Console.
{% endstep %} {% step %} #### **Navigate to the API tokens page** In the left sidebar, navigate to **Security > API**. ![](/files/vuUbzRj9OXqmy0M0CQ7W) {% endstep %} {% step %} #### **Create the token** Click **Create Token**. Enter an identifiable name (e.g., `Radiant Security API Token`) and click **Create Token** again. ![](/files/sC7TgxuExTg2Q86iPBIR) {% endstep %} {% step %} #### **Copy the token value** Copy the **Token value** shown in the pop-up and store it securely.
{% hint style="warning" %} The token value is shown only once and cannot be retrieved later. If it is lost, you must generate a new token. {% endhint %} {% endstep %} {% endstepper %} ### Add the credential in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Credentials** and click **+ Add Credential**. 3. Search for and select **Okta**, then click **Configure Credential**. 4. Under **Credential Name**, enter a descriptive name (e.g., `Okta-Credentials`). 5. Under **Required Credentials**, enter the values from Okta: * **Okta domain**, in the form `https://my-org.okta.com` * **API token** 6. Click **Add Credential** to save the configuration. ### Add the data connector in Radiant Security 1. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 2. Search for and select **Okta**, then click **Data Feeds**. 3. Under **Select your data feeds**, select **Okta Alerts & Activity Logs** and click **Credentials**. 4. From the drop-down, select the Okta credential you created. 5. Click **Add Connector** to save the configuration. ### Add the action connector in Radiant Security The Okta action connector lets Radiant execute identity response actions against the same Okta tenant, including user account lockdown, session termination, and IP blocking through Okta Network Zones. For the full list of supported actions and the Okta scopes each one requires, see [Okta actions](https://help.radiantsecurity.ai/radiant-cases/radiant-cases/response-actions#okta-actions). 1. From the navigation menu, select **Settings** > **Action Connectors** and click **+ Add Connector**. 2. Search for and select **Okta**. 3. Confirm that the Okta credential is selected. 4. Click **Add Connector**. ### Verify ingestion After Okta begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"okta_system_logs"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Network Security # Akamai CDN Connect Akamai CDN to Radiant Security to forward edge access logs via Amazon S3 for AI triage. Akamai CDN is a content delivery network that serves and accelerates internet-facing web applications from a globally distributed edge, shielding origin servers from volumetric traffic and DDoS attacks. Connecting Akamai CDN forwards edge access logs to Radiant Security via Amazon S3. Radiant uses these logs to correlate external requests against your web applications with identity, endpoint, and authentication activity during AI triage, giving analysts visibility into the traffic behind a web-facing alert. ### Prerequisites * [ ] Admin access to Akamai Control Center * [ ] DataStream 2 provisioned on your Akamai contract * [ ] An AWS account with permissions to create or modify S3 buckets, SNS topics, and IAM policies * [ ] An S3 bucket where Akamai will store logs (follow [Create an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) to create one) * [ ] An AWS Access Key ID and Secret Access Key with `ListBucket`, `GetObject`, and `PutObject` permissions on the bucket ### Configure Akamai CDN For full vendor instructions, see [Create a stream](https://techdocs.akamai.com/datastream2/docs/create-stream) and [Stream logs to Amazon S3](https://techdocs.akamai.com/datastream2/docs/stream-amazon-s3) in Akamai's documentation. Akamai CDN forwards logs through DataStream 2. Create a stream that delivers your edge access logs to the S3 bucket Radiant reads from. 1. Sign in to Akamai Control Center with an admin account. 2. Open the DataStream application and click **Create stream**. 3. On the **Configuration** tab, enter a stream name and select the group and the delivery properties you want to monitor. 4. In **Data sets**, select the fields to include in your logs. Keep the defaults unless you have a specific need. 5. On the **Destination** tab, select **Amazon S3** and enter: * **Name**: a description for the destination * **Bucket**: your S3 bucket name * **Folder path**: the prefix within the bucket where logs are written (e.g., `akamai/`) * **Bucket region**: `us-west-2` * **Access key ID**: your AWS Access Key ID * **Secret access key**: your AWS Secret Access Key * **Log format**: JSON 6. Click **Validate & Save**. Akamai writes a verification file to the bucket to confirm access. 7. Continue to the **Summary** tab and click **Activate** to start the stream. ### Configure S3 and add the data connector in Radiant Security Now that Akamai is writing logs to your S3 bucket, complete the setup by following the [Configure Amazon S3 to forward logs to Radiant Security](https://help.radiantsecurity.ai/radiant-connectors/ingestion-methods/configure-amazon-s3-to-forward-logs-to-radiant-security) guide. That guide walks through: 1. Configuring the bucket policy and creating an SNS topic. 2. Adding the **Amazon Web Services S3** data connector in Radiant Security. 3. Configuring S3 event notifications so new objects trigger ingestion. When you select the **Amazon Web Services S3** connector in step 2, select the **Akamai CDN** data feed to continue. When the S3 setup is complete, return to this article to verify ingestion. ### Verify ingestion After the S3 setup is complete, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"akamai_cdn"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Aruba ClearPass Connect Aruba ClearPass to Radiant Security to forward authentication, authorization, and accounting logs for AI triage. Aruba ClearPass is a network access control (NAC) platform that authenticates and authorizes users and devices joining wired, wireless, and VPN networks, and enforces policy to contain unmanaged or compromised endpoints. Connecting Aruba ClearPass forwards authentication, authorization, accounting, and session logs to Radiant Security via syslog through the Radiant Agent. Radiant uses ClearPass logs to enrich identity and network-access artifacts during triage, giving analysts visibility into who connected, from what device, and whether the access decision succeeded or failed. ### Prerequisites * [ ] Admin access to Aruba ClearPass * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from Aruba ClearPass ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Aruba ClearPass (syslog)**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Aruba ClearPass Credentials`), or select an existing Radiant Agent credential from the drop-down menu. 6. Click **Add Connector**. ### Add a syslog target on Aruba ClearPass Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Aruba ClearPass data. If you do not know the port, contact your Customer Success representative. 1. Sign in to the Aruba ClearPass console. 2. Navigate to **Administration** > **External Servers** > **Syslog Targets**.
3. Click **Add**. 4. Enter the following parameters: * **Host Address**: the IP address or hostname of the Radiant Agent. * **Description**: `Radiant Security Agent`. * **Protocol**: `TCP`. * **Server Port**: the port configured on the Radiant Agent to receive Aruba ClearPass data. 5. Click **Save**. ### Configure log forwarding on Aruba ClearPass Each **Syslog Export Filter** supports one **Export Template** and one **Predefined Field Group**, so you create one filter per row in the table below. Use a consistent naming pattern (e.g., `Radiant Security - `). 1. In the Aruba ClearPass console, navigate to **Administration** > **External Servers** > **Syslog Export Filters**. 2. Click **Add**. 3. Enter the following parameters: * **Name**: a descriptive name following the pattern above (e.g., `Radiant Security Session Logs - Logged in users`). * **Description**: `Radiant Security Syslog Forwarder`. * **Export Template**: the Export Template for this filter (e.g., `Session Logs`). * **Export Event Format Type**: `CEF`. * **ClearPass Servers**: leave blank.
4. Click the **Filter and Columns** tab and configure the following: * **Data Filter**: `[All Requests]`. * **Columns Selection**: select the Predefined Field Group that pairs with the Export Template you chose, from the table below. 5. Click **Save**. 6. Repeat steps 2–3 for each **Export Template** and **Predefined Field Group** pair in the table. #### Export Templates and Predefined Field Groups
Export TemplatePredefined Field Group
Session LogsFailed Authentications
Session LogsGuest Access
Session LogsLogged in users
Session LogsRADIUS Accounting
Session LogsTACACS+ Accounting
Insight LogsEndpoints
Insight LogsClearPass Guest
Insight LogsOnboard Enrollment
Insight LogsRADIUS Authentications
Insight LogsRADIUS Failed Authentications
Insight LogsTACACS Authentication
Insight LogsTACACS Failed Authentication
Insight LogsWEBAUTH Failed Authentications
Insight LogsWEBAUTH
Insight LogsApplication Authentication
Insight LogsPosture Antivirus Summary
Insight LogsPosture Antispyware Summary
Insight LogsPosture DiskEncryption Summary
Insight LogsPosture Summary
7. Each **Syslog Export Filter** can only support one export template and one predefined group. The final result should look like this:
### Verify ingestion After Aruba Clearpass begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"aruba_clearpass"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Check Point Firewall Connect Check Point Firewall to Radiant Security to forward security log events for AI triage. Check Point Firewall is a next-generation firewall that inspects network traffic and blocks malicious activity, intrusion attempts, and policy violations. Connecting Check Point Firewall forwards Security Logs to Radiant Security over syslog. Radiant uses these events for AI triage, giving analysts context on network-level threats during alert investigations. Check Point Firewall can forward logs to Radiant Security in two ways: * **Through the Radiant Agent (recommended).** Forward to a Radiant Agent deployed in your environment. * **Direct to Radiant Security.** Forward over TLS to the Radiant syslog cluster. Use only when a Radiant Agent is not available. ### Prerequisites * [ ] Admin access to Check Point Firewall * [ ] Check Point R80.10 or later for the built-in Log Exporter * [ ] For the Radiant Agent path: a deployed [Radiant Agent](https://help.radiantsecurity.ai/radiant-connectors/data-connectors/install-the-radiant-security-agent) reachable from the Check Point gateway or management server * [ ] For the direct path: network egress from the Check Point gateway or management server to `cluster.syslog.radiantsecurity.ai` on TCP port `6514` {% hint style="info" %} If you are running a Check Point version earlier than R80.10, the built-in Log Exporter is not available. Forward logs via [OPSEC LEA](https://community.checkpoint.com/t5/SMB-Gateways-Spark/How-to-send-log-from-Checkpoint-moreover-Opsec-LEA/td-p/29508) instead. {% endhint %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Check Point Firewall**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent Integration`). To reuse an existing Radiant Agent credential, select it from the drop-down menu. 6. Click **Add Connector**. ### Enable extended logging in Check Point Before configuring syslog forwarding, confirm your security policies and rules are configured to generate logs. For each rule, enable the **Track** option and set it to **Log**. Where applicable, enable **Extended Log**. For details, see the [Check Point Tracking Options documentation](https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_LoggingAndMonitoring_AdminGuide/Topics-LMG/Tracking-Options.htm). ### Configure Check Point to forward syslog through the Radiant Agent Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Check Point Firewall data. If you do not know the port, contact your Customer Success representative. The procedure depends on whether your Check Point gateways are centrally managed by SmartConsole or individually managed through each gateway's WebUI. {% tabs %} {% tab title="Centrally managed gateways" %} 1. Connect to **SmartConsole** with Administrator credentials. 2. Go to **Logs & Monitor** and select **Log Exporter** under the **Gateways** tab. 3. Click **+ Add Exporter** to create a new log exporter. 4. Enter the following parameters: * **Name**: `RadiantSecurityForwarder` * **Target Server**: * **IPv4 Address**: the IP address of the Radiant Agent. * **Protocol**: `TCP` * **Port**: the port configured on the Radiant Agent to receive Check Point Firewall data. * **Format**: `JSON` * Select **Show Obfuscated Fields** if present. * Under **Select Logs to Forward**, select only **Security Logs**. 5. Click **OK** to save the configuration. 6. Navigate to **Gateways & Servers** in SmartConsole. 7. Select the gateway or cluster to configure, then click **Edit**. 8. Go to **Logs** > **Log Export Settings**. 9. Under **Log Exporter**, select the log exporter created above (e.g., `RadiantSecurityForwarder`). 10. Click **OK** to save changes. 11. Click **Publish** to confirm the changes. 12. Navigate to **Security Policies** and click **Install Policy** to apply the configuration to the selected gateways. {% endtab %} {% tab title="Individual gateways" %} 1. Access the gateway's WebUI with Administrator credentials. 2. Navigate to **Logs & Monitoring** or **System Logs**. The label varies by firmware version. 3. Locate the **Log Exporter** or **Syslog** configuration section. 4. Click **Add Syslog Server**. 5. Enter the following parameters: * **Name**: `RadiantSecurityForwarder` * **IPv4 Address**: the IP address of the Radiant Agent. * **Protocol**: `TCP` * **Port**: the port configured on the Radiant Agent to receive Check Point Firewall data. * **Format**: `JSON` * Select **Show Obfuscated Fields** if present. * Under **Select Logs to Forward**, select only **Security Logs**. 6. Click **OK** to save the configuration. {% endtab %} {% endtabs %} ### Configure Check Point to forward syslog directly to Radiant Security Use this path only when a Radiant Agent is not available. The procedure depends on whether your Check Point gateways are centrally managed by SmartConsole or individually managed through each gateway's WebUI. {% tabs %} {% tab title="Centrally managed gateways" %} 1. Connect to **SmartConsole** with Administrator credentials. 2. Go to **Logs & Monitor** and select **Log Exporter** under the **Gateways** tab. 3. Click **+ Add Exporter** to create a new log exporter. 4. Enter the following parameters: * **Name**: `RadiantSecurityForwarder` * **Target Server**: * **IPv4 Address**: `cluster.syslog.radiantsecurity.ai` * **Protocol**: `TCP` * **Port**: `6514` * **Format**: `JSON` * Select **Show Obfuscated Fields** if present. * Under **Select Logs to Forward**, select only **Security Logs**. 5. Click **OK** to save the configuration. 6. Navigate to **Gateways & Servers** in SmartConsole. 7. Select the gateway or cluster to configure, then click **Edit**. 8. Go to **Logs** > **Log Export Settings**. 9. Under **Log Exporter**, select the log exporter created above (e.g., `RadiantSecurityForwarder`). 10. Click **OK** to save changes. 11. Click **Publish** to confirm the changes. 12. Navigate to **Security Policies** and click **Install Policy** to apply the configuration to the selected gateways. {% endtab %} {% tab title="Individual gateways" %} 1. Access the gateway's WebUI with Administrator credentials. 2. Navigate to **Logs & Monitoring** or **System Logs**. The label varies by firmware version. 3. Locate the **Log Exporter** or **Syslog** configuration section. 4. Click **Add Syslog Server**. 5. Enter the following parameters: * **Name**: `RadiantSecurityForwarder` * **IPv4 Address**: `cluster.syslog.radiantsecurity.ai` * **Protocol**: `TCP` * **Port**: `6514` * **Format**: `JSON` * Select **Show Obfuscated Fields** if present. * Under **Select Logs to Forward**, select only **Security Logs**. 6. Click **OK** to save the configuration. {% endtab %} {% endtabs %} ### Verify ingestion After Check Point Networks Firewall begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"checkpoint_firewall"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Cisco # Cisco ASA Connect Cisco ASA to Radiant Security to forward firewall and IPS syslog alerts for AI triage. Cisco ASA (Adaptive Security Appliance) is a stateful firewall and IPS platform that inspects perimeter and internal traffic to block threats such as exploit attempts, malicious connections, and protocol abuse. Connecting Cisco ASA forwards firewall and IPS syslog alerts to Radiant Security through the Radiant Agent. Radiant triages the syslog alerts and uses the surrounding connection data to determine whether observed traffic reflects a real compromise or benign network activity. ### Prerequisites * [ ] An ASDM and CLI user with Admin privileges (privilege 15) * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from the Cisco ASA * [ ] An [additional Cisco license](https://community.cisco.com/t5/security-knowledge-base/asa-versions-image-names-and-licensing/ta-p/3126264#toc-hId--1214164938) if you intend to activate the IPS module. No additional license is required to forward syslog alerts ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco ASA**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent integration`). To reuse an existing Radiant Agent, select it from the drop-down menu. 6. In the **Connector tag** field, enter a random value. This value acts as the salt to randomize the **Token** you download in the next step. 7. Click **Add Connector**. 8. Copy the **Token** value or download the **Token** file, then download the **SSL certificate**. You will need both when configuring Cisco ASA. 9. Click **Done** to save your changes. ### Install the Radiant SSL certificate on Cisco ASA Use either the ASDM GUI or the ASA CLI to import the certificate you downloaded from Radiant. {% tabs %} {% tab title="ASDM" %} 1. Log in to Cisco ASDM. 2. Navigate to **Configuration** > **Device Management** > **Certificate Management** > **CA Certificates**. 3. Click **Add**. 4. On the **Install Certificate** pane: * In **Trustpoint Name**, enter `Radiant-Security-Syslog`. * Select **Install from a file** to import the `.pem` file, or select **Paste certificate in PEM format** to paste the encoded certificate into the text box. 5. Click **Install Certificate**. 6. Click **OK**.
{% endtab %} {% tab title="CLI" %} 1. Log in to the Cisco ASA CLI. 2. Enter `enable` to access privileged mode. 3. Enter `conf t` to access configuration mode. 4. Create a new trustpoint: `crypto ca trustpoint radiant-security-syslog` 5. Enter `exit` to leave trustpoint configuration. 6. Copy the base64-encoded certificate provided by Radiant Security. 7. Import the CA certificate: `crypto ca authenticate radiant-security-syslog` 8. Paste the encoded certificate into the terminal. 9. On the line after the certificate text, press **Enter**, then type `quit`. 10. Enter `yes` to accept the certificate.
11. Enter `exit` to leave configuration mode. 12. Enter `write mem` to save the configuration. {% endtab %} {% endtabs %} ### Forward syslog from Cisco ASA {% hint style="info" %} Before forwarding syslog, confirm that the relevant Cisco ASA security features are enabled and configured so the firewall produces useful security data. See the Cisco documentation for [Threat Detection (ASDM)](https://www.cisco.com/c/en/us/td/docs/security/asa/asa912/asdm712/firewall/asdm-712-firewall-config/conns-threat.html), [Threat Detection (CLI)](https://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/firewall/asa-96-firewall-config/conns-threat.html), [IPS quick start](https://www.cisco.com/c/en/us/td/docs/security/asa/quick_start/ips/ips_qsg.html), and [IPS CLI configuration](https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/modules_ips.html#42923). {% endhint %} 1. Log in to the Cisco ASA CLI. 2. Enter `enable` to access privileged mode. 3. Enter `conf t` to access configuration mode. 4. Enable logging: `logging enable` 5. Enable the timestamp field: `logging timestamp rfc5424` 6. Configure the firewall to include the Token from Radiant. Substitute `` with the token you generated when adding the data feed: `logging device-id string ` 7. Enable the username field: `no logging hide username` 8. Keep the device receiving connections if the syslog connection drops: `logging permit-hostdown` 9. Use IP addresses instead of object names: `no names` 10. Set the logging level to informational: `logging trap informational` 11. Set up syslog forwarding: `logging host {external_interface} cluster.syslog.radiantsecurity.ai TCP/6514 secure` 12. Enter `exit` to leave configuration mode. 13. Enter `write mem` to save the configuration. ### Verify ingestion After Cisco ASA begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cisco_asa"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Cisco FTD Connect Cisco FTD to Radiant Security to forward firewall and intrusion event syslog for AI triage. Cisco FTD forwards syslog to Radiant Security through the Radiant Agent. This guide covers adding the Cisco FTD data feed in Radiant, deploying the Radiant Agent as the syslog receiver, and configuring syslog forwarding from the Cisco FDM UI. ### Prerequisites * [ ] Config user role in Cisco FDM * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from the Cisco FTD device ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco FTD (syslog)**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent integration`). To reuse an existing Radiant Agent credential, select it from the drop-down menu. 6. Click **Add Connector**. ### Configure Cisco FTD to forward syslog Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Cisco FTD data. If you do not know the port, contact your Customer Success representative. 1. Log in to the Cisco FDM UI with a **config** user. 2. From the top navigation bar, select the Cisco FTD device. 3. Under **System Settings**, select **Logging Settings**. 4. Enable **Data Logging**. 5. Under **Message Filtering for Firepower Threat Defense**, set **Severity level for filtering all events** to **Information**.
6. Under **Syslog Servers**, click the **+** button to add a new syslog server. 7. Click **Create new Syslog Server**. 8. Enter the IP address of the Radiant Agent. 9. For **Protocol Type**, select **TCP**. 10. For **Port Number**, enter the port configured on the Radiant Agent to receive Cisco FTD data. 11. Under **Interface for Device Logs**, select an interface with connectivity to the Radiant Agent. 12. Click **OK**, then select the newly created syslog server. 13. Click **SAVE**.
14. Click the deploy button to deploy the changes.\ ![Untitled(3)](https://20705827.fs1.hubspotusercontent-na1.net/hubfs/20705827/Knowledge%20Base%20Articles/Cisco%20FTD%20\(syslog\)/Untitled\(3\).png) ### Verify ingestion After Cisco FTD begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cisco_firepower"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Cisco ISE Configure the Cisco ISE connector in Radiant Security to forward Cisco Identity Services Engine authentication and audit logs for AI triage. Radiant ingests Cisco Identity Services Engine (ISE) authentication, authorization, and accounting logs through a Radiant Security Agent acting as a syslog receiver. This guide covers adding the Cisco ISE data feed in Radiant and configuring Cisco ISE to forward logs to the agent. ### Prerequisites * [ ] Admin access to Cisco ISE * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from Cisco ISE ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors** and click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco Identity Services Engine** and click **Credentials**. 5. Under **Credential Name**, enter a descriptive name (e.g., `Radiant Agent Integration`), or select an existing Radiant Agent credential from the drop-down menu. 6. Click **Add Connector**, then click **Done**. ### Configure logging in Cisco ISE Set up a remote logging target that points to the Radiant Security Agent, then map it to the ISE log categories you want forwarded. #### Configure a remote logging target {% stepper %} {% step %} #### **Open the Remote Logging Targets page** In the Cisco ISE GUI, click the **Menu** icon and choose **Administration** > **System** > **Logging** > **Remote Logging Targets**, then click **Add**. {% endstep %} {% step %} #### **Configure the target** Enter the following values: * **Name**: a descriptive name for the target (e.g., `Radiant_Security_Syslog`). * **Target Type**: **TCP Syslog**. * **Status**: **Enabled**. * **Description**: (optional) a brief description of the target. * **Host/IP Address**: the IP address or hostname of the Radiant Security Agent. * **Port**: the TCP port configured on the Radiant Security Agent to receive Cisco ISE traffic. Ensure the port is not blocked by firewalls between Cisco ISE and the agent. If you do not know the port, contact your Customer Success representative. * **Facility Code**: **Local6**. * **Maximum Length**: `8192`. * **Include Alarms For this Target**: **Yes**. * **Comply to RFC 3164**: **Yes**. {% hint style="info" %} If you use a Fully Qualified Domain Name (FQDN) for **Host/IP Address**, enable DNS caching on all Policy Service Nodes (PSNs) in the deployment to avoid performance degradation. Without DNS caching, Cisco ISE queries the DNS server for every syslog packet. Use the `service cache enable hosts ttl 180` CLI command on each PSN. {% endhint %} {% endstep %} {% step %} #### **Save the target** Click **Save**. When Cisco ISE prompts `You have chosen to create an unsecure (TCP/UDP) connection to the server. Are you sure you want to proceed?`, click **Yes** to confirm. {% endstep %} {% endstepper %} #### Map the logging target to categories {% stepper %} {% step %} #### **Open Logging Categories** In the Cisco ISE GUI, click the **Menu** icon and choose **Administration** > **System** > **Logging** > **Logging Categories**. {% endstep %} {% step %} #### **Select the parent categories** Under **Log Categories**, select each of the following: * `AAA Audit` * `AAA Diagnostics` * `Accounting` * `Administrative and Operational Audit` * `Posture and Client Provisioning Audit` * `Profiler` * `External MDM` * `Passive ID` {% endstep %} {% step %} #### **Set severity and local logging** For each category: * Set **Log Severity Level** to `INFO`. Some severity levels cannot be changed; leave those as they are. * (Optional) Disable **Local Logging** if you do not want logs stored on the PSN that generated them. {% endstep %} {% step %} #### **Assign the remote logging target** Under **Targets**, use the arrow icons to move your remote logging target (e.g., `Radiant_Security_Syslog`) from **Available** to **Selected**. Click **Save** to apply the changes. Repeat for each category in the list. {% endstep %} {% endstepper %} For Cisco's reference documentation, see [Configure External Syslog Server on ISE](https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/222223-configure-external-syslog-server-on-ise.html). ### Verify ingestion After Cisco ISE begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cisco_ise"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Cisco Meraki Configure the Cisco Meraki connector in Radiant Security to forward Meraki syslog traffic for AI triage. Cisco Meraki forwards syslog to Radiant Security through the Radiant Agent. This guide covers adding the Cisco Meraki data feed in Radiant and configuring the Meraki dashboard to forward syslog to the agent. ### Prerequisites * [ ] Admin access to Cisco Meraki * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from the Cisco Meraki appliance ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Cisco Meraki**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent Integration`). To reuse an existing Radiant Agent credential, select it from the drop-down menu. 6. Click **Add Connector**. ### Configure Cisco Meraki to forward syslog Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Cisco Meraki data. If you do not know the port, contact your Customer Success representative. 1. Sign in to the [Cisco Meraki dashboard](https://dashboard.meraki.com/). 2. Navigate to **Network-wide** > **Configure** > **General**. 3. Under **Reporting**, click **Add a syslog server**. 4. Enter the **Server IP** and **Port** of the Radiant Agent.
5. Under **Roles**, select **URL**, **Flows**, and **Security events**. 6. Navigate to **Security & SD-WAN** > **Configure** > **Firewall**. 7. Under **Logging**, set the drop-down to **Enabled** for each firewall rule whose traffic you want forwarded.
### Verify ingestion After Cisco Meraki begins forwarding, confirm alerts and events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cisco_meraki"`. 3. Confirm recent alerts and events appear. {% hint style="info" %} Allow several minutes for alerts and events to be parsed, indexed, and available for search. {% endhint %} # Cloudflare WAF Connect Cloudflare WAF to Radiant Security to forward HTTP request logs and firewall events for AI triage. Cloudflare WAF is a cloud-delivered web application firewall that protects internet-facing applications from threats such as SQL injection, cross-site scripting, credential stuffing, malicious bots, and DDoS attacks by inspecting and filtering traffic at the network edge. Connecting Cloudflare WAF forwards HTTP request logs and firewall events to Radiant Security via Amazon S3. Radiant uses these logs to correlate external attack attempts against your web applications with downstream identity, endpoint, and authentication signals during AI triage, giving analysts the full attack chain behind every alert. ### Prerequisites * [ ] Super Administrator access (or Log Share permissions) to Cloudflare * [ ] An AWS account with permissions to create and modify S3 buckets, SNS topics, and IAM policies * [ ] An S3 bucket where Cloudflare will store logs (follow this AWS guide to create one: [Creating a general purpose bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)) {% hint style="warning" %} Cloudflare Logpush requires a Bucket Policy to allow Cloudflare to write to your bucket. (You generally do not need an Access Key/Secret Key for Cloudflare Logpush if using the recommended Bucket Policy method.) {% endhint %} ### Configure Cloudflare WAF Ensure that you have your S3 bucket information at hand. You must configure a Bucket Policy on your S3 bucket to allow Cloudflare to write logs to it. Please refer to Cloudflare's documentation on [Enable Amazon S3](https://developers.cloudflare.com/logs/logpush/logpush-job/enable-destinations/aws-s3/) for the required JSON policy. ### Configure Logpush integration 1. In the Cloudflare dashboard, go to the **Logpush** page at the account or domain level you want to monitor (also known as zone). * For account: [Go to Logpush](https://dash.cloudflare.com/?to=/:account/logs) * For domain (also known as zone): [Go to Logpush](https://dash.cloudflare.com/?to=/:account/:zone/analytics/logs) 2. Depending on your choice, you have access to [account-scoped datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/account/) and [zone-scoped datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/zone/), respectively. 3. Select **Create a Logpush job**. 4. In **Select a destination**, choose **Amazon S3**. 5. Enter or select the following destination information: * **Bucket:** S3 bucket name * **Path:** Bucket location within the storage container * **Organize logs into daily subfolders** (recommended) * **Bucket region** * If your policy requires [AWS SSE-S3 AES256 Server Side Encryption ↗](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html). * To **Grant Cloudflare access to upload files to your bucket**, you must apply a bucket policy ↗ (if you did not add it already): * Copy the JSON policy displayed on [this page](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-policies-s3.html#iam-policy-ex0), then go to your bucket in the Amazon S3 console and paste the policy in **Permissions** > **Bucket Policy**. * Click **Save**. When you are done entering the destination details, select **Continue**. 6. To prove ownership, Cloudflare will send a file to your designated destination. To find the token, select the **Open** button in the **Overview** tab of the ownership challenge file, then paste it into the Cloudflare dashboard to verify your access to the bucket. Enter the **Ownership Token** and select **Continue**. 7. Select the dataset to push to the storage service, `http_requests` or `firewall_events` . Since each Logpush job only pushes one dataset, setup a second Logpush job if you want both datasets. 8. In the next step, you need to configure your Logpush job: * Enter the **Job name**. * Under **If logs match**, you can select the events to include and/or remove from your logs. Refer to [Filters](https://developers.cloudflare.com/logs/logpush/logpush-job/filters/) for more information. Not all datasets have this option available. * In **Send the following fields**, you can choose to either push all logs to your storage destination or selectively choose which logs you want to push. 9. **Advanced Options** should be kept as default. * Warning: The **CVE-2021-44228 redaction option** in Cloudflare's Advanced Options replaces `${` with `x{`. Default is OFF, but if it is ON, Radiant cannot detect Log4Shell-style attacks because the pattern has been mangled at the source. 10. Select **Submit** once you are done configuring your Logpush job. ### Create and get access to an S3 bucket Cloudflare uses Amazon Identity and Access Management (IAM) to gain access to your S3 bucket. The Cloudflare IAM user needs the `PutObject` permission for the bucket. Logs are written into that bucket as gzipped objects using the S3 Access Control List (ACL) `Bucket-owner-full-control` permission. {% hint style="info" %} **Note:** For example, if you want to store logs in the bucket `burritobot` in the `logs` directory, the S3 URL would be `s3://burritobot/logs` {% endhint %} Ensure **Log Share** permissions are enabled, before attempting to read or configure a Logpush job. For more information refer to the [Roles](https://developers.cloudflare.com/logs/logpush/permissions/#roles) section. To enable Logpush to Amazon S3: 1. Create an S3 bucket. Refer to Amazon's "Create an S3 bucket" documentation. 2. Edit and paste the policy below into **S3** > **Bucket** > **Permissions** > **Bucket Policy.** {% hint style="info" %} **Note:** Replace the `Resource` value with your own bucket path. The `AWS Principal` is owned by Cloudflare and should *not* be changed. {% endhint %} ```json { "Id": "", "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1506627150918", "Action": ["s3:PutObject"], "Effect": "Allow", "Resource": "arn:aws:s3::://*", "Principal": { "AWS": ["arn:aws:iam::391854517948:user/cloudflare-logpush"] } } ] } ``` {% hint style="info" %} **Note:** Logpush uses multipart upload for S3. Aborted uploads will result in incomplete files remaining in your bucket. To minimize your storage costs, Amazon recommends configuring a lifecycle rule using the `AbortIncompleteMultipartUpload` action. Refer to [Uploading and copying objects using multipart upload ↗](https://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config). {% endhint %} ### Configure S3 bucket for Radiant Security Now that Cloudflare is configured to send logs to your S3 bucket, you need to configure the bucket to allow Radiant Security to collect the logs. Follow the [Configure Amazon S3 to forward logs to Radiant Security](https://help.radiantsecurity.ai/~/revisions/922Q246ivW25E7jQi4sE/radiant-connectors/data-connectors/configure-amazon-s3-to-forward-logs-to-radiant-security) guide to: 1. Configure a bucket policy to allow Radiant Security read access. 2. Create and configure an SNS topic for event notifications. 3. Set up S3 event notifications for the folder prefix(es) you configured in Cloudflare. 4. Create the Amazon S3 Connector on Radiant Security. ### Verify ingestion After Cloudflare WAF begins forwarding, confirm events are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"cloudflare_waf"`. 3. Confirm recent events appear. {% hint style="info" %} Allow several minutes for events to be parsed, indexed, and available for search. {% endhint %} # Darktrace NDR Connect Darktrace NDR to Radiant Security to forward AI Analyst and Model Breach alerts for AI triage. Darktrace NDR is a network detection and response platform that uses self-learning AI to identify anomalous behavior, lateral movement, and emerging threats across on-premises, cloud, and hybrid networks. Connecting Darktrace NDR forwards AI Analyst alerts, Model Breach alerts, and system status alerts to Radiant Security via syslog through a Radiant Agent. Radiant uses these alerts during the Enrichment stage to correlate network anomalies with other telemetry. ### Prerequisites * [ ] Admin access to Darktrace * [ ] A deployed [Radiant Agent](/radiant-connectors/ingestion-methods/install-the-radiant-security-agent) reachable from the Darktrace appliance ### Add the data connector in Radiant Security 1. Log in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, click **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Radiant Agent**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Darktrace NDR**, then click **Credentials**. 5. Under **Credential Name**, enter an identifiable name for the Radiant Agent integration (e.g., `Radiant Agent integration`). To reuse an existing Radiant Agent credential, select it from the drop-down menu. 6. Click **Add Connector**. ### Configure Darktrace NDR to forward syslog Before starting, confirm the IP address of the Radiant Agent and the port configured to receive Darktrace NDR data. If you do not know the port, contact your Customer Success representative. 1. Log in to the Darktrace Console. 2. Navigate to the **Admin** panel. 3. Under **System Configuration**, navigate to **Modules** > **Darktrace/Cloud**.
4. Under **Workflow Integrations**, click **Syslog**. 5. Click the **Syslog JSON** tab. 6. Enter the following values: * **Send Alerts**: Enabled * **Server**: the IP address of the Radiant Agent * **Server Port**: the port configured on the Radiant Agent to receive Darktrace NDR data * **Use Application Name**: Enabled * **Application Name**: `darktrace` * **Send AI Analyst Alerts**: Enabled * **AI Analyst Behavior Filter**: Compliance, Critical, Suspicious * **Send Model Breach Alerts**: Enabled * **Model Breach Behavior Filter**: Compliance, Critical, Suspicious * **Send System Status Alerts**: Enabled * **Send Resolved System Status Alerts**: Enabled * **Minimum System Status Priority**: High * **Master**: All 7. At the top of the **Syslog Workflow Integration** window, toggle on the **Enabled** button. 8. Click **Save**. ### Verify ingestion After Darktrace NDR begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"darktrace_ndr"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Dragos Platform Connect Dragos Platform to Radiant Security to forward OT and ICS security alerts for AI triage. Dragos Platform is an operational technology (OT) security platform that monitors industrial control system (ICS) environments for threats, vulnerabilities, and operational risk. Connecting Dragos Platform forwards OT and ICS security alerts to Radiant Security via the Dragos REST API. Radiant uses these alerts to apply AI triage to industrial threats, giving analysts a unified view across OT and IT environments. ### Prerequisites * [ ] Admin or Owner access to Dragos Platform * [ ] Network access from Radiant Security egress IPs to your Dragos Platform Console URL {% hint style="info" %} Radiant Security pulls alerts from Dragos Platform over the public internet. Allowlist the following Radiant Security egress IPs on your Dragos Platform endpoint or any upstream firewall: * `100.21.80.201` * `52.11.97.167` * `35.164.70.154` {% endhint %} ### Create an API key in Dragos Platform 1. Sign in to the Dragos Platform console. 2. Navigate to **Admin** > **Users**. 3. Under **API Keys**, click **Add new API key**. 4. Enter a name for the key (e.g., `RadiantSecurityDataConnector`). 5. Click **Generate Key**. 6. Copy the **ID** and **Secret** values. You will enter these as **Key ID** and **Key Secret** in Radiant Security in the next section. 7. Click **OK**. {% hint style="warning" %} The Secret value is shown only once and cannot be retrieved later. Store it securely before closing the dialog. {% endhint %} ### Add the data connector in Radiant Security 1. Sign in to [Radiant Security](https://app.radiantsecurity.ai/). 2. From the navigation menu, select **Settings** > **Data Connectors**, then click **+ Add Connector**. 3. Search for and select **Dragos Platform**, then click **Data Feeds**. 4. Under **Select your data feeds**, select **Dragos Platform**, then click **Credentials**. 5. Under **Credential Name**, enter a descriptive name (e.g., `Dragos - API`). 6. In the **Base URL** field, enter the URL you use to access the Dragos Platform console (e.g., `https://companyName.platform.dragos.cloud`). 7. In the **Key ID** field, paste the **ID** you copied from Dragos Platform. 8. In the **Key Secret** field, paste the **Secret** you copied from Dragos Platform. 9. Click **Add Connector**. 10. Click **Done** to save your changes. ### Verify ingestion After Dragos Platform begins forwarding, confirm alerts are reaching Radiant. 1. In Radiant, navigate to [Log Management](https://app.radiantsecurity.ai/logs). 2. Filter by `rs_connectorType:"dragos_platform"`. 3. Confirm recent alerts appear. {% hint style="info" %} Allow several minutes for alerts to be parsed, indexed, and available for search. {% endhint %} # Forcepoint --- [Next Page](/llms-full.txt/1)