全文約1.3萬字 7圖   閱讀約35分鐘

作為解決安全架構(gòu)中的技術(shù)、信息和彈性風(fēng)險的技術(shù)專家,，您應(yīng)該：

■ 規(guī)劃您與組織高級干系人的互動,，以積累業(yè)務(wù)上下文信息并促進安全架構(gòu)的益處。

■ 使用框架方法（如NIST CSF）加速構(gòu)建安全架構(gòu),。您必須計劃定制它,，以滿足您明確定義的業(yè)務(wù)和戰(zhàn)略目標(biāo),。

■ 使用安全方法論（如SABSA）定義業(yè)務(wù)上下文，并在架構(gòu)層次之間提供系統(tǒng)工程級別的可追溯性和嚴密性,。

■ 評估框架和方法論的組合（兩者并非互斥）如何能“兩全其美”地利用它們各自的好處,。

安全架構(gòu)方法論和框架方法為了實現(xiàn)它們的全部價值，執(zhí)行起來可能很復(fù)雜,。缺乏經(jīng)過深思熟慮的安全架構(gòu),，將導(dǎo)致部署無效的安全能力（要么部署過度，要么存在差距）,?？蛻粼噲D了解如何實現(xiàn)安全架構(gòu)能力，以便更好地為其組織服務(wù),。有幾種不同的策略,，包括方法論和框架，每種策略都有優(yōu)缺點,。

對安全架構(gòu)活動的一種批評是,，它們通常被視為昂貴的一次性活動或阻礙敏捷交付的活動，并且很快就不能反映運行時的實際情況,。本指南解釋了如何開始構(gòu)建您自己的以組織為中心的自定義的安全架構(gòu)方法的過程,，包括如何將安全架構(gòu)嵌入到交付實踐中。它提供了關(guān)于如何準備好將安全架構(gòu)作為組織中正在進行的活動來實現(xiàn)的指導(dǎo),。

安全架構(gòu)是高度結(jié)構(gòu)化的,，無論是就第一原則使用方法論開發(fā)，還是定制一個架構(gòu)框架,。成功的實現(xiàn),，需要在選擇、設(shè)計,、集成到現(xiàn)有業(yè)務(wù)實踐的整個過程中,，進行仔細的管理。選擇并在某些情況下合并方法,，以提供最合適的安全架構(gòu)流程,，是實現(xiàn)業(yè)務(wù)目標(biāo)所必需的。為了清楚起見,，本指南幫助用戶準備并為其組織選擇最合適的路徑,。

該指南指導(dǎo)您完成應(yīng)該計劃的活動，以支持實現(xiàn)安全架構(gòu)方法,。階段從具有確定步驟的戰(zhàn)略需求到幫助形成邏輯安全,。它建議為了設(shè)計過程的順利進行做好準備，以幫助實現(xiàn)必要的安全組件和技術(shù)。實現(xiàn)戰(zhàn)略技術(shù)目標(biāo),，意味著安全架構(gòu)必須是一個活的過程,，而不是一次性事件。該方法提供了指導(dǎo),，幫助將安全架構(gòu)嵌入到業(yè)務(wù)和ITT實踐中,，以確保其被接受和集成。

安全架構(gòu)項目的常見風(fēng)險包括：

■ 缺乏深思熟慮的安全架構(gòu)將導(dǎo)致部署無效的安全能力（要么部署過度,，要么存在差距）,。要非常周密，并在安全架構(gòu)實現(xiàn)的各個階段,，包括所有干系人,，以確保安全能力沒有被錯誤地部署。

■ 在實施安全架構(gòu)過程時,，未能定義范圍將導(dǎo)致定義錯誤的安全架構(gòu),。不完整的范圍邊界，與無范圍邊界或只是假設(shè)的范圍邊界一樣糟糕,。因此,，應(yīng)盡一切努力確保覆蓋度和完整性。與IT領(lǐng)導(dǎo)一起確認并確保為您的安全架構(gòu)過程定義了正確范圍,。

■ 如果在不了解風(fēng)險的情況下開發(fā)安全架構(gòu),，組織本質(zhì)上是在開發(fā)一個上下文無關(guān)的通用控制模板。這將沒有重點,，也不會解決一個組織面臨的真正風(fēng)險,。所有的安全架構(gòu)活動都應(yīng)該致力于管理風(fēng)險。

■ 識別現(xiàn)有的安全和控制框架,。如果忽視或忽略此步驟,，則所需的控制框架需求與安全架構(gòu)設(shè)計之間可能存在不一致。治理和設(shè)計之間缺乏一致性,，將導(dǎo)致控制不足或缺失,，這可能導(dǎo)致審計失敗。與所有安全治理和風(fēng)險團隊合作,，并使用組織安全策略和標(biāo)準,，以幫助構(gòu)建安全架構(gòu),。

■ 如果沒有有效的溝通計劃,，重大風(fēng)險將影響安全架構(gòu)活動的整體成功。如果不計劃讓干系人,，特別是高級職員參與進來,，他們很可能不會在你需要的時候立即出現(xiàn)。制定干系人參與計劃。

■ 不仔細規(guī)劃和準備這一階段的風(fēng)險,，將使我們無法定義有效的安全架構(gòu),。關(guān)鍵的風(fēng)險在于沒有足夠詳細的組織和業(yè)務(wù)流程信息，來決定所需的邏輯安全服務(wù),。通過訪問這類文檔以及與整個組織中可以提供指導(dǎo)的干系人進行聯(lián)系,，可以緩解這些問題。

■ 始終檢查分層防御,。不要跳過它,，因為那樣會引入與安全架構(gòu)縝密性相關(guān)的潛在風(fēng)險。在紙面上看起來所有的要求都得到了滿足,。但是,，應(yīng)驗證補償控制是否充分滿足了要求。

■ 需要定義足夠的觸發(fā)器,，以促使安全架構(gòu)師將現(xiàn)有安全架構(gòu)應(yīng)用于新項目,。

■ 架構(gòu)師必須努力確保當(dāng)業(yè)務(wù)目標(biāo)發(fā)生變化時，能夠及時更新邏輯和技術(shù)安全架構(gòu),。還必須維護和更新為DevOps創(chuàng)建的參考架構(gòu)和編程組件等構(gòu)件,。

這個指導(dǎo)框架有助于定義安全架構(gòu)的方法,，它包括五個階段,，與實現(xiàn)的重點領(lǐng)域相一致。階段包括：

1. 界定范圍,，理解環(huán)境,。

2. 獲得戰(zhàn)略級的安全洞察力。

3. 支持邏輯安全架構(gòu)的開發(fā),。

4. 促進技術(shù)安全架構(gòu)的設(shè)計,。

5. 使安全架構(gòu)成為一個動態(tài)的活躍的過程。

圖1總結(jié)了這些階段,，提供了每個階段的子階段活動和可能的結(jié)果,。

圖1-安全架構(gòu)方法指導(dǎo)框架

在設(shè)計安全架構(gòu)過程時,，熟悉安全架構(gòu)的方法論和框架非常重要,。在本指南中，我們區(qū)分了方法論方法和框架方法,，其中方法論方法把大部分工作留給實踐者,，而框架方法在本質(zhì)上更具規(guī)范性。本指南將這些術(shù)語定義為：

■ 框架：一份可用于開始工作的設(shè)定的控制和實踐的列表,，即一份洗衣單或一組關(guān)于“什么”的項目,。此外,，框架可以與內(nèi)部指令（如標(biāo)準、政策和指南）相關(guān),，以幫助定義安全架構(gòu),。

■ 方法論：一條從初始點到設(shè)定的期望點的路徑，也就是一系列關(guān)于“如何”做某事的步驟或指南,。

方法論可以是指一個框架或該框架的一個或多個步驟,，并且可以指導(dǎo)客戶使用框架。一些框架本身包括實現(xiàn)指南,，并且可能有一些步驟來幫助定制或改編以適應(yīng)客戶的業(yè)務(wù)需求,。

安全架構(gòu)應(yīng)該是一個活的過程,，而不是一次性的,。本節(jié)提供了如何將安全架構(gòu)流程嵌入到組織實踐中的指導(dǎo)。

1.a. 干系人管理

本指南強調(diào)了干系人對安全架構(gòu)的成功實現(xiàn)至關(guān)重要,。

理解與干系人的互動,，需要正式的活動和更多的信息交流。跟蹤干系人參與的內(nèi)容和性質(zhì)的一種方法,，是創(chuàng)建和分發(fā)一個RACI（負責(zé)-問責(zé)-咨詢-知情）矩陣,。RACI矩陣應(yīng)該映射到組織角色。

如果沒有干系人管理,，安全架構(gòu)師就可能無法與關(guān)鍵人員溝通,，無法讓關(guān)鍵人員參與安全架構(gòu)的維護和發(fā)展。他們冒著只與不斷減少的原始參與者交流的風(fēng)險,，而不是仔細管理來自組織內(nèi)部的領(lǐng)導(dǎo)和專家,，而這些領(lǐng)導(dǎo)和專家的輸入是至關(guān)重要的。干系人的支撐和支持,，對于確保安全架構(gòu)的成功維護非常重要,。

1.b. 將安全架構(gòu)嵌入到業(yè)務(wù)中

對安全架構(gòu)活動的一種批評是，它們通常被視為昂貴的一次性活動,，并且很快就不能反映運行時的實際情況,。這對于采用敏捷開發(fā)程序、云服務(wù)和CI/CD類型活動的企業(yè)來說尤其是一個問題,，這些活動在一個持續(xù)的,、有計劃的基礎(chǔ)上發(fā)生變化。

支持在多變環(huán)境中維護當(dāng)前安全架構(gòu)遠景的方法包括：

■ 將安全架構(gòu)活動嵌入開發(fā)和運營活動,，以支持持續(xù)管理和控制,。

■ 與組織中現(xiàn)有的架構(gòu)功能保持一致——例如，企業(yè)架構(gòu),。

■ 定義和維護參考安全架構(gòu),。它們可以是高級的架構(gòu)解決方案,，也可以是實際構(gòu)建的,、隨時（重新）使用的架構(gòu)解決方案,，以適應(yīng)特定的用例、模式或其他邏輯需求,。

如果安全架構(gòu)流程要真正在敏捷和DevOps中工作,，架構(gòu)師需要尋找可以轉(zhuǎn)換為工作流步驟的技術(shù)層流程，或者在代碼提交,、構(gòu)建和應(yīng)用程序交付中無縫進行檢查/審核,。在敏捷交付中，除非是在設(shè)計/規(guī)劃期間與開發(fā)團隊一起完成,，或者作為帶外活動執(zhí)行,，否則人工評審的空間很小。

為了支持這些對靈活性和敏捷性的戰(zhàn)略需求,，可能需要工具來適應(yīng)集成,、自動化和其他技術(shù)能力。自動化部署可以使用云功能以編程方式執(zhí)行,，它們可以為基礎(chǔ)設(shè)施和身份組件提供“基礎(chǔ)設(shè)施即代碼”選項,。

因此，對于某些人來說,，安全架構(gòu)確實可以是一種“紙上談兵”的演練,，在這種演練中，需要花時間向領(lǐng)導(dǎo)層了解業(yè)務(wù)方向和戰(zhàn)略,，從而根據(jù)內(nèi)部安全治理和外部標(biāo)準形成邏輯安全,。它也可以是完全設(shè)計的技術(shù)參考組件，準備到項目的交付點,，以便為其自身的獨特需求進行配置（參見圖2）,。

圖2-使架構(gòu)可持續(xù)

1）將安全架構(gòu)活動嵌入到日常開發(fā)和運營中

部署IT的每個組織都有某種類型的開發(fā)和發(fā)布周期。必須積極識別和管理風(fēng)險,。必須定義基于風(fēng)險的觸發(fā)器,，以促使安全架構(gòu)團隊采取行動，幫助改進和改變安全架構(gòu),，以應(yīng)對新的挑戰(zhàn),。

通過調(diào)查組織的影響和變更可能產(chǎn)生持續(xù)影響的地方，為持續(xù)的安全架構(gòu)過程做好準備,。用于評估對安全架構(gòu)產(chǎn)生影響的典型信息源包括：

■ 變更管理

■ 風(fēng)險管理

■ 新項目倡議/規(guī)劃

■ 審計報告

■ 公開報道

一些活動可能需要由組織的安全組初始化,，包括：

■ 識別安全系統(tǒng)和過程中的差距和漏洞

■ 定期審查安全架構(gòu)的戰(zhàn)略層（應(yīng)進行此項審查，以確定范圍是否發(fā)生變化,，以及現(xiàn)在是否有新的戰(zhàn)略要求改變了安全架構(gòu)的重點,；這項活動基本上會重復(fù)第2.c.子階段中提到的圍繞高級領(lǐng)導(dǎo)層的活動,。

安全架構(gòu)提供了一組從業(yè)務(wù)層、邏輯層和技術(shù)層開始的分層概念,。每一層的“速度”或變化率根據(jù)不同的刺激因素而不同,，必須謹慎管理：

■ 業(yè)務(wù)安全需求必須與業(yè)務(wù)戰(zhàn)略保持一致。邏輯需求解決了這些業(yè)務(wù)需求,，但一般來說,，這些層不是快速移動的。但是,，隨著時間的推移,，它們會導(dǎo)致業(yè)務(wù)需求的重大變化（例如，引入靈活性/可伸縮性/敏捷性）,。

■ 安全架構(gòu)需要人工流程來跟蹤和關(guān)注邏輯安全架構(gòu)的變化,，而這些流程最終需要輸入到架構(gòu)的技術(shù)層。

■ 在技術(shù)層,，其他因素和條件影響了安全架構(gòu)的實例化方式,。例如，對敏捷性的需求,，意味著可能需要在交付中嵌入更多的安全自動化,。因此，安全架構(gòu)過程必須適應(yīng)技術(shù)變化,，并以SDLC的“速度”這樣做,。

組織可以使用敏捷交付方法論遞增地部署新技術(shù)。在敏捷增量過程中,，技術(shù)安全架構(gòu)可能需要更改以響應(yīng)或適應(yīng)新技術(shù)的挑戰(zhàn),。因此，安全架構(gòu)師必須在敏捷團隊中有代表,。但是,，邏輯安全架構(gòu)和業(yè)務(wù)安全戰(zhàn)略架構(gòu)的變化可能要小得多，當(dāng)它們發(fā)生變化時,，安全架構(gòu)師必須采取行動,，確保將其影響過濾到技術(shù)架構(gòu)中。

2）與現(xiàn)有架構(gòu)功能保持一致

與企業(yè)架構(gòu)功能密切合作,，可能是一種很好的方式,，用于讓安全架構(gòu)參與到項目中來，無論是常規(guī)運營還是使用敏捷方法,。安全架構(gòu)實踐通常與企業(yè)和解決方案架構(gòu)保持良好的一致,。例如，SABSA有一份白皮書解釋了與TOGAF的集成,。

建議企業(yè)架構(gòu)在集體領(lǐng)導(dǎo)下作為IT安全的對等組織工作,。它更進一步,，提供了一個分散的EA團隊，由來自應(yīng)用程序,、基礎(chǔ)設(shè)施,、IT安全的架構(gòu)師組成。

業(yè)務(wù)結(jié)果驅(qū)動的EA能力側(cè)重于創(chuàng)建可操作的建議,，以交付創(chuàng)新的方法,，提供明確的架構(gòu)指導(dǎo),，并使用完全支持業(yè)務(wù)工作的工具和實踐進行運營,。安全架構(gòu)師應(yīng)該與EA合作，以確保安全架構(gòu)基于風(fēng)險的部署建議與EA輸出保持一致,。

3）安全參考架構(gòu)

設(shè)計和構(gòu)建安全參考架構(gòu),，是幫助項目團隊理解其部署中對安全性的基本期望的好方法。由于模式是為項目設(shè)計的,，所以架構(gòu)師應(yīng)該確定它們是否適合重復(fù)使用,，并根據(jù)需要為將來的活動存儲工件。

安全架構(gòu)師在談?wù)搮⒖及踩軜?gòu)時的含義是不同的,。對某些人來說,，參考架構(gòu)是一個帶有方框的大型圖表，方框中包含了需要部署的組件名稱,。對其他人來說,，它是可重用的技術(shù)設(shè)計模式。參考架構(gòu)也可以是完整構(gòu)建的部署,，準確配置為滿足安全治理的期望,，并準備好為另一個項目（或再一次的同一個項目）重新部署！

1.c. 決定風(fēng)險觸發(fā)器和閾值，以審查和修訂已建立的架構(gòu)

為了幫助嵌入并確保活動成為可重復(fù)的流程,，組織需要定義將啟動安全架構(gòu)團隊活動的觸發(fā)器,。為此，與干系人一起制定計劃,，以確定活動、風(fēng)險、項目規(guī)劃信息和其他有助于指導(dǎo)安全架構(gòu)持續(xù)參與的輸入,。

如果沒有足夠的觸發(fā)器來提示安全架構(gòu)師采取行動，將現(xiàn)有的安全架構(gòu)應(yīng)用于新項目是不可能的,。實踐者經(jīng)常說安全架構(gòu)是一個過程,，而不是一個東西，使用觸發(fā)器來調(diào)用架構(gòu)師的動作是確保過程運行的關(guān)鍵部分,。

本階段指南旨在確保對范圍界定,、風(fēng)險和現(xiàn)有控制信息的收集,。

2.a. 獲取現(xiàn)有風(fēng)險概要

從業(yè)者需要全面了解組織的風(fēng)險狀況。這意味著獲得戰(zhàn)略風(fēng)險,、風(fēng)險管理目標(biāo)和控制目標(biāo),，并包括獲得跟蹤技術(shù)風(fēng)險的企業(yè)風(fēng)險管理工具。

如果開發(fā)安全架構(gòu)時不了解風(fēng)險,，那么組織實際上是在開發(fā)一個與上下文無關(guān)的通用控制模板,。這將缺乏重點，也無法解決組織面臨的真正風(fēng)險,。

此外,，安全架構(gòu)必須與組織治理（即內(nèi)部策略、標(biāo)準,、流程和過程）保持一致,，因為它提供了安全架構(gòu)的權(quán)威企業(yè)邊界。編寫內(nèi)部政策和標(biāo)準是為了解決已經(jīng)確定的風(fēng)險,，但需要通過明確的行動和步驟來減輕這些風(fēng)險,。

SABSA和NIST CSF方法都使用了已識別的風(fēng)險（和機會）。它們都利用風(fēng)險管理過程,，來通知和指導(dǎo)將安全功能嵌入到安全架構(gòu)中的方式,。因此，能夠訪問風(fēng)險信息源,，是順利進行安全架構(gòu)設(shè)計和持續(xù)實施的關(guān)鍵因素,。

這些步驟不是風(fēng)險評估，而是指導(dǎo)您在構(gòu)建安全架構(gòu)期間應(yīng)該訪問哪些風(fēng)險信息,。當(dāng)然,，如果在收集過程中發(fā)現(xiàn)風(fēng)險評估尚未執(zhí)行，建議您執(zhí)行安全風(fēng)險評估,。

一旦您有權(quán)訪問所有關(guān)鍵風(fēng)險源,，此活動即告完成。

2.b. 確定架構(gòu)的范圍

邊界需要應(yīng)用于安全架構(gòu)范圍,，以便只審查/實現(xiàn)必要的區(qū)域,。這個范圍很可能是整個組織企業(yè)，也可能是一個確定的業(yè)務(wù)功能或進一步的細分,，這取決于活動的目標(biāo),。

使用范圍界定來明確安全架構(gòu)要覆蓋的系統(tǒng)，并避免用戶之間的混淆,。

界定范圍有助于創(chuàng)建一個堅實的基礎(chǔ)來支持階段3,，它檢查安全架構(gòu)的戰(zhàn)略級決策。

如果在實現(xiàn)安全架構(gòu)過程時未能界定范圍，則會導(dǎo)致安全架構(gòu)定義不當(dāng),。干系人系統(tǒng)可能缺失,，可能在安全能力方面存在真正的差距，也可能被排除在外的同事剝奪原有權(quán)利,。

范圍界定是一個相當(dāng)短的活動,，在定義總體安全架構(gòu)方法之前，它與業(yè)務(wù)主管和干系人一起執(zhí)行,。

幾乎所有后續(xù)活動都依賴于范圍界定,。不完整的范圍，與沒有范圍或只是假定的范圍一樣糟糕,。因此,，應(yīng)盡一切努力確保覆蓋度和完整性。范圍可以由整個企業(yè)或特定安全策略域和底層標(biāo)準的覆蓋范圍來定義,。

2.c. 確定現(xiàn)有的安全標(biāo)準和內(nèi)部控制框架

許多組織以合規(guī)為導(dǎo)向,，具有安全能力,，能夠履行審計師,、監(jiān)管者和立法者規(guī)定的義務(wù)。受監(jiān)管行業(yè)尤其如此,。一種常見的方法是依賴控制框架作為選擇控制的源或起點,。公開控制框架通常形成一長串可能的控制，組織應(yīng)該考慮在退出的基礎(chǔ)上實施這些控制,。ISO 27002和NIST SP 800-53是控制框架的例子,，它們被特別期望用作“購物清單”。用戶需要執(zhí)行資產(chǎn)風(fēng)險評估,，以確定所需的控制及其實施水平和范圍,。

如果忽視或忽略此步驟，則所需的控制框架需求與安全架構(gòu)設(shè)計之間就可能存在不一致,。治理,、保證和設(shè)計之間缺乏一致性，將導(dǎo)致控制不足或缺失,，從而可能導(dǎo)致審計失敗,。這可能導(dǎo)致額外的返工和控制補救，甚至名譽受損和監(jiān)管罰款,。

2.d. 確定現(xiàn)有的安全系統(tǒng)和能力

一些現(xiàn)有的安全系統(tǒng)和功能可能存在于大多數(shù)組織中,。需要對現(xiàn)有的安全系統(tǒng)、能力和過程進行調(diào)查,。

一些架構(gòu)師將選擇對現(xiàn)有的安全部署執(zhí)行成熟度評估,，以更好地了解嵌入式程度以及安全能力相對于各自任務(wù)的執(zhí)行情況。收集盡可能多的關(guān)于安全能力的信息,，不僅僅是工具化的一般描述,。

安全架構(gòu)師必須在整個組織中輪詢多個團隊以收集安全能力信息,。不要低估這項任務(wù)在現(xiàn)實世界中的重要性和難度。

您必須與應(yīng)用程序所有者,、企業(yè)安全控制區(qū)域,、安全團隊、安全運營團隊,、DevSecOps和開發(fā)團隊進行溝通,。

當(dāng)架構(gòu)師確認所有組都提供了信息或斷言他們沒有安全能力時，此任務(wù)就完成了,。對組織安全能力有一個良好的,、最新的了解，是安全架構(gòu)的一個重要資源,。在組織中創(chuàng)建和維護良好的IT可見性,，是成功的關(guān)鍵。

此階段包含重要的上下文活動,，包括確定要采取的安全架構(gòu)策略和獲取關(guān)鍵上下文信息的方法,，以及安排溝通和會議。

3.a. 決定安全架構(gòu)策略

本指南的第一階段對于將要使用的方法論或安全架構(gòu)框架是不可知的,。此階段支持選擇和創(chuàng)建組織將使用的安全架構(gòu)方法,。

在本指南中，如前一階段所總結(jié)的,，我們提供了方法論方法（如SABSA）和框架方法（如NIST CSF）之間的比較,，以幫助支持決策。盡管還有其他方法,，但它們屬于這些廣泛的方法類別,。

安全架構(gòu)方法論為邏輯架構(gòu)和底層技術(shù)安全架構(gòu)創(chuàng)建上下文和概念基礎(chǔ)。這使得業(yè)務(wù)期望與安全性更緊密地結(jié)合起來,。框架使用一組假定的相似性和跨用戶的共同期望來確定安全架構(gòu),。CSF等框架方法為方法論提供了支撐。

安全架構(gòu)方法為邏輯安全架構(gòu)創(chuàng)建上下文和概念基礎(chǔ),?？蚣苁褂靡唤M假定的相似性和跨用戶的共同期望來確定安全架構(gòu)。

方法論方法有助于定義一個清晰的業(yè)務(wù)上下文,，在此基礎(chǔ)上可以創(chuàng)建概念架構(gòu),。然后使用它來了解和構(gòu)造邏輯安全架構(gòu)。在這種情況下,，該方法論成功地定義了滿足業(yè)務(wù)需求的架構(gòu),。

另一方面，框架是根據(jù)安全專業(yè)人員和貢獻組織的經(jīng)驗構(gòu)建的，以提供一套“最佳實踐”指南和控制措施,。幸運的是,，安全架構(gòu)框架設(shè)計者認識到了業(yè)務(wù)需求，并在其方法中嵌入了一些定制化,，以幫助滿足各個業(yè)務(wù)需求,。

然而，在實踐中,，方法論可以在其方法中使用安全架構(gòu)框架,、最佳實踐指南和安全標(biāo)準，以適應(yīng)業(yè)務(wù)的需要,。這為架構(gòu)師提供了一些選擇,。然而，他們需要充分研究并熟悉安全架構(gòu)方法和框架,，以便為組織做出正確的決策,。

圖3顯示了選擇一種方法背后的挑戰(zhàn)和原理。說明了在使用框架或方法論以及使用組合方法的選項之間的選擇,。

圖3-方法論和框架

必須在開始之前決定如何實現(xiàn)您的安全架構(gòu)方法,。如果未選擇該方法，則在安全架構(gòu)的實際工作開始之前,，許多子階段活動將保持不完整或無法開始,。

這顯然是一個定性的決定。然而,，有關(guān)安全架構(gòu)框架方法是否合適的證據(jù)，可以通過查看合規(guī)性和法律義務(wù)等來源來收集,。

如果您不確定,，或者對資源和能力有顧慮，并且沒有其他特定需求,，那么邁向安全架構(gòu)的第一步應(yīng)該是使用NIST CSF,，對其進行調(diào)整，使其符合您本地的標(biāo)準和實踐,。隨著安全架構(gòu)程序的成熟,，您可能希望更好地與業(yè)務(wù)需求保持一致，并且可以使用方法論方法,，在“按需”的基礎(chǔ)上將它們與框架一起引入,。

3.b. 確定獲得相關(guān)組織見解的方法

安全架構(gòu)計劃的某些上下文，只能從高級管理人員和執(zhí)行人員處獲得,。任何框架都有一個額外的步驟：為運行框架準備所需的輸入,。在大型分布式組織中，這一步驟可能非常繁重，因為許多豎井和單元將擁有必要的信息,。但是,，獲取業(yè)務(wù)驅(qū)動的一個關(guān)鍵信息源，是通過您的安全治理功能,。

必須收集有關(guān)安全性的業(yè)務(wù)見解,。為了促進這一點，計劃與高層領(lǐng)導(dǎo)的互動,。在確定需要從哪些高級領(lǐng)導(dǎo)人員那里獲得見解時,，請記住他們必須對范圍內(nèi)的業(yè)務(wù)和技術(shù)領(lǐng)域負責(zé)。為了獲得最大的利益和洞察,，領(lǐng)導(dǎo)人員必須擴展到業(yè)務(wù)職能的范圍,。

如何利用SABSA獲取戰(zhàn)略信息

為了幫助決定不僅是采取哪些方法，而且需要收集哪些信息,，我們看看SABSA如何獲取業(yè)務(wù)數(shù)據(jù)并形成戰(zhàn)略架構(gòu)元素,。

像SABSA這樣的方法論，分解了業(yè)務(wù)上下文并幫助利用了一組業(yè)務(wù)屬性示例——每個屬性都有一個明確的含義,。這就創(chuàng)建了概念架構(gòu),。架構(gòu)師必須獲得并生成業(yè)務(wù)安全需求。它能夠根據(jù)業(yè)務(wù)安全需求直接解釋邏輯安全需求,。

安全架構(gòu)框架在其特定領(lǐng)域有需要滿足的目標(biāo)（例如,，金融服務(wù)控制期望、風(fēng)險管理目標(biāo)和政府要求）,。因此,，它們可能會提供一個更具規(guī)范性的途徑。然而,，SABSA一開始就選擇性忽視這些目標(biāo),。

一個類比是建模工具包。框架是一個Airfix飛機建模工具包,，包含構(gòu)建飛機的說明,。你可以忽略小模塊，選擇不同的顏色等等,，但最終,，你得到的是一個飛機。方法論是一盒樂高積木和一本“樂高創(chuàng)意計劃書”——也就是說,，它提供了一些你能做什么的好主意和如何做的指南,，但是你究竟把什么搭建在一起，卻完全是你自己創(chuàng)造的,。

領(lǐng)導(dǎo)層的洞察力有助于創(chuàng)建一組優(yōu)秀的驅(qū)動因素,，從業(yè)務(wù)角度來看,，這些驅(qū)動因素需要安全措施的支持。這些信息將從與領(lǐng)導(dǎo)層互動和戰(zhàn)略文件審查（如商業(yè)計劃和投資者數(shù)據(jù)信息）中獲得,。這為安全的必要性提供了重要的上下文,。一旦這些驅(qū)動因素被確認，它們就被用作下面的安全架構(gòu)的基礎(chǔ),。一些例子（來自面談或戰(zhàn)略文件）：

業(yè)務(wù)目標(biāo)示例：

■ 確保業(yè)務(wù)靈活性和敏捷性,，以實現(xiàn)增長

■ 建立高效的數(shù)據(jù)處理

■ 確保業(yè)務(wù)服務(wù)對所有用戶/客戶在任何時候都能獲得

■ 符合所有道德和相關(guān)法律框架

與業(yè)務(wù)目標(biāo)相關(guān)的業(yè)務(wù)安全目標(biāo)示例：

■ 跨擴展企業(yè)，保護業(yè)務(wù)數(shù)據(jù)

■ 在所有員工需要時可以提供

■ 確保業(yè)務(wù)流程的可靠性

■ 遵守道德,、法律和監(jiān)管義務(wù)

SABSA幫助定義業(yè)務(wù)屬性,，以形成“業(yè)務(wù)屬性概要”。這直接映射回安全目標(biāo),。安全屬性是一組戰(zhàn)略項,，它們本身暗示著安全需求。SABSA方法論提供了一組可利用的示例安全屬性,，但也可以使用自定義創(chuàng)建的屬性,。

圖4顯示了一個示例，其中業(yè)務(wù)安全目標(biāo)映射到一組安全屬性以形成業(yè)務(wù)屬性概要,。

圖4-識別安全屬性以滿足業(yè)務(wù)目標(biāo)

注意,，對于那些尋求SABSA和NIST CSF之間正式整合的人，SABSA研究所已經(jīng)發(fā)起了SENC項目“SABSA增強的NIST網(wǎng)絡(luò)安全框架”,。該項目的基本原理是,，為NIST CSF提供了基于SABSA的業(yè)務(wù)屬性分析的“前端”方法。

3.c. 計劃溝通和會議

在適當(dāng)?shù)闹卫砗捅O(jiān)督下,，將安全架構(gòu)作為組織內(nèi)的一組持續(xù)過程來實施,，以在技術(shù)層提供一種全面和不斷發(fā)展的安全風(fēng)險管理方法。

這一階段在實踐中是一個項目管理活動,，以確保與所有應(yīng)該參與的人取得聯(lián)系,。它應(yīng)該計劃在安全架構(gòu)創(chuàng)建和維護活動期間執(zhí)行。

必須制定該計劃,，以保持與主要干系人的溝通和接觸。在本指南的第一階段,，有一個稱為“干系人管理”的子階段,，作為“使安全架構(gòu)成為動態(tài)的、活的過程”階段的一部分,。這兩個階段有著顯著的聯(lián)系——那個子階段是關(guān)于識別和管理哪些干系人需要參與,，而這個階段是關(guān)于安全架構(gòu)活動和與它們的交互。

如果沒有有效的計劃,，就存在影響安全架構(gòu)活動總體成功的重大風(fēng)險,。如果沒有計劃讓干系人,，特別是高級職員參與進來，他們不大太可能在你需要的時候立即給予幫助,。溝通也有助于促進安全架構(gòu)的理念被干系人群體所接受,。這避免了安全架構(gòu)在完成之前就已經(jīng)成為冷板凳的風(fēng)險。這項活動的時間安排很重要,。這些計劃應(yīng)該在開發(fā)安全架構(gòu)之前制定,。同時，這也是一個行動計劃,，將在整個過程中進行修改和變更,。

此階段包含了支持生成邏輯安全架構(gòu)的活動的指南，包括方法的識別,、支持控制分配活動,、與標(biāo)準保持一致。

4.a. 確定開發(fā)邏輯安全架構(gòu)的方法

框架和方法論以不同的方式處理邏輯安全性,，因此,，在開發(fā)這個架構(gòu)層之前，您需要考慮這些偏差,。

本指南的這一步,，為您所選擇的方法創(chuàng)建必要的邏輯安全架構(gòu)構(gòu)件做好了準備。不仔細規(guī)劃和準備這一階段的風(fēng)險,，將使我們無法定義有效的安全架構(gòu),。確保您能夠獲得必要的文檔，并與整個組織中能夠提供指導(dǎo)的干系人保持聯(lián)系,。

方法1：使用NIST CSF定義邏輯安全架構(gòu)

對于NIST CSF,，創(chuàng)建邏輯安全的過程，是使用框架概要執(zhí)行的,。框架概要（Framework Profile）是根據(jù)組織的業(yè)務(wù)需求構(gòu)建的,。框架概要比邏輯層擴展得更遠,，并且還解決了更多的技術(shù)問題,。

本指南的前幾個階段，幫助您獲取有關(guān)組織的安全態(tài)勢,、當(dāng)前風(fēng)險狀況,、戰(zhàn)略業(yè)務(wù)的關(guān)鍵信息。這些信息源被組合起來,，用于在架構(gòu)師構(gòu)建當(dāng)前概要（Current Profile）時告知架構(gòu)師,。

可以使用相同的框架概要來開發(fā)目標(biāo)概要（Target Profile）——這將考慮到組織風(fēng)險和管理目標(biāo)，以及應(yīng)該如何處理它們,。

請記住,，在構(gòu)建當(dāng)前概要和目標(biāo)概要時,，它們是用實現(xiàn)層度量來定義的，這些度量既受業(yè)務(wù)需求的指導(dǎo),，又受風(fēng)險管理指導(dǎo)的通知,。為此，來自框架核心的控制和實現(xiàn)層的選擇,，應(yīng)該完全可以被追溯到：

■ 特定的已識別的業(yè)務(wù)需求：可以執(zhí)行一個過程,，如SABSA對業(yè)務(wù)上下文的識別和前一階段描述的業(yè)務(wù)屬性概要的創(chuàng)建，以使業(yè)務(wù)需求與控制能力系統(tǒng)性保持一致,。請記住,，框架是可擴展的，可以根據(jù)需要進行修改,。

■ 目標(biāo)概要層的選擇,，需要直接解決已識別的風(fēng)險。不要僅僅把這個過程作為一個雄心勃勃的步驟來使用,；看看風(fēng)險評估信息,，并決定需要改進哪些控制措施，來緩解已發(fā)現(xiàn)的問題,。

使用目標(biāo)概要并將其與當(dāng)前概要進行比較,，可以提供詳細信息，幫助定義邏輯安全架構(gòu)所需的內(nèi)容,、其結(jié)構(gòu)及其組件（甚至更多的技術(shù)安全架構(gòu)需求）,。圖5描述了這種比較以及風(fēng)險評估是如何居于核心地位的。它展示了如何使用核心CSF框架來度量控制的實現(xiàn)層,，包括子類別,。創(chuàng)建當(dāng)前狀態(tài)概要。評估風(fēng)險敞口,，并確定未來狀態(tài)概要需要什么,。方框顏色表示實現(xiàn)層的級別。

圖5-當(dāng)前和目標(biāo)框架概要設(shè)計的比較

一旦組織的框架概要準備好,，就可以檢查現(xiàn)有的部署,，并將它們與該概要進行比較。

使用名為“框架實現(xiàn)層”的度量,，您可以為已審查的控制的操作,，指定一個嚴格性級別。層的級別從1（局部）上升到2（知悉風(fēng)險）,、3（可重復(fù)）和4（自適應(yīng)）。層并不意味著成熟度評估度量,。然而,，NIST CSF框架指南建議,，評估為1級的任何控制措施，至少應(yīng)尋求轉(zhuǎn)移到2級,。

方法2：使用SABSA方法論創(chuàng)建邏輯安全架構(gòu)

通過框架方法,，定義了邏輯安全架構(gòu)的基礎(chǔ)。圖5顯示了NIST CSF的核心功能,。然而,，在SABSA中，定義邏輯架構(gòu)實際上是一項系統(tǒng)工程任務(wù),，用于定義整個系統(tǒng)的關(guān)鍵方面,、其組件子系統(tǒng)以及這些子系統(tǒng)如何交互和控制。控制本身來源于業(yè)務(wù)目標(biāo)和由業(yè)務(wù)屬性概要定義的概念架構(gòu),。

準備使用SABSA定義邏輯安全架構(gòu),，需要了解架構(gòu)范圍內(nèi)的組織。SABSA確定了在這一級別需要明確的要素,，包括了解哪些信息資產(chǎn)需要保護,、政策架構(gòu)（用于風(fēng)險管理）、關(guān)鍵業(yè)務(wù)流程,、信任框架和域映射,。邏輯安全架構(gòu)本質(zhì)上表示安全服務(wù)，用于在定義的風(fēng)險策略中保護域內(nèi)和域間的信息資產(chǎn)和流,。

在SABSA中,，安全域是幫助定義邏輯架構(gòu)的基本構(gòu)建塊。安全域是“被單個安全策略頒發(fā)機構(gòu)定義和擁有的通用安全策略所約束的一組元素”,。

一旦定義了所轄范圍的策略域,，進而定義了支持這些策略域的安全標(biāo)準，下一個關(guān)鍵領(lǐng)域就是理解業(yè)務(wù)流程和功能需求,，以便可以映射域相互關(guān)系和信任,。通過這樣做，邏輯安全架構(gòu)所需的安全服務(wù)可以明確定義,。

在決定必須應(yīng)用控制的位置時,，一個重要步驟是檢查邏輯安全架構(gòu)范圍內(nèi)的參與者組之間的相互關(guān)系。參與者按照組織策略控制進行分組,，稱為“域”,。可以根據(jù)信任關(guān)系來考慮控制,。內(nèi)部安全標(biāo)準將至少定義為最低基線,。

SABSA認為，“重要的信任概念涉及在域內(nèi)管理信任的各種策略權(quán)威,、設(shè)置用于管理每個域中實體行為的策略,，以及域間信任關(guān)系,。”

在邏輯安全架構(gòu)中,，策略架構(gòu)和域被映射,。通過構(gòu)造基于策略域的架構(gòu)，域之間必要的信任可以通過關(guān)聯(lián)進行分配,。策略域信任是為支持業(yè)務(wù)活動而建立的,，并且存在于業(yè)務(wù)事務(wù)中的所有各方之間。這些信任與業(yè)務(wù)安全屬性相關(guān)聯(lián),，這些屬性提供了在業(yè)務(wù)中的域之間成功定義邏輯安全控件的方法,。

4.b. 促進控制分配

如何執(zhí)行控制分配，取決于構(gòu)造的方法（即方法論,、框架或兩者的組合）,。控制分配（Control assignment）是為滿足組織的業(yè)務(wù)需求而選擇的邏輯安全服務(wù)。

此步驟的目的是以非技術(shù)性的方式（即不明確指出如何滿足控制）,，清楚地傳遞安全服務(wù),。執(zhí)行此步驟，有助于為技術(shù)安全架構(gòu)提供明確的需求,。如果沒有這一步,，就無法使業(yè)務(wù)需求與技術(shù)安全保持一致。

根據(jù)您的方法,，它們將被向前映射,，以創(chuàng)建構(gòu)件，捕獲必要的安全服務(wù)以滿足期望,。這一階段的成果必須與干系人分享和審查,，因此要相應(yīng)地進行計劃。

在此階段可能出現(xiàn)的風(fēng)險包括,，干系人的輸入沒有得到充分考慮,。這導(dǎo)致在分配邏輯安全控制時，未考慮干系人的責(zé)任領(lǐng)域,。

4.c. 將安全框架,、指南、最佳實踐納入邏輯安全架構(gòu)

如前一個子階段所述,，使用安全框架是創(chuàng)建邏輯安全架構(gòu)的一個組成部分,。框架方法和方法論方法是有區(qū)別的,。

例如,，NIST CSF構(gòu)建了外部安全框架、指南和最佳實踐的使用，稱之為“信息參考”,。NIST CSF的附錄A提供了參考資料,，其中涉及通用框架，如COBIT 5,、ISO/IEC 27001:2013、NIST SP 800-53版本4和其他（詳見NIST CSF附錄A）,。但是,，請注意，NIST CSF的信息參考組件可以根據(jù)任何本地需求進行擴充,，無論它們是額外的外部框架,、指南和最佳實踐，還是內(nèi)部安全政策和標(biāo)準,。

該活動為架構(gòu)師準備好合并可能影響邏輯安全架構(gòu)的安全標(biāo)準,、指南和其他最佳實踐。忽視這些輸入,，將帶來與合規(guī)義務(wù)不符的風(fēng)險,。

SABSA方法要求，架構(gòu)必須滿足業(yè)務(wù)需求,，而且標(biāo)準的納入是實例化業(yè)務(wù)需求的一種形式,。SABSA與NIST CSF一樣，并沒有取代標(biāo)準,，相反,，它需要能夠與標(biāo)準保持一致。這有助于部署滿足所有業(yè)務(wù)領(lǐng)域（包括合規(guī)性和治理）的所有需求的控制,。

這個階段的關(guān)鍵活動包括支持技術(shù)設(shè)計需求,，確保防御是分層的，確?？勺匪菪?，以及幫助供應(yīng)商選擇過程。

5.a. 支持技術(shù)安全架構(gòu)設(shè)計

準備技術(shù)安全架構(gòu)的設(shè)計,。這將要求架構(gòu)師深入理解將在其中實例化控制的技術(shù)環(huán)境,。它還將要求架構(gòu)師與技術(shù)領(lǐng)導(dǎo)層和干系人進行更多的交互。

邏輯安全架構(gòu)的服務(wù)需求和期望是通用的,，與技術(shù)無關(guān),。它需要那些負責(zé)所有相關(guān)IT環(huán)境的安全從業(yè)人員和技術(shù)干系人的洞察和經(jīng)驗。這種方法將有助于產(chǎn)品和能力的選擇,。當(dāng)控制可能受到兼容性或集成方法的影響時,，甚至存在性能問題的情況下，這一點尤其重要。

SABSA和NIST CSF創(chuàng)建安全架構(gòu)的方法,，都要求安全過程,、工具、供應(yīng)商能力與邏輯安全架構(gòu)要求一致,。

您必須收集有關(guān)技術(shù)企業(yè)的相關(guān)信息,，以幫助了解在何處以及如何應(yīng)用技術(shù)安全。從收集的詳細技術(shù)信息,，轉(zhuǎn)移到技術(shù)安全架構(gòu),，需要映射到邏輯安全架構(gòu)需求。這可以使用SABSA或NIST CSF方法進行,。

圖6所示的示例,，使用了由CSF類別和子類別定義的NIST CSF安全服務(wù)映射，顯示了從更廣泛的映射活動中提取的內(nèi)容,。

在定義了邏輯安全架構(gòu)之后,，SABSA致力于定義兩個架構(gòu)層，作為我們在本研究中廣泛描述的技術(shù)安全架構(gòu)的一部分：

■ 第一個是物理架構(gòu)：該層定義了過程機制,、需要保護的資產(chǎn),，包括基礎(chǔ)設(shè)施系統(tǒng)。

■ 第二個是組件架構(gòu)：進一步詳細說明技術(shù)服務(wù),，如供應(yīng)商工具,、特定流程、用戶身份和低級別的能力應(yīng)對,。

在定義這些時,，可以將安全能力進行分組以實現(xiàn)。這就制定了SABSA的行動計劃,，并根據(jù)能力解決的風(fēng)險,，確定了路線圖的優(yōu)先級。

將控制需求與能力進行映射,，允許測試能力的總體覆蓋范圍——確保所有控制需求都具有某種解決它們的能力,。這種映射方法還允許進行選項分析——可以測試控制方法的候選分組（例如，不同的模式或不同的補償控制集）,，以確定覆蓋需求的程度,，從而做出決策。

圖6-從NIST CSF安全服務(wù)映射到技術(shù)安全架構(gòu)組件

5.b. 確保分層防御（縱深防御）

縱深防御是任何安全架構(gòu)都要展示的重要特性,。因此,，架構(gòu)師應(yīng)該準備好測試技術(shù)安全架構(gòu)控制（包括組裝的供應(yīng)商工具）是否確實提供了主要的和補償?shù)姆謱臃烙?/strong>，來保護范圍內(nèi)的企業(yè),。

NIST CSF在組中使用核心功能和類別來組裝控制,，這些組（假設(shè)控制部署在這些組中并用于相同的受保護資產(chǎn)）將提供該層的控制集并相互補償,。這是使用CSF結(jié)構(gòu)的一個顯著好處，并且?guī)椭思軜?gòu)師有意地對控制集進行分層,。

由于SABSA在組裝邏輯和技術(shù)安全架構(gòu)方面更加開放,，因此它使用了不同的方法來確保分層防御。SABSA提供了“多層控制策略”,，其中包含與NIST CSF中固有的核心功能結(jié)構(gòu)相似的元素,。因此，它有助于確保,，已確定的控制措施確實能夠起到分層和補償其他控制措施的作用,。

SABSA多層控制策略如圖7所示，并顯示了如何使用不同的策略（威懾,、預(yù)防、檢測等）來應(yīng)對風(fēng)險,。在應(yīng)對特定風(fēng)險的策略中,，控制措施的組合提供了分層和補償能力集。

圖7-SABSA多層控制策略

5.c. 將可追溯性管理納入策略

可追溯性是框架和方法論方法的固有能力,。這是任何好的安全架構(gòu)思想的一個特點,。確保可追溯性,，使架構(gòu)師能夠：

■ 為審計師和風(fēng)險經(jīng)理提供證明符合架構(gòu)和風(fēng)險管理期望的方法,。

■ 為高層領(lǐng)導(dǎo)提供有關(guān)安全支出如何專注于業(yè)務(wù)需求的見解。這有助于證明安全能力部署的合理性,。

■ 評估安全架構(gòu)提供的“完整性”程度,。

■ 將控制與解決特定風(fēng)險的需求關(guān)聯(lián)起來，并分配風(fēng)險所有權(quán),。負責(zé)任的業(yè)務(wù)領(lǐng)導(dǎo)人,，將有能力查看風(fēng)險是如何解決的。

可追溯性是框架和方法論方法中的一種固有能力,，從邏輯需求一直追溯到技術(shù)和過程控制,，并且可以反過來，因為它是一種雙向特性,。

在戰(zhàn)略層面,，NIST CSF沒有明確指導(dǎo)架構(gòu)師，如何考慮戰(zhàn)略業(yè)務(wù)需求之間的關(guān)系,，以及這些需求如何影響框架,。因此，為了確保從業(yè)務(wù)上下文到技術(shù)控制的可追溯性,，框架的用戶將需要使用一種方法,，例如SABSA的業(yè)務(wù)屬性概要。如第2階段所述，SABSA研究所啟動了SENC項目“SABSA增強的NIST網(wǎng)絡(luò)安全框架”,，該項目的基本原理是為NIST CSF提供了基于SABSA的業(yè)務(wù)屬性概要的方法,。

可追溯性是為不同的干系人定義具有多個視圖的架構(gòu)的重要部分。沒有它,，技術(shù)架構(gòu)可能與業(yè)務(wù)目標(biāo)和戰(zhàn)略需求不一致,。隨著時間的推移，這種不匹配將帶來無法預(yù)見的風(fēng)險,，這是由于無法將邏輯需求與技術(shù)部署協(xié)調(diào)起來所造成的,。

5.d. 支持組件和供應(yīng)商選擇的決策

組件和供應(yīng)商選擇的準備工作，包括積極熟悉可能需要的安全工具,。架構(gòu)師應(yīng)該調(diào)查新技術(shù)和方法,，以確定它們的有效性。

通過使用邏輯安全架構(gòu)中的需求,，可以定義一組與技術(shù)無關(guān)的期望,。這可用于評估滿足需求的不同技術(shù)和過程選項。有幾種不同類型的評估,，可用于支持組件和供應(yīng)商評估,。組件、過程和供應(yīng)商產(chǎn)品的組合可以相互評估,，以確定是否適合滿足要求,。或者,，可以比較各種方法,，甚至是解決安全需求的供應(yīng)商工具。

供應(yīng)商選擇的最后也是最重要的支持來源,，將是參與供應(yīng)商選擇的其他干系人,。與技術(shù)干系人建立良好的工作關(guān)系，包括設(shè)計權(quán)威和領(lǐng)域?qū)＜?。這將有助于支持在選擇和構(gòu)造解決安全需求的選項時所做的努力,。他們的見解將有助于解決重要的方面，例如性能影響和規(guī)模影響,，以及工作負載影響如安全軟件部署,、處理速度和潛在延遲、與基礎(chǔ)架構(gòu)和應(yīng)用程序組件的兼容性,、集成路徑等,。

（本篇完）

本篇文章來源于微信公眾號: 網(wǎng)絡(luò)安全觀