資訊安全控制措施

資訊系統取得、開發與維護

2011-08-19
上次談到了ISO 27001中有關網路、作業系統、應用系統的存取控制要求,藉由部署適當的控制措施,可降低組織的安全風險,接下來將說明標準中有關資訊系統取得、開發與維護的安全要求。
對大多數的組織而言,資訊系統的獲得有兩個來源,一個是由內部人員自行開發撰寫應用程式,另一個則是由外部廠商來協助開發或提供套裝軟體。

不過,無論是採用委外服務或是自行開發,對於資訊系統所需的安全目標都是一致的,相關的安全控制目標與措施,可以參考ISO 27001附錄A.12「資訊系統取得、開發與維護」的內容,它主要有六個控制項目,依序說明如下。

資訊系統的安全要求

在A.12.1資訊系統的安全要求中,目標是要確保在導入資訊系統的時候,安全是其中必要的考量,它的控制措施為「A.12.1.1安全要求分析與規格」,主要是希望在一開始評估規劃資訊系統時,就要將安全項目納入其中。

包括資訊系統對組織整體營運的重要性為何?是否評估此一系統失效或受到入侵時可能產生的安全風險?所需要的安全防護層面有哪些?如果系統本身無法達到所需的安全強度,是否可尋求其他的配套措施來降低風險?

除了管理面之外,在技術面需要考量的項目包括,系統是否具有可自動運作的控制措施,能夠偵測出系統的異常情況;或是具有輔助性的人工控管方法,可進行參數的調整來增加安全的強度。

還有系統是否採用了合乎業界標準的開發工具和流程(例如CMMI),或是產品本身已通過安全標準(例如ISO 15408)的驗證與評估,這些也可納入採用資訊系統時的安全要求。

系統的正確處理

在A.12.2應用系統的正確處理項目中,目標是要採取適當的控制措施,讓這些與營運有關或是處理重要資訊的系統,能夠確保所處理資料的正確性,同時避免受到未經授權的修改或濫用。這個項目一共有四項控制措施,分別說明如下:

A.12.2.1 輸入資料確認
這項措施是要求針對所輸入的資料,系統能夠主動地加以確認其適切性,以避免不當輸入所產生的風險。

例如許多網站都提供了會員資料輸入或內容搜尋的功能,因此針對所輸入的資料,在內容上面可加以限制,像是價格欄位僅允許輸入數字、身分證字號只允許輸入10個字元等,透過對於數值的範圍、資料完整性、資料量及有效字元等的偵測,可避免像是資料隱碼(SQL Injection)或緩衝區溢位(Buffer Overflow)等常見的攻擊。

A.12.2.2 內部處理的控制措施
針對不當的輸入,資訊系統需要有能力加以因應,像是資料檢核(Validation Check)的功能,應該要併入系統之中,以便主動地偵測和因應處理錯誤,或是蓄意的不當行為所引發的問題。

所以程式本身需要考量設計相關的核對項目,包括像是批次處理的管控,可確保資料更新前的前後一致性;檔案總數的控制,核對資料完成之關聯檔案數值是否一致;進行程式運作程序的查核,在問題發生時可暫停下一步的處理等,這些都是實務可用的作法。

A.12.2.3 訊息完整性
要求針對所處理的資料,應實施確保訊息完整的控制措施,例如透過加密機制或雜湊函數(Hash)的應用,確保所處理資料的完整。

A.12.2.4 輸出資料確認
除了輸入資料的確認之外,輸出資料的確認也同樣重要,例如目前經常運用的地理位置查詢服務,若輸出的地址有誤,可能會讓人走到汽車不應走的鄉間小路而陷入困境,因此這項控制措施要求系統所輸出的資料必須加以確認,以符合實際可用的情況。

資訊加密與控管

針對資訊加密的控管方面,在A.12.3「加密控制措施」的項目中,目標是要藉由加密方式,確保資訊不會受到未經授權的存取、竄改和干擾,也就是要達到機密性、完整性及可用性的要求,其控制措施說明如下:

A.12.3.1 使用加密控制措施的政策
針對與營運或是個人隱私有關的敏感資訊,組織應依照風險評鑑的結果,制訂統一的加密政策,說明要採取何種加密技術或控制方法來保護這些資訊。

目前,許多組織都使用了筆記型電腦、智慧型手機等行動裝置,或是可移除式的媒體像是行動硬碟、隨身碟等,針對這些裝置的使用、授權方式及加密的作法,都應該在相關政策或作業程序中加以說明。

A.12.3.2 金鑰管理
對使用加密措施的組織而言,最重要的就是用來加密的金鑰該如何妥善的保存,因為一旦金鑰遺失或受到破壞,也代表資料可能無法繼續使用。

因此,在金鑰管理的生命周期中,從金鑰產生、分派啟用、儲存、更新、廢止到封存和銷毀等,都要有完整的作業程序作為基礎,才能達到所謂的良好管理,另外千萬別忘記了,只要是和金鑰有關的作業活動,都要保留完整的記錄,以便進行後續的安全稽核。

系統檔案與開發過程安全

針對系統檔案安全的控管方面,A.12.4「系統檔案」的控制目標是要防止系統的檔案受到未經授權的存取或修改,它具有三項控制措施,分別說明如下:

A.12.4.1 作業軟體的控制
在作業系統上進行軟體安裝,應有相關的作業程序以便加以控制。在實務方面,使用者若未經過授權,應避免在作業系統上安裝應用軟體。

特別要注意的是,許多作業系統的重大修補,像是版本升級或是Service Pack的安裝,都需要經過適當的測試,以確保穩定度與相容性沒有受到影響,才可以實施更新的動作,否則新版本的作業系統很可能會因為不穩定或是不熟悉操作,而導致其他的問題發生。

A.12.4.2 系統測試資料的保護
在系統進行運作測試的時候,應該要避免使用真實的個人資料或者是敏感資訊來進行,這已經是老生常談的作法之一,這項控制措施即是要求需要小心選擇並且保護用來測試的資料,以避免資料的外洩。

所以,在測試時要注意所使用的資料是否已經過授權取得,資料本身是否已剔除或替代敏感性的內容,在測試完成之後,是否已經徹底將資料從系統中清除。

A.12.4.3 程式原始碼的存取控制
程式原始碼的重要性,對資訊系統來說無庸置疑,因此原始碼的存取必須受到嚴格的管控。

一般而言,原始碼會集中並儲存在特定地點(Source Libraries),控制措施則包括了是否已建立作業程序、是否設定存取權限、是否保存在安全的環境等,即使是程式開發人員需要取得程式原始碼並進行更新,也要先經過授權,並依照作業程序才可進行。

在A.12.5「開發與支援過程的安全」控制項目中,目標是要能有效維持應用系統本身和所處理資訊的安全,其控制措施說明如下:

A.12.5.1 變更控制程序
針對資訊系統的變更,需要制訂正式的變更程序才可進行,也就是說,重點在於整個過程都需要有適當的監控,因此最好的作法是參照文件化的變更作業程序,同時依據之前A.10.1.2變更管理的相關要求來實施。

A.12.5.2 作業系統變更後的應用程式技術審查
在A.12.4.1曾提到作業系統軟體的更新不當,可能會引發安全問題,因此這項控制措施要求在變更之後,需要進行審查測試,以避免影響到組織作業或其他關鍵系統。

換句話說,只要有系統進行變更作業,就要對應到後續的技術審查,所有更新作業與運作情況,都要留下適當的記錄才行。

A.12.5.3 套裝軟體變更的限制
組織若是使用廠商所提供的套裝軟體,這項控制措施建議應盡量避免相關套件的修改,所進行的變更活動也要加以嚴格管控。

因此實務上若需要修改軟體套件,首先要徵詢相關廠商的意見,並且評估變更之後的後續維護要如何進行,以避免產生安全漏洞。

A.12.5.4 資料外洩
許多資訊系統為了方便維護,開發者可能留下後門或隱密通道,這些可能會是資料外洩的管道之一,在實務上要完全加以防堵是非常困難的。

比較可行的作法為在系統上線前進行系統掃描,確認是否有不當的訊息外送或開放的傳輸埠,另外也要監測系統資源的使用與網路活動,以防範資料洩漏的事件發生。

A.12.5.5 委外的軟體開發?
組織若選擇委外廠商來進行軟體開發,就必須要加以適當的監督,確認遵守組織的安全政策要求,這部份可參照A.10.2第三方服務交付管理的要求來實施,實務上也建議組織將安全要求明列在所簽訂的委外合約之中。

技術脆弱性管理

在資訊系統取得、開發與維護的要求方面,最後一項控制項目為A.12.6技術脆弱性管理,它的控制措施是A.12.6.1技術脆弱性控制,因為資訊系統本身並非十全十美,需要定期或及時地加以修補,這項控制措施就是要求能夠及時取得和弱點有關的資訊,並採取對應的行動來降低因已公布的安全弱點而遭受到不必要的攻擊。

建議的適當作法為建立一份完整的資訊資產清冊,詳細記載系統的相關資訊,例如版本、廠商、部署狀態、負責人員等,並與廠商保持溝通連繫,以掌握系統的安全現況。

參考資料
1. ISO/IEC 27001:2005
2. ISO/IEC 27002:2005

(本文原載於網管人第67期)


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!