white-hat

ホワイトハット

堅牢な防御的セキュリティ機能を構築し、セキュリティ・バイ・デザインの原則を実践し、倫理的なハッキングを行うことで、倫理とコンプライアンスを維持しながら、システム、データ、ユーザーを積極的に保護します。

こんなときに使います

次のような場合にこのスキルを使用します：

• セキュリティ要件を備えた新しいシステムを設計するとき
• セキュリティ制御や防御策を実装するとき
• 許可を得たセキュリティテストや評価を実施するとき
• 防御的な戦術を用いてセキュリティインシデントに対応するとき
• セキュリティ意識向上やトレーニングのプログラムを構築するとき
• コンプライアンス要件や規制要件を実装するとき
• セキュリティアーキテクチャや設計パターンを開発するとき
• インシデント対応計画や手順を作成するとき
• セキュリティ監視や検知機能を確立するとき
• セキュリティコードレビューやアーキテクチャ分析を実施するとき

できること

1. セキュリティ・バイ・デザイン

• 初期設計から実装まで、セキュリティを統合します
• セキュリティ原則（最小権限、多層防御、フェイルセーフ）を適用します
• 設定ミスがあっても保護される安全なデフォルト設定を実装します
• 後から付け加えるのではなく、セキュリティを考慮して設計します
• 設計上の意思決定において、セキュリティ上のトレードオフを明示的に検討します

2. 防御的なセキュリティ実装

• 脅威を防止、検知、対応する保護制御を構築します
• セキュリティ層（ネットワーク、ホスト、アプリケーション、データ）を実装します
• セキュリティ監視とロギングを確立します
• セキュリティインシデントに対する検知機能を導入します
• セキュリティイベントへの対応メカニズムを作成します

3. 倫理的なセキュリティテスト

• 適切な範囲とルールのもと、許可を得たテストを実施します
• セキュリティツールを責任ある倫理的な方法で使用します
• 修正方法の指針を添えて、調査結果を建設的に報告します
• テスト中のプライバシーと機密性を尊重します
• 脆弱性に関する責任ある開示の慣行に従います

4. セキュリティ文化の醸成

• 組織全体でセキュリティ意識の向上を促します
• 開発者にセキュアコーディングの実践方法をトレーニングします
• 開発チーム内にセキュリティチャンピオンを設けます
• セキュリティに関するドキュメントやガイドラインを作成します
• セキュリティチームと開発チームの連携を促進します

ホワイトハットの手法

セキュリティアーキテクチャと設計：

• リスクを早期に特定して対処するための脅威モデリング
• 一般的なセキュリティ上の問題に対応するセキュリティ設計パターン
• 実装前に行うセキュアアーキテクチャレビュー
• 規制要件を統合するコンプライアンス・バイ・デザイン
• ユーザーデータを最初から保護するプライバシー・バイ・デザイン

防御的な実装：

• 入力値の検証とサニタイズ
• インジェクション攻撃を防ぐための出力エンコーディング
• 認証と認可の実装
• 暗号技術の適切な使用と鍵管理
• セキュリティヘッダーとHTTPセキュリティ制御
• 情報を漏えいさせないエラー処理

セキュリティテストと検証：

• 静的アプリケーションセキュリティテスト（SAST）
• 動的アプリケーションセキュリティテスト（DAST）
• 依存関係を対象としたソフトウェア構成分析（SCA）
• インタラクティブアプリケーションセキュリティテスト（IAST）
• 手動によるセキュリティコードレビュー
• 侵入テスト（許可を得て範囲を定めたもの）

監視と対応：

• セキュリティ情報イベント管理（SIEM）
• 侵入検知システム（IDS）
• エンドポイント検知・対応（EDR）
• ログ管理とセキュリティ分析
• インシデント対応の計画と実行
• フォレンジック機能の開発

例

# Conduct threat modeling for new feature
npm run white-hat:threat-model -- --feature "user-payment" --method STRIDE

# Perform secure code review
npm run white-hat:code-review -- --path src/payment/ --tools "sonarqube,checkmarx"

# Implement security controls
npm run white-hat:implement-controls -- --control "input-validation" --framework express

# Run authorized security testing
npm run white-hat:security-test -- --target staging.example.com --scope web-application

# Build incident response plan
npm run white-hat:incident-response -- --scenario "data-breach" --output plan.md

出力形式

White Hat Security Assessment
──────────────────────────────
System: Healthcare Patient Portal
Assessment Date: 2026-02-26
Assessment Type: Proactive Security Review
White Hat Lead: Ethical Defender #3

Security Posture Summary:
- Security Maturity Level: 6.2/10 (Developing)
- Compliance Status: 85% HIPAA aligned
- Critical Security Gaps: 4
- Immediate Risks: 2
- Security Debt: Medium (accumulating)

Security by Design Assessment:

1. Feature: Patient Medical Record Access
   Design Security Score: 7.8/10
   
   Security Controls Implemented:
   - Role-based access control (RBAC) with least privilege
   - Audit logging for all access attempts
   - Session management with proper timeout
   - Input validation for search parameters
   - Output encoding for displayed data
   
   Gaps Identified:
   - No geographic access restrictions (can access from anywhere)
   - No device fingerprinting for anomaly detection
   - Consent revocation not immediately effective
   - Bulk export capability lacks rate limiting
   
   Threat Model Results:
   - STRIDE Analysis:
     * Spoofing: Medium risk (weak multi-factor authentication)
     * Tampering: Low risk (data integrity controls strong)
     * Repudiation: Low risk (comprehensive audit logging)
     * Information Disclosure: High risk (data exfiltration possible)
     * Denial of Service: Medium risk (no rate limiting on API)
     * Elevation of Privilege: Low risk (RBAC implementation solid)
   
   Recommendations:
   - Implement geographic access restrictions
   - Add device fingerprinting and anomaly detection
   - Make consent revocation immediate
   - Add rate limiting to bulk export

2. Feature: Doctor-Patient Messaging
   Design Security Score: 6.1/10
   
   Security Controls Implemented:
   - End-to-end encryption for messages
   - Message retention policy (30 days)
   - Attachment scanning for malware
   
   Gaps Identified:
   - No message integrity verification
   - No non-repudiation mechanisms
   - Attachments not scanned for PHI (protected health information)
   - No secure file sharing alternative offered
   - Message threading vulnerable to injection
   
   Threat Model Results:
   - Data-in-transit: Strong (encryption)
   - Data-at-rest: Weak (attachments stored unencrypted)
   - Authentication: Medium (session-based, no step-up for sensitive)
   - Authorization: Weak (no message-level permissions)
   
   Recommendations:
   - Implement digital signatures for message integrity
   - Add PHI detection for attachments
   - Offer secure file sharing as alternative
   - Add message-level authorization checks

Defensive Security Implementation Review:

1. Authentication System:
   Implementation Quality: 8.4/10
   
   Strengths:
   - Multi-factor authentication implemented
   - Password policy enforces complexity
   - Account lockout after failed attempts
   - Session management with secure flags
   
   Weaknesses:
   - No step-up authentication for sensitive actions
   - Password reset vulnerable to timing attacks
   - Session fixation possible in certain flows
   - No biometric authentication options
   
   Security Test Results:
   - Password cracking resistance: High (>100 years at current hashing)
   - MFA bypass attempts: 0 successful (out of 1000 simulations)
   - Session hijacking: 2 vectors identified (mitigation recommended)

2. Data Protection:
   Implementation Quality: 7.2/10
   
   Strengths:
   - Encryption at rest for database fields
   - Encryption in transit via TLS 1.3
   - Key management using AWS KMS
   - Data classification implemented
   
   Weaknesses:
   - Some PHI in logs (partial mitigation)
   - Backup encryption not consistently applied
   - Data minimization not fully implemented
   - Right to erasure implementation incomplete
   
   Compliance Check:
   - HIPAA: 18/22 requirements met (82%)
   - GDPR: 14/18 requirements met (78%)
   - CCPA: 12/15 requirements met (80%)

Ethical Testing Results:

1. Authorized Penetration Test:
   Scope: Web application, APIs, mobile app
   Duration: 40 hours
   
   Findings:
   - Critical: 0
   - High: 3
   - Medium: 8
   - Low: 12
   - Informational: 15
   
   Notable Findings:
   - API rate limiting insufficient (high)
   - JWT token leakage in logs (medium)
   - Insecure direct object reference (high)
   - Missing security headers (medium)
   
   Remediation Status:
   - Immediate fixes: 3/3 high severity
   - 30-day plan: 6/8 medium severity
   - 90-day plan: 2/8 medium severity + all low severity

2. Security Code Review:
   Lines Reviewed: 45,200
   Security Issues Found: 47
   Issue Density: 1.04 issues/1000 lines
   Industry Average: 1.5 issues/1000 lines
   
   Common Issues:
   - Hardcoded secrets: 3 instances
   - Insufficient input validation: 12 instances
   - Weak cryptographic usage: 2 instances
   - Insecure error handling: 8 instances

Security Monitoring & Response:

1. Detection Capability:
   Coverage: 72%
   Mean Time to Detect (MTTD): 3.2 hours
   Alert Accuracy: 68% (32% false positives)
   
   Gaps:
   - No behavioral anomaly detection
   - Cloud infrastructure monitoring limited
   - Container security monitoring absent
   - API security monitoring basic

2. Response Capability:
   Mean Time to Respond (MTTR): 4.8 hours
   Mean Time to Recover (MTTR): 8.5 hours
   Incident Response Team Readiness: 6.8/10
   
   Improvement Areas:
   - Automated incident response playbooks
   - Better communication templates
   - Regular tabletop exercises
   - Forensic tooling investment

Security Roadmap Recommendations:

1. IMMEDIATE (Next 30 days):
   - Fix 3 high-severity penetration test findings
   - Implement PHI detection for attachments
   - Add geographic access restrictions
   - Conduct security awareness training

2. QUARTER 1 (Next 90 days):
   - Implement step-up authentication
   - Deploy behavioral anomaly detection
   - Complete right to erasure implementation
   - Conduct incident response tabletop exercise

3. QUARTER 2 (Next 180 days):
   - Implement zero trust architecture
   - Deploy container security monitoring
   - Achieve security certification (ISO 27001, SOC 2)
   - Establish bug bounty program

4. LONG-TERM (Next 12 months):
   - Build security operations center (SOC)
   - Implement security chaos engineering
   - Achieve HITRUST certification
   - Establish security metrics program

Security Culture Assessment:
- Developer Security Training: 45% completion
- Security Champion Program: Not established
- Security in Sprint Planning: Occasionally
- Security Tooling Adoption: 60%
- Security Metrics Tracking: Basic

Culture Recommendations:
1. Establish security champion program (1 per 10 developers)
2. Integrate security into sprint planning (security stories)
3. Implement gamified security training
4. Create security metrics dashboard visible to all
5. Regular security brown bags and knowledge sharing

Value Delivered:
- Risk Reduction: Estimated 65% reduction in breach likelihood
- Compliance Improvement: 15% increase in compliance coverage
- Security Maturity: +2.4 points on security maturity model
- Incident Prevention: 3 potential breaches prevented
- Cost Savings: Estimated $2.8M (breach costs avoided)
- Reputation Protection: Maintained patient trust and confidence

注意事項

• ホワイトハットセキュリティは事後対応ではなく、事前対応です
• セキュリティは製品ではなくプロセスです。継続的な改善に注力してください
• セキュリティと使いやすさ、ビジネスニーズのバランスを取ってください
• 活動量だけでなく、セキュリティの有効性を測定してください
• 教育と協力を通じてセキュリティ文化を育んでください
• セキュリティには継続的な投資と注意が必要です
• セキュリティ業務では倫理的な配慮が最も重要です
• 組織内でセキュリティに関する知識を透明性をもって共有してください
• セキュリティインシデントやヒヤリハットから学んでください
• セキュリティはビジネスを妨げるのではなく、実現を支援するべきです
• 最も効果的なセキュリティは、正規のユーザーには意識されません
• 定期的なセキュリティ評価により、セキュリティ負債の蓄積を防げます