Getting Started¶
Deploy AI SIEM on your existing Log Processor VPC and OpenSearch domain, connect your sources, let the baselines learn, then detect and respond. Deployment is a single CloudFormation stack and typically completes in about 10–15 minutes.
Prerequisites¶
- Log Processor must be deployed first — it 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.
- An 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. The
setup-domainhelper issues the ACM certificate and manages DNS 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. - Access to the SNS subscription confirmation email — alerts are not delivered until confirmed.
Deploy in the same region as Log Processor. AI SIEM resolves the VPC, subnets, and OpenSearch domain from Log Processor via SSM parameters, and Lambda requires its deployment package to be in the deployment region. Deploying to a different region will fail.
AWS infrastructure costs are determined by your subscription configuration, deployment choices, and usage volume. They are billed directly to your AWS account by AWS and are independent of the software fee. Review your AWS Billing and Cost Management console regularly.
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, AI SIEM reads its metric anomalies 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 beside the CloudTrail/GuardDuty events on the same resource and 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 at query 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.
Set the AiMonitorStackName stack parameter (same account, alongside LogProcessorStackName) at launch or update — that lets the editor read AI Monitor's subscription catalog. Then in the editor (Configure → Data Sources → AI Monitor Correlation) choose which subscriptions contribute. If AiMonitorStackName is not set, the correlation panel reports the feature as unavailable and nothing else is affected.
Step 1: Subscribe on AWS Marketplace¶
- Navigate to the AI SIEM listing on AWS Marketplace.
- Click Continue to Subscribe.
- Accept terms and wait for subscription activation (~2 minutes).
- Click Continue to Configuration.
- 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 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:
| Parameter | Description | Example |
|---|---|---|
ConfirmStackName |
Must match your stack name exactly | AISIEM |
LogProcessorStackName |
Name of your deployed Log Processor stack (required — provides the shared VPC, subnets, and OpenSearch domain) | LogProcessor |
AiMonitorStackName |
Name of your deployed AI Monitor stack, same account (optional, advanced+). When set, the editor reads AI Monitor's subscription catalog so you can choose which metric anomalies correlate. Leave empty if AI Monitor is not deployed. | AIMonitor |
Tier |
Pinned to the tier you subscribed to on Marketplace — shown but not selectable. No action needed. | (fixed) |
AlertEmail |
Email for threat notifications | security@company.com |
EditorCertificateArn |
ACM certificate ARN from setup-domain cert-only (Step 2a) |
arn:aws:acm:us-east-1:... |
EditorDomain |
Editor domain (strongly recommended). The hostname you validated in Step 2a. Cognito login uses it as the callback, so set it at launch. | siem.company.com |
EditorMfa |
MFA enforcement for editor login: OFF, OPTIONAL (each user enrolls), or ON (required for all). TOTP authenticator apps. |
OPTIONAL |
CrossAccountIds |
Comma-separated account IDs for cross-account threat detection (advanced+). Use this, OrganizationId, or both. |
111111111111,222222222222 |
OrganizationId |
AWS Organization ID for cross-account access (advanced+). Authorizes the whole org instead of listing accounts. Optional. | o-abc123def4 |
Log sources are configured after deploy, in the editor. The launch form has no bucket fields. Once the stack is up, add CloudTrail and VPC Flow Log sources under Configure → Data Sources (or with the
create-flowlogshelper for Flow Logs). That path both records the bucket and wires its S3 notification. See Step 5.Deployment time: ~10–15 minutes. The stack resolves Log Processor's VPC and OpenSearch parameters via SSM, adds security group ingress, creates the SIEM-specific resources, and initializes the configuration bucket.
Step 3: Confirm the SNS subscription¶
Check the address(es) in AlertEmail and click the confirmation link in the AWS SNS email. Threat alerts are not 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
The stack must already know this domain — which it does, because you passed EditorDomain at launch — or Cognito login will reject the callback. The certificate from Step 2a is reused; nothing is re-issued.
Step 4: Create the first user and access the editor¶
- Create your first user in AI SIEM's own Cognito pool, using your own email — there is no pre-made "admin" account:
scripts\users.cmd <stack> create <your-email>. The user receives a temporary password. - Roles (enterprise tier only): the enterprise tier adds role-based access. Run
scripts\groups.cmd <stack> initonce to create the admin / analyst / viewer groups, then add your user toadmin:scripts\groups.cmd <stack> add-to-group <your-email> admin. A user in no group signs in as read-only viewer. On other tiers there are no roles — any user you create signs in with full editor access. - Browse to
https://<your-domain>/editor(or the editor URL in the CloudFormation Outputs tab) and log in. - 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:
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 under 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.
VPC Flow Logs — the stack already creates the flow-log bucket (lifecycle, delivery policy for local and cross-account, 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. 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. Default traffic type is ALL — S3 delivery is cheap and capturing everything feeds on-demand forensics; use --traffic REJECT only to minimize S3 storage. Flow logs are read by Athena only.
Cross-account buckets need four things, not two.
wire-log-buckethandles the notification and the queue policy. The bucket's owner must also grant<stack>-IngestionRole→s3:GetObjectin the bucket policy, and if SSE-KMS encrypted, the same role →kms:Decryptin the key policy. Without these, notifications arrive but every read fails — the queue drains into the DLQ and nothing is indexed. Alternative: replicate the bucket into one the SIEM account owns and wire that.
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.
For cross-account findings, launch the stack with OrganizationId or CrossAccountIds to open the SIEM's event bus, then in each source account run scripts\wire-events.cmd setup <central-account-id> [region] [--source LIST] to forward findings. --source is a comma list of guardduty,securityhub,config (default: all).
Verify the underlying services are on:
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.
Reading the health indicators¶
| Status | Meaning | Action |
|---|---|---|
| Ingesting | Events received in the last 24 hours | None |
| Enabled but no S3 bucket configured | Source is on but has nowhere to read from | Enter a bucket and save |
| AWS service not enabled | GuardDuty, Security Hub, or Config is off in this account | Enable it in that service's console |
| No events in 24h | Configured correctly but nothing arrived | Normal for EventBridge sources on a quiet account; for S3 sources check the bucket notification |
| Disabled | Switched off in configuration | Enable it if wanted |
Baseline learning: ML behavioral models begin learning immediately and become effective after 7–14 days of baseline data. Static detection rules fire from day one and are tunable under Configure → Detection Rules.
See custom detection rules and context-aware severity for authoring and tuning detections.
Step 5a: Check everything is working¶
Open FAQ in the editor. Every answer is a live check against the real dependency, so it reflects what your deployment can actually do: entitlement tier, Bedrock AI backend (a real model invocation), OpenSearch reachability, events reaching OpenSearch, alert email delivery, enabled data sources, and the version line (stack, tier, release, build).
Only high-scoring events reach OpenSearch. Every event is written to the S3 datalake for Athena queries, but only those scoring above the promotion threshold are indexed into OpenSearch for dashboards. Low OpenSearch counts alongside healthy ingestion counts is expected, not a fault.
Operational oversight (CloudWatch alarms)¶
AI SIEM follows a monitor-the-monitor discipline: the editor dashboards and threat alerts are the primary signal, and a layer of CloudWatch alarms gives independent oversight of the SIEM itself. The alarms are created by the stack, summarized on the CloudWatch dashboard's Alarm Status panel, and notify the same AlertEmail SNS topic. Two kinds:
- Security signal —
<stack>-high-severity-threatsfires when a critical-severity threat is detected, independent of the per-threat email. - Pipeline health — ingestion/threat dead-letter queues, detection-queue backlog, Lambda errors, the remediation scheduler heartbeat going missing, sustained OpenSearch write failures, any WORM audit write failure, and the daily archive pass.
Read failures in the health checks report unknown rather than green, so the oversight layer errs toward surfacing a problem rather than hiding one.
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 (advanced tier and above). Two steps, in order:
Step A — in each remote account creates the trust roles AI SIEM assumes:
scripts\setup-remote-access.cmd setup <central-account-id>
This creates AISIEM-remote-read (read CloudTrail and VPC Flow Log objects from S3) and AISIEM-remote-respond (remediation, enterprise tier only). These role names are fixed and must not be changed.
Step B — in the AI SIEM account registers the remote account and bucket:
scripts\add-account.cmd <stack> <remote-account-id> --trail-bucket <bucket>
You can also list account IDs in CrossAccountIds or set OrganizationId to authorize a whole AWS Organization.
Data retention and compliance¶
Retention follows the 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 via Athena. Retention is set by tier.
| Retained data | Basic | Essential | Advanced | Enterprise |
|---|---|---|---|---|
| Events — searchable (OpenSearch) | 7 d | 90 d | 365 d | 365 d |
| Events — retained (S3 / Athena) | 7 d | 90 d | 365 d | 365 d |
| Threats | 7 d | 90 d | 180 d | 365 d |
| Threat timelines | 7 d | 90 d | 180 d | 365 d |
| Audit trail (default) | 30 d | 90 d | 365 d | 365 d |
| Config bucket — old object versions kept | 7 d | 14 d | 30 d | 30 d |
For HIPAA (6 years) or SOX (7 years) audit-log obligations, raise the AuditRetentionDays stack parameter at deploy (up to 36500 days); choose COMPLIANCE Object-Lock mode if records must be immutable until retention elapses. To keep raw logs longer than your tier's default, raise DatalakeRetentionDays (e.g. 2555 for 7 years) — it extends cold S3/Athena retention without a tier change; the hot OpenSearch window stays tier-governed.
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:
- Delivery to S3 is cheap — roughly $0.25/GB plus S3 storage, billed by AWS independent of AI SIEM.
- Processing every record is where cost runs away — this is the part AI SIEM bounds, by querying flow logs in place with scheduled Athena sweeps rather than scoring every object.
| Flow log volume | Delivery (~$0.25/GB) | Storage @90 days | Storage @1 year | Storage @7 years | @7 years, tiering on* |
|---|---|---|---|---|---|
| 1 GB/day | ~$7.5/mo | ~$2/mo | ~$8/mo | ~$58/mo | ~$12/mo |
| 10 GB/day | ~$75/mo | ~$21/mo | ~$84/mo | ~$580/mo | ~$120/mo |
| 100 GB/day | ~$750/mo | ~$207/mo | ~$840/mo | ~$5,800/mo | ~$1,200/mo |
* Approximate, at steady state, with S3 Intelligent-Tiering (Archive Instant Access) on the cold tail — still Athena-queryable, no restore or retrieval fee. All figures are estimates in us-east-1; verify against current Amazon S3 pricing. Fixed costs are the editor load balancer, any interface VPC endpoints, and the shared OpenSearch domain (usually the largest single line). See the flow-log cost guardrail for how detection cost stays flat.
Step 6: Review threats¶
As threats are detected, they appear in the Threats panel with a severity score (0–100), a unified timeline of correlated events, MITRE ATT&CK mapping (advanced+), an AI-generated investigation playbook (advanced+), and one-click remediation options (enterprise). The detail view opens inline with Summary (at-a-glance triage) and Details (full evidence, timeline, correlated identities, audit history, and playbook) tabs. See response and remediation and analyst queues.
Updating¶
- Open AWS Marketplace → Manage Subscriptions → Set up your account → Update.
- Stack updates are non-destructive — all data is preserved, no downtime.
- Tier changes: update the Tier parameter and run a stack update.
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. Run teardown in this order:
- 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), and stops the CloudTrail trail. Add --delete-trail to delete rather than stop it, and --delete-buckets to destroy the log buckets AI SIEM created (irreversible).
- Delete the stack:
aws cloudformation delete-stack --stack-name <stack>
aws cloudformation wait stack-delete-complete --stack-name <stack>
-
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 delete.
-
Sweep up any orphans (optional):
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. Dry-run by default.
Cross-account roles survive.
AISIEM-remote-readandAISIEM-remote-respondin each remote account remain; remove them withscripts\setup-remote-access.cmd remove <central-account-id>. If you deployed the delegated remediation add-on, tear it down per account withscripts\remediation_docs\deploy-remediation.cmd <stack> --cleanup.
Support¶
- Documentation: https://perfware.cloud/aisiem
- Email: support@perfware.cloud
- Security inquiries: security@perfware.cloud