Initial commit - 611 cybersecurity skills across all subdomains

skills/implementing-zero-standing-privilege-with-cyberark/references/standards.md

@@ -0,0 +1,51 @@
+# Zero Standing Privilege with CyberArk - Standards Reference
+
+## Zero Trust Frameworks
+
+### NIST SP 800-207 - Zero Trust Architecture
+- Never trust, always verify
+- Least privilege access to resources
+- Microsegmentation and policy enforcement points
+- Dynamic, risk-based access policies
+
+### CISA Zero Trust Maturity Model
+- Identity pillar: JIT/JEA access for all identities
+- Advanced maturity: Automated privilege provisioning/deprovisioning
+- Optimal maturity: Continuous verification with ephemeral access
+
+## TEA Framework Components
+
+### Time
+- Session duration: minimum required for task completion
+- CyberArk default: 1 hour, configurable 15 min to 8 hours
+- Business hours enforcement optional
+- Auto-termination on session inactivity
+
+### Entitlements
+- Principle of least privilege
+- Dynamic role creation scoped to specific resources
+- Permission boundaries to prevent escalation
+- Entitlement analytics for right-sizing
+
+### Approvals
+- Risk-based approval routing
+- Multi-level approval for critical access
+- Auto-approval for previously approved, low-risk requests
+- ITSM integration (ServiceNow, Jira) for audit trail
+
+## Compliance Requirements
+
+### SOC 2 - CC6
+- CC6.1: Logical access security restricted
+- CC6.3: Access authorized, modified, removed timely
+- ZSP provides evidence of no standing privileges
+
+### PCI DSS v4.0
+- 7.2.1: Access limited to least privilege
+- 7.2.4: Access reviewed at least every 6 months
+- ZSP eliminates the review burden by removing standing access
+
+### SOX Section 404
+- Separation of duties enforcement
+- Access to financial systems must be controlled
+- JIT access provides clear audit trail of who accessed what, when

skills/implementing-zero-standing-privilege-with-cyberark/references/workflows.md

@@ -0,0 +1,99 @@
+# Zero Standing Privilege with CyberArk - Workflows
+
+## JIT Access Request Workflow
+
+```
+Developer needs to access AWS production environment
+    │
+    ├── Opens CyberArk Secure Cloud Access portal
+    │
+    ├── Selects target: AWS Account "Production" (123456789012)
+    │
+    ├── Selects policy: "Developer Production Read Access"
+    │
+    ├── Specifies duration: 2 hours
+    │
+    ├── Provides justification: "Investigating PROD-1234 latency issue"
+    │
+    ├── Submits request
+    │
+    ├── CyberArk evaluates TEA policy:
+    │   ├── Time: 2 hours within allowed range
+    │   ├── Entitlements: Read-only production access
+    │   └── Approval: Manager approval required
+    │
+    ├── Approval request sent to manager (Slack/email)
+    │
+    ├── Manager approves
+    │
+    ├── CyberArk provisions ephemeral IAM role:
+    │   ├── Creates role with ReadOnlyAccess + resource restrictions
+    │   ├── Sets session duration to 2 hours
+    │   └── Generates temporary STS credentials
+    │
+    ├── Developer accesses AWS console/CLI with temp credentials
+    │   └── All actions recorded in session log
+    │
+    └── After 2 hours: role deleted, credentials revoked
+```
+
+## Standing Privilege Migration Workflow
+
+```
+Phase 1: DISCOVERY AND ANALYSIS
+    ├── Export all IAM users/roles with standing admin access
+    ├── Analyze CloudTrail logs for actual permission usage
+    ├── Identify which permissions are actually used vs. assigned
+    ├── Calculate right-sized policy for each use case
+    └── Map standing privileges to CyberArk ZSP policies
+
+Phase 2: POLICY CREATION
+    ├── Create CyberArk SCA policies for each access pattern
+    ├── Define TEA parameters:
+    │   ├── Maximum session duration per policy
+    │   ├── Entitlement scope (AWS managed policies + custom)
+    │   └── Approval requirements (auto vs. manual)
+    ├── Configure approval workflows
+    └── Test policies with pilot group
+
+Phase 3: PILOT MIGRATION (2-4 weeks)
+    ├── Assign ZSP policies to pilot users
+    ├── Remove standing privileges from pilot users
+    ├── Monitor for access denied errors
+    ├── Adjust policies based on feedback
+    └── Measure: request volume, approval time, session duration
+
+Phase 4: FULL MIGRATION (4-8 weeks)
+    ├── Migrate teams in waves (1 team per week)
+    ├── Remove standing privileges after ZSP confirmed working
+    ├── Configure auto-detect for new standing privilege creation
+    └── Report metrics to security leadership
+
+Phase 5: CONTINUOUS GOVERNANCE
+    ├── Weekly: Review and right-size ZSP policies
+    ├── Monthly: Audit for any standing privilege re-creation
+    ├── Quarterly: Entitlement optimization report
+    └── Alert on: New standing admin roles created outside CyberArk
+```
+
+## Emergency Break-Glass Workflow
+
+```
+CyberArk SCA unavailable or network issue
+    │
+    ├── Retrieve break-glass credentials from:
+    │   ├── Physical safe (sealed envelope)
+    │   ├── Or secondary vault (Azure Key Vault / AWS Secrets Manager)
+    │
+    ├── Authenticate with break-glass credentials
+    │
+    ├── Perform emergency actions
+    │
+    ├── Document all actions taken
+    │
+    └── Post-incident:
+        ├── Rotate break-glass credentials
+        ├── Review session logs for the emergency access
+        ├── File incident report
+        └── Verify no unauthorized changes made
+```