خدمات الأمان

Continuous Threat Exposure Management: continuously scans public endpoints, domains and certificates to enumerate the external attack surface and entry points, identifies reachable attack paths, attaches asset context (public routes, dependencies, owner) and feeds exposure events plus shared-schema findings to the VM ledger. Maps to ATT&CK T1190 (Exploit Public-Facing Application) and T1595 (Active Scanning).

• المُدخلات: assets, dns, certificates, open-endpoints
• المخرجات: attack-paths, exposure-findings, asset-context
• Integration: تسلّم CTEM مسارات الهجوم وسياق الأصول إلى سجل VM؛ وهما أساس درجة إمكانية الوصول.

Dynamic application security testing (DAST): probes running applications with dynamic inspection across scan scopes and authenticated scenarios (logged-in paths), and reports reproducible runtime vulnerability findings with request/response evidence to the VM ledger.

• المُدخلات: running-apps, scan-scopes, auth-scenarios
• المخرجات: runtime-findings, request-response-evidence
• Integration: يُرسل DAST نتائج تشغيل قابلة لإعادة التكرار (أدلة الطلب/الاستجابة) إلى سجل VM.

Static application security testing: analyzes source code for vulnerable patterns and missing sanitization, and through static analysis and taint / data-flow inspection reports code findings with file and line to the VM ledger. Also inspects dependency manifests and emits dependency notes.

• المُدخلات: source-code, dependency-manifests
• المخرجات: code-findings, taint-paths, dependency-notes
• Integration: يُرسل SAST نتائج فحص الكود مع اسم الملف والسطر إلى سجل VM، مما يسرّع تحديد هدف الإصلاح.

Spear-phishing detection (SPECT): detects impersonation in received mail — header verification (SPF/DKIM/DMARC) against domain-normalisation comparison (punycode / homoglyph / added characters), URL rewrite targets against the sender — and reports targeted-mail findings to the VM ledger. Covers ATT&CK T1566 (Phishing).

• المُدخلات: received-mail, domain-intel, mail-flow-records
• المخرجات: targeted-mail-findings, lookalike-domain-notes, impersonation-evidence
• Integration: SPECT emits findings with header, domain-normalisation and URL-mismatch evidence to the VM ledger, starting the takeover tracking.

Vulnerability management (wvme): consumes the shared-schema findings emitted by the four upstream services, dedups and scores them by reachability and exploitability, and tracks the remediation lifecycle in a ledger keyed by CPE/CVE. Accepts CVE/CPE feed input.

• المُدخلات: findings-from-ctem, findings-from-dast, findings-from-sast, findings-from-spear-phishing, cve-cpe-feeds
• المخرجات: vulnerability-ledger, remediation-status, exposure-reports
• Integration: VM is the ledger service: it receives the upstream services' findings in the shared schema and dedups, scores and tracks remediation.

Governance (NIST CSF 2.0 GOVERN): turns a CSF 2.0 organizational profile (current and target tier per subcategory) into gaps, scores a risk register by likelihood × impact against a risk appetite, and tiers a supplier register by criticality, listing the missing requirements (security clause, incident-notification clause, reassessment, exit plan). POST /v1/security/govern computes deterministically from the body alone and stores nothing.

• المُدخلات: csf-profile, risk-register, supplier-register
• المخرجات: profile-gaps, scored-risk-register, supplier-findings
• Integration: GRC can take VM-ledger findings as risk-register input. Its output carries CSF subcategory ids, the same id space IR and DR use.
• POST /v1/security/govern · GET /v1/security/govern returns a worked example

Incident response (NIST CSF 2.0 RESPOND): from one incident report, returns its category, priority and escalation, a playbook whose every step names its RS subcategory, the notification deadlines the stated facts trigger (Japan APPI preliminary and final reports, GDPR Art. 33, NIS2 Art. 23) and the criteria for moving to recovery. POST /v1/security/respond is deterministic and stores nothing.

• المُدخلات: incident-report, vm-findings
• المخرجات: triage, playbook, notification-deadlines, recovery-criteria
• Integration: IR opens an incident from VM-ledger or SPECT findings and hands off to DR once the recovery criteria hold.
• POST /v1/security/respond · GET /v1/security/respond returns a worked example

Recovery (NIST CSF 2.0 RECOVER): from assets' criticality, RTO, RPO, dependencies and backups (last success, last restore test, offsite, immutable), returns dependency-ordered restore waves, RPO checks, 3-2-1-1-0 checks, RTO inversions, verification steps and end-of-recovery criteria, and stakeholder and public communication milestones. POST /v1/security/recover is deterministic and stores nothing.

• المُدخلات: assets, rto-rpo, dependencies, backup-records
• المخرجات: restore-waves, backup-findings, end-criteria, communications
• Integration: DR is the recovery plan used once IR's recovery criteria hold; in steady state it runs as a backup and RTO/RPO check.
• POST /v1/security/recover · GET /v1/security/recover returns a worked example