從最近發生的個資外洩事件，例如國內「玉X銀1.6萬筆個資外洩，重罰400萬」與國外「SONY PSN用戶資料外洩近一億筆，善後至少耗費1.71億美元」及「花旗（Citigroup）系統被駭，36萬持卡人受影響」等，引起業界紛紛討論如何因應，以防止個資外洩而要負損害賠償責任。
需求階段就納入安全考量
個資是以紙本或電子形式（資訊系統）存在。針對電子形式的個資外洩問題，其「防範於未然」之對策，即是發展一套具品質又較安全的資訊系統。而所謂具品質又較安全的資訊系統應涵括那些層面？依據ISO/IEC 12207-2008之定義，資訊系統由一組彼此互動之系統元件組合而成，系統元件可為硬體、軟體、資料、人員、流程（例如提供服務予使用者之流程）、程序（例如操作說明）、設施、材料和天然實體（例如水、生物、礦物）或任何組合。依此定義要發展一套較安全的資訊系統，需要考慮的層面包括資訊系統本身之應用系統、軟體及硬體的安控機制、使用者的行為習慣、操作人員的資安認知與管理規範及資訊系統的安全操作等，須於開始討論需求時，就將上述各個層面之安全需求納入考量，爭取適切的預算、資源與人力，再進行後續系統發展等相關活動。
|
新個資法影響企業營運的三大改變
個人資料保護法於去年5月26日總統公布，其中影響企業之重大營運有三：首先，在無法確認損失金額時，最高賠償限額為新台幣二億元。其次是中央與地方機關都有對企業執行個資實施狀況檢查權與罰鍰權。再者為符合既定要件之財團法人或公益社團法人，可以提起集體賠償訴訟。若損害造成時，企業能舉證非其組織造成者，則免賠償。受檢企業未依照個資法規定實施，則企業要繳交罰鍰最高為50萬元，其代表人要連帶被罰，以及公布企業名稱、負責人姓名與違法情形。關於集體訴訟，目前已知有律師團或相關財團法人準備或已備妥受理賠償訴訟之資格，並向其客戶或會員說明在個資法施行後，可以為他們提供該項服務。前述三事項，若企業可以按照個資法要求實施，並在事件發生時，舉出證據，證明該企業已妥善保護客戶之資訊且該事件非其所為，則該企業必取得客戶之信任而商譽提升。反之，當企業發生上述任一事項，若再由客戶於媒體或網際網路披露，像「塑化劑事件」一樣，則對該企業之業績、營運及聲譽影響甚鉅，企業不可小覷。
|
要如何發展一套具品質又較安全的資訊系統？茲以美國司法部的系統發展生命週期指引的十個系統發展階段為基礎，再參考美國標準與技術研究院(NIST)的NIST SP 800-64之安全管控工作項目與NIST SP 800-27之資訊技術安全原則以及行政院研究發展考核委員會之「資訊系統風險評鑑參考指引、安全控制措施參考指引及Web應用程式安全參考指引」，整理安全的資訊系統發展生命週期（Secure-Systems Development Life Cycle, S-SDLC）相關活動，協助大家發展較安全的資訊系統，以因應日趨嚴重之個資/資安事件及個資法之施行。
開始說明S-SDLC相關活動之前，先瞭解資訊系統的品質要求，根據ISO/IEC 25010-2011（註六）規範，資訊系統的產品品質模式（如圖1）包括八種特性：功能適用性、性能效率、兼容性、可用性、可靠性、安全性、可維護性及可移植性，大家熟知的資訊安全特性分別於可靠性的一個子特性—可用性與安全性的五個子特性：機密性、完整性、不可否認性、可歸責性及真實性。由此可知，若符合安全要求的資訊系統，則已具備品質的特性。
.JPG)
圖1、產品品質模式Product Quality Model (圖片來源：作者提供，2011/9)
將個資保護融入安全系統生命週期
S-SDLC包括十個發展階段（如圖2）：啟始、研析與預算編列、規劃、需求分析、設計、開發、整合與測試、建置/移轉、運作與維護、處置。各階段與個資管理及保護相關工作項目略述於後：
圖2、S-SDLC安全的資訊系統發展生命週期 (圖片來源：作者提供，2011/9)
階段一、啟始
資訊人員與業務單位人員需從個資法與相關施行細則面向，討論系統新增業務功能、既有業務流程問題、個資/資訊安全政策（以下簡稱政策）及指引等要求，確認此業務需求之業務負責人、專案經理及專案團隊，將前述業務需求的範圍、預計達到的目標與目的、現狀、與組織業務目標與方向的關係、可能的解決方案（自製或外購）、節省成本或提升效率資訊及可能的經費需求等撰寫成「業務需求概述」文件，以供審核。
階段二、研析與預算編列
依據前一階段審核過的「業務需求概述」，作進一步的分析與研究，略述於后：
（一） 對業務面與系統面作進一步的研究與分析時，需考慮個資法與相關施行細則及政策規範，以解析使用者之功能與資訊需求、現有系統可支援此新需求之狀況及新需求欲達到的業務目標及其績效衡量機制。例如，就已上線個資含量高的系統，因應個資法要求而新增客戶個資修改更新的功能等。
（二） 運用「資訊系統風險評鑑參考指引」之高階風險評鑑作法（註七），決定系統之風險等級為「高、中或普」，然後參考「安全控制措施參考指引」選擇相對應的安控措施。再以個資管理與保護的向度，依「隱私衝擊評鑑(PIA)檢核表」（以下簡稱PIA檢核表），檢視使用者需求是否符合相關個資法規與政策；若有未符合的狀況，則須視情況執行相關風險評鑑，再檢視所選取的安控措施是否已涵蓋個資之風險。若否，則再加適切的安控措施，並修訂相關需求文件。再執行業務衝擊分析，以瞭解系統可用性需求。在進行隱私衝擊評鑑時，除了符合個資法母法及施行細則規範外，此專案需求也應參照與整體IT架構的關係。例如資料傳輸的加密，若是透過IT基礎架構來達成，也就不一定要在此專案開發的應用系統上做加密。
（三） 將前述業務面、系統面、個資法規、政策及安全控制措施的需求彙整，參考NIST資訊技術安全原則，進行系統架構規劃、可行性與成本／效益分析、實施時程研擬、專案採購策略確定、所需的人力與資源規劃、專案風險分析及專案績效衡量指標訂定等。然後，根據前述彙整要項，進行成本預估，再編列預算，以完成業務投資計畫（1~3年）或系統功能新增計畫，並通過審核以進入下一階段。
階段三、規劃
計畫通過之後，資訊人員開始規劃第一階段或當年度的專案工作。首先成立專案團隊，確認需要的人力資源，以進行相關規劃工作。再研擬專案需求或招標需求文件、採購計畫、專案管理計畫、建構管理計畫、品質保證計畫、驗證與確認計畫及系統安全計畫，以妥善規劃專案相關活動，及早發現可能的問題並提出應對方案，以確保系統符合使用者、個資法規及政策需求。其中系統安全計畫為整個系統發展過程所需要的安控資源、人力及機制等之規劃，包括：
(一)、 系統特徵：描述系統名稱、主要負責人員與職責、系統類別、系統運作狀態、系統功能說明與目的、系統環境說明、與其他系統介接／資料分享及此系統遵循的法規或規範等。
(二)、 系統處理的資料：說明需要受保護的資料名稱、資料組成（欄位）與機密性、完整性及可用性的等級。
(三)、 整個系統發展生命週期之安全管理：包括個資隱私衝擊評鑑、風險評鑑與管理、資料存取規則、說明各類別使用者的存取權限管控描述、在整個系統發展生命週期之安全管理相關的工作項目說明等。
(四)、 運作安控措施：說明人員之資歷、實體環境保護機制、資訊（虛擬）環境保護、說明資料進出正式上線系統（環境）的管控機制、緊急應變規劃、應用系統之管理、安全認知教育訓練及存取管控與行為監控機制等。
審核此規劃文件時，個資管理與保護及資安向度，係依據前一階段確定之安控措施、PIA檢核表及NIST資訊技術安全原則檢視，以確保相關需求已在此文件中呈現。若有需求未符合的狀況，則須視情況執行相關風險評鑑，建議適切的安控措施，並修訂相關文件。
階段四、需求分析
資訊人員分析使用者所需功能與非功能性之輸入、處理及輸出需求。其中非功能性需求之安全管控部分，係依據前述「系統安全計畫」之內容或招標文件及與客戶訪談內容，進一步分析其詳細功能，並撰寫於功能需求規格文件中。審核此需求文件時，係依據系統安全計畫或招標文件內容、PIA檢核表、NIST資訊技術安全原則及「Web應用程式安全參考指引」之安全需求規範檢視，若有不符須執行風險評鑑，採取對應措施並修訂需求文件。再依據「驗證與確認計畫」研擬「完整測試計畫」，以規劃系統發展過程中之相關測試活動，以確保系統符合需求規格文件及滿足使用者的需求。
階段五、設計
依據功能需求規格文件，進行系統設計。以「功能需求規格」設計應用系統架構，可參考Web應用程式安全參考指引之安全軟體設計控制措施，檢視Web應用之安全控管是否已考慮周全。以「非功能性需求規格」可參考NIST資訊技術安全原則，並整合於系統設計規格文件。審核此設計文件時，須確認個資相關資料流（Data Flow）之安全管控機制是否與需求規格文件所述相符，若有不符同樣須執行風險評鑑，採取對應措施並修訂設計文件。在此階段亦須完成系統開發環境建置、撰寫與審核使用者手冊、系統管理手冊及系統建置／移轉計畫等。
階段六、開發
依據設計規格文件與程式語言編碼原則，撰寫程式。於開始撰寫程式之前，先實施安全程式編碼原則與常見編碼錯誤課程教育訓練，以提升程式撰寫人員之資安認知並防範已知的錯誤。其中Web 應用程式之安全控制措施可參考Web應用程式安全參考指引之Web 應用程式安全檢核表中相對應之安全基準，檢視程式之完整性。運用安全程式碼分析工具，尋找Web-based程式之資安弱點與確認是否有惡意程式碼存在，並改正之。另需以人工檢視方式，確認非Web-based程式是否有惡意程式碼存在。在此階段尚須完成教育訓練教材與緊急應變計畫撰寫與審核等。
階段七、整合與測試
依據「完整測試計畫」建置測試環境、執行相關測試活動及管理測試所找出的問題。測試活動包括整合測試、安全測試、系統功能測試及使用者驗收測試，其中安全測試包括系統弱點掃瞄、原碼檢測或網頁弱點掃瞄等，以找出系統與原始碼的弱點及是否有惡意程式碼存在，並要求改正。以「建構管理計畫」之要求，控管此系統的軟、硬體及應用系統的原始碼與文件之版本。
階段八、建置／移轉
依據「系統建置／移轉計畫」執行系統建置與移轉，通知使用者系統上線相關事宜、實施系統管理者與使用者教育訓練、執行資料輸入或轉換、依據相關文件建置系統並確認系統運作正常。若有非預期狀況發生，則須視狀況進行風險評鑑，以建議適切安控措施因應。最後，召開系統上線狀況報告會議，審視執行狀況，並做成紀錄，以作為後續其他系統上線之參考。
階段九、運作與維護
系統正式上線後，需指派維運人員與規範相關職責，開始維運系統。定期備份資料與系統軟體、監控系統運作狀況、執行資訊安全風險評鑑，並視情況進行因應措施。處裡使用者的諮詢、問題回報及變更需求。當有變更發生時，更新應用系統、軟體或硬體，須重新建baseline，再評估資訊安全風險，以採取相對應措施。若有公布新版個資法規，則須執行隱私衝擊評鑑，再作個資風險評鑑，以採取因應措施。當有重大個資／資安事件發生時，應啟動「緊急應變計畫」以即時因應，確保系統持續營運不中斷。
階段十、處置
準備系統處置計畫，以妥善處理處置事宜。依照計畫執行資料歸檔或轉換資料、歸檔或轉換系統軟體、將相關儲存媒介消磁、歸檔系統相關文件及結束系統運作。若有設備不再使用時，須妥善處置，以防範資料外洩。最後，召開系統下線狀況報告會議審視執行狀況，並做成紀錄，以作為後續其他系統下線之參考。
綜合前述十個階段所描述的安控活動，從啟始、研析與預算編列起至運作與維護及處置，業務單位、高階主管、資訊單位主管、基層主管、系統管理人員、承辦人員及使用者，均要投入系統發展活動，貢獻心力，始有機會發展一套「具品質又較安全的資訊系統」，且在較安全的環境運作，即可降低個資外洩的風險，提供予客戶既安全又安心的服務。尤其應在研析與預算編列階段就先納入隱私衝擊分析，將個資風險考慮進去。若是在設計階段，才使用威脅分析模型，恐怕委外開發的系統已經發包出去，可能須另案處理安控需求，不僅整體成本會提升，還會造成專案延遲，無法及時遵循法規要求或符合業務目標。
資訊系統的漏洞未及早發現與及時補強，只是表面的現象，細究事件造成原因，多半會發現該資訊系統在規劃、設計或開發之初就未考慮個資與資安保護之需求，已先天不足，故而要求強化資訊系統運作環境的安全與人員之資安意識提升，以補其不足之處。「亡羊補牢」雖為之不晚，但若能事先「防範於未然」，則對企業與客戶都是最好的因應之道。
本文作者任職IT軟體服務業，擁有資安輔導顧問多年經驗。如您對本文有任何感想，歡迎來信交流：isnews@newera.messefrankfurt.com