Differences

This shows you the differences between two versions of the page.

--- wiki:ai:gaudi-security [2026/07/21 17:33] – created swilson
+++ wiki:ai:gaudi-security [2026/07/21 18:00] (current) – swilson
@@ Line 1: / Line 1: @@
 ====== Security ======
-  * We watch Intel's security advisories, the national vulnerability database, and the government's known-exploited-vulnerability list every day.
+This page covers how we track, triage, and patch security vulnerabilities affecting Gaudi hardware and software, plus the access control and compliance policies that apply to Gaudi nodes.
-  * New advisory → reviewed within 24 hours → checked against what's actually deployed → patched per severity (critical within 14 days, high within 30 days, medium next quarter, low annually).
-  * If Intel hasn't shipped a fix for something, we log it, apply workarounds (network isolation, tighter access), tell the customer in their monthly report, and — if it's serious — bump up their migration timeline.
+===== Where We Watch for Vulnerabilities =====
-  * Everything else (access control, audit logs, compliance certifications) follows the exact same policy as our NVIDIA fleet. No special exceptions for Gaudi.
+We monitor three sources every day, not just when something happens to surface in the news:
+  * **Intel Security Advisories:** covers vulnerabilities in Gaudi firmware, the ''habanalabs'' kernel driver, and the SynapseAI stack specifically. See [[https://www.intel.com/content/www/us/en/security-center/default.html|Intel Product Security Center]].
+  * **NIST National Vulnerability Database (NVD):** the standard public CVE feed, which catches anything affecting the underlying OS, kernel, or third-party packages Gaudi nodes run. See [[https://nvd.nist.gov/|NVD]].
+  * **CISA Known Exploited Vulnerabilities (KEV) catalog:** flags any CVE that is confirmed to be actively exploited in the wild, which changes how urgently we treat it regardless of its CVSS score. See [[https://www.cisa.gov/known-exploited-vulnerabilities-catalog|CISA KEV Catalog]].
+===== How a New Advisory Gets Handled =====
+<code>
+  Advisory published
+        |
+        v
+  Reviewed within 24 hours
+        |
+        v
+  Checked against what's actually deployed
+  (which nodes, which driver/firmware/OS versions)
+        |
+        v
+  Patch available?  ----No---->  Log it, apply compensating controls,
+        |                        report to customer, consider accelerating
+       Yes                       migration timeline if severe
+        |
+        v
+  Patched per severity SLA (see table below)
+</code>
+===== Patch Timing by Severity =====
+^ Severity              ^ Patch within                ^
+| Critical (CVSS 9.0+)  | 14 days (7 days if it's in the CISA KEV catalog) |
+| High (7.0–8.9)        | 30 days                     |
+| Medium (4.0–6.9)       | Next quarterly maintenance window |
+| Low                   | Annually                    |
+This is the same SLA used for OS patching generally, not a separate Gaudi-specific timeline; see [[gaudi-os-patching-hardening|OS Patching and Hardening]] for how it's applied to kernel and package updates.
+**Why the CISA KEV catalog matters:** a Critical CVE that's just been published is dangerous in theory. A Critical CVE that's on the KEV list is confirmed to be actively used against real targets right now, which is why we compress the SLA further in that case rather than waiting the full 14 days.
+===== When Intel Hasn't Shipped a Fix =====
+Not every CVE has a patch available the moment it's disclosed, especially now that Gaudi is on a slower release cadence than an actively-marketed platform (see [[gaudi-discontinued-clarification|Setting the Record Straight on "Discontinued"]]). When that happens, we don't just wait silently:
+  * **Log it** in the risk register, with the CVE ID, affected nodes, and severity.
+  * **Apply compensating controls** where possible: network isolation of the affected service, tighter access restrictions, or disabling a vulnerable feature if it isn't in active use.
+  * **Report it to the customer** in their monthly security report, so it's visible rather than buried.
+  * **Escalate the migration timeline** if the CVE is severe and no patch looks likely soon; see [[gaudi-migration-planning|Migration Planning]] for what that conversation looks like.
+===== Access Control, Audit Logging, and Compliance =====
+Gaudi nodes follow the exact same policy as the rest of the fleet; there is no separate or relaxed standard for Gaudi hardware.
+  * **Access control:** a four-tier model (read-only, operator, admin, root/break-glass), with multi-factor authentication required at every tier. SSH access is only permitted through a bastion host; direct internet-facing SSH is not allowed.
+  * **Audit logging:** ''auditd'' runs on every node and ships logs to the central aggregator within 60 seconds of the event. Logs are kept hot for 90 days, then archived for a year.
+  * **Compliance frameworks:** CIS Benchmark Level 1 (all nodes), SOC 2 Type II (audited annually), NIST Cybersecurity Framework (reviewed annually), and DISA STIG for government customers specifically.
+===== Related Pages =====
+  * [[gaudi-os-patching-hardening|OS Patching and Hardening]] — the hardening baseline and patch SLA this page's severity table is drawn from.
+  * [[gaudi-monitoring-diagnostics|Monitoring and Diagnostics]] — how we'd actually detect exploitation of an unpatched CVE, not just the paperwork trail.
+  * [[gaudi-migration-planning|Migration Planning]] — what happens when an unpatched CVE is severe enough to accelerate a customer's move off Gaudi.
 ----

Combined Cloud Managed Services

Site Tools

Differences

Page Tools