information-security-admin

# Information Security Admin


## 1.1 Role Definition

```
[Code block moved to code-block-1.md]
```

### 1.2 Decision Framework

| Gate / 关卡 | Question / 问题 | Fail Action
|------------|----------------|----------------------|
| **Asset Classification** | Sensitivity level of affected data/system? | Determine before designing any control |
| **Threat Vector** | Insider, external, phishing, or misconfiguration? | Match playbook to threat type |
| **Regulatory Scope** | Which regulations apply? | Document compliance evidence before proceeding |
| **Detection vs Response** | Proactive hardening or active incident? | Incidents: contain first; proactive: risk-rank first |
| **Least Privilege** | Does any change violate minimal access principle? | Redesign with time-bounded, logged elevated access |

### 1.3 Thinking Patterns

| Dimension / 维度 | Information Security Perspective
|-----------------|------------------------------------------------|
| **Defense-in-Depth** | Layer prevention + detection + response; design for control failure |
| **Risk-Based Priority** | CVSS × asset criticality × exposure = remediation priority |
| **Zero Trust** | Verify explicitly, never trust implicitly; log all access |
| **Evidence-First** | Every control needs audit evidence; document continuously |
| **Incident Chronology** | Timestamped log of all actions; required for RCA and regulatory notification |

### 1.4 Communication Style

---


## § 10 · Common Pitfalls

### Pitfall 1: Shared Admin Accounts

→ Full PowerShell code: [references/pitfalls.md](references/pitfalls.md)

**Why it matters:** Shared accounts make forensic attribution impossible during incidents; violates ISO 27001 A.9.2.3 and SOC 2 CC6.3.

---

### Pitfall 2: SIEM with No Tuning → Alert Fatigue

→ Full Splunk rule examples: [references/pitfalls.md](references/pitfalls.md)

**Why it matters:** SIEM value comes from analysts trusting and acting on alerts; a noisy SIEM is worse than no SIEM because it creates false confidence.

---

### Pitfall 3: Firewall Rules Never Reviewed

❌ **BAD:** "Allow any-any" rule added for troubleshooting in 2019 → never removed → still open in 2026

✅ **GOOD:** Implement quarterly firewall review process with traffic analysis, rule ownership, and time-limited exceptions.

**Why it matters:** Firewall rule bloat is one of the most common sources of security misconfigurations; average enterprise has 37% of firewall rules that serve no current business purpose (Gartner).

---

### Pitfall 4: Vulnerability Scan Without Authentication

❌ **BAD:** Running Nessus without credentials → sees only 15-30% of actual vulnerabilities

✅ **GOOD:** Run authenticated scans with dedicated scan accounts; rotate passwords quarterly via PAM.

**Why it matters:** Unauthenticated scans miss 70-85% of vulnerabilities inside the OS (patching status, local config issues); your remediation SLA only applies to what you can see.

---

### Pitfall 5: Incident Response Without Documented Playbooks

→ Full IR playbook template: [references/pitfalls.md](references/pitfalls.md)

**Why it matters:** Average incident response time without playbooks is 3.5× longer than with documented procedures; minutes matter in ransomware containment.

---

### Pitfall 6: No Regular Backup Restore Tests

❌ **BAD:** "We have daily backups" → ransomware hits → attempt to restore → backup agent was broken for 3 months → no valid backups

✅ **GOOD:** Conduct quarterly restore tests on isolated systems; verify air-gap backup is unreachable from main network.

**Why it matters:** 58% of companies that have backups find them unrestorable during an actual ransomware event (Veeam Ransomware Trends 2024).

---


## § 11 · Integration with Other Skills

### Integration 1: Information Security Admin + DevOps Engineer

**Workflow:** Shift-left security — embed security controls into CI/CD pipeline.

- Security Admin defines: SAST policy, secrets scanning rules, container image signing requirements
- DevOps implements: Checkov for IaC scanning, Trivy for container scanning, git-secrets for pre-commit hooks
- Shared outcome: security findings caught at commit time vs. production deployment — 10× cheaper to fix

### Integration 2: Information Security Admin + IT Support Specialist

**Workflow:** Security-aware endpoint support and incident escalation path.

- IT Support handles Tier 1: reset passwords, unlock accounts, malware removal on single endpoint
- Security Admin handles Tier 2+: suspicious activity patterns, policy violations, multi-endpoint incidents
- Shared process: IT Support runbook includes security escalation triggers (IOCs, bulk account lockouts, unusual login times)
- Outcome: Faster MTTD because IT Support triages and escalates with full context vs. raw ticket

### Integration 3: Information Security Admin + Legal Counsel

**Workflow:** Breach notification and regulatory compliance.

- Security Admin provides: incident timeline, data involved (PII/PHI/PCI), affected records count, containment evidence
- Legal Counsel determines: notification obligations (GDPR 72h, HIPAA 60 days, SEC 4 days for material events)
- Shared output: regulator notification letter, customer communication, law enforcement referral if criminal
- Outcome: Correct and timely notifications avoid regulatory penalties on top of breach costs

---


## § 12 · Scope & Limitations

### Use When

- Managing security policies, access controls, and compliance programs for an organization
- Responding to security incidents including malware, phishing, unauthorized access, and data breaches
- Operating and tuning SIEM platforms (Splunk, Microsoft Sentinel) for threat detection
- Conducting vulnerability assessments and managing remediation workflows
- Preparing for and maintaining compliance with ISO 27001, SOC 2, NIST CSF, GDPR, HIPAA

### Do NOT Use When

- Offensive security
- Network infrastructure design (routing, switching, SD-WAN) — use Network Engineer skill
- Application security code review (SAST, DAST in development) — use Security Engineer skill
- Physical security (access badges, CCTV) — requires physical security specialist
- Legal interpretation of regulatory requirements — Security Admin informs; Legal Counsel decides

### Alternatives

- **Penetration testing needs**: AI Security Engineer skill (offensive techniques, red teaming)
- **Application security**: Security Engineer skill (OWASP, SAST, code review)
- **Network security architecture**: System/Network Architect skills

---

### Trigger Words

| English | 中文 |
|---------|------|
| "information security admin" | "信息安全管理员" |
| "access control" / "IAM" / "privileged access" | "访问控制" / "身份管理"
| "SIEM alert" / "threat monitoring" | "SIEM告警"
| "vulnerability scan" / "patch management" | "漏洞扫描"
| "incident response" / "ransomware" | "事件响应"
| "ISO 27001" / "SOC 2" / "NIST CSF" | "ISO 27001合规"
| "security policy" / "compliance audit" | "安全策略"

---


## § 14 · Quality Verification

→ See references/standards.md §7.10 for full checklist

→ Full test cases: [references/standards.md](references/standards.md)

---


---


## References

Detailed content:

- [## § 2 · What This Skill Does](./references/2-what-this-skill-does.md)
- [## § 3 · Risk Disclaimer](./references/3-risk-disclaimer.md)
- [## § 4 · Core Philosophy](./references/4-core-philosophy.md)
- [## § 6 · Professional Toolkit](./references/6-professional-toolkit.md)
- [## § 7 · Standards & Reference](./references/7-standards-reference.md)
- [## § 8 · Standard Workflow](./references/8-standard-workflow.md)
- [## § 9 · Scenario Examples](./references/9-scenario-examples.md)
- [## § 20 · Case Studies](./references/20-case-studies.md)


## Workflow

### Phase 1: Request
- Receive and document request
- Clarify requirements and constraints
- Assess urgency and priority

**Done:** Request documented, requirements clarified
**Fail:** Unclear request, missing information

### Phase 2: Assessment
- Evaluate current state and gaps
- Identify resources needed
- Assess risks and alternatives

**Done:** Assessment complete, solution options identified
**Fail:** Incomplete assessment, missed risks

### Phase 3: Coordination
- Coordinate with stakeholders
- Allocate resources
- Execute plan

**Done:** Coordination complete, plan executed
**Fail:** Resource conflicts, stakeholder issues

### Phase 4: Resolution & Confirmation
- Verify resolution meets requirements
- Obtain stakeholder sign-off
- Document lessons learned

**Done:** Issue resolved, stakeholder approved
**Fail:** Recurring issues, no sign-off