# 大型國際銀行DevSecOps的進一步實踐 - 架構安全左移 - 周紀海(Jihai) {%hackmd @HWDC/BJOE4qInR %} >#### 》[議程介紹](https://hwdc.ithome.com.tw/2024/session-page/3162) >#### 》[填寫議程滿意度問卷|回饋建言給辛苦的講者](https://forms.gle/M6jYNBZsYPKBwoV98) ## IT在金融行業特有的挑戰與文化 * 互聯網的IT本身就是業務利潤中心 * 銀行的IT是成本中心,兩種完全不同,IT不是直接創造收入的部門,不是那麼受重視 * 只在意結果 * IT部門協作不協調 * 高層只關心業務交付而不在意如何去改進 * 金融行業的監管與安全的特殊要求,數據敏感,要求相當高 * 整個開發過程追求穩定,按部就班,繁瑣的審批流程,瀑布式更適合 * 開發流程很慢,試錯成本很高,創新風險很大,不像遊戲錯誤可以用回饋的方式 * 銀行裡面存在陳舊系統,20, 30甚至40年,像是IBM AS400 * 大型主機規模很龐大,延伸到幾十個國家,並不容易去改動 * 單體架構為主,依賴很多,更改很慢 * 使用RPG語言 * 但很多工具都只支持比較新的操作語言 * 花費很高,效率很低下 * 第三方採購的系統在公司裡的二次開發 * 就像是一個黑匣子 * 增加溝通協調的成本 - IT在金融業特有的挑戰: - 金融業的 IT 部門是成本中心,不直接創造利潤 - 安全要求高:監管重,資料敏感 - 金融行業技術更新慢, 創新有風險,且試錯成本高 - 銀行裡普遍存在的陳舊系統 (AS400) - 銀行裡的第三方系統是黑盒子,無法取得原始碼 ## DevOps 10年歷程 為什麼實施10年大範圍的DevOps轉型. 1. 提高效能 2. 更快/更好/更安全的業務交付, 提高巿場競爭力. 3. 通過轉型, 最終在公司實現DevOps/DevSecOps文化. 2014: DevOps 2016: CICD + OKR 2018: Org change + 快速發佈模式 2019: BizDevOps & DevSecOps試點 2021: DevSecOps推廣到整個滙豐 ## DevOps 工具棧和自動化 - 任務管理工具 - 源代碼管理工具 - 代碼品質分析工具 - 持續整合工具 - 編譯工具 - 單元測試工具 - 製品管理工具 - 自動化測試工具 - 自動化配置和發佈工具 - 監控工具 ## 核心度量指標和 OKR - 核心度量指標 - PDPTPPY (Release Frequency) - Incident Number - Lead Time - Change Failure Rate - OKR - Double PDTY - Half Incidient Number (每年 Release Freq 要2倍, incident 數量減半) ## 組織結構轉變 - 敏捷化 變成Feature Team # 從 DevOps 到 DevSecOps 的轉變 ## 什麼是 DevSecOps DevSecOps 最終目的是將信息安全意識"左移"到開發團隊, 融入到開發過程的每個階段, 最終讓所有人對安全負責. ## 為什麼需要 DevSecOps 讓開發速度更快, 成本更低, 更好的控制風險 (安全測試融入到開發流程的關係) ## 從DevOps到DevSecOps 1.安全人員加入到開發團隊. 減少溝通effort, 減少對立之類的 2. 開發人員有安全意識, 那麼也不需要安全部門找上門 ## 實現DevSecOps的挑戰. - 主要還是人跟文化 - 人不夠重視/也需學習成本/需高層支持 - 技術 - 流程 ## 安全左移體系建設 ## DevSecOps技術 - SAST (對代碼掃描) - e.g. SonarQube, 挑戰是不準確 - 白盒技術 - DAST - 黑盒技術, 模擬hacker攻擊.好處是相對精準, 挑戰是成本較高 or 產生一些dirty data - IAST - SCA - 分析應使用的第三方是否有問題. - RASP ## 工具管理平台 - Cyberflows (匯丰自行開發的) 控制工具, 去觸發相對應的技術(SAST,SCA). 另外好處是數據收集. ## DevSecOps 度量 - 工具是否使用 - 安全漏洞SLA ## 安全培訓 -- 對開發團隊做培訓 ## 安全編碼培訓平台Secure Code Warrior ## 模擬攻擊 ## 開發團隊的安全專家 ## 安全編程競賽 ## 社區分享和識庫建設. 更進一步左移-- 安全架構設計 OWASP A04-2021- Insecure Design 在項目設計階段, 就讓安全工作介入 ## IriusRisk - 威脅建模自動化評審平台. --- 這是我剛剛打錯位置的版本.. # 匯豐銀行DevOps轉型10年歷程 ## IT在金融行業特有的挑戰與文化 * 互聯網的IT本身就是業務利潤中心 * 銀行的IT是成本中心,兩種完全不同,IT不是直接創造收入的部門,不是那麼受重視 * 只在意結果 * IT部門協作不協調 * 高層只關心業務交付而不在意如何去改進 * 金融行業的監管與安全的特殊要求,數據敏感,要求相當高 * 整個開發過程追求穩定,按部就班,繁瑣的審批流程,瀑布式更適合 * 開發流程很慢,試錯成本很高,創新風險很大,不像遊戲錯誤可以用回饋的方式 * 銀行裡面存在陳舊系統,20, 30甚至40年,像是IBM AS400 * 大型主機規模很龐大,延伸到幾十個國家,並不容易去改動 * 單體架構為主,依賴很多,更改很慢 * 使用RPG語言 * 但很多工具都只支持比較新的操作語言 * 花費很高,效率很低下 * 第三方採購的系統在公司裡的二次開發 * 就像是一個黑匣子 * 增加溝通協調的成本 ## DevOps 10年歷程 * 提高研發效率 * 2014滙豐開始DevOps轉型,開始試點 * 2016年自動化,度量跟OKR,大範圍的推廣 * 2018組織結構轉變,和快速發布模式 * 先前有大型的開發團隊數十人道上百人,專門的測試團隊,專門的運維團隊 * 測試人員不夠的話就要等待 * 大型開發團隊跟測試、運維團隊打散重新組成,一個以服務或模組為主的小型團隊,避免部門牆的問題 * 轉型也是非常痛苦,經歷2-3年的時間才完成轉型工作 * 2019年嘗試bIZDEVOP跟DecSecOps * 2021年整個滙豐進行推廣 * 滙豐口號:Go Fast, Break Less ## DevOps 工具棧以及自動化 * Jira * Github, Bitbucket, RTC(大型主機) * Sonarqube(企業版) * CI: Jenkins, TeamCity * Build: Maven, MSBuild, Gradle * Unit: JUnit, NUnit * Repo: Nexus * E2E Test: Selenium, QTP, Jmeter * 自動化配置: Puppet, Ansible * 監控工具: [...] ## 核心度量指標和OKR * COre * Release Frequency * Incident Number * Lead Time * Change Faulure Rate * OKR * Double PDTY (發布個數需要每年遞增一倍) * Half Incident Number (每年事故次數減少一半) ## 組織結構的轉變 - 敏敏捷化Pod團隊 # 從 DevOps 到 DevSecOps的轉變 ## 什麼是DevSecOps 把信息安全意識左移到開發團隊,讓所有人對安全負責 ## 為什麼我們需要DevSecOps * 傳統開發模式從寫代碼到上線需要3週時間加上一週的安全評審時間 * 通過CI/CD自動化種種的方式減少前面三週時間,但安全評審時間還是一週 * 如果還要更快瓶頸就在安全評審這段,透過左移工作到Dev這塊 * 好處是更快而且成本更低,更好的控制風險 ## 安全左移 * 不僅是左移工具,還有把安全能力也左移 ## 從DevOps 到 DevSecOps * 安全管控不用推到最後的環節 * 為了業務更快進入市場會避開安全評審,這會有很大的風險,透過DevSEcops可上線的同時又達到安全 * 安全專家不懂業務,業務專家不動安全,但通過左移能更好跟安全人員協作 * 以前的時候覺得安全專家是警察的角色讓人又愛又恨,發現問題卻不解覺問題,但現在不需要安全部門來找你,妳自己就能解決 ## 實現DevSecOps的挑戰 * 技術方面就是不夠完善,主要挑戰還是來自於文化 * 包括學習成本,開發人員就是寫代碼的為什麼還要搞安全呢?不接受左移的理念 * 最後還是很多技術高管本身沒有那麼接觸DevSecOps * 第一步要做甚麼? 對高層洗腦,讓高層接受這個意識,由上往下推動比較簡單 # DevSecOps安全左移體系檢設 ## DevSecOps 技術 * SAST(靜態應用安全掃描),例如Sonarqube,好處是精準的告訴你那一行代碼存在什麼安全漏洞,程序原比較容易接受,缺點:誤報率很高,10個漏洞其實2,3個不是漏洞,並不是100%準確,需要投入人力物力去驗證。 * DAST(動態應用安全技術),黑盒技術,模擬黑客攻擊,安全模擬,例如透過送Payload來模擬黑客攻擊,可以精準進行掃描,缺點:使用成本高,會產生一些髒數據 * IAST(交互式應用安全技術): 透過插Agent擷取流量進行安全掃描,要部署到每個伺服器,所以部署成本很高 以上是用來保證自己的程式安全 * SCA(軟件成分分析技術): 保證第三方 * 實時應用安全保護技術(RASP ## DevSecOps 工具和自動化 DevSecOps * Threat Modeling : Iris Risk * SAST : Checkmarx * SCA : Sonartype * IAST : CONTRAST * DAST : Netsparker * Infra Security : Nessus * Log : Elastic & Splunk Production * Monitoring : Grafana, ITRSGEneos * WAF & RASP ## DevSecOps 工具管理平台 - Cyberflows * 滙豐平台自研 * 透過這個平台可以控制各種不同管理工具來手動進行掃描,可以用來統一進行數據收集 ## DevSecOps 度量 * 各類安全工具是否有使用 * 上線前有沒有解決安全漏洞 * 安全漏洞的趨勢 * 安全漏洞SLA 發現問題,但是要怎麼解決?最終還是靠程序員 ## 安全能力建設:安全培訓 * 透過線上線下進行培訓 ## Secure Code Warrior 線上安全編碼培訓平台 * 有哪些漏洞 * 要怎麼修復 ## 安全能力建設: 模擬攻擊 * 程序員沒有動力 * 沒有人攻擊的話,影響是不會顯現出來 * 會產生僥倖心裡,沒有人來攻擊我就是安全的 * 讓程序員轉換角色變成攻擊者,會設立靶場讓程序員主動攻擊,讓他們自己能深刻體會到,增強安全意識 ## 組織結構 - 開發團隊的安全專家 * 一樣會培養開發團隊內的安全專家,會提供3個月的培訓 (Security Champion Program),透過種種的學習與實操 * 讓Security Chaptio貢獻我們的社區 ## DecSecOps 文化建設 - 安全編程競賽 ## DevSecOps 文化建設 - 社區分享和知識庫建設 * 可以去Knowledgebase找 # DecSecOps 更進一步左移 - 安全架構設計 ## OWASP TOP 10 * 每幾年總結的安全隱患 * A04: 不安全的設計 ## 為什麼需要安全架構設計 * 監管機構要求越來越高 * 讓安全工作更徹底 ## 目標一: 讓安全控制進一步左移,為開發團隊賦能 ## 滙豐信息安全部門與證券部門的的協作案例 * 三個層面 ## 角色與定位 * 開發團隊 * 產品經理/專案經理 * 安全架構員 * 架構師 * DevSecOps負責人 * 安全專家 ## 安全設計文黨的規範化與自動化 * 安全部門把文檔標準化之後可以初步對安全文檔進行分析減少後續成本 ## 威脅建模自動化評審平台: IriusRisk ## 威脅建模工作的左移與自動化 * 傳統的安全評審模式只要開發部門把安全文檔維護好之後由安全團隊進行評審 * 新的左移模式則是設計文檔還是由開發團隊進行維護,在威脅建模當中進行架構圖設計(以前是由安全部門進行),然後透過工具進行自動化的安全評審,最終再透過安全部門進行驗證 * 跟過去相比,大部分工作都左移到安全團隊 # DevSecOps未來展望 * Security Development * Secure Architecture Design * 3rd party challenge * DevSecOps Community * Hacking Box Training * Cloud Security * Knowledge Base * Open Source ## AI助力DevSecOps * 用AI分析誤報來降低誤報率 * AI可以協助解決安全專家的緊缺問題 * AI能否協助程序員進行培訓 ## 最終目標: 群體免疫 * 作疫苗就是用來抵抗病毒,作DevSecOps就是用來進行群體免疫,全體對安全負責。 ===以下聊天區=== 第1頁講快10分鐘了. 這個會後會提供影片或是他的 PPT 嗎 => 應該會提供power point => 要作者同意才會提供. 感覺冷氣有點冷.. 銀行的成本單位願意花在IT上的錢還是一般小型企業望塵莫及的,這些安全掃描方案有一定使用量應該也是不少錢。 -> 一般小型企業願意花的成本只夠買綠乖乖 時間超過了.. AI幫助DevSecOps -> 需要更安全地使用AI -> 工作永動機 AI幫助 DevSecOps -> 讓 AI 自己做 -> 躺平 ^^ 標準教科書做法,很厲害