GSS資安電子報0190期【十招讓你提升應用系統安全】

在企業的各種服務中，軟體應用程式往往是最具風險的部分。在Forrester ”The State of Application Security, 2020”的報告中，也提到大多數外部的攻擊事件都是透過軟體弱點(42%)或是應用程式漏洞(35%)的方式進行攻擊。

由於開發模式改變，應用系統複雜度提升及交付時程縮短等，開發人員往往被要求在短時間壓力之下盡快上線新功能，使得開發人員更加依賴第三方函式庫(尤其是開放源始碼也就是Open Source)來寫出更強更獨特的應用系統。而因為開放源始碼在使用上越來越頻繁，企業開始調整他們的資訊安全措施；此外，微服務(Container)和API的盛行，將此類服務模組化的新架構，也使得資安措施的擬定更加複雜。 面對這一波業界的新趨勢，企業已經開始感到壓力，擔憂安全性跟不上新開發需求的風險。 而企業確保軟體安全的方法之一就是採用”應用程式安全最佳實例”並將之整合進軟體開發週期(SDLC)中。 以下提出前十大”應用程式安全最佳實例”供企業選用並實行。

1.掌握你的資產

為了掌握資產並進而保護，可以試問自己是否知道下列問題: 你知道你的服務、應用程式、網站是在哪些伺服器上嗎？ 你提供的各種服務、應用程式、網站包含了哪些開放源始碼(Open Source)？ 如果你認為以上問題與掌握資產無關， 試著了解美國三大信貸機構Equifax所發生的資安事件吧！Equifax因為未能保護好超過1.45億筆客戶資料而受到7億美元的法律訴訟罰鍰!就說明了解自己營運或使用的應用系統(含供應鏈服務、網站)上有那些軟體在運作是相當的重要。 即使Equifax聲稱他們不知道網站正在使用易受攻擊的開放源始碼，但他們確實未能修復涵蓋弱點的開放源始碼Apache Struts也導致Equifax這家信貸評級機構造成不小的損失。

持續追蹤並掌握你的資產可以避免以及節省各種麻煩，而且這個過程應該要自動化，隨著組織的擴張及發展，這任務會變成一個無盡迴圈。

且除了掌握資產之外，還需要花些時間整理分類你的資產，標記哪些資產對你的業務服務是極重要的，哪些是次重要的? 排定其重要性將對於後續風險評估以及補救措施有著相當大的幫助。

2.施行風險控管

列出各項供應鏈服務、應用程式、網站之後，就可以開始研究開放源始碼所帶來的威脅並擬定修復排除或是降低發生機會或是影響層面的方案。

在組織施行資安措施時常見的考量如:駭客可以使用哪些途徑破壞你的應用程式？ 組織內是否已經具備檢測相關的安全措施以及防禦駭客行為的手段？或是目前組織內需要其他面向的工具? 此外我們需要對組織內擁有各項安全措施做現實面的考量，畢竟即便做了各項防護甚至是最高層級的保護措施，也不能保證百分百不會被駭客攻擊。所以我們必須從長遠的角度來誠實地評估，制定組織能夠負荷的規範，過於嚴格的規範只會淪為口號，要記得資安就像馬拉松，而非短跑。

而在判斷風險時請使用以下基本公式: 風險=攻擊概率x攻擊影響 思考風險的另一個方式，就是評估事件發生的可能性及發生後的嚴重程度之間的關係。就像走在路上鯨魚掉下來砸到自己的機會很低，儘管被砸到的後果很嚴重，你不會因此不敢出門；而遠足時可能會被蚊子叮的機會很高，但除了幾處叮咬傷外，不會對自己造成多大的危害。

3.保持在最新版本

你是否使用最新版本的作業系統？那第三方的軟體呢？ 如果你的答案是否，那你可能暴露在風險之中。 

定期更新所使用的商業軟體或是開放源始碼來修復軟體是確保軟體安全性的重要步驟之一。建立弱點管理機制(如WhiteSource Vulnerability Database)當各項產品、專案內發現新的弱點時，將發布通知及報告給相關負責人，以及做到在發布之前提供修復建議，提供各負責人保護其軟體的機會。

然而如果沒有導入相關機制，無法於第一時間修復風險，就無法提升我們的資安層級。 WHITESOURCE REPORT - DEVSECOPS INSIGHTS 2020Download Free Report 若更新至最新版是否將影響服務是開發人員的顧慮，其實選擇導入自動化工具就可以有很大的幫助，讓部署變得簡單且頻繁。在每一週, 每一天你的版本都會是最新的。

4.管理組織內的微服務Containers

在近年來，越來越多企業因其靈活性擁抱這項技術，而Container使得在整個SDLC中在各種環境進行建置、測試和部署變得更加容易，也變得越來越流行。

目前普遍認為Container是安全的，有鑑於其特性如獨立的OS環境及功能導向的細分，可以降低其他服務涵蓋的風險。但Container仍然面臨漏洞被利用的風險，例如透過服務之間資料交換的過程，植入惡意語法進而做到竊取機敏資料或是使得服務中斷等手段。此外，存儲在Container中的程式碼本身就可能容易受到攻擊。

為確保你的環境是否安全，建議在CI/CD環節應該從頭到尾(包含服務儲存庫( Container Registry )的每個環節)去做自動化檢測，確認你的開放源始碼還有自行開發的程式碼是否涵蓋漏洞。

除了在各環節制定檢測機制之外，使用Container還包括幾項重要的做法，例如，如果您使用的是Docker Hub，則使用Docker Content Trust之類的工具對自己的Image進行安全簽章；如果您的團隊在Microsoft Azure上，則使用共用存取簽章。

5.補救措施應制定優先序分類機制

近年來開放源始碼弱點數逐年增加，沒有任何一點要停止的跡象。而規劃修復階段，開發人員在資訊安全與功能開發之間，往往取得不到一個好的平衡點，因此對於一個開發團隊來說擬定優先序分類機制是至關重要的。

為此我們必須根據漏洞的嚴重性（CVSS等級），對於應用程式、系統、服務影響層面嚴重程度以及各種其他因素來執行風險評估。考慮到優先序分類，將影響開發團隊的時程規劃，對於開放源始碼涵蓋弱點的精確性以及程式是否實際使用到該套件將變得格外重要。

總結開發團隊應考慮各種因素，對嚴重度較高的風險安排優先序加以解決，並將嚴重度較低的風險排至較為後期的修復事項。

6.加密、加密、再加密

數年來，弱加密問題一直名列於OWASP Top 10的榜單上，任何應用程式不管是靜態資料或是傳輸中的資料都應該加密。

當傳遞資料時，遭受中間人攻擊或是其他形式的攻擊手法洩漏相關機敏資料，若沒有任何加密手段，將可能明文呈現用戶的帳號、密碼等相關資訊，屆時將影響用戶及公司權益。

而在盤點哪些數據該加密時，也應該確認使用的SSL驗證為最新，當然雜湊（Hashing）也有助於提升安全層級。

另外，也請記住別使用自己設計的加密方式或加密演算法，應該使用專業並且涵蓋豐富經驗的團隊開發的資安產品或技術來正確執行。

7.權限控管

依照使用需求給予相對應的權限，可以避免任何角色都能使用所有功能，正如網路安全指南說的，每一次的資料交換都應該經過正確的身分驗證和授權。

用意自然是針對像是當駭客取得系統的訪問權限，可以阻止駭客存取其他系統的機敏資料，甚者防止內部風險，如筆記型電腦遺失或在寫email的時候，附上錯誤的檔案，或是有心人士的惡意攻擊。透過特權帳號的管理，並遵循「最小權限原則」(僅給予員工讀取資料的權限)，就可減少組織暴露於風險的可能。

8.導入自動化流程來管理弱點

在近幾年，隨著資訊安全意識提升，開發人員對應用程式的安全性掌握越來越高，尤其是在涉及風險管理之類的任務時。開發團隊會儘早地進行測試，並且在弱點更容易修復、成本更低的情況下盡早修復。有鑑於弱點數量眾多，開發人員需要自動化工具來幫助他們管理繁瑣的測試過程。

為了在開發過程中測試程式碼，我們可以透過靜態應用程式安全測試（SAST）和動態應用程式安全測試（DAST）可以幫助組織發現程式中的潛在漏洞。但儘管SAST和DAST在彌補安全漏洞方面起著重要作用，但並非透過SAST以及DAST就能完全解決所有的安全漏洞。

近年來開發應用程式統計超過92％，其開放源始碼通常佔函式庫的60-80％。 這意味著應用程式的安全需把開放源始碼的安全性也加入到檢測範圍中。為此我們可以透過軟體組成分析（SCA）工具，可以幫助組織在SDLC上運行自動化的安全檢核並產出報表，並識別環境中的所有開放源始碼，並檢測哪些已知漏洞使您的應用程式處於危險之中。

只要我們把測試環節提前並整合自動化檢測開放源始碼，我們就能更有效率地管理每個應用程式的風險。

9.滲透測試

儘管導入自動化工具可以幫助您在發布之前解決絕大多數資訊安全問題，但是如果沒有引用滲透測試，就沒有完整執行應用程式安全這項工作。滲透測試人員可以驗證您的程式碼，發現系統潛藏的安全性弱點，好的滲透測試人員更了解駭客會用哪些手段攻擊你的系統。

你可以考慮聘請專業的駭客公司，也可以聘用從事漏洞獎金計劃的自由職業者，例如HackerOne和BugCrowd，他們可以自行尋找漏洞以獲取獎金。如果你還沒有贊助任何的漏洞獎金計畫，你應該趕快開始!

儘管聘請滲透測試人員將使組織產生額外費用，但以資訊安全的角度還是請白帽駭客嘗試攻擊，才能明白目前系統涵蓋潛藏的危機。

10.請小心使用、對待Token

大多數的開發人員都只注意保護自家Token往往忽略了保護串接第三方服務的Token。 圖

現況就是你可以在開發人員常使用的服務、社群網站看到涵蓋Token的現象，甚至將Token存放於開放源始碼的儲存庫這種公開的平台，而不是放在更安全的地方。

所以請勿再將你的第三方服務Token存放至程式碼中，給他人存取的機會。 應用程式最佳安全實作為基本實作 因此，上述項目中的所有內容，建議都導入至組織的開發流程中。這些項目包含了應採取最低限度的步驟，以最大程度地降低對貴公司的應用程式和資料造成的風險。

遵守上述項目可以在很大程度上避免了其他人可能犯的常見錯誤，使組織內的應用系統比其他人更難以被駭客利用。儘管沒有一項應用程式安全措施能夠完全抵禦駭客攻擊，但遵循並持續遵守這些項目才能使您的應用程式免受駭客的困擾，從而使組織內的資訊安全更加的落實。