這幾天談到 Alert、誤報、事件關聯與 IR 時，
我一直強調一件事：看到告警不等於已經確認攻擊成立。
但當分析人員完成初步判斷，認為某個外部 IP 確實具有風險之後，下一個問題就是：接下來要怎麼處理？
最直接的方式，是由人員登入防火牆，建立 IP 物件、加入阻擋群組，再確認防火牆規則是否生效。這樣做的好處是每個動作都由人員確認，但當類似的 Alert 不斷出現，同樣的操作也會一直重複。
Stellar Cyber 本身提供回應與串接功能，可以依照設定的條件，將 Alert 中的 IP 送到防火牆。這讓我開始思考：哪些處置可以交給系統自動執行？哪些動作即使技術上做得到，仍應該保留人工判斷？
這篇分享的不是我從零開發一套 SOAR，也不是要表示所有 Alert 都能自動處理。我實際做的，是先觀察告警，找出適合自動化的情況，再使用 Stellar Cyber 既有功能連動 Sophos 防火牆。後來遇到防火牆群組管理需求，我再透過 AI 協助開發 Python 程式，由自己完成調整、測試與部署。
剛開始接觸自動回應時，我認為最重要的不是立刻把 Connector 設定好，而是先確認哪些 Alert 適合自動處理。
Stellar Cyber 中可能出現不同類型的 Alert，每一類告警的判斷條件與誤報風險都不一樣。如果只因為告警是 High 或 Critical，就把裡面的 IP 全部送到防火牆，可能會把正常服務、客戶信任的來源，甚至必要的連線一起阻擋。
因此，我會先觀察一段時間，了解告警為什麼被觸發、涉及的是來源還是目的 IP，以及這類行為在客戶環境中是否可能正常發生。
我實際設定時，主要針對外部具有風險的 IP 連線，再搭配多個條件進行篩選。至於使用哪些條件，仍要看 Alert 類型及客戶環境，並不是所有客戶都套用同一組固定規則。
這段觀察過程也讓我理解，自動化並不是省略判斷，而是把原本由人員做的判斷，整理成系統可以執行的條件。條件如果沒有先確認清楚，系統只會更快地執行錯誤動作。
確認某類 Alert 適合自動處理後，我會在 Stellar Cyber 中設定相應的規則條件及回應功能。
在我實際接觸的環境中，有碰到 Forti、Palo Alto、Sophos，這次先以 Sophos 防火牆來介紹。整體流程可以簡化成：
A 群組是我事先在 Sophos 防火牆上建立的，防火牆規則也會引用這個群組。當 Stellar Cyber 觸發符合條件的 Alert 時，系統會自動把 IP 建立成防火牆物件，再加入指定群組，不需要每一筆都由人員登入防火牆操作。
Sophos Firewall 的設計本來就會區分 IP Host 與 IP Host Group。IP 位址可以建立成 Host 物件，再加入 Host Group，而群組則能被防火牆規則或其他政策引用。Stellar Cyber 在這裡負責的是透過產品既有的串接能力，把 Alert 中符合條件的 IP 送進我預先設定的處置位置。
這部分是使用產品提供的功能，不是我自己撰寫 Respond Connector，也不能描述成我自行開發了 Stellar Cyber 與 Sophos 之間的 API 串接。
自動化流程設定完成後，我仍會確認實際結果。
因為從 Stellar Cyber 觸發回應，到防火牆真正執行阻擋，中間還有好幾個狀態：
Stellar Cyber 上可以看到回應失敗的狀態，但我仍會到防火牆確認寫入結果。因為平台顯示指令已經送出、設備接受指令，以及防火牆規則真正生效，不能全部當成同一件事。
如果只看到 Alert 已經被處理或關閉，就認為 IP 一定遭到阻擋，也可能造成錯誤判斷。
自動回應並不是把規則打開之後就永遠不需要調整。
我在設定以前會先觀察哪些 Alert 適合自動化，設定完成後也會繼續確認實際寫入狀況。因為客戶的服務、對外連線及正常使用行為可能改變，原本適合的條件不一定永遠適用。
例如，同樣是外部風險 IP，不同 Alert 所代表的活動並不完全相同。有些只是短時間的連線嘗試，有些可能持續針對特定服務；有些 IP 的風險資訊也可能隨時間改變。因此，規則的目的不是把所有看起來可疑的來源一次封鎖，而是先限定在已經觀察、能清楚描述，而且處置影響相對可以控制的範圍。
後續確認時，我會留意兩個方向。
第一個方向是 Alert 與防火牆之間的寫入。我要知道符合條件的 IP 是否真的成為防火牆物件，並進入指定群組。如果 Stellar Cyber 顯示失敗，就需要再確認是連線、權限、設備回應，還是其他設定問題。
第二個方向是群組搬移。A 群組接收新的 IP，Python 程式再於固定時間搬到 B。這兩段不是同一個自動化，因此即使前一段成功，後一段仍可能出現問題。電子郵件中的搬移筆數與執行狀態，就是用來協助確認第二段是否正常。
實際檢查方式也會依設備與環境調整。這不是一份所有防火牆都能直接套用的固定步驟，而是我在 Sophos 防火牆環境中使用的做法。
自動寫入開始運作後，接下來遇到的是防火牆群組管理問題。
新的風險 IP 會持續進入 A 群組，但群組不可能在完全不管理的情況下無限增加。如果 A 群組持續累積物件，最後可能因為設備限制而無法再寫入新的 IP。
因此，我們使用 A、B 兩個群組：
這樣一來，IP 從 A 移到 B 之後，仍然在防火牆規則的處理範圍內；A 則可以重新保留空間，繼續接收新的物件。
當時 B 群組尚未達到上限。我們曾經想過，如果未來 B 也滿了，可以再建立 C 群組接替，但這個情況並沒有實際發生。因此，這只能寫成當時的規劃，不能描述成已經完成並驗證的三層群組機制。
A、B 群組的搬移並不是 Stellar Cyber 原生功能，而是後續依實際維運需求補上的流程。
這支程式的需求由我提出，我再利用 AI 協助產生程式碼。取得初步程式碼後，仍由我依環境調整、測試並完成部署。使用的語言是 Python，程式每天在固定時間執行，把 A 群組內的物件搬移到 B 群組。
這段經驗不是單純對 AI 說一句需求，程式就能直接放到正式環境。AI 可以協助產生程式架構與部分邏輯，但它不知道實際的防火牆設定、群組名稱、驗證方式及現場限制。這些仍需要由我確認，程式也必須經過測試後才能部署。
搬移流程中，如果物件沒有成功寫入 B，原本的資料仍會留在 A，不會因為搬移失敗就直接從阻擋群組消失。至於重複的 IP，則由防火牆本身處理，Python 程式沒有另外建立一套重複資料整理邏輯。
程式每天執行完成後，也會寄送電子郵件，通知這次搬移了多少筆，以及執行是否正常。
這封信看起來只是一個小功能，但它解決了一個很實際的問題：排程程式如果沒有任何輸出，人員可能不知道它究竟有正常執行、沒有資料需要搬移，還是早已發生錯誤。
自動化除了要會執行，也要讓人知道它執行了什麼。
除了防火牆，我也測試過 Stellar Cyber 與 Sophos、SentinelOne EDR 的回應功能。從功能測試來看，平台可以觸發相關處置。
但在真實事件中，我仍會進入 EDR 的系統頁面，確認設備與事件狀況後，再由人員執行隔離，而不是只要符合 Alert 條件就立刻自動隔離端點。
原因不是技術做不到，而是兩種處置的影響不同。
將外部風險 IP 加入防火牆阻擋群組，如果前面的規則條件經過觀察與確認，影響範圍相對容易控制。但隔離一台內部設備，可能會讓使用者無法工作、讓伺服器中斷服務，也可能影響不能任意停機的設備。
尤其在尚未確認設備用途時，直接隔離可能造成其他問題。因此，EDR 隔離即使完成過技術測試，正式事件仍保留人工確認。
這讓我逐漸理解，決定一項動作要不要自動化，不能只問「系統能不能做」，還要問：
除了直接連動防火牆或 EDR，告警本身也可以透過其他工具進行流程處理。
例如 n8n 可以依照設定條件，替 Alert 加上標籤或關閉 Alert。這能減少部分重複操作，但它處理的是告警工作流程，不一定會先確認防火牆是否成功寫入 IP。
因此，以下狀態必須分開：
Alert 被關閉，只能代表平台上的告警狀態已經改變，不能直接證明 IP 封鎖成功，更不能代表相關風險已經完全處理。
n8n 的完整串接、標籤、通知與追蹤流程，我會留到後面的 Day 28 再深入說明。這裡只先帶出一個觀念：自動化流程可能同時改變好幾個系統的狀態，但這些狀態不一定彼此等同。
回頭看這段過程，Stellar Cyber 的既有回應功能，解決了如何把符合條件的 IP 送到防火牆；AI 協助開發的 Python 程式，則補上 A、B 群組的整理需求。
兩者搭配後，確實減少了部分重複操作，但整套流程仍需要人工決定哪些 Alert 適合自動處理、規則條件如何設定，以及怎麼確認執行結果。
EDR 的測試也讓我看到另一條界線：有些動作雖然技術上可以自動執行，但一旦判斷錯誤，可能直接影響營運，所以真實處置仍需要人員確認。
對我來說，自動化的價值不是把人完全移出流程，而是讓系統處理條件明確、重複性高，而且失敗影響可以控制的動作。分析人員則把時間留給環境判斷、例外處理與結果驗證。
能自動執行，不代表所有事情都應該自動化。真正重要的是，知道哪個環節可以交給系統，也知道什麼時候必須把決定留給人。
本文中的自動化流程依據我實際接觸的環境與使用經驗整理。不同產品版本、防火牆型號、授權及客戶環境可能有不同的設定方式，實際導入仍應以產品文件與現場測試結果為準。
iThome鐵人賽
看影片追技術