Showcase: My dashboard for tracking cloud IAM changes across AWS, Azure, GCP.

Sarah Johnson · 2026-08-07T04:36:22Z

Having observed a critical gap in traditional SIEM solutions regarding cloud-native identity and access management (IAM) visibility, I developed a custom dashboard to track IAM changes across multi-cloud environments. While IBM QRadar provides robust log aggregation and correlation, its out-of-the-box content for cloud IAM often lags behind the rapid, API-driven changes inherent to AWS IAM, Azure AD, and Google Cloud IAM. This dashboard is designed to augment QRadar by providing a real-time, normalized view of high-risk identity events, which can then be forwarded as offenses for deeper investigation. The core architecture involves three primary components: 1. **Cloud-Specific Collectors:** Lightweight Python agents utilizing official SDKs (Boto3, MS Graph API, Google Cloud Client Library) to poll audit logs for specific IAM event types. 2. **Normalization Engine:** A central service that maps heterogeneous cloud events (e.g., AWS's `CreateUser`, Azure's `Add user`, GCP's `google.iam.admin.v1.CreateServiceAccount`) into a common JSON schema. 3. **Dashboard & Alerting Layer:** A Streamlit application for visualization, with a secondary webhook service to create QRadar offenses for critical changes. The normalization schema is pivotal. Here is a simplified example of its structure: ```json { "event_id": "cloud-iam-event-001", "timestamp": "2023-10-27T10:00:00Z", "cloud_provider": "aws", "normalized_action": "USER_CREATED", "target_principal": "arn:aws:iam::123456789012:user/new_admin", "initiating_principal": "arn:aws:iam::123456789012:user/deploy_bot", "source_ip": "192.0.2.1", "raw_event": { ... }, "risk_score": 85 } ``` Key metrics and visualizations tracked by the dashboard include: - **Principal Velocity:** Number of new users, service accounts, or roles created per cloud account over a rolling 24-hour window. - **Permission Escalation Events:** Additions of high-privilege policies (e.g., `AdministratorAccess`, `Owner`) to existing principals. - **Credential Lifecycle:** Key creation, deletion, or inactivity for service accounts and IAM users. - **Cross-Account Trust Modifications:** Changes to STS assume-role policies or resource-based trust relationships. Integration with QRadar is achieved via the HTTP-based QRadar API. When the dashboard's risk score for an event exceeds a configured threshold (e.g., 75), it triggers a POST request to the QRadar console, creating an offense with a meaningful description and the normalized payload attached as a custom event property. This allows analysts to pivot from the QRadar offense directly to the contextual dashboard view. The main pitfalls encountered during development were: - **API Rate Limiting:** Cloud providers enforce strict API call limits, necessitating intelligent batching and backoff logic in the collectors. - **Log Latency:** Cloud audit logs are often delivered with a delay of several minutes, making true real-time monitoring challenging. - **Schema Drift:** Cloud providers frequently update their audit log schemas, requiring continuous maintenance of the normalization mappings. This approach does not replace QRadar's core functions but acts as a specialized, high-fidelity feed. It addresses the specific need for proactive IAM governance in cloud environments, an area where generic log parsing can miss nuanced but critical threats like gradual privilege creep or service account compromise. The code for the collectors and normalization engine is available in a GitHub repository for those interested in implementation details.

Page 2 / 2 Prev

IBM QRadar Reviews

Last Post by Bob Wilson 1 hour ago

16 Posts

16 Users

0 Reactions

2 Views

RSS

Bob Wilson

(@bobw)

Reputable Member

Joined: 3 weeks ago

Posts: 176

07/08/2026 8:42 pm

Polling audit logs with SDKs is a solid starting point, but I'm curious about the latency you're seeing. When we tried that approach, the delay between an API action and its appearance in CloudTrail or Azure Activity Log was the real bottleneck. Have you considered supplementing the collectors with provider-native event systems, like AWS EventBridge for IAM? You can catch some events faster that way, though you're right that coverage isn't always complete.

null

ReplyQuote

Page 2 / 2 Prev