工程師思路系列・事出必有因

資安診斷,不是回答「安全不安全」
把不確定的現場,整理成可以行動的知識

「我們公司,到底安不安全?」

這是一個看似簡單、實際上很難回答的問題。難的不是技術,而是問題本身的形狀:它預設了答案只有兩種。

這篇想談的,是一份資安診斷應該怎麼思考:它該看什麼、該承認什麼、該把讀者帶到哪裡。

資安不是二元問題

如果答案只能是「安全」或「不安全」,那麼幾乎所有企業都會落在「不安全」,而且會一直停在那裡。因為從「不安全」走到「安全」的距離看起來太遠、太貴、太模糊,遠到讓人不知道從哪裡開始。

更有用的問法是:現在的暴露在哪裡?哪些已經處理了?哪些還沒有?下一步處理哪一個,最值得?

問題的形狀一改,答案就不再是一個判決,而是一張可以往前走的地圖。

從設備清單,看見暴露地圖

企業主未必熟悉「勒索軟體」「殭屍網路」這些名詞,但一定知道辦公室裡有什麼:幾台電腦、一台 NAS、門口的監視器、角落的事務機、機櫃裡那台分享器。

這份清單,是企業主看得懂的世界。

工程師要做的,是把它翻譯成另一張圖:每一台設備可能怎麼被接觸到、它接在網路的哪個位置、它出事時會牽動什麼。好的診斷,就是把「設備清單」翻譯成「暴露地圖」的過程。

事出必有因
企業主感受到的,常常是症狀:網路變慢、信箱被停、檔案打不開。真正的暴露點,往往在好幾個環節之前,在一台沒人管理的設備、一組從沒改過的密碼、一條沒人記得的網路線上。暴露地圖的價值,就是讓症狀與根因之間的路徑變得看得見。

不要只問防了多少,要問還剩下什麼

談資安時,最常見的思考方式是產品思維:這個盒子可以防什麼?

另一種是風險思維:裝完這個盒子之後,還有什麼是它處理不了的?

兩種問法看的是同一件事,得出的結論卻完全不同。產品思維容易走向「買了就完整」的錯覺;風險思維則會自然推導出:每一項控制措施都只改變了一部分風險,剩下的部分,需要另一項措施、另一筆預算、另一段時間。

所以一份誠實的診斷,不會只列出每項措施的能力,而是讓讀者看到:一項一項累加之後,剩餘風險如何逐步下降,以及最後仍然剩下什麼。資安無法做到零風險,目標從來都是在合理的預算內,把風險降到可以接受的範圍。

延伸閱讀:Cyber Kill Chain 的視角
Lockheed Martin 在 2011 年提出的 Cyber Kill Chain,把一次入侵拆成七個階段:偵察、武器化、投遞、漏洞利用、安裝、命令與控制、達成目標。攻擊必須一環扣一環才能成功,防守方只要在任何一環切斷,攻擊就會中止。
用這個視角看,「防了多少」就是一項措施切斷了哪幾個環節;「還剩下什麼」就是哪幾個環節還沒有任何措施能切斷。每多導入一項措施、多切斷幾個環節,就是縱深防禦的意思。
這個框架也有自己的邊界:它以惡意程式入侵為原型。攻擊者若直接用外洩的合法帳號密碼登入,就會跳過投遞、漏洞利用、安裝這幾個環節,專門防守這幾段的措施完全看不到。框架本身,同樣需要知道自己看不到什麼。

好的診斷,必須知道自己不知道什麼

診斷有兩種邊界,常常被混在一起談:

邊界 它描述的是
做不到 工具與措施的能力邊界:某一項防護,本來就處理不了某一類問題。
還不知道 我們對現實世界的認知邊界:從描述推得出「可能」,但要到現場才知道「是不是」。

承認「做不到」,是對讀者誠實;承認「還不知道」,是對方法誠實。後者更難,也更重要。

一份根據企業自行描述所做的診斷,能推論的是「這類設備、在這類條件下,可能形成什麼暴露」。至於那台設備的韌體版本、管理介面有沒有對外開放、帳號密碼是誰在管,這些在沒有實際確認之前,都只是合理的假設。把假設寫成結論,診斷就越界了。

這不是保守,而是工程判斷的基本紀律:知道自己的觀測邊界在哪裡。

把未知,整理成值得確認的問題

承認未知之後,下一步不是停下來,而是把未知轉換成問題。

「這類設備可能存在風險」不是結論。真正有用的下一句是:什麼資訊,可以讓我們確認它到底有沒有暴露?

✔這台設備的管理頁面,從公司外面連得進去嗎?
✔它的密碼是誰設的?最後一次更換是什麼時候?
✔公司的備份,上一次實際還原測試是什麼時候?
✔曾經出現過的「網路怪怪的」,後來有找到原因嗎?

每一個問題,都有明確的方式可以回答。這樣一來,診斷就從一份靜態的報告,變成一段認知的過程:能判斷的先判斷,需要確認的,整理成清楚的問題留下來確認。

判斷,而不只是排序

列出所有風險、依高低排好順序,是管理工具會做的事。工程判斷要回答的是另一組問題:

✔這個風險,現在值得處理嗎?
✔處理它需要什麼?錢、時間、還是習慣的改變?
✔這項措施做完,實際會改變什麼?
✔做完之後,還有哪些部分沒有被處理?

判斷也包括決定「現在不說什麼」。工程師能列出的選項很多,但對一位時間有限的企業主而言,選項太多本身就是一種阻力。與其攤開所有可能,不如清楚指出第一步,其餘留待條件成熟時再談。專業有時不是展示知道多少,而是替對方判斷,他現在需要知道什麼。

改善不是結案,而是再看一次

資安最常見的誤區,是把它當成一條直線:發現問題、買東西、部署、結案。

但每一次改善,都會改變現場。新的控制措施會讓原本看不見的東西浮現,也會暴露下一層原本被掩蓋的問題。所以真正的流程是一個循環:

1 看見:把設備清單翻譯成暴露地圖。
2 理解:分清楚哪些是推論、哪些已確認,把未知整理成問題。
3 判斷:決定什麼值得現在處理、處理後會改變什麼。
4 改善:採取措施,並清楚知道它沒有處理到的部分。
5 再看一次:重新觀察,發現新的未知,回到第一步。

這個循環其實不只適用於資安。它是一種更普遍的工程改善哲學:把不確定的現實,一輪一輪地轉換成可以做決策的知識。資安只是它最需要被認真對待的場景之一,因為在這裡,停在原地的代價,通常要等到出事那天才看得見。

延伸閱讀:與 NIST 網路安全框架 2.0 對照
這個循環不是新發明。美國國家標準暨技術研究院(NIST)在 2024 年發布網路安全框架(CSF)2.0,並另外出版一份給中小企業的快速入門指南(SP 1300),對象正是資安計畫很少、甚至還沒有的企業。對照起來:
看見對應「識別」功能的資產盤點(ID.AM):先知道企業依賴哪些硬體、軟體與服務。
理解對應風險評估(ID.RA):評估這些資產可能存在的弱點。
判斷對應 2.0 版新增的「治理」功能:風險要處理到什麼程度、先處理哪一項,是經營者的決策。
改善對應「保護」等功能中的具體措施。
再看一次對應 2.0 版新增的「改善」類別(ID.IM):資安是持續進行的工作,要不斷重新評估。
CSF 也不是一張有及格線的檢查表。它用「現況輪廓」與「目標輪廓」描述企業現在在哪裡、要往哪裡去,這正是第一段「資安不是二元問題」的意思。
同樣要誠實標出邊界:CSF 2.0 共有治理、識別、保護、偵測、回應、復原六大功能,本文談的方法論主要落在前幾項;事件發生之後的回應與復原,是另一個需要專門準備的主題。給企業主使用的自檢,也刻意不使用這些術語,而是從他認得的設備清單起步,先把啟動門檻降到最低。

資安診斷,不是替企業回答「安全不安全」。
而是讓企業知道:
現在知道什麼、還不知道什麼,以及下一步值得做什麼。
Mr. τ|風雲網通系統有限公司 PCPiLOT
#資安診斷 #風險思維 #剩餘風險 #NIST_CSF #CyberKillChain #工程師思路 #事出必有因
Last modified: 2026-09-25

Author

Comments

Write a Reply or Comment

Your email address will not be published.