https://newera17031.activehosted.com/index.php?action=social&chash=ba1b3eba322eab5d895aa3023fe78b9c.2767&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=ba1b3eba322eab5d895aa3023fe78b9c.2767&nosocial=1

觀點

牽一髮而動全身

2009 / 07 / 06
DAVE SHACKLEFORD  譯 ■ 左恩燦
牽一髮而動全身
拙劣的變更控制會使你組織的安全整個地傾覆。以下5個步驟告訴你,如何發展一個變更管理計畫。

  凌晨2點,詭譎的活動在主要的網路裝置上演,觸發了網路操作中心的警報器。你正在封鎖Telnet服務,以及從外部進入此網路的連結,因為這個活動是不應該發生的。15分鐘快速地拼湊出答案後,你發現那些連結根本沒有被封鎖。原因是,前幾天有人為了幫供應商的技術人員取得網路存取權限,而作了設定上的改變,因此,無心地把你推入了夢魘中。

  這個極其簡單的例子說明了一個重點:不適當的變更控制,是許多安全經理頭痛的根源,且經常發生。把網路封鎖非常困難,因為網路是不停流動的:它必須實施修補更新,合作夥伴必須取得存取權限,而且還需要提供新的服務。一個未經管理的變更,會使網路上那一排乾淨俐落的封鎖列整個傾覆。

  變更管理對安全經理來說,意指許多事情。就某方面來說,變更管理是指,它能夠使程序都各就其位,在IT環境中進行變更,例如新的防火牆規則,或是路由器存取控制進入權清單,以及系統更新等。這個程序包括認可、測試及排程。然而,IT安全團隊經常會把變更管理的概念,與組態的控制與管理畫上等號,包括像是資料完整性的監控與系統掃描等活動。雖然它們的概念不同,但是對安全都十分重要,而且變更管理與組態管理之間的關係也愈來愈強。

  安全的挑戰是,當他們所控制的系統與裝置,正在展開變更與組態管理程序時,能將安全本身整合至現存的IT變更管理程序中。組織必須將安全涵蓋進來,以協助進行系統變更,並且為營運管理的相關風險提出建議。現今,安全要在組織中佔一席之地是比較容易的,因為組織能理解,有些IT上的變更可能會帶來一些風險。

  然而,安全人員必須扮演一個值得信賴的顧問,而不是一個不管變更可不可行的發號施令者,並且能夠表示與老闆共進退的工作意願,促進企業宗旨。

  為了發展良好的變更管理計畫,讓我們用5個重要步驟來檢視安全角色。

1.要求與審批

變更管理程序的最初階段,是變更的要求(request)或RFC (Request for Comments)文件的要求。大部分的情況是,它會被放到變更管理應用中,成為其中一部分,並且被提交至變更諮詢委員會(CAB,change advisory board)列入考量。通常,此委員會包括幾個典型的代表人物,來自諸如客服支援、網路操作、伺服器與系統管理、安全、內部稽核、資料庫管理與應用程式發展等部門。其他成員可能還有代表法律、營運,以及行政等部門。

  一旦CAB准允RFC進入程序,就必須通過一連串的審批(approval),它會讓所有相關的「利益攸關者」決定此變更是否應該執行。資訊安全團隊應該涉入審批程序裡,並考量變更對企業可能造成的風險後,作批准的決定。此初階的變更管理程序應該有一個內建的訊息回饋迴路,這樣審批工作流程上的人員,就可以向請求變更者詢問問題,或是與其他相關人員討論變更後所產生的其它問題。

安全人員必須:

. 確保要求的來源有根據:透過檢查使用者帳戶與資料庫、身分管理系統與記錄檔案等,通過驗證與授權請求改變。


. 為變更要求建立稽核存底(audit trail):誰提出變更要求,誰登入變更管理系統去檢查變更,與審批程序相關人等有誰,誰為變更作了註解等。

  安全團隊在實施他們自己的系統變更,如IPSes與防火牆時,為RFC文件提供了重要資訊,包括技術上必須作的實際變更,系統會作的改變,以及在這個環境中,對那些或其它系統可能產生的風險等。而非起因於此變更佈署的潛在風險,也應該被記錄下來。

2.計畫與測試

  變更管理的計畫階段,正是對所提出的變更,進行真正詳細檢查的階段。在此階段,變更對組織風險可能產生的影響,安全團隊必須進行詳細地評估。例如,安全人員可能因為決定准許合作夥伴的網路存取權限,而替重要資源帶來新的威脅,或者因為某些已知的弱點,導致軟體佈署產生風險。

  計畫的佈署與取消應該由提出變更的人,以及其他與此佈署相關的小組提供。這些也應該被安全人員列入仔細評估,以確保那些計畫是符合組織政策、而且合理的。而與安全相關的變更,計畫階段應該同時包括人員判斷,這一點也必須被涵蓋至變更計畫中,而且需有特定的標準以決定計畫是否取消。

  測試階段包括實驗測試、變更或取消計畫的模擬。與實驗測試有關的標準組織政策或作業流程應該被遵守,而且測試結果也應該對CAB成員報告。因為對其他小組應用系統的變更,安全團隊在標準的功能測試完成之後,經常會執行一些風險評估。例如,可能會對新系統或應用程式進行弱點掃描。安全團隊測試他們自己所作的變更或對安全裝置與應用程式的取消計畫時,也應該遵循實驗測試流程。

計畫與佈署小妙招

要從頭開始發展一個變更管理計畫,是很棘手的
工作,但是組織仍然可以按部就班地順利佈署。


  當企業從頭開始發展一個變更管理計畫時,常常會面臨很多使人挫敗的挑戰。有效的變更管理,仰賴於合理準確的系統與應用程式的目錄編制,同時,有資產與資料優先排序的資料分類計畫將很有幫助。建立系統目錄與實施資產與資料分類是很複雜的,而且經常都是冗長乏味的苦差事。因此,既然變更管理是一種與整個IT部門有關的紀律問題,那麼有政治口水戰也是很平常的。以下這些步驟可協助完成計劃與佈署:

  擅用你的資料分類或其他的資產管理計畫,將最緊要的與具潛在風險的資產,按優先順序處理。開發一個主要的資產與系統組態資料庫,用來追蹤記錄。例如,被用在ITIL架構中組態管理佈署的組態管理資料庫(CMDB, Configuration Management Database)。

  定義變更項目或變更型式需被妥善管理;相對於那些不需要被管理者。例如,新增一個新的使用者帳戶到Active Directory目錄服務中,可能不需要一個完整發展的變更管理程序,但是,假如是新增一個規則至防火牆,那麼就有此需求。

  確定公司老闆與股東(或利益攸關者)誰將參與此流程,並且設立一個變更諮詢委員會。考量法規遵循。假如你必須對一個或更多的規範負責,對所有在變更管理工作流程中的相關人員來說,確保變更對現存的管控與文件將產生的影響或衝擊,是不可或缺的考量。

  有幾個架構可以提供變更與組態管理指導方針。ITIL對管理IT操作與基礎架構,涵蓋了詳細的指導。雖然ITIL被批評太過於複雜,佈署也很困難,有些專家建議,可以ITIL的變更管理元件為基礎,來啟動ITIL的佈署。


3.排程與討論

  排程變更很簡單。所有有利害關係以及會受影響的部份,都應該確定那些變更都有列入排程,並且在適當的時間施行。許多企業會有標準變更視窗(standard change windows)的設置,而且這些視窗無論何時都必須是可被利用的,通常是在深夜或清晨,較少人工作以及很少業務在運作的時間進行。

  有效的溝通是非常重要的。負責佈署變更計畫的團隊,必須以E-mail與電話溝通,說明正在進行的變更,並指出進行變更的時間。誰應該被通知,各個組織有所不同,但絕佳的作法是,通知事件回報團隊名單中的每一個人,亦被稱為“call tree”。安全團隊必須被告知即將發生的變更,包括IT維運團隊與其它可能受影響的小組。如果是安全防護變更的話,安全人員必須告知每一個人。

4.執行佈署

  在此階段中,變更是根據計畫而實施的。安全團隊人員如果不是有一個標準的待命輪調制,隨時有人戒備,就是會執行變更,假如與安全系統或應用程式相關的話。任何變更都應該被視為有可能招致重大的安全風險,或是當關鍵應用系統進行變更時,必須嚴謹地監控。同時,在變更期間,可能的話安全團隊應善加利用監控的解決方案,像是入侵偵測系統 (IDS) 。

  由於變更是有不確定性的,或是有取消的可能,在人員下班期間出現變更視窗,這時要聯繫到工作同仁是有困難的,因此某些職位的安全人員應該隨時待命,這一點極為重要。

3大類變更管理工具

有幾個產品可協助變更與組態管理進行的更流暢。

  有幾種工具可執行集中式的變更與組態管理功能。第1類有些是將傳統的修補更新管理與組態管理結合,透過可將系統與應用程式編列清單的代理程式或裝置,來安裝或監控修補程式更新,並且控制組態的細節。這些工具包括BigFix Enterprise Suite(BES)平台、Configuresoft公司的Enterprise Configuration Manager (ECM)、Kace的KBOX系統管理裝置、BladeLogic公司的 Operations Manager,以及Lumension公司的PatchLink系統等。

  其他的工具是有關政策管理與組態監控,可執行檔案完整性的監控,以及在組織特定裝置環境下執行政策。組織將參考基準的組態(baseline configurations)進行定義,規劃至政策裡,而且一旦實施,這些工具會對變更進行監控。這些工具也可以在政策的原則下,發出警報通知或是自動化組態設定與矯正。工具包括Tripwire Enterprise、nCircle公司的Configuration Compliance Manager與Solidcore S3 Control。

  第3種包括傳統的變更管理產品,它們可以整合客服支援的故障單(help-desk ticketing)、變更要求與審批工作流程工具,以及內建的稽核功能。工具包括BMC的 Remedy、HP的Change and Configuration Center,以及IBM的Tivoli hange and Configuration Management等解決方案。


5.文件管理與後續行動

  所有變更動作均留下記錄文件,對維持一個有效的稽核存底非常重要。所有的組態變更必須被儲存至中央資料庫,還有核准認可資料、註解、測試計畫、取消計畫,以及其他與工作流程相關的文件,都應該依循組織政策被保留。這麼做的理由是,遵循管理政策。因為所有儲存、處理過程與傳輸的系統,都被涵蓋在像是沙賓法案(Sarbanes-Oxley)與支付卡產業資料安全標準(PCI-DSS)當中,而稽核員日後也會經常詢問查看,有關所有從上一次變更之後的文件。在做系統或應用程式的疑難排解或安全調查與事件處理流程時,也非常需要變更的稽核存底。

  每當變更的處理程序與計畫不同,或須執行取消計畫時,就得舉辦後續的會議或分析。任何安全的問題都是起因於變更,像是資料曝露,或是系統與網路弱點被帶進來,這些都應該是安全人員所主導的後續會議之基本內容。

絆腳石

  安全團隊進行變更管理時,有幾個要點請謹記在心,以免掉入陷阱。

. 了解變更管理與組態管理之間的差異。變更管理是一個處理程序架構,可由IT技術協助。組態管理必較常與工具本身畫上等號,像是裝在伺服器上的代理程式,可監控關鍵性檔案的變更,或是組態資料庫。(請見「變更管理工具」)。然而,設計良好的組態管理,在安全團隊進行變更管理時,將提供相當大的協助。

. 要達成有效又具風險的變更管理,最大的障礙在於人員與程序,而非技術問題。請更專注在與不同的IT小組與營運單位同仁合作,以了解安全人員在變更管理的工作流程中應扮演的角色。

. 當你在評估組態監控與執行工具時,要找那些可以整合至整個組織的變更管理產品。不要替安全防禦與安全產品,再發展出另一個獨立的產品。

  雖然組態監控工具已開始和變更管理產品整併,但這2個的結合還言之過早。因為現在安全專家必須專注在政策與程序,為變更作風險分析,提升內部的程序,以及確保變更管理工作流程之中,是否所有適切的稽核存底步驟都被遵從。

案例研究

電子商務管控

零售商為遵循PCI規範與安全考量,展開變更管控軟體之佈署。

  支付卡產業資料安全標準( P C I - D S S ),促使R e s t orati o n Hardware傢俱公司在它的電子商務平台佈署變更管控軟體。Restoration Hardware公司是一個高級傢俱零售商,位於美國加州Corte Madera城鎮。

  PCI內容中有關10.5.5 與11.5的條文要求,必須佈署檔案完整性的監控軟體。Restoration Hardware先尋找可以符合規範的品項,在注意過幾個產品之後,選擇了Solidcore S3Control產品,它可即時地追蹤變更,並且執行變更政策。

  「我們當時需要有所依循,因此Solidcore公司提供我們達到PCI中有關檔案完整性的檢查,」IT營運經理Bobby Wen表示。「安全是我們從中多得的利益」。

  此軟體可防止未註冊的二進位碼(binary)執行,所以它扮演的角色就像是入侵偵測與防禦系統,他說。假如入侵者設法進入一個系統,他將無法透過上傳一個二進位碼然後控制系統。那樣的安全就是零售商想要的,但是遵循PCI規範的需求卻是他們最後拿到經費的理由,他說。

  Solidcore很輕易地就與零售商的變更管理系統ControlTier整合,並且能確保是在變更政策下執行,2者都是從時間點與內容角度著眼,Wen表示。

  Restoration Hardware在它的電子商務平台佈署軟體,主要是在處理信用卡業務的網頁與應用伺服器上。此軟體是由安裝在系統上的代理程式,以及一個給管理者的操作介面所組成。

  因為Restoration Hardware公司是早期採用Solidcore產品的企業,有關新技術的部份,他必須向稽核員作一些解釋,而稽核員也一直在祈禱,希望這個軟體能達到PCI的要求,Wen表示。因為有Solidcore的報表功能,零售廠商可向稽核員展示系統變更的圖解畫面,取代簡易的log記錄畫面。

  除了PCI,此公司計畫將此軟體的使用,再擴展至沙賓法案的遵循。