[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HE0PS2RVT4HHH7YC92ESJN":3,"skill-same:01M6HE0PS2RVT4HHH7YC92ESJN":118},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6HE0PS2RVT4HHH7YC92ESJN","deploying-software-defined-perimeter",null,"Deploy a Software-Defined Perimeter using the CSA v2.0 specification with Single Packet Authorization, mutual TLS, and SDP controller\u002Fgateway configuration to enforce zero trust network access.","HenriqueMC17\u002Fagente-core","HenriqueMC17","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206460478?v=4","01M6HB63HBBF18AC4H09XTB549","Henrique Monteiro Cardoso","01M6HB63NGSQXWKWCFWW2B20W0",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"software","deploying software defined perimeter","network-access","with","enforce","trust","specification","access","t1078","tls","cybersecurity","ztna","zero-trust","controller","network","ZeRO","gateway","pr","deploy","architecture","2026-11-10 10:12:30",false,"---\nname: deploying-software-defined-perimeter\ndescription: Deploy a Software-Defined Perimeter using the CSA v2.0 specification with Single Packet Authorization, mutual TLS, and SDP controller\u002Fgateway configuration to enforce zero trust network access.\ndomain: cybersecurity\nsubdomain: zero-trust-architecture\ntags:\n- zero-trust\n- sdp\n- software-defined-perimeter\n- network-access\n- ztna\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.AA-01\n- PR.AA-05\n- PR.IR-01\n- GV.PO-01\nmitre_attack:\n- T1133\n- T1078\n- T1021\n- T1046\n- T1190\ncategory: deploying-software-defined-perimeter\n---\n# Deploying Software-Defined Perimeter\n\n## Prerequisites\n\n- Understanding of zero trust principles (NIST SP 800-207)\n- Knowledge of CSA Software-Defined Perimeter specification\n- Familiarity with PKI and mutual TLS authentication\n- Experience with network security architecture\n\n## Overview\n\nA Software-Defined Perimeter (SDP) implements zero trust by creating a dynamically provisioned, identity-centric perimeter around individual resources. Defined by the Cloud Security Alliance (CSA), SDP makes application infrastructure invisible to unauthorized users through a \"dark cloud\" approach where services are hidden until authenticated and authorized. Unlike traditional VPN, SDP establishes one-to-one encrypted connections between verified users and specific applications.\n\nThis skill covers deploying SDP using the CSA v2.0 specification, implementing Single Packet Authorization (SPA), configuring the SDP controller and gateway, and validating the deployment against NIST SP 800-207 requirements.\n\n\n## When to Use\n\n- When deploying or configuring deploying software defined perimeter capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When building or improving security architecture for this domain\n- When conducting security assessments that require this implementation\n\n## Prerequisites\n\n- Familiarity with zero trust architecture concepts and tools\n- Access to a test or lab environment for safe execution\n- Python 3.8+ with required dependencies installed\n- Appropriate authorization for any testing activities\n\n## Architecture\n\n### SDP Components (CSA Specification)\n\n```\n┌─────────────────────┐\n│ SDP Controller       │\n│ - Authentication     │\n│ - Authorization      │\n│ - Policy management  │\n│ - Key management     │\n└──────────┬──────────┘\n           │\n    ┌──────┴──────┐\n    │             │\n    v             v\n┌────────┐  ┌────────────┐\n│ IH     │  │ AH         │\n│(Client)│  │(Gateway)   │\n│        │  │            │\n│ SPA    │──│ Protected  │\n│ mTLS   │  │ Resources  │\n└────────┘  └────────────┘\n\nIH = Initiating Host (User Device)\nAH = Accepting Host (Application Gateway)\nSPA = Single Packet Authorization\n```\n\n### SDP Deployment Models\n1. **Client-to-Gateway**: User device connects through SDP gateway to backend applications\n2. **Client-to-Server**: Direct connection between user and application server\n3. **Server-to-Server**: Workload-to-workload communication through SDP\n4. **Gateway-to-Gateway**: Site-to-site connectivity replacing traditional VPN tunnels\n\n## Key Concepts\n\n### Single Packet Authorization (SPA)\nSPA is a network security mechanism where the SDP gateway drops all TCP\u002FUDP packets by default. A cryptographically signed single packet must be sent before any connection is established. The gateway validates the SPA packet, and only then opens a temporary port for the authenticated session. This makes the gateway invisible to port scanners.\n\n### Mutual TLS (mTLS)\nAfter SPA validation, both the client and server authenticate each other using X.509 certificates. This bidirectional authentication prevents man-in-the-middle attacks and ensures both endpoints are verified.\n\n### Dynamic Provisioning\nSDP connections are provisioned on-demand based on real-time policy evaluation. No persistent network tunnels exist; each session is individually authorized and encrypted.\n\n## Workflow\n\n### Phase 1: SDP Controller Deployment\n\n1. **Deploy SDP Controller**\n   - Install SDP controller on hardened, redundant infrastructure\n   - Configure PKI integration for certificate issuance\n   - Set up authentication backend (LDAP, SAML, OIDC)\n   - Configure policy database with application definitions\n   - Enable audit logging for all controller decisions\n\n2. **Configure Authentication**\n   - Integrate with enterprise IdP via SAML 2.0 or OIDC\n   - Configure device certificate enrollment (SCEP\u002FEST)\n   - Enable multi-factor authentication requirements\n   - Set up certificate revocation checking (OCSP\u002FCRL)\n\n3. **Define Access Policies**\n   - Map users\u002Fgroups to authorized applications\n   - Define device posture requirements per application\n   - Configure contextual conditions (location, time, risk level)\n   - Set session duration and re-authentication intervals\n\n### Phase 2: SDP Gateway Deployment\n\n4. **Deploy Accepting Hosts (Gateways)**\n   - Install SDP gateway instances in front of protected applications\n   - Configure default-drop firewall rules (deny all inbound)\n   - Enable SPA listener on designated ports\n   - Configure mTLS with controller-issued certificates\n   - Set up health monitoring and failover\n\n5. **Configure Application Definitions**\n   - Register each protected application with the controller\n   - Define backend server IPs, ports, and protocols\n   - Configure load balancing for multi-instance applications\n   - Set up application health checks\n\n### Phase 3: Client Deployment\n\n6. **Deploy Initiating Hosts (Clients)**\n   - Install SDP client software on user endpoints\n   - Enroll device certificates through automated provisioning\n   - Configure SPA key material distribution\n   - Test authentication flow: SPA → mTLS → application access\n\n7. **Validate End-to-End Flow**\n   - Verify SPA packets are accepted by gateway\n   - Confirm mTLS handshake succeeds with valid certificates\n   - Test application access through the SDP tunnel\n   - Verify unauthorized access is blocked (no SPA = invisible gateway)\n\n### Phase 4: Operational Validation\n\n8. **Security Testing**\n   - Port scan the SDP gateway to confirm invisibility (all ports show filtered\u002Fclosed)\n   - Attempt connection without valid SPA (must fail silently)\n   - Test with revoked client certificate (must be denied)\n   - Attempt lateral movement from one authorized app to another unauthorized app\n   - Validate audit trail completeness\n\n9. **Monitoring and Maintenance**\n   - Configure SIEM integration for SDP controller and gateway logs\n   - Set up alerting for failed SPA attempts and certificate errors\n   - Establish certificate rotation schedule\n   - Document incident response procedures for SDP events\n\n## Validation Checklist\n\n- [ ] SDP Controller deployed with HA and audit logging\n- [ ] IdP integration tested with SAML\u002FOIDC and MFA\n- [ ] SDP Gateways deployed with default-drop firewall\n- [ ] SPA mechanism validated (gateway invisible to port scans)\n- [ ] mTLS established between clients and gateways\n- [ ] Access policies enforce least-privilege per user\u002Fapp\n- [ ] Device certificate enrollment automated\n- [ ] Unauthorized access attempts blocked silently\n- [ ] Lateral movement between apps prevented\n- [ ] Logs streaming to SIEM with alerting configured\n- [ ] Certificate rotation and revocation procedures tested\n\n## References\n\n- CSA Software-Defined Perimeter Architecture Guide v3\n- CSA SDP Specification v2.0\n- NIST SP 800-207: Zero Trust Architecture\n- CISA Zero Trust Maturity Model v2.0\n- fwknop: Single Packet Authorization implementation\n","# Deploying Software-Defined Perimeter\n\n## Prerequisites\n\n- Understanding of zero trust principles (NIST SP 800-207)\n- Knowledge of CSA Software-Defined Perimeter specification\n- Familiarity with PKI and mutual TLS authentication\n- Experience with network security architecture\n\n## Overview\n\nA Software-Defined Perimeter (SDP) implements zero trust by creating a dynamically provisioned, identity-centric perimeter around individual resources. Defined by the Cloud Security Alliance (CSA), SDP makes application infrastructure invisible to unauthorized users through a \"dark cloud\" approach where services are hidden until authenticated and authorized. Unlike traditional VPN, SDP establishes one-to-one encrypted connections between verified users and specific applications.\n\nThis skill covers deploying SDP using the CSA v2.0 specification, implementing Single Packet Authorization (SPA), configuring the SDP controller and gateway, and validating the deployment against NIST SP 800-207 requirements.\n\n\n## When to Use\n\n- When deploying or configuring deploying software defined perimeter capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When building or improving security architecture for this domain\n- When conducting security assessments that require this implementation\n\n## Prerequisites\n\n- Familiarity with zero trust architecture concepts and tools\n- Access to a test or lab environment for safe execution\n- Python 3.8+ with required dependencies installed\n- Appropriate authorization for any testing activities\n\n## Architecture\n\n### SDP Components (CSA Specification)\n\n```\n┌─────────────────────┐\n│ SDP Controller       │\n│ - Authentication     │\n│ - Authorization      │\n│ - Policy management  │\n│ - Key management     │\n└──────────┬──────────┘\n           │\n    ┌──────┴──────┐\n    │             │\n    v             v\n┌────────┐  ┌────────────┐\n│ IH     │  │ AH         │\n│(Client)│  │(Gateway)   │\n│        │  │            │\n│ SPA    │──│ Protected  │\n│ mTLS   │  │ Resources  │\n└────────┘  └────────────┘\n\nIH = Initiating Host (User Device)\nAH = Accepting Host (Application Gateway)\nSPA = Single Packet Authorization\n```\n\n### SDP Deployment Models\n1. **Client-to-Gateway**: User device connects through SDP gateway to backend applications\n2. **Client-to-Server**: Direct connection between user and application server\n3. **Server-to-Server**: Workload-to-workload communication through SDP\n4. **Gateway-to-Gateway**: Site-to-site connectivity replacing traditional VPN tunnels\n\n## Key Concepts\n\n### Single Packet Authorization (SPA)\nSPA is a network security mechanism where the SDP gateway drops all TCP\u002FUDP packets by default. A cryptographically signed single packet must be sent before any connection is established. The gateway validates the SPA packet, and only then opens a temporary port for the authenticated session. This makes the gateway invisible to port scanners.\n\n### Mutual TLS (mTLS)\nAfter SPA validation, both the client and server authenticate each other using X.509 certificates. This bidirectional authentication prevents man-in-the-middle attacks and ensures both endpoints are verified.\n\n### Dynamic Provisioning\nSDP connections are provisioned on-demand based on real-time policy evaluation. No persistent network tunnels exist; each session is individually authorized and encrypted.\n\n## Workflow\n\n### Phase 1: SDP Controller Deployment\n\n1. **Deploy SDP Controller**\n   - Install SDP controller on hardened, redundant infrastructure\n   - Configure PKI integration for certificate issuance\n   - Set up authentication backend (LDAP, SAML, OIDC)\n   - Configure policy database with application definitions\n   - Enable audit logging for all controller decisions\n\n2. **Configure Authentication**\n   - Integrate with enterprise IdP via SAML 2.0 or OIDC\n   - Configure device certificate enrollment (SCEP\u002FEST)\n   - Enable multi-factor authentication requirements\n   - Set up certificate revocation checking (OCSP\u002FCRL)\n\n3. **Define Access Policies**\n   - Map users\u002Fgroups to authorized applications\n   - Define device posture requirements per application\n   - Configure contextual conditions (location, time, risk level)\n   - Set session duration and re-authentication intervals\n\n### Phase 2: SDP Gateway Deployment\n\n4. **Deploy Accepting Hosts (Gateways)**\n   - Install SDP gateway instances in front of protected applications\n   - Configure default-drop firewall rules (deny all inbound)\n   - Enable SPA listener on designated ports\n   - Configure mTLS with controller-issued certificates\n   - Set up health monitoring and failover\n\n5. **Configure Application Definitions**\n   - Register each protected application with the controller\n   - Define backend server IPs, ports, and protocols\n   - Configure load balancing for multi-instance applications\n   - Set up application health checks\n\n### Phase 3: Client Deployment\n\n6. **Deploy Initiating Hosts (Clients)**\n   - Install SDP client software on user endpoints\n   - Enroll device certificates through automated provisioning\n   - Configure SPA key material distribution\n   - Test authentication flow: SPA → mTLS → application access\n\n7. **Validate End-to-End Flow**\n   - Verify SPA packets are accepted by gateway\n   - Confirm mTLS handshake succeeds with valid certificates\n   - Test application access through the SDP tunnel\n   - Verify unauthorized access is blocked (no SPA = invisible gateway)\n\n### Phase 4: Operational Validation\n\n8. **Security Testing**\n   - Port scan the SDP gateway to confirm invisibility (all ports show filtered\u002Fclosed)\n   - Attempt connection without valid SPA (must fail silently)\n   - Test with revoked client certificate (must be denied)\n   - Attempt lateral movement from one authorized app to another unauthorized app\n   - Validate audit trail completeness\n\n9. **Monitoring and Maintenance**\n   - Configure SIEM integration for SDP controller and gateway logs\n   - Set up alerting for failed SPA attempts and certificate errors\n   - Establish certificate rotation schedule\n   - Document incident response procedures for SDP events\n\n## Validation Checklist\n\n- [ ] SDP Controller deployed with HA and audit logging\n- [ ] IdP integration tested with SAML\u002FOIDC and MFA\n- [ ] SDP Gateways deployed with default-drop firewall\n- [ ] SPA mechanism validated (gateway invisible to port scans)\n- [ ] mTLS established between clients and gateways\n- [ ] Access policies enforce least-privilege per user\u002Fapp\n- [ ] Device certificate enrollment automated\n- [ ] Unauthorized access attempts blocked silently\n- [ ] Lateral movement between apps prevented\n- [ ] Logs streaming to SIEM with alerting configured\n- [ ] Certificate rotation and revocation procedures tested\n\n## References\n\n- CSA Software-Defined Perimeter Architecture Guide v3\n- CSA SDP Specification v2.0\n- NIST SP 800-207: Zero Trust Architecture\n- CISA Zero Trust Maturity Model v2.0\n- fwknop: Single Packet Authorization implementation\n",{"name":5,"tags":44,"author":47,"domain":29,"license":15,"version":48,"category":5,"nist_csf":49,"subdomain":54,"description":7,"mitre_attack":55},[31,45,46,21,30],"sdp","software-defined-perimeter","mahipal","1.0",[50,51,52,53],"PR.AA-01","PR.AA-05","PR.IR-01","GV.PO-01","zero-trust-architecture",[56,57,58,59,60],"T1133","T1078","T1021","T1046","T1190","main","5eea5b3296f4673b5f481e8bcc1ba76281149f16","modules\u002Fdeploying-software-defined-perimeter",0,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core","https:\u002F\u002Fgithub.com\u002FHenriqueMC17","Qualquer tecnologia suficientemente avançada é indistinguível da mágica.","2026-09-28 22:40:38",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add HenriqueMC17\u002Fagente-core --skill deploying-software-defined-perimeter",{"tool":75,"command":76},"bunx","bunx skills add HenriqueMC17\u002Fagente-core --skill deploying-software-defined-perimeter",{"tool":78,"command":79},"pnpm","pnpm dlx skills add HenriqueMC17\u002Fagente-core --skill deploying-software-defined-perimeter","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002FSKILL.md",true,[83,89,94,100,104,108,114],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"assets\u002Ftemplate.md","ASSET","资产文件",1512,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002Fassets\u002Ftemplate.md",{"path":90,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002FLICENSE",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fapi-reference.md","REFERENCE","参考文档",1886,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002Freferences\u002Fapi-reference.md",{"path":101,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fstandards.md",2867,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002Freferences\u002Fstandards.md",{"path":105,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fworkflows.md",5201,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002Freferences\u002Fworkflows.md",{"path":109,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":112,"sourceHtmlUrl":113},"scripts\u002Fagent.py","SCRIPT","脚本",6804,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002Fscripts\u002Fagent.py",{"path":115,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":116,"sourceHtmlUrl":117},"scripts\u002Fprocess.py",10419,"https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fdeploying-software-defined-perimeter\u002Fscripts\u002Fprocess.py",[119,149,174,197,213,234],{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":130,"publishedAt":39},"01M6HPFF0RCN0X6WT5EBSV71GY","validating-backup-integrity-for-recovery","Validate backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to ensure backups are reliable for disaster recovery and ransomware response scenarios.","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[131,132,133,134,135,136,29,137,138,139,140,141,142,27,143,144,145,146,147,148],"integrity","backup","recovery","validating backup integrity for recovery","for","testing","validate","verification","hash-verification","incident-response","ransomware","detection","t1490","disaster-recovery","restore","incident","disaster recovery","ransomware response",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":39},"01M6HPFAWJVFK25Q33K3T7WQ8G","triaging-vulnerabilities-with-ssvc-framework","Triage and prioritize vulnerabilities using CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree framework to produce actionable remediation priorities.","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[],[156,157,158,159,22,29,160,161,162,163,164,165,166,167,168,169,170,171,172,173],"vulnerabilities","framework","ssvc","triaging vulnerabilities with ssvc framework","triage and prioritize","CISA","vulnerability-management","risk-management","cvss","remediation","vulnerability","prioritization","decision-tree","prioritize","decision","priorities","actionable","tree",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":39},"01M6HPF6JS9X72WP59094H3ASQ","triaging-security-incident","Performs initial triage of security incidents to determine severity, scope, and required response actions using the NIST SP 800-61r3 and SANS PICERL frameworks. Classifies incidents by type, assigns priority based on business impact, and routes...","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Ftriaging-security-incident\u002FSKILL.md",[],[181,182,146,29,183,184,185,27,143,186,187,188,189,190,191,192,193,194,195,196],"security","triaging security incident","actions","soc","NIST","analysis","severity-classification","incident-triage","SANS-PICERL","SOC-operations","picerl","conversion","isolation","scope","impact","consistency",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":203,"publishedAt":39},"01M6HPF2EX6ZYNYYHKBRJN7GEF","triaging-security-incident-with-ir-playbook","Classify and prioritize security incidents using structured IR playbooks to determine severity, assign response teams, and initiate appropriate response procedures.","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Ftriaging-security-incident-with-ir-playbook\u002FSKILL.md",[],[181,204,205,182,146,22,29,206,184,140,207,208,27,143,209,187,169,210,211,212],"playbook","triaging security incident with ir playbook","teams","IR-playbook","severity","classification","classify","incidents","initiate",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":219,"publishedAt":39},"01M6HPEY9XPGE7X95AG4XJFQAW","triaging-security-alerts-in-splunk","Triages security alerts in Splunk Enterprise Security by classifying severity, investigating notable events, correlating related telemetry, and making escalation or closure decisions using SPL queries and the Incident Review dashboard. Use when...","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Ftriaging-security-alerts-in-splunk\u002FSKILL.md",[],[181,220,221,222,223,224,29,225,226,227,184,228,27,229,230,231,190,232,146,233],"security alerts","splunk","triaging security alerts in splunk","alerts","review","siem","dashboard","search","correlation-search","t1566","notable-events","incident-review","cm","de",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":240,"publishedAt":39},"01M6HPET6XGEPEJPN7V032JGZ0","tracking-threat-actor-infrastructure","Threat actor infrastructure tracking involves monitoring and mapping adversary-controlled assets including command-and-control (C2) servers, phishing domains, exploit kit hosts, bulletproof hosting, a","https:\u002F\u002Fgithub.com\u002FHenriqueMC17\u002Fagente-core\u002Fblob\u002Fmain\u002Fmodules\u002Ftracking-threat-actor-infrastructure\u002FSKILL.md",[],[241,242,243,244,29,245,246,247,248,249,250,229,251,252,232,253,233,254,255,256],"infrastructure","tracking threat actor infrastructure","tracking","threat","monitoring","mitre-attack","threat-actor","threat-intelligence","command-and-control","dns","command","exploit","intelligence","domains","kit","hosts"]