The Defender's Window（防禦者之窗）：資安主題演講（第 4/4 段）

🧑‍🏫 這是 OpenAI 資安主題演講的最後一段。講者說明 OpenAI 內部怎麼用 agents（能自己規劃、動手完成多步驟工作的 AI）把「找漏洞到修好漏洞」整條流程自動化，並具體建議企業現在該做什麼。想知道 AI 實際怎麼用在資安的人，很值得一看。

• 35:33 OpenAI 內部啟動 Code Red，動員工程、資安、研究共 250 人組成跨職能團隊，打造第一版 Defense Factory
  ↳ Code Red 是公司內部的緊急動員令。OpenAI 抽調工程、資安、研究共 250 人組成跨部門小組，做出第一版 Defense Factory，也就是用 agents 串起資安流程的整套架構。
• 35:33 目標是邁向 continuous defense（持續防禦），讓內部系統與服務也以 agents 為基礎運作
  ↳ continuous defense（持續防禦）是指不再定期做一次檢查，而是讓 agents 盡量自己跑完找漏洞、修漏洞的流程。OpenAI 自家的內部系統也要用這種方式運作。
• 36:05 流程第一步是盤點（inventory）：了解技術資產、端點等所有可能被攻擊的面向
  ↳ 第一步是 inventory（盤點）：先搞清楚公司有哪些系統、伺服器、電腦等端點。不知道自己有哪些東西，就不可能守得住。
• 36:05 第二步是用各種 cyber models 掃描整個技術資產做 discovery；講者指出「找到問題」算是簡單的部分
  ↳ 第二步是 discovery（找問題）：用 cyber models（專門處理資安任務的 AI 模型）掃過所有系統找漏洞。講者特別說，找到問題反而是簡單的部分，難的在後面。
• 36:37 Dynamic validation：讓 agents 在問題交給開發者修補前，先進行驗證
  ↳ dynamic validation（動態驗證）：漏洞交給工程師之前，先讓 agents 實際確認它是真的、值得修，工程師就不會被一堆假警報淹沒。
• 36:37 Ownership assignment：透過 Slack、PagerDuty 等內部系統與原始碼，找出每個問題該交給誰修補
  ↳ ownership assignment（指派負責人）：找到問題後，還得知道誰該修。agents 會查 Slack（團隊聊天工具）、PagerDuty（值班通報系統）和原始碼紀錄，判斷該交給哪個團隊。
• 36:37 修補後還要驗證修補是否真的解決了原本的問題
  ↳ remediation（修補）不是改完就結束，還要回頭確認原本的漏洞真的消失了，避免以為修好、其實沒修到。
• 37:10 既有的傳統資安工具維持不變，Defense Factory 是整合它們；主要整合應用程式原始碼、資安工具與 workflows
  ↳ 公司原本的資安工具照樣使用，不用丟掉。Defense Factory 負責把它們串起來，主要串三樣：程式碼、資安工具，以及 workflows（工作流程，也就是事情一關一關怎麼往下傳）。
• 37:10 Workflows 很關鍵，因為漏洞在流程中需要被指派、在團隊間轉移並追蹤狀態
  ↳ 一個漏洞從發現到修好，要指派給人，可能在團隊之間轉手，還得隨時知道進度到哪。沒有好的流程，漏洞很容易卡在半路沒人管。
• 37:40 新加入的元素是 agents，以及依各組織客製的 skills；部分 skills 已隨 Codex plugin 與 CLI 發布，可作為參考
  ↳ 新加入的是 agents 和 skills（依公司狀況客製、教 agent 怎麼做事的能力包）。部分 skills 已隨 Codex（OpenAI 的寫程式 AI）的 plugin 外掛與 CLI 指令列工具公開，可以拿來參考。
• 37:40 另一個關鍵是隔離環境，特別是能讓應用程式與 agent 一起執行，讓 agent 反覆迭代並驗證
  ↳ 另一個關鍵是隔離環境：跟正式系統分開，把應用程式和 agent 放在一起跑。agent 可以反覆嘗試、反覆驗證，就算弄壞了也不會影響正在使用的服務。
• 38:11 架構需在組織自己的網路內執行，能存取內部系統，同時讓原始碼與 IP 留在網路內保持安全
  ↳ 整套架構要放在公司自己的網路裡。這樣 agent 才查得到內部系統，原始碼和 IP（智慧財產，例如公司的技術機密）也不會流到外面。
• 38:11 Agents 執行在虛擬機器中；雖然也有 containers 等抽象方式，但 VM 提供較強的隔離
  ↳ agents 跑在 VM（虛擬機器，用軟體模擬出的一台獨立電腦）裡。containers（容器，比較輕量的打包隔離方式）也能用，但 VM 隔離得比較徹底。
• 38:43 VM 可透過 kernel 監控 agent 的互動、工具使用與呼叫；agent 即使改寫檔案也仍在監控之下
  ↳ VM 可以從 kernel（作業系統最底層的核心）看到 agent 做了什麼、呼叫了哪些工具。就算 agent 改了檔案，也還在監控範圍內。
• 38:43 VM 之上是 development container，建立在 Microsoft 的開放標準上，可把相依套件、工具打包進開發環境
  ↳ VM 上面再放 dev container（開發容器）。它採用 Microsoft 提出的開放標準，把程式需要的套件和工具全部打包成一個現成的開發環境。
• 38:43 Dev container 提供可重現性，讓 agents 每次都在相同環境中運作
  ↳ 好處是可重現：agent 每次都在一模一樣的環境裡工作，不會因為某台機器少裝一個東西就跑出不同結果，出問題也比較好追查。
• 39:15 Dev container 也能加入 hooks，例如放入 Falcon sensor、串接 Wiz 做監控
  ↳ hooks（預留給外部工具接進來的位置）可以用來加監控，例如裝 CrowdStrike 的 Falcon sensor（端點偵測程式），或串接 Wiz（雲端資安平台）。
• 39:15 最上層是帶著 skills 的 agent；這套架構讓 agents 能在整個組織大規模執行
  ↳ 最上層才是帶著 skills 的 agent。下面幾層先把環境、隔離、監控都處理好，agents 才能在整個公司大量同時運作。
• 39:45 成果：dynamic validation 的誤報率（false positive rate）降到 1% 以下，講者說許多組織的數字遠高於此
  ↳ false positive rate（誤報率）是指回報為漏洞、其實不是漏洞的比例。經過動態驗證後降到 1% 以下，講者說很多組織的誤報率遠高於這個數字。
• 39:45 成果：agents 執行的修補中，修補回滾率（fix rollback rate）低於 1%，絕大多數修補都成功
  ↳ fix rollback rate（修補回滾率）是指修完反而出問題、只好撤回的比例。agents 做的修補只有不到 1% 需要撤回，幾乎都修成功。
• 40:17 運作模式：各系統的輸入與脈絡流入執行 Codex 與 agents 的環境，再產出結果
  ↳ 整體運作像一條管線：各個系統的資料和背景資訊送進執行 Codex 與 agents 的環境，處理完再產出結果。
• 40:17 Dynamic validation 會驗證掃描工具或 Daybreak 找到的漏洞：是否重複、是否已被提報、內部系統是否可觸及
  ↳ 動態驗證會檢查掃描工具或 Daybreak（OpenAI 的資安 program 與模型，也能找漏洞）找到的漏洞：有沒有重複、是否已經有人回報、內部系統實際上能不能被打到。
• 40:47 Ownership assignment 同樣模式，透過 PagerDuty、GitHub 等找出負責人，把漏洞順利交給各團隊
  ↳ 指派負責人也用同一套模式：agent 去查 PagerDuty、GitHub（存放程式碼的平台）上的紀錄，找出對的團隊，把漏洞順利交出去。
• 40:47 Verified remediation：在獨立環境中搭配應用程式執行修補，讓 agent 能高度確信問題已完全解決
  ↳ verified remediation（經驗證的修補）：在獨立環境裡連同應用程式一起執行修補、實際測試，讓 agent 能很有把握地確認問題已經完全解決。
• 41:26 OpenAI 投入大量人力，因為認為現在正是 cyber models 變得非常強大的時期
  ↳ 為什麼投入這麼多人？因為 OpenAI 判斷，現在正是資安 AI 模型能力變得非常強的時期，值得全力投入。
• 41:26 OpenAI 也和部分客戶採用相同模式：組跨職能團隊、執行 cyber models，全力推動端到端修補流程
  ↳ OpenAI 也帶著部分客戶照同一套做法進行：組跨部門小組、讓資安模型跑起來，全力打通「找到漏洞到修好漏洞」的整條流程。
• 41:26 這樣做能找出組織內的交接問題與瓶頸，再逐步消化待辦項目
  ↳ 實際跑過一遍，就會看出流程卡在哪裡，例如哪兩個團隊之間常交接不順、哪一關最慢。找到瓶頸之後，再一步步清掉累積的待修清單。
• 42:07 善用防禦者優勢的三件事：集中力量找出並修補漏洞、給 agents 專屬環境、邁向 continuous defense
  ↳ 防守方要把握優勢，有三件事：集中力量找漏洞、修漏洞；給 agents 專屬的工作環境；朝持續防禦前進。
• 42:07 OpenAI 正在把這套架構產品化，目前自己先 dogfooding，已有少數客戶使用早期版本
  ↳ OpenAI 正在把這套架構做成產品。目前先 dogfooding（公司先把自己的產品拿來自己用，測過再推出），也有少數客戶在用早期版本。
• 42:07 目前容量有限，只與一小群客戶合作，未來幾週到幾個月會逐步推出
  ↳ 因為量能有限，目前只和一小群客戶合作，接下來幾週到幾個月會陸續推出。
• 42:58 客戶一致的回饋是「有了模型，要怎麼實際運用並產生成果」，讓模型落地是 OpenAI 接下來的重點
  ↳ 客戶最常問的都是同一件事：「模型很強，但要怎麼用在我們公司、真的做出成果？」所以 OpenAI 接下來的重點，是讓模型真正落地。
• 43:32 Matt 強調不要等 OpenAI 的產品，所有元件都已經準備好了
  ↳ 講者 Matt 直接說：不要等 OpenAI 的產品，需要的元件現在都已經有了，可以自己先動手組起來。
• 43:32 本次演講著重在預防（找出並修補弱點）；客戶已能用模型與工具建立調查、回應等資安維運 workflows
  ↳ 這場演講談的是預防，也就是事先找出並補好弱點。出事之後的調查和應變，客戶現在也已經能用模型和工具建立流程。
• 44:13 OpenAI 的方向是和客戶一起學習、分享有效做法，再把它變成產品
  ↳ OpenAI 的做法是跟客戶邊做邊學，把真正有效的方法整理出來分享，再做成產品。
• 44:13 下一步一：申請 Daybreak program，取得這些工具
  ↳ 第一步：申請 Daybreak program，取得這些工具。
• 44:13 下一步二：從 Codex Security plug-in 開始，可先從一個 repository 做起，再透過 CI 擴大到數萬、數十萬的規模
  ↳ 第二步：先用 Codex Security plug-in，從一個 repository（程式碼專案庫）試起，再透過 CI（程式每次更新就自動執行檢查的機制）擴大到數萬、數十萬的規模。
• 44:46 下一步三：用 CLI 與 SDK 打造自己的資安工具，依自身脈絡客製化
  ↳ 第三步：用 CLI 和 SDK（開發工具包，讓工程師把功能接進自己程式的現成元件）打造自己的資安工具，依公司狀況量身調整。
• 44:46 建議研究 Dev Container，把一切打包成可重現的環境，能穩定執行內部測試，也提供清楚的系統脈絡與 ownership
  ↳ 建議研究 Dev Container：把一切打包成可重現的環境，內部測試能穩定執行，也讓 agent 清楚知道系統的樣貌、各部分由誰負責。
• 45:16 Defense Factory 的組成：models 提供能力，Codex 與開發工具讓能力落地，資安 workflows 提供更具體的起點
  ↳ Defense Factory 有三層：模型提供能力；Codex 等開發工具讓能力真正運作起來；資安 workflows 則提供具體的起點，不必從零開始想。
• 45:16 客戶最大的挑戰是人力容量，因此 OpenAI 會打造不需客戶自建的完整端到端產品
  ↳ 客戶最大的困難是人手不夠，沒辦法自己建。所以 OpenAI 要做一套從頭到尾都完整的產品，客戶不需要自己蓋。
• 45:53 OpenAI 將透過 Daybreak Defense Network，引入訓練與導入合作夥伴，協助客戶走完這段歷程
  ↳ OpenAI 會透過 Daybreak Defense Network 引進負責教育訓練和導入的合作夥伴，陪客戶一路把防禦建起來。
• 45:53 講者認為 defender's window 是真實存在的，要趁現在能使用 Daybreak models 的時機立刻行動
  ↳ defender's window（防守者的時間窗口）指的是防守方現在就能用上強大資安模型的這段時機。講者認為它真實存在，應該趁能使用 Daybreak 模型的現在立刻行動。
• 46:23 守護數位與實體世界需要資安團隊、研究者、合作夥伴、維護者共同參與；每個貢獻的修補與分享的經驗都能幫助其他防禦者
  ↳ 守護數位與實體世界，需要資安團隊、研究者、合作夥伴和維護者一起參與。每貢獻一個修補、每分享一次經驗，都能幫到其他防守的人。

OpenAI 內部 Defense Factory 透過 dynamic validation，把誤報率（false positive rate）降到多少？