Skip to content

Latest commit

 

History

History
802 lines (628 loc) · 33.7 KB

CYBERSEC_BLUEPRINT.md

File metadata and controls

802 lines (628 loc) · 33.7 KB

🛡️ MAXIMUS CYBERSEC BLUEPRINT - Enterprise Discord Security Architecture

Version: 2.0 Date: 2025-10-28 Status: ⚠️ PLANNING ONLY - NO CODE IMPLEMENTED Adherence: 100% DOUTRINA Vértice (Constitution v2.5)

⚠️ CRITICAL STATUS DISCLAIMER: This document represents PLANNING AND ARCHITECTURE ONLY. No code has been implemented yet. All status indicators, completion claims, and "production ready" statements refer to the planning phase being complete, NOT the implementation. Phase 1 (foundation) has NOT started.

📋 Executive Summary

This blueprint defines the enterprise-grade cybersecurity architecture for MAXIMUS Discord Bot ("Arcanjo Miguel"). It synthesizes PhD-level research on Discord API security, threat intelligence integration, and adversarial TTPs into a cohesive, production-ready system.

Core Principle: MAXIMUS is not a bot with security features. It is a security system that uses Discord as its operational interface.

🏗️ I. Architectural Foundation - Phase 1 (NOT STARTED)

1.1 Planned Architecture (Phase 1 - ⚪ NOT STARTED)

⚠️ STATUS: The architecture below is PLANNED but NOT IMPLEMENTED. No code, services, or database exist yet.

MAXIMUS Bot (Phase 1 - PLANNED)
├── PostgreSQL 16 (Persistent Data) - NOT CREATED
│   ├── 7 Models: guilds, guild_settings, users, warnings, custom_commands, reaction_roles, audit_logs
│   └── Prisma ORM (Type-safe queries)
├── Redis 7 (Cache + Rate Limiting) - NOT CREATED
│   ├── Guild settings cache (1h TTL, 99% hit rate)
│   └── Token bucket rate limiter (5 pre-configured limiters)
├── Inversify v6 (Dependency Injection) - NOT CREATED
│   └── 5 Services: Guild, User, Warning, Moderation, AuditLog
├── Discord.js v14 - NOT INSTALLED
│   ├── REST API (state management)
│   └── Gateway API (real-time events via WebSocket)
└── TypeScript 5.3 (Boris Cherny principles) - NOT CONFIGURED

1.2 Cybersecurity Layer Integration Points

The cybersec architecture extends Phase 1 by adding:

  1. Security Service Layer - New Inversify services for threat detection, intelligence, and response
  2. Event Processing Pipeline - Real-time threat analysis on Gateway events
  3. External TIP Integration - Bidirectional communication with MISP, OpenCTI, Vértice-MAXIMUS
  4. Forensic Data Export - SIEM integration to overcome 45-day audit log retention limit

🔐 II. Security Service Architecture

2.1 Service Catalog

Service Responsibility Dependencies Scope
ThreatDetectionService Real-time content/behavioral analysis Redis (state tracking), MISP/OpenCTI (IOC validation) Singleton
ThreatIntelligenceService IOC enrichment, sighting reporting, bidirectional TIP sync PyMISP, OpenCTI GraphQL client Singleton
ForensicExportService Audit log export to SIEM, permanent storage, chain of custody Prisma (local cache), Elasticsearch/Splunk API Singleton
IncidentResponseService ChatOps orchestration, interactive triage, playbook execution Discord Interactions API, ServiceNow/incident.io Singleton
AntiRaidService Mass-join detection, CAPTCHA enforcement, automated mitigation Redis (rate tracking), GuildService Singleton

2.2 Service Interface Definitions (TypeScript)

// src/types/security.ts

import { Snowflake, Message, GuildMember } from 'discord.js';

/**
 * ═══════════════════════════════════════════════════════════════
 * THREAT DETECTION SERVICE
 * ═══════════════════════════════════════════════════════════════
 * Real-time analysis of Gateway events for security threats.
 * Implements multi-stage detection pipeline:
 * 1. Ingestion (Gateway events)
 * 2. Parsing & Analysis (RegEx, NLP, Hash checks)
 * 3. Alerting & Action (delete/ban + alert to #soc-alerts)
 */
export interface IThreatDetectionService {
  /**
   * Analyzes message content for phishing links, malware attachments, toxicity
   * @returns Threat score (0-100) and classification
   */
  analyzeMessage(message: Message): Promise<ThreatAnalysisResult>;

  /**
   * Detects behavioral anomalies (mass deletion, privilege escalation)
   * @returns Anomaly detection result with severity
   */
  detectBehavioralAnomaly(userId: Snowflake, action: AuditAction): Promise<AnomalyResult>;

  /**
   * Validates URL against blocklists and Google Safe Browsing
   * @returns Malicious URL classification
   */
  checkURLReputation(url: string): Promise<URLReputationResult>;

  /**
   * Scans file attachment (hash check + optional VirusTotal API)
   * @returns Malware scan result
   */
  scanFileAttachment(fileUrl: string, hash: string): Promise<MalwareScanResult>;
}

/**
 * ═══════════════════════════════════════════════════════════════
 * THREAT INTELLIGENCE SERVICE
 * ═══════════════════════════════════════════════════════════════
 * Bidirectional integration with MISP, OpenCTI, Vértice-MAXIMUS
 */
export interface IThreatIntelligenceService {
  /**
   * Query MISP for known information about an IOC
   * @param ioc - IP, domain, hash, email
   * @returns MISP Event data with context
   */
  queryMISP(ioc: string, iocType: IOCType): Promise<MISPEvent | null>;

  /**
   * Report sighting back to MISP (IOC seen "in the wild")
   */
  reportSighting(ioc: string, guildId: Snowflake): Promise<void>;

  /**
   * Create new MISP event for novel threat discovered on Discord
   */
  createMISPEvent(threat: ThreatData, guildId: Snowflake): Promise<MISPEvent>;

  /**
   * Query OpenCTI GraphQL API for threat actor/campaign data
   */
  queryOpenCTI(indicator: string): Promise<OpenCTIIndicator | null>;

  /**
   * Forward threat to Vértice-MAXIMUS ecosystem for cross-platform analysis
   */
  forwardToVerticeMaximus(threat: ThreatData): Promise<void>;
}

/**
 * ═══════════════════════════════════════════════════════════════
 * FORENSIC EXPORT SERVICE
 * ═══════════════════════════════════════════════════════════════
 * Overcomes Discord's 45-day audit log retention limit.
 * Implements permanent, searchable archive for compliance.
 */
export interface IForensicExportService {
  /**
   * Export Discord audit log entry to SIEM (Splunk/Elasticsearch)
   * @param entry - Audit log entry from Discord API
   */
  exportToSIEM(entry: AuditLogEntry): Promise<void>;

  /**
   * Cache audit log entry locally in PostgreSQL (permanent storage)
   */
  cacheAuditLog(entry: AuditLogEntry): Promise<void>;

  /**
   * Maintain chain of custody for forensic evidence
   * @returns Cryptographic hash of event data for integrity
   */
  generateChainOfCustody(entry: AuditLogEntry): string;

  /**
   * Batch export historical logs (compliance requirement)
   */
  batchExportAuditLogs(guildId: Snowflake, startDate: Date, endDate: Date): Promise<void>;
}

/**
 * ═══════════════════════════════════════════════════════════════
 * INCIDENT RESPONSE SERVICE (ChatOps/SecOps)
 * ═══════════════════════════════════════════════════════════════
 * Interactive triage and response workflow within Discord
 */
export interface IIncidentResponseService {
  /**
   * Create enriched alert with interactive buttons in #soc-alerts
   * @param threat - Threat detection result
   * @returns Message with "Ban User", "Delete Message", "Ignore" buttons
   */
  createInteractiveAlert(threat: ThreatAnalysisResult, message: Message): Promise<void>;

  /**
   * Handle button interaction (analyst clicks "Ban User")
   */
  handleInteractionResponse(interaction: ButtonInteraction): Promise<void>;

  /**
   * Initiate incident response playbook (/incident start)
   * Creates private channel, invites IR team, creates ticket in ServiceNow
   */
  startIncidentPlaybook(incidentType: string, guildId: Snowflake): Promise<void>;

  /**
   * Update alert message with "Action Taken" status
   */
  updateAlertStatus(messageId: Snowflake, action: string, analyst: string): Promise<void>;
}

/**
 * ═══════════════════════════════════════════════════════════════
 * ANTI-RAID SERVICE
 * ═══════════════════════════════════════════════════════════════
 * Detects and mitigates coordinated mass-join attacks
 */
export interface IAntiRaidService {
  /**
   * Track join rate using Redis (sliding window algorithm)
   * @returns True if join rate exceeds threshold (e.g., >10 joins/10s)
   */
  detectMassJoin(guildId: Snowflake): Promise<boolean>;

  /**
   * Enforce CAPTCHA for new members during raid
   */
  enforceCAPTCHA(member: GuildMember): Promise<void>;

  /**
   * Automatic mitigation: timeout server, kick recent joins, notify admins
   */
  triggerAutoMitigation(guildId: Snowflake): Promise<void>;

  /**
   * Check account age against minimum threshold
   */
  validateAccountAge(member: GuildMember, minAgeDays: number): Promise<boolean>;
}

📊 III. Event Processing Pipeline

3.1 Gateway Event → Threat Detection Flow

┌─────────────────────────────────────────────────────────────────┐
│ Discord Gateway (WebSocket)                                     │
│ Opcode 0 (Dispatch) → Event: MESSAGE_CREATE                     │
└────────────────────────┬────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ 1. INGESTION                                                    │
│ Event Handler: onMessageCreate(message)                         │
│ Parse: content, author, attachments, embeds                     │
└────────────────────────┬────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ 2. PARALLEL ANALYSIS                                            │
│ ├─ ThreatDetectionService.analyzeMessage()                      │
│ │  ├─ URL extraction → checkURLReputation()                     │
│ │  ├─ Attachment hash → scanFileAttachment()                    │
│ │  └─ NLP toxicity scoring                                      │
│ └─ ThreatIntelligenceService.queryMISP() (if IOC detected)      │
└────────────────────────┬────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ 3. DECISION LOGIC                                               │
│ if (threatScore > 80) → HIGH SEVERITY                           │
│ if (50 <= threatScore <= 80) → MEDIUM (alert only)              │
│ if (threatScore < 50) → LOW (log only)                          │
└────────────────────────┬────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────────────────┐
│ 4. AUTOMATED RESPONSE (HIGH SEVERITY)                           │
│ ├─ message.delete() (REST API)                                  │
│ ├─ ModerationService.timeoutUser() or banUser()                 │
│ ├─ IncidentResponseService.createInteractiveAlert()             │
│ │  → Post to #soc-alerts with VirusTotal link + buttons         │
│ ├─ ForensicExportService.exportToSIEM()                         │
│ └─ ThreatIntelligenceService.reportSighting()                   │
└─────────────────────────────────────────────────────────────────┘

3.2 Critical Gateway Events for Security

Event Intent Required Analysis Pipeline Automated Action
MESSAGE_CREATE MESSAGE_CONTENT (privileged) URL/hash/NLP analysis Delete + ban if malicious
MESSAGE_DELETE GUILD_MESSAGES Log to SIEM (forensic trail) None (passive logging)
GUILD_MEMBER_ADD GUILD_MEMBERS (privileged) Account age check, join rate tracking CAPTCHA or kick if raid detected
GUILD_MEMBER_UPDATE GUILD_MEMBERS (privileged) Role change anomaly detection Alert if privilege escalation
GUILD_AUDIT_LOG_ENTRY_CREATE GUILD_MODERATION Real-time admin action monitoring Alert + export to SIEM
GUILD_BAN_ADD GUILD_MODERATION Log ban with reason Export to SIEM

Privileged Intent Challenge: The most critical events (MESSAGE_CONTENT, GUILD_MEMBERS) require manual Discord verification. This creates a bottleneck for rapid deployment.

Mitigation Strategy:

  1. Apply for privileged intents immediately during Phase 2 development
  2. Implement "degraded mode" that functions with limited data while awaiting approval
  3. Document intent requirements in bot setup guide

🔌 IV. External Integration Architecture

4.1 MISP Integration (Malware Information Sharing Platform)

Library: PyMISP (Python) or custom REST client (TypeScript) Protocol: HTTPS REST API Authentication: API key (stored in environment variables)

Capabilities:

  1. Query IOCs: GET /attributes/restSearch - Search for IP, domain, hash, email
  2. Report Sightings: POST /sightings/add - Report IOC seen on Discord
  3. Create Events: POST /events/add - Submit novel threat discovered via bot
  4. Attribute Tagging: Tag Discord-sourced intel with custom tags (e.g., tlp:white, source:discord)

Data Flow:

Discord (malicious URL detected)
  → ThreatDetectionService.analyzeMessage()
  → ThreatIntelligenceService.queryMISP(url, IOCType.DOMAIN)
  ← MISP Event (context: APT group, campaign, CVE)
  → IncidentResponseService.createInteractiveAlert() (enriched with MISP data)
  → ThreatIntelligenceService.reportSighting(url, guildId)

4.2 OpenCTI Integration (Open Cyber Threat Intelligence)

Library: GraphQL client (Apollo or similar) Protocol: GraphQL over HTTPS Authentication: API key

Capabilities:

  1. Query threat actors, campaigns, malware families
  2. Retrieve STIX/TAXII indicators
  3. Enrich Discord alerts with APT attribution

Example Query:

query GetIndicatorByValue($value: String!) {
  indicators(filters: { key: "value", values: [$value] }) {
    edges {
      node {
        id
        name
        pattern
        created_by_ref {
          name
        }
        labels
      }
    }
  }
}

4.3 Vértice-MAXIMUS Ecosystem Integration

Protocol: Bidirectional API (REST or GraphQL) Purpose: Cross-platform threat correlation

Capabilities:

  1. Forward Discord threats to Vértice for ecosystem-wide analysis
  2. Receive threat intel from Vértice's 9-layer immune system
  3. Leverage Vértice's LLM-powered threat narrative generation

Data Structure (JSON):

{
  "source": "discord",
  "guild_id": "123456789",
  "threat_type": "phishing_url",
  "ioc": "https://malicious-domain.com/login",
  "timestamp": "2025-10-28T12:34:56Z",
  "context": {
    "user_id": "987654321",
    "message_content": "[REDACTED]",
    "attachment_hashes": ["sha256:abc123..."]
  }
}

4.4 SIEM Integration (Splunk / Elasticsearch)

Purpose: Overcome 45-day audit log retention limit Protocol: HTTP Event Collector (Splunk) or Bulk API (Elasticsearch)

Log Format (Structured JSON):

{
  "timestamp": "2025-10-28T12:34:56.789Z",
  "source": "maximus_bot",
  "guild_id": "123456789",
  "event_type": "MEMBER_BAN_ADD",
  "actor": {
    "user_id": "111111111",
    "username": "admin#1234"
  },
  "target": {
    "user_id": "222222222",
    "username": "malicious_user#5678"
  },
  "reason": "Phishing attempt - URL: https://malicious.com",
  "metadata": {
    "bot_version": "2.0.0",
    "threat_score": 95,
    "misp_event_id": "e9f2a3b1-...",
    "chain_of_custody_hash": "sha256:def456..."
  }
}

Retention Policy: Permanent (or per compliance requirements, e.g., 7 years for financial institutions)

🛡️ V. Threat-Informed Security Model (Best Practices)

5.1 DOUTRINA Compliance - Security Principles

Artigo III (Confiança Zero):

  • Bot token treated as untrusted credential (environment variables only, never hardcoded)
  • All user input sanitized and validated (command injection prevention)
  • Permission checks before every privileged action

Artigo II (Padrão Pagani):

  • Zero TODOs or placeholders in production code
  • All tests pass before commit (no @pytest.mark.skip equivalent)
  • Production-ready code on day one

Artigo V (Legislação Prévia):

  • Security architecture designed BEFORE autonomous features
  • Rate limiting and circuit breakers implemented from Phase 2 start

5.2 Discord-Specific Security Requirements

Requirement Implementation Rationale
Least Privilege Bot requests only specific bitwise permissions (e.g., KICK_MEMBERS, BAN_MEMBERS, VIEW_AUDIT_LOG) Prevents total server takeover if token compromised (CVE-2025-26604 lesson)
No ADMINISTRATOR Permission Explicitly forbidden unless compensating controls ADMINISTRATOR bypasses all hierarchy checks - catastrophic if exploited
Secure Credential Management Bot token in .env, added to .gitignore, loaded via process.env.BOT_TOKEN Prevents accidental exposure in git commits
Rate Limit Compliance Parse X-RateLimit-* headers, implement backoff queue Avoids 429 errors and Invalid Request Limit ban (10,000 invalid/10min)
Input Sanitization Validate all command arguments with RegEx whitelist Prevents command injection (CVE-2020-15147)
Role Hierarchy Validation Check bot.roles.highest.position > target.roles.highest.position Prevents privilege escalation (CVE-2020-15278)

5.3 Data Privacy & Legal Compliance

GDPR Considerations (EU servers):

  • Implement Legitimate Interest Assessment (LIA) for logging user data
  • Provide /privacy command showing data collected and retention policy
  • Offer /gdpr-export command for users to request their data
  • Delete user data on request (GDPR Article 17 - Right to Erasure)

CCPA Considerations (California users):

  • Provide privacy notice at bot invite time
  • Implement "Do Not Sell" functionality (N/A for security bot, but document)

Chain of Custody (Forensic Evidence):

  • Every exported audit log includes cryptographic hash (SHA-256)
  • Hash stored alongside original event in SIEM
  • Ensures data integrity for potential legal proceedings

📐 VI. Database Schema Extensions

6.1 New Models for Cybersecurity Features

threat_detections - Persistent record of all detected threats

model ThreatDetection {
  id             String   @id @default(cuid())
  guildId        String
  guild          Guild    @relation(fields: [guildId], references: [id], onDelete: Cascade)

  messageId      String?  // If threat was in a message
  userId         String
  username       String

  threatType     String   // phishing_url, malware_attachment, toxicity, raid, etc.
  threatScore    Int      // 0-100
  ioc            String?  // The actual indicator (URL, hash, IP)

  mispEventId    String?  // ID of MISP event if reported
  openCTIId      String?  // ID of OpenCTI indicator if queried

  actionTaken    String   // delete_message, ban_user, timeout_user, alert_only, none

  metadata       Json?    // Flexible additional data (VirusTotal results, etc.)

  createdAt      DateTime @default(now())

  @@index([guildId, createdAt])
  @@index([threatType, threatScore])
}

archived_audit_logs - Permanent storage to overcome 45-day retention

model ArchivedAuditLog {
  id                String   @id @default(cuid())
  guildId           String
  guild             Guild    @relation(fields: [guildId], references: [id], onDelete: Cascade)

  discordAuditLogId String   // Original Discord audit log entry ID

  actionType        String   // MEMBER_BAN_ADD, ROLE_UPDATE, etc.

  actorId           String?
  actorTag          String?

  targetId          String?
  targetTag         String?

  reason            String?

  changes           Json?    // Before/after state

  chainOfCustodyHash String  // SHA-256 hash for integrity verification

  exportedToSIEM    Boolean  @default(false)
  siemExportDate    DateTime?

  createdAt         DateTime

  @@index([guildId, actionType, createdAt])
  @@index([chainOfCustodyHash])
}

incident_cases - Tracks IR playbook executions

model IncidentCase {
  id              String   @id @default(cuid())
  guildId         String
  guild           Guild    @relation(fields: [guildId], references: [id], onDelete: Cascade)

  incidentType    String   // phishing_campaign, data_breach, raid, etc.
  severity        String   // low, medium, high, critical
  status          String   // open, investigating, resolved, closed

  channelId       String   // Private IR channel created for this incident

  assignedAnalyst String?  // User ID of analyst handling case

  relatedThreats  String[] // Array of ThreatDetection IDs

  timeline        Json     // Array of timestamped events

  externalTicketId String? // ServiceNow or incident.io ticket ID

  createdAt       DateTime @default(now())
  updatedAt       DateTime @updatedAt
  closedAt        DateTime?

  @@index([guildId, status, severity])
}

6.2 guild_settings Extension

Add cybersecurity configuration fields to existing guild_settings model:

model GuildSettings {
  // ... existing fields ...

  // Security Operations
  socAlertsChannelId     String?  // Channel for #soc-alerts
  threatScoreThreshold   Int      @default(80) // Auto-action threshold

  // Anti-Raid
  antiRaidEnabled        Boolean  @default(true)
  joinRateThreshold      Int      @default(10)  // Joins per window
  joinRateWindowSeconds  Int      @default(10)
  minAccountAgeDays      Int      @default(7)
  captchaEnabled         Boolean  @default(false)

  // Threat Intelligence
  mispEnabled            Boolean  @default(false)
  mispURL                String?
  mispAPIKey             String?  // Encrypted at rest

  openCTIEnabled         Boolean  @default(false)
  openCTIURL             String?
  openCTIAPIKey          String?  // Encrypted at rest

  verticeMaximusEnabled  Boolean  @default(false)
  verticeMaximusAPIURL   String?

  // SIEM Export
  siemEnabled            Boolean  @default(false)
  siemType               String?  // splunk, elasticsearch
  siemURL                String?
  siemAPIKey             String?  // Encrypted at rest

  // GDPR/Privacy
  gdprMode               Boolean  @default(false)
  dataRetentionDays      Int      @default(90)
}

🚨 VII. Operational Boundaries & Constraints

7.1 API Rate Limits - Strategic Implications

Limit Type Value Impact on Security Bot
Global 50 req/sec Cannot ban >50 users/sec during raid (defensive deficit)
Invalid Requests 10,000/10min Poorly designed bot can self-ban during incident
Per-Route Varies (e.g., 5 msg/5sec per channel) Alert flooding can trigger rate limit

Mitigation Strategies:

  1. Metered Mitigation: Queue ban actions, execute at <50/sec rate
  2. Prioritization Algorithm: Ban high-threat users first (threat score descending)
  3. Graceful Degradation: If rate limited, switch to timeout (lighter action) or lockdown server
  4. Multi-Bot Sharding: For large servers (>2,500 guilds), implement sharding (mandatory)

7.2 Privileged Intents - Approval Bottleneck

Challenge: MESSAGE_CONTENT and GUILD_MEMBERS intents require Discord verification, which can take weeks.

Solution:

  1. Phase 2.1 (No Privileged Intents): Implement features that don't require privileged data:
    • Audit log monitoring (GUILD_AUDIT_LOG_ENTRY_CREATE)
    • Ban/kick logging (GUILD_BAN_ADD)
    • SIEM export
    • Forensic archiving
  2. Phase 2.2 (Privileged Intents Approved): Enable full threat detection:
    • Message content scanning
    • Anti-raid (requires GUILD_MEMBERS)

7.3 Data Ephemerality - 45-Day Retention Problem

Discord Audit Log Retention: 45 days (permanent deletion after)

Compliance Gap: Many regulations (SOX, HIPAA, FINRA) require 7+ years retention

Solution: ForensicExportService implements:

  1. Real-time export to SIEM on every GUILD_AUDIT_LOG_ENTRY_CREATE event
  2. Local PostgreSQL cache in archived_audit_logs table
  3. Batch export job (daily cron) to pull last 24h of logs via REST API
  4. Chain of custody hashing for legal admissibility

🎯 VIII. Threat Landscape - MITRE ATT&CK Mapping

8.1 Adversarial TTPs Targeting Discord

Tactic Technique Discord-Specific Implementation MAXIMUS Countermeasure
Initial Access T1566.002 (Phishing: Spearphishing Link) Malicious URLs in DMs/channels ThreatDetectionService.checkURLReputation()
Execution T1204.002 (Malicious File) Infostealer disguised as game installer ThreatDetectionService.scanFileAttachment()
Command & Control T1102 (Web Service) Malware uses Discord API for C2 Network monitoring (out of scope for bot, but document)
Exfiltration T1567.002 (Cloud Storage) Data exfil to Discord CDN via webhooks Monitor for abnormal file uploads (future feature)
Impact T1485 (Data Destruction) "Nuking" - mass channel deletion AntiRaidService + role hierarchy checks

8.2 Defensive Coverage Map

MITRE ATT&CK Coverage
├── Initial Access (100% - phishing detection)
├── Execution (80% - file scanning, no sandboxing yet)
├── Persistence (N/A - Discord bots can't achieve traditional persistence)
├── Privilege Escalation (90% - role hierarchy validation)
├── Defense Evasion (60% - detect toxicity evasion, no adversarial ML defense yet)
├── Credential Access (N/A - no credential harvesting on Discord)
├── Discovery (N/A - passive platform)
├── Lateral Movement (N/A - no network traversal)
├── Collection (100% - all collection logged to SIEM)
├── Command and Control (30% - can detect, but not block network-level C2)
├── Exfiltration (70% - can detect unusual uploads, no DLP yet)
└── Impact (95% - anti-raid, anti-nuke, audit logging)

🔬 IX. Research-Informed Feature Roadmap

9.1 LLM-Powered Enhancements (Phase 4-5)

Research Finding: LLMs can conduct highly sophisticated social engineering at scale (USENIX Security '25).

MAXIMUS Response:

  1. LLM-Based Toxicity Detection: Replace RegEx with fine-tuned transformer model (BERT/RoBERTa)
  2. Conversational Threat Analysis: Detect multi-message social engineering sequences
  3. Adversarial Robustness: Implement defenses against evasion techniques (e.g., leetspeak, homoglyphs)

Ethical Constraint: NEVER use LLMs for offensive social engineering (DOUTRINA Artigo III - Confiança Zero)

9.2 Adversarial Machine Learning Defense (Phase 5)

Research Finding: AI-based moderation can be evaded with adversarial examples.

MAXIMUS Response:

  1. Ensemble Detection: Combine multiple detection methods (RegEx + NLP + hash-based) - attacker must evade all
  2. Adversarial Training: Train NLP models on adversarial examples
  3. Human-in-the-Loop: High-confidence detections auto-action, medium-confidence alerts analyst (ChatOps)

📜 X. Legal & Ethical Framework

10.1 GDPR Compliance (EU Servers)

Legitimate Interest Assessment (LIA):

  • Purpose: Server security and fraud prevention
  • Necessity: Logging user actions is necessary to detect threats
  • Balancing Test: Security interest outweighs minimal privacy impact
  • Safeguards: Data anonymization where possible, 90-day retention (configurable)

User Rights:

  • /privacy - View privacy policy
  • /gdpr-export - Export personal data
  • /gdpr-delete - Request data deletion (except audit logs required for legal compliance)

10.2 Chain of Custody for Forensic Evidence

Standard: NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response)

MAXIMUS Implementation:

  1. Collection: Event captured from Discord Gateway with timestamp
  2. Hashing: SHA-256 hash generated immediately (ForensicExportService.generateChainOfCustody())
  3. Storage: Hash + event stored in archived_audit_logs table (PostgreSQL - immutable after write)
  4. Transfer: Event exported to SIEM with hash included in metadata
  5. Verification: Analyst can verify integrity by re-hashing event data and comparing

Legal Admissibility: Documented chain of custody ensures evidence admissible in court (Federal Rules of Evidence 901)

🔧 XI. Technology Stack - Security Layer

Component Technology Purpose
Threat Detection TypeScript + discord.js v14 Event processing pipeline
NLP/ML Hugging Face Transformers (Python microservice) Toxicity scoring, social engineering detection
Hash Analysis Node.js crypto module SHA-256 file hashing
URL Reputation Google Safe Browsing API Phishing/malware URL detection
File Scanning VirusTotal API Malware attachment scanning
MISP Integration PyMISP (Python) or REST client (TypeScript) Threat intelligence queries
OpenCTI Integration GraphQL client (Apollo) APT/campaign enrichment
SIEM Export Splunk HTTP Event Collector / Elasticsearch Bulk API Permanent audit log storage
Rate Limiting Existing Redis Token Bucket (Phase 1) API rate limit compliance
Forensic Hashing Node.js crypto.createHash('sha256') Chain of custody

🎓 XII. References - Research Foundation

This blueprint synthesizes findings from:

  • Discord API Documentation: Gateway Events, Rate Limits, Permissions (discord.com/developers)
  • Academic Research: USENIX Security '25 (LLM social engineering), IEEE S&P 2024 (adversarial ML)
  • Threat Intelligence: MITRE ATT&CK (T1102, T1567.002), MISP Project, OpenCTI
  • Security Standards: NIST SP 800-86 (forensics), GDPR Article 17, Federal Rules of Evidence 901
  • CVE Analysis: CVE-2020-15147 (RCE), CVE-2020-15278 (privilege escalation), CVE-2025-26604 (token theft)
  • Malware Case Studies: ChaosBot (Rust C2), Python RAT, Discord CDN abuse

✅ XIII. Acceptance Criteria - DOUTRINA Compliance

Artigo II (Padrão Pagani):

  • ✅ Zero placeholders or TODOs in production code
  • ✅ All TypeScript interfaces fully implemented
  • ✅ All tests passing (no skip flags)

Artigo III (Confiança Zero):

  • ✅ Bot token never hardcoded (environment variables only)
  • ✅ All user input sanitized
  • ✅ Permission checks before privileged actions

Artigo V (Legislação Prévia):

  • ✅ Security architecture designed BEFORE implementation
  • ✅ Rate limiting and circuit breakers from day one
  • ✅ GDPR compliance built-in, not bolted-on

Artigo IV (Antifragilidade):

  • ✅ System strengthens with chaos (adversarial examples improve detection)
  • ✅ Threat intel feedback loop (sightings reported to MISP)

🚀 Next Steps

This blueprint will be translated into:

  1. CYBERSEC_ROADMAP.md - Phased implementation timeline (Phases 2-5)
  2. CYBERSEC_IMPLEMENTATION_PLAN.md - Task-level execution plan (TypeScript code, Prisma migrations, API integrations)

Blueprint Status: ✅ COMPLETE - Ready for roadmap generation

Author: Juan Carlos de Souza (Arquiteto-Chefe) Co-Architect: Claude-Code (Antropic) Reviewed By: DOUTRINA Vértice v2.5 Date: 2025-10-28