神明的故事是會被宣傳和流傳許久的。
曾經有幸坐上台中的一部計程車，一路上和司機大哥寒暄，跟我介紹起他的另一個的身分—馬祖轎班。他說起一個關於神明的故事。
故事中的主角，是一位家喻戶曉的大人物，後來因為犯了一些案件去坐牢。司機大哥說，他在某次參與媽祖遶境時，印象中有這麼一位人物，跟著民眾貴在媽祖轎前，等待從轎底鑽過去的那一刻。但不知怎麼神轎來到這人面前，就突然來了個大轉彎。又連續幾天過去，司機大哥說這人似乎都換了不同衣服，不死心地在遶境的路線上等著鑽轎底，但神轎總是在最後一刻就轉身離去，似乎不想保佑這號人物。後來，司機大哥才意識到，此人正是公司做了違法事情而被法院判處刑責和罰金的某集團董事長。
因為曾見識到真實的神蹟，我從司機大哥的話語間感受到堅信與虔誠。這就讓我想起「資安」，只不過資安沒有所謂的神蹟故事，只有「事故」，事故也最常讓人拿來說三道四，甚至也會流傳許久。尤其在近幾年，上市上櫃企業依照法規《**臺灣證券交易所股份有限公司對有價證券上市公司重大訊息之查證暨公開處理程序》與《財團法人中華民國證券櫃檯買賣中心對有價證券上櫃公司重大訊息之查證暨公開處理程序》**的要求之下，只要發生嚴重的資通安全事件，就有義務讓相關關注方知情，公司的資安事故彷彿變成家喻戶曉的災難。
過去我們談論到「從AWS資訊安全事件中學習」，已經可以理解資安事故的處理流程，先要建立事故管理的團隊與方式，這其中就必須合乎法規的要求，包括必須要在「時限內」公開相關資訊。部分的組織在發生狀況的第一時間，其實無法快速得知災害影響的範圍，可能連哪些系統被攻擊、多少資料外洩都不一定清楚。
舉例來說，多數製造業有著「企業資源規劃(ERP)系統」，系統中一定儲存許多生產、財務、庫存的資料，甚至會與其他系統相介接。因此，資安事件管理的事前準備工作建議優先盤點資訊資產，特別存在於ERP系統中的資料，其次是相關聯的應用軟體和硬體設備，再次是相關聯的服務介面，這些介面的形式可能是網路甚至是雲服務。資產盤點完畢後，就可以掌握資產間的關聯，以及其發生安全事件後的相互影響。
從上例的觀點而言，資安事故管理其實是基於對於資訊資產的安全去做維護，也就是設法維護資訊資產的機密、完整及可用，避免資料遭到未經授權存取或破壞，所以資安首要條件便是做好資訊資產的盤點及鑑別其重要價值，而以 ISO 27001 來說分別是 A.5.8資訊及其他相關聯資產之清冊 及 A.5.12資訊之分類分級 兩個條款。
一般人不曾想過會在媽祖遶境時看到神蹟故事，但一定都不想在自己的組織中見到資安事故發生。如果您的組織已經在努力維護好資安，不願讓資安事故發生，那麼請再回頭檢視自身的資訊資產清冊是否有落實盤點，以及落實應有的資產保護機制。資安將不只是期待神蹟的信仰，也不再是含糊的口號，而是逐漸貼切地「親民」與「落地」。
作者：潘柏廷 Conrad Pan
現職：亞瑟國際驗證專任資安技術專家，資深資安教育者，曾任資安輔導顧問，專長領域為資安、個資、人工智慧
