AI SIEM — Getting Started Guide

Version: 26h2 | Product: AI SIEM | Perfware.cloud

Prerequisites

• Log Processor must be deployed first (provides the shared VPC, subnets, and OpenSearch domain via SSM). AI SIEM runs its own Cognito user pool and ALB — it does not use Log Processor's.
• AWS account with admin access (or IAM permissions per the deploy policy)
• A domain and a Route 53 hosted zone for the editor (strongly recommended). The editor is served over HTTPS via an ALB with Cognito login, which needs a certificate and a stable hostname. setup-domain (Step 2a) issues the ACM certificate and manages the DNS records for you — you do not create the certificate by hand.
• An existing CloudTrail trail delivering to S3. AI SIEM reads from your bucket; it does not create a trail. Confirm with aws cloudtrail describe-trails
• SNS subscription confirmation email access — alerts are not delivered until confirmed

Optional: AI Monitor Integration (advanced tier and above)

AI Monitor is not required. AI SIEM deploys and runs fully without it. When AI Monitor is deployed on the same shared OpenSearch domain (the Log Processor one), AI SIEM reads its metric anomalies from that domain and correlates them — no extra wiring, no producer changes, no EventBridge. Deploying it alongside unlocks:

• Metric-anomaly correlation — infrastructure signals AI SIEM cannot see in logs (CPU spike on an idle instance = cryptomining, EBS write surge = ransomware, RDS connection spike = SQL injection) appear in the threat timeline alongside the CloudTrail/GuardDuty events on the same resource and time window.
• On-demand flow query — an anomalous network-egress spike triggers a scoped Athena query against the always-captured flow logs for that resource and window, surfacing the exfiltration destination detail at query cost, not continuous-processing cost.
• Log Processor pattern correlation — application-layer detections (auth-failure spikes, crash loops, unusual query patterns) reach AI SIEM through AI Monitor and surface as correlated security events, closing the gap that infrastructure-only tools (GuardDuty, CloudTrail) cannot see.

These features are advanced tier and above. Set the AiMonitorStackName stack parameter (same account, alongside LogProcessorStackName) when you launch or update the stack — that is what lets the editor read AI Monitor's subscription catalog. Then in the editor (Configure → Data Sources → AI Monitor Correlation) you choose which subscriptions contribute; selecting one correlates every resource it matches (a wildcard subscription covers all matching instances). If AiMonitorStackName is not set, the correlation panel reports the feature as unavailable and nothing else is affected.

Step 1: Subscribe on AWS Marketplace

1. Navigate to the AI SIEM listing on AWS Marketplace
2. Click Continue to Subscribe
3. Accept terms and wait for subscription activation (~2 minutes)
4. Click Continue to Configuration
5. Select your tier and preferred region, then Continue to Launch

Step 2a: Issue the editor certificate (before launch)

Run cert-only first. It requests and DNS-validates an ACM certificate for your editor domain in your hosted zone — no ALB or stack involved yet — and prints the certificate ARN to use at launch:

scripts\setup-domain.cmd cert-only siem.company.com Z0123456789ABCDEF us-east-1

It reuses an existing issued certificate if one is already present, otherwise it requests one, adds the validation CNAME to Route 53, and waits for validation (2–5 minutes). Note the printed Certificate ARN — that is EditorCertificateArn for the next step, with EditorDomain set to the same hostname. The DNS record that points the domain at the editor is created after deploy, in Step 3a (the ALB does not exist yet).

Step 2: Deploy the CloudFormation Stack

On the fulfillment page, provide these parameters:

Step 3: Confirm SNS Subscription

Check the email address(es) provided in AlertEmail. Click the confirmation link in the AWS SNS email. Threat alerts will not be delivered until confirmed.

Step 3a: Point the domain at the editor (after deploy)

Now that the stack exists, run setup-domain again — this time with the stack name instead of cert-only. It resolves the stack's ALB and creates the Route 53 alias so your domain resolves to the editor:

scripts\setup-domain.cmd AISIEM siem.company.com Z0123456789ABCDEF us-east-1

This is required for the editor to be reachable by name. (The certificate from Step 2a is reused; nothing is re-issued.) The stack must already know this domain — which it does, because you passed EditorDomain at launch — or Cognito login will reject the callback.

Step 4: Create the First User (and Access the Editor)

1. Create the first admin in AI SIEM's own Cognito pool: scripts\users.cmd <stack> create <email> (e.g. scripts\users.cmd AISIEM create admin@company.com). The user receives a temporary password.
2. Role-based access (enterprise): a user in no group defaults to admin, so your first user can sign in immediately. Before adding more users with restricted roles, run scripts\groups.cmd <stack> init once to create the admin / analyst / viewer groups, then scripts\groups.cmd <stack> add-to-group <email> <group> per user.
3. Browse to https://<your-domain>/editor (or the editor URL in the CloudFormation Outputs tab), and log in.
4. The threat dashboard shows connected sources, active threats, and system health.

Step 5: Configure Data Sources

In the editor, go to Configure → Data Sources. Sources arrive by two different mechanisms, which determines what you need to do:

S3-based sources (need a bucket)

CloudTrail and VPC Flow Logs are read from S3. The bucket must send s3:ObjectCreated notifications to the ingestion queue.

CloudTrail

Enter the bucket in Configure → Data Sources and click Save Sources. AI SIEM configures the notification for you when it can. If it reports it could not (usually a cross-account bucket), use the helper:

scripts\wire-log-bucket.cmd <stack> <bucket> <region> <bucket-profile>

# same account
scripts\wire-log-bucket.cmd AISIEM my-cloudtrail-logs

# bucket owned by a log archive account
scripts\wire-log-bucket.cmd AISIEM org-trail-logs us-east-1 logarchive

Merge-safe: existing notifications are preserved. Add --dry-run to preview. For a shared bucket carrying both CloudTrail and Flow Logs, wire each source with its own --prefix so the notifications coexist (e.g. --prefix AWSLogs/111/CloudTrail/).

VPC Flow Logs

The stack already creates the flow-log bucket (with lifecycle, the delivery policy for local and cross-account, the ingestion notification, and the Athena Glue table). You do not create or wire a bucket. The create-flowlogs helper just turns on a flow log for a workload VPC you name, pointing at that stack bucket, with Hive-compatible per-hour partitioning so it is directly queryable by Athena:

scripts\create-flowlogs.cmd AISIEM --vpc vpc-0abc123
scripts\create-flowlogs.cmd AISIEM --vpc-from-stack vpcsample --traffic ALL

A target VPC is required (--vpc or --vpc-from-stack). The tool never targets the shared Log Processor / AI Monitor VPC and refuses to run if the target resolves to it. Re-running is harmless.

One or more VPCs, one bucket: point as many VPCs as you like at the stack bucket — AWS partitions deliveries by aws-account-id= / aws-region= under the key path, so they coexist and Athena can query across all of them.

Cross-account (remote VPCs): run create-flowlogs from the remote account with --bucket <stack-flow-bucket> (the FlowLogsBucket stack output). The stack’s bucket policy already permits delivery from other accounts when it was launched with OrganizationId (any account in the org) or CrossAccountIds (the listed accounts). No per-account bucket-policy edits.

Traffic type: default ALL — S3 delivery is cheap, and capturing everything is what feeds on-demand forensics. The cost of processing flow logs is bounded by the duty-cycle + circuit breaker (see the Cost section), not by discarding data at capture. Use --traffic REJECT only to minimize S3 storage. Two things read the bucket: Athena (on-demand flow queries + the hourly scan-sweep, via the flowlogs_raw table) and the duty-cycled ingestion path (continuous port-scan detection).

EventBridge sources (nothing to configure — in this account)

GuardDuty, Security Hub and AWS Config are delivered by EventBridge rules the stack creates. In the SIEM’s own account there is no bucket and no setup. They only produce data when something happens, so zero events is normal on a quiet account.

These only work if the underlying AWS service is enabled. AI SIEM checks this for you and the panel will say AWS service not enabled rather than leaving you guessing. To verify yourself:

aws guardduty list-detectors
aws securityhub describe-hub
aws configservice describe-config-rules --query "ConfigRules[].ConfigRuleName"

Empty results mean the service is off and those rules will never fire. Enabling GuardDuty is the highest-value one; it begins producing findings on its own within a few hours.

Reading the health indicators

Narrowing a built-in rule (exclusions)

Each built-in rule can carry exclusions so a known-good pattern stops tripping it — for example, excluding your deploy pipeline's office CIDR from Root Account Usage, or a specific service principal from a rule. Under Configure → Detection Rules, each built-in has an Exclusions section: add a condition (field, operator, value) and Save. If any exclusion matches an event, that rule does not fire for it. The fastest way is from the threat itself: open a threat fired by a built-in rule and click “(exclude this)” next to the rule name — it pre-fills an exclusion drawn from that threat (its source IP as a /24, or its principal) for you to review and Save. Exclusions suppress only: they can make a rule fire less, never hide a real anomaly (the behavioral baseline still scores every event on its own), and every change is audited. Available on all tiers.

Custom detection rules (advanced+)

Beyond the built-in rules, you can author your own under Configure → Detection Rules → Custom rules. A custom rule fires when all its conditions match and raises the threat score to at least its severity (it never lowers a higher score), then rides the same timeline, alerts, reports, and audit trail as any built-in detection. Three ways to create one:

• Start from a template — click a ready-made detection (secret read, access-key creation, MFA disabled, snapshot shared, and more) to fill the builder, then tweak. Works on any tier that includes custom rules, no AI required.
• Describe it in plain English — type what you want to detect (for example, “someone reads a secret from a new IP”) and AI drafts the rule for review. Requires the AI (Bedrock) feature. You can also Refine an existing rule the same way, and click More ideas for AI-suggested detections you don't already have.
• Import a Sigma rule — paste a Sigma rule (YAML) and it is translated into a custom rule. Import is a fast start for a rule you already have — a bounded translator, not a full Sigma engine, and it never silently mistranslates (anything it can't map is named for you to add by hand). It handles AND-ed fields with the modifiers equals / in-list / contains / starts-with / ends-with / > / ≥ / < / ≤ / cidr / exists, plus level, log source, and attack.* tags. An OR condition (selA or selB, or 1 of …) is imported as several rules, one per branch (AI SIEM rules already fire independently) — review each before saving. Not translated: regular expressions (excluded by design — use contains/starts-with/ends-with or an in-list), |all/base64 modifiers, and nested/AND-across-selection or negated conditions. For anything beyond that, describe the detection in plain English and let AI draft it.

Whatever the source, the rule opens in the builder for review — nothing is saved until you click Apply, then Save Rules. Custom rules can carry an ATT&CK tactic and technique, so they extend your MITRE coverage. Every save is recorded in the audit trail with a per-rule diff of what was added, changed, or removed.

Context-aware severity (advanced+)

On advanced tiers and above, a matched rule can score higher in riskier context. Two fixed modifiers apply on top of a rule's severity, and both only ever raise a score — never lower one below the rule's stated severity, and never override a higher ML score:

• Root principal — a rule matched by the account root identity is scaled up. This needs no configuration.
• Untrusted source IP — a rule matched from an address outside your trusted networks is scaled up. This one is inert until you declare what "trusted" means: add your office egress, VPN, or bastion addresses under Configure → Detection Rules as severityModifiers.trustedIps (a list of exact IP strings). With no list configured, the IP modifier does nothing, so turning the tier on never silently inflates your scores.

The modifiers deliberately key only on identity and network facts — not on whether the activity is anomalous, which the ML baseline already measures — so a finding is never double-counted. A root action from an unknown IP can reach maximum severity; the same action from a trusted network scores at the rule's base.

Step 5a: Check Everything Is Working

Open FAQ in the editor. Every answer is a live check against the real dependency rather than a configuration readback, so it reflects what your deployment can actually do:

• Entitlement tier — your active Marketplace dimension, and a warning if it does not match the deployed tier
• Bedrock AI backend — performs a real model invocation, which is the only way to detect an unsubmitted Anthropic use case form
• OpenSearch reachability — distinguishes a network problem from an authorization one
• Events reaching OpenSearch — index and document counts
• Alert email delivery — flags subscriptions still awaiting confirmation, which otherwise fail silently
• Enabled data sources — and warnings for sources enabled without a bucket
• Version — stack, tier, release and build, useful to quote in a support request

Multi-Account Monitoring

AI SIEM is deployed once, in one account, and reads security data from any number of other accounts using cross-account IAM roles. Available on advanced tier and above.

There are two steps, run in two different accounts and in this order:

Step A — in each remote account

Creates the trust roles AI SIEM assumes. Run with credentials for the account you want to monitor, passing the account ID of the account where AI SIEM is deployed:

scripts\setup-remote-access.cmd setup <central-account-id>

This creates two roles:

• AISIEM-remote-read — read CloudTrail and VPC Flow Log objects from S3
• AISIEM-remote-respond — remediation actions, enterprise tier only

Step B — in the AI SIEM account

Registers the remote account and the bucket to read from, so ingestion begins:

scripts\add-account.cmd <stack> <remote-account-id> --trail-bucket <bucket>

You can also list the account IDs in the CrossAccountIds stack parameter, or set OrganizationId to authorize an entire AWS Organization. Either may be used, or both.

Multi-region coverage

• CloudTrail — an organization trail delivers all regions to one bucket, so a single bucket covers everything with no extra work
• VPC Flow Logs — regional. Configure flow logs in each region to deliver to one central bucket
• GuardDuty and Security Hub — EventBridge is regional. Use a delegated administrator with auto-enable across regions, and findings aggregate to the admin account

Helper Scripts

Download the helper scripts (aisiem-scripts.zip). Unzip anywhere and run from that folder. Windows .cmd and Linux/macOS .sh versions are provided for most; a few use Python and need boto3 (pip install boto3). Run them with AWS credentials for the account named in the table below.

Data Retention & Compliance

Retention follows the same hot-vs-total split compliance frameworks are written around: a searchable (hot) window in OpenSearch for fast triage, and a longer retained (cold) copy in the S3 datalake, queryable any time via Athena. Threat records live in DynamoDB; the audit trail lives in a tamper-evident (WORM) store. Retention is set by tier — longer history is part of what you get moving up.

Threat, timeline, and audit retention are set per tier and applied automatically; the config bucket keeps prior versions of siem-config.json for the window above (a safety net for rollback) before expiring them. Audit retention can also be raised independently at deploy — see the note below.

Querying Historical Data

Every event is written to an S3 datalake in Parquet, partitioned for efficient Athena queries, regardless of whether it was promoted to OpenSearch. Use this for investigations reaching further back than the OpenSearch retention window:

s3://<stack>-siem-datalake-<account>-<region>/
    cloudtrail/account_id=.../region=.../year=.../month=.../day=.../*.parquet
    flowlogs/account_id=.../region=.../year=.../month=.../day=.../*.parquet
    guardduty/ securityhub/ config-changes/ threats/

A Glue database named <stack>_siem is created with tables over these prefixes. Filter on the partition columns so Athena scans only what it needs:

SELECT * FROM cloudtrail
WHERE account_id = '111111111111'
  AND region = 'us-east-1'
  AND year = '2026' AND month = '08';

Cost Expectations

AI SIEM's own resources are modest and mostly usage-based. With VPC Flow Logs the cost splits into two very different parts, and AI SIEM is built around that distinction:

• Delivery to S3 is cheap — roughly $0.25/GB plus S3 storage, billed by AWS independent of AI SIEM. Even a busy VPC logging ALL traffic at tens of GB/day is a modest, storage-class-manageable line.
• Processing every record is where cost runs away — scoring each flow object in Lambda is what can reach hundreds of dollars in a day and thousands if left unattended. This is the part AI SIEM bounds.

Step 6: Review Threats

As threats are detected, they appear in the Threats panel with:

• Severity score (0–100)
• Unified timeline showing all correlated events
• MITRE ATT&CK mapping (advanced+)
• AI-generated investigation playbook (advanced+)
• One-click remediation options (enterprise)

The detail view opens inline below the list with two tabs. Summary is the at-a-glance triage view — key facts, the description, current assignment, and a quick overview — so you can decide what to do without scrolling. Details holds the full breakdown: evidence, event timeline, correlated identities, audit history, and the response playbook. The rule that fired the threat is shown on the Summary tab and in Evidence as a link: a custom rule opens that rule under Configure → Detection Rules; a built-in rule (shown with a readable name) opens the built-in rules section, and offers an “(exclude this)” action that pre-fills an exclusion for that rule from the threat. A “Back to threat” link returns you where you were. Any role can follow the link to view; editing the rule still requires an admin or analyst.

Tuning a noisy group (advanced+): when a rule fires repeatedly and fills a group with similar threats, expand the group and click ✨ Analyze. AI assesses whether they look like false positives and proposes an exclusion to add to the firing rule (shown alongside the facts the threats share). You then choose two separate actions: Apply rule change opens the rule in the builder with the exclusion added for your review — nothing is saved until you Apply and Save Rules, and the change is audited — and Mark these N as false positive clears the existing pile. The suggestion can only ever narrow a rule, never broaden it, and custom rules are floors-only, so a tuning can't hide a real anomaly the behavioural baseline would still catch. Requires custom rules and the AI (Bedrock) feature.

Assessing a rule (advanced+): in the custom-rule builder, click ✨ Assess to have AI sanity-check the rule you're editing — whether it does what its name says, is too broad, has redundant conditions, or is trying to express something the event fields can't (for example a cross-account comparison, which the data doesn't carry). The critique is grounded in a field-capability contract (each field's type, legal values, and the comparisons that aren't possible) plus deterministic checks, so the structural facts don't rely on the model. It's advisory only: nothing changes, you decide what to edit. Requires custom rules and the AI (Bedrock) feature.

Notes: as you work a threat, add free-text notes in the Audit History section. Notes are append-only and appear in the threat's history (and the audit trail) alongside status changes and remediations, so the investigation reads as a running record.

Download a report: the detail header has a Download button that exports a self-contained HTML incident report — facts, evidence, timeline, correlated identities, the full audit trail, and the playbook — with live links back to the threat and to any custom rule that fired. Hand it to a ticket, an email, or an auditor; the links open the live record for anyone who can sign in.

Filtering & assigning work: the Threats toolbar filters by status, severity, type, and a time window (last 24h, 48h, week, month, 2 months, or older — handy for clearing an older backlog). Select a threat to open its detail, then use the assignment control: an admin can assign to any user or claim it; an analyst can claim it for themselves. Tick Assigned to me to work only your own queue, and (admins) use the Assigned to dropdown to filter by owner or find unassigned threats. Every assignment is recorded in the audit trail (who assigned what to whom, and when).

Updating

• Open AWS Marketplace → Manage Subscriptions → Set up your account → Update
• Stack updates are non-destructive (all data preserved, no downtime)
• Tier changes: update the Tier parameter and run a stack update

Troubleshooting

When contacting support, include the Version line from the FAQ panel — it identifies your stack, tier, release and build.

Teardown (Uninstalling)

Deleting the CloudFormation stack does not detach the data sources that feed it. Bucket notifications and any VPC Flow Logs created for AI SIEM live outside CloudFormation and survive the delete. Left in place, notifications fire at a queue that no longer exists, and flow logs keep writing to S3 while you continue paying for storage.

Run teardown in this order:

1. Sever sources (dry run first):

   python scripts\sever_sources.py <stack>
   python scripts\sever_sources.py <stack> --apply

   Deletes VPC flow logs, removes this stack's bucket notifications (merge-safe: other tools' notifications are preserved), and stops the CloudTrail trail. Each action is confirmed individually. Add --delete-trail to delete rather than stop the trail. Add --delete-buckets to also destroy the log buckets AI SIEM created (irreversible — requires typing each bucket name to confirm).

2. Delete the stack:

   aws cloudformation delete-stack --stack-name <stack>
   aws cloudformation wait stack-delete-complete --stack-name <stack>

3. OpenSearch artifacts: no action needed. The stack’s custom resources remove AI SIEM’s dashboards, index templates, ISM policy, and seed indices from the shared domain automatically on stack delete. (Your event data lives in the S3 datalake, not the domain.)

4. Sweep up any orphans (optional): a CloudFormation delete can occasionally leave resources behind — a bucket that still had content, an ENI mid-detach, a VPC endpoint or security group this stack created in the shared VPC. cleanup.py (in the helper-scripts bundle) finds and removes only what this stack owns and never touches the shared Log Processor / AI Monitor VPC or OpenSearch domain. It is dry-run by default — run it once to see what remains, then again with -confirm (prompt per resource) or -force:

   python scripts\cleanup.py <stack> <region>
   python scripts\cleanup.py <stack> <region> -confirm

   Log/threat buckets are only reported unless you pass -delete-buckets, and the WORM audit bucket is never touched without its own separate opt-in. Run it after the stack delete completes.

VPC Flow Logs: Cost vs Detection

Flow-log processing is the single largest cost variable — not delivery to S3, which is cheap. AI SIEM therefore captures ALL traffic to S3 by default and bounds the processing, rather than logging less. Detection comes from three complementary paths:

When flow processing runs, AI SIEM's ingestion filter drops routine noise before scoring: internal VPC-to-VPC ACCEPT traffic, ACCEPT on safe ports (443, 80, 53) to private destinations, and broken records. Only REJECT flows, large transfers, and ACCEPT to external addresses on unusual ports reach the scoring pipeline — and everything, filtered or not, remains in the S3 datalake for Athena.

AI Monitor correlation (advanced+)

With AiMonitorStackName set (see Step 2), AI Monitor's metric anomalies are correlated into threat timelines automatically — no wiring, no producer change. Under Configure → Data Sources, the AI Monitor Correlation panel lists the subscriptions AI Monitor marks for SIEM correlation (read from its subscription catalog) and lets you choose which contribute to the SIEM. Correlation is opt-in: check each subscription you want correlated — nothing is correlated until you select it. Selecting a subscription correlates all resources it matches. Log Processor pattern detections reach the SIEM the same way: subscribe AI Monitor to a Log Processor pattern metric, and a spike surfaces here as a correlated event. If AiMonitorStackName was not set at launch, the panel reports the feature as unavailable.

On-demand flow query (advanced+)

Flow logs are delivered to S3 continuously (ALL traffic; delivery is cheap), so the detail is always there when an incident happens — there is nothing to turn on. When AI Monitor flags an anomalous network-egress spike on a resource, AI SIEM resolves that resource to its network interfaces and IPs and runs a scoped Athena query against the flow datalake, pruned to that resource and the anomaly's time window. It reads back the top destinations, ports and byte volumes and raises a threat with that evidence, correlated into the timeline like any detection. You pay per-incident query cost (cents), not the cost of scoring all traffic — and no VPC flow-log configuration is changed on your resources.

Support

• Documentation: https://perfware.cloud/aisiem
• Email: support@perfware.cloud
• Security inquiries: security@perfware.cloud