Full Report
How Wiz security uses Service Catalog to turn cloud risk into service ownership
Analysis Summary
# Best Practices: Service-Centric Security Ownership
## Overview
These practices address the "actionability gap" in cloud security. Rather than treating security risks as a disconnected list of infrastructure findings, this model organizes risk around the **Service**. By aligning security ownership with existing engineering operational structures, organizations can automate remediation routing and ensure accountability.
## Key Recommendations
### Immediate Actions
1. **Audit Existing Ownership Data:** Inventory your code repositories (e.g., GitHub CODEOWNERS) to identify how teams currently define "on-call" or "operational" ownership.
2. **Define the "Service" Unit:** Establish a shared definition of a "service" between Security and DevOps to ensure both teams use a consistent frame of reference.
3. **Implement Basic Tagging:** Ensure cloud resources associated with high-risk services have a `ServiceID` or `Owner` tag.
### Short-term Improvements (1-3 months)
1. **Sync Security to Operations:** Build or use a tool (via API) to sync code repository ownership data into your security platform's Service Catalog.
2. **Map Communication Channels:** Create a 1:1 mapping between a Service and a specific Slack/Teams channel for automated alerting.
3. **Differentiate Alerting vs. Ownership:** Refine metadata to distinguish between "who gets paged for uptime" and "who is accountable for security remediation."
### Long-term Strategy (3+ months)
1. **Automate Orchestration:** Implement automated workflows (e.g., Wiz Workflows) that trigger remediation or ticket creation based on service context without manual security intervention.
2. **Establish Governance KPIs:** Measure "Service Health" rather than "Finding Count," holding service owners accountable for the security posture of their specific service.
3. **Escalation Loops:** Build automated reminder and escalation workflows for aging service-level risks.
## Implementation Guidance
### For Small Organizations
- Focus on manual tagging of critical assets.
- Use a single communication channel for all security alerts but use "Service" prefixes in naming conventions to help direct work.
### For Medium Organizations
- Implement automated synchronization between your repository's metadata and your security tool.
- Transition from "Security team fixes it" to "Security team routes it" to the service owner.
### For Large Enterprises
- Use robust API-driven automation to keep Service Catalogs updated across thousands of repositories.
- Develop dedicated Slack/Teams channels for every service to prevent "alert fatigue" in main engineering channels.
## Configuration Examples
* **Service Metadata Schema:**
yaml
Service: "Payment-Processor"
Owner: "FinTech-Team-Alpha"
Alert-Channel: "#alerts-fintech-alpha"
On-Call: "PagerDuty-Schedule-ID"
Security-Tier: "Critical"
* **Workflow Logic:**
`IF [Finding] occurs ON [Resource] THEN [Lookup ServiceID] -> [Notify Alert-Channel] -> [Tag Owner]`
## Compliance Alignment
- **NIST CSF (PR.AA-1):** Alignment of asset management with organizational communication.
- **ISO/IEC 27001:** Information asset ownership and responsibility (Annex A).
- **CIS Controls:** Inventory and Control of Enterprise Assets (Control 01).
## Common Pitfalls to Avoid
- **Inconsistent Tagging:** If tagging isn't mandatory or automated, the service catalog will be incomplete and lose team trust.
- **Ignoring Existing Systems:** Don't build a new ownership database from scratch; reuse what engineers already use for operational on-calls.
- **Noise Concentration:** Sending all security alerts for all services into one channel, leading to "notification blindness."
## Resources
- **Wiz Service Catalog:** [hxxps://www.wiz.io/blog/introducing-wiz-service-catalog]
- **Wiz API Documentation:** For syncing external ownership data.
- **GitHub CODEOWNERS Documentation:** For establishing initial ownership mappings.