文章段落
Continuous Security
雲端時代的來臨，讓DevOps這個名詞一時間流行起來。DevOps無非是讓公司的平台服務“快速部署”及“快速的測試”達到公司想要的outcomes是合於期望的。但快速的結果可能是讓整個平台的安全打了折扣。
請參考下圖，右手邊多了一塊是把Security加入考量的因素。
DevOps是一個持續不斷的對軟體產品做出快速的功能釋出及優化並且能提高開發人員與維運人員的協同作業，故在DevOps這一部分很多的工作都依靠自動化的作業。這一部分很多DevOps工程師都已經有相當的經驗了，這一篇我們淺談企業在實行DevOps的組織型態時如何能把安全的部分融入成整個DevOps的一部分且也不會讓Security拖累DevOps效能與效率。
Security in DevOps
關於這一點已經有很多專家在講DevOps的組織文化了，我們不在這裡「掉書袋」了。
相反的在Security裡，資安團隊著中的可能是如下的議題
1. 根據內外部的法規法例及標準，我們的產品有沒有符合.例如歐盟的GDPR
2. 我們的產品目前有多少的security incidents
3. 我們的產品還有多少的資安問題需要上patch的
等等
傳統上開發團隊與資安團隊常常會因為各自的目標不同可能有互相對抗的狀況發生，這對企業整體運作無疑是不好的事。
如何讓DevOps與Security運作順利呢？
哪就必須讓Security融合成DevOps的一部分，DevOps教導我們把Development 跟Operation融合再一起。這時我們必須也要把Security融合近DevOps(如上圖）。DevSecOps–將DevOps的焦點，從整個CI/CD的快速部署整合把層次拉高到整個組織對資安的要求。成為之前提到的在整個產品的開發週期及維運中也把security加進去成為”continuous security”。
Continuous Security
這裡我們分三個面向
1. 以測試導向的資訊安全
2. 監控與資安事件的回應
3. 風險評估與逐步成熟的資安防禦
以測試導向的資訊安全
資訊安全的第一步是要定義我們要“控制“的部分有哪些，定義之後就需要施作而後做測試。例如在Linux 的 OS裡有哪些標準設定需要做，例如要不要開firewall，要開什麼port。什麼服務這台Linux只有提供Web service是不是應該只開Apache服務要不要有TLS的加密等。這些都需要被定義好並與相關的團隊協調後能夠施作而且能夠定期的稽核這些設定是否有符合規則，最好能夠夠自動化這一類的工作。例如Chef 的Inspec能夠支援這些稽核要求，甚至在CI/CD的階段也能夠把這些資安要求加入。例如把OWASP top 10的檢查在CI/CD 階段就加入檢查。
簡單的來說就是把我們對整個產品的security baseline是什麼，這些基本要求要能夠在security/developers/operators三個團隊間達到成一致，確認這些基本要求都很重要。在Application/Infra layer都需要有一些security baseline都需要達到。
在CI/CD的Pipeline中，security control也很重要，若是這些服務被外來的駭客攻擊放置一些malware，哪所做出來的產品就可能有後門讓駭客來控制。
持續性的自動化安全測試
如同TDD的精神，我們也必須先把測試的要求先定義實作出來。每一個我們要求的資安控制項目都有達到才能進行下一個步驟。所以在CI/CD及 IaC(Infrastructure as a code)都需要有定義好的資安要求並能在每個階段持續不斷的測試（如下圖）
以測試導向的資訊安全的方式有幾個好處
1. 預先寫好這些資訊安全要求，並產出相關的文件。文件中能有非常清楚明白的定義讓開發人員能夠完全的了解，哪麼開發人員在建立產品時就可以一併將這些資訊安全要求銘記在心。不用像以前開發的方式，功能做出來了才被要求去修正永遠也修正不完的資安要求。
2. 每個資安要求都能夠非常明確，例如 “網路通訊間要加密”，這對技術人員來說非常模糊的說法。在Server 與client間要有Https的加密方式
3. 有了一般化的資安要求後，這些一般化的資安控制要求就能被一再重複在不同的產品使用。因為這些資安控制項都是基本的。
4. 當這些要求在整個產品週期中都被實行後，我們需要再對產品做相關的資安修補就可以大幅減少。團隊可以把多餘的心力聚焦在其他工作上。
監控與資安事件的回應
相信所有人都知道監控的重要，因為只要服務放在網路上，總有一天你的服務一定會受到各式各樣的網路攻擊。而所以監控就變得很重要，監控的層面也變得很廣。從infra層到程式端甚至是資料本身也須要被監控，然而每個公司的資源有限我們不太可能每一個資安層面都能面面具到的照顧到，所以這時資安的要求必需要被分優先權。
我們需要透過監控的方式來達到1)偵測整個產品服務的異常，不管是在哪個層面infra layer/ Application/ Data layer這些平常服務產生的我們需要從中去做相對應的分析。但如此多的不一樣層面及大量的的log資料來源需要做此類的分析可能就很耗時與困難，而且什麼叫正常什麼叫異常可能整個團隊一開始也沒辦法完全定義的很清楚，這時也許UBEA(User and entity behavior analytics)是一個不錯的選擇。2)若有資安事件發生這些監控的資料能夠成為資安鑑識重要資料來源。
關於什麼是UBEA可以參考以下的連結解說
https://www.varonis.com/blog/user-entity-behavior-analytics-ueba/
除了分析log之外，我們要如何偵測入侵者呢？一般傳統的方式是使用IDS(Intrusion detection system)進階一點的就再使用IPS(intrusion prevention system).若是使用VM的方式部署服務，哪Host base IPS/IDS也可能一併部署下去。但如同我們之前有文章提到部署了這麼多資安控制項在我們的環境裡，有沒有可能會影響我們的效能與設定操作的複雜性，這些都需要被考量進去。
再來網路層面就會是用Netflow的方式監看目前所有連線是不是都是正常合法的，有沒有不正常的連線。這在傳統機房或雲端的IaaS模式不是太難，但在PaaS模式例如Container下困難度就會很高。
如何做到當有資安事件的攻擊能快速反應呢？若是一般沒有準備好的團隊一定就是手忙腳亂毫無章法，往往不知怎麼應對。這裡提供六個階段幫助你做好準備
1. 準備階段—確保你有最低限度的標準程序來對應這些資安事件
2. 確認階段–快速且準確的辨認資安事件是否發生
3. 圍堵階段—一但確認後要防止事件狀況惡化
4. 消除階段— 消除此一資安事件
5. 回復階段— 將產品服務回到上一次的已知的良好狀況
6. 學習階段— 回顧這一個事件為何發生的來龍去脈，並修正在準備階段的資安標準程序，防止依後有相同事件發生
這是一個循環的程序，一個PDCA的模式
風險評估與逐步成熟的資安防禦
一個完整的持續安全的環境會建立在良好的文化組織與管理上，所有成員對資安都有ㄧ致的共識標準。之後就是在技術層面上施作與標準的資安事件的回應程序。
但其實在組織中，”人員“的部分才是最大風險，如何在DevOps team裡做好風險管控呢？
風險管理就是需要“辨認”什麼樣的“威脅”會對我們的服務造成“危害”，這些威脅需要被分“優先順序”制定“對應的方式”。在DevOpos team良好的風險管理必須達到三個目標
1. 如同DevOps的做法，對資安議題要有快速小量的疊代。每次針對的資安提議能夠被分類的夠小夠明確，能在很快的時間組成一個程序
2.自動化， 這也是 DevOps重要的部分，如何把自動化應用上資安議題上。
3. 需要組織裡的每一個人參與資安事件的討論，並且能像討論功能開發一樣建立與維持產品的安全是需要團隊合作的。
另外要讓產品的資安防禦逐漸的優化，持續的資安測試也是不可或缺的。團隊內部可以針對產品或服務持續性的測試，例如 vulnerability scanning, fuzzing, static code analysis, configuration auditing等等整合到CI/CD的pipeline之中。且 CI/CD是在DevOps team的SDLC(Software development lifecycle)架構之下。
我們同時也可以雇用外部廠商來扮演外部的攻擊者，對我們的產品或服務(非正式環境）做攻防演練，由外部廠商扮演紅軍內部成員為藍軍定期攻防演練。可以紙上作業（類似軍隊的兵棋推演）到模擬測試。
總結，成熟的資安產品服務需要時間逐步成熟。如何將資安如入產品或服務甚至融入公司的組織中，這需要公司的高層有強烈支持下才有辦法運作。但在這轉型的期間雖然可能會很痛苦，但所帶來的效益將不只是技術與知識方面進步還有整合團隊的合作並請能帶來好的顧客滿意度.
