原創|行業資訊|編輯:鄭恭琳|2020-12-29 11:51:35.500|閱讀 283 次
概述:使用正確的工具和正確的規則正確地設置靜態分析,將幫助您保護軟件安全,證明自己在為審核員做正確的事情,并表明您在遵循“設計安全”和“設計隱私”的原則。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關鏈接:
使用正確的工具和正確的規則正確地設置靜態分析,將幫助您保護軟件安全,證明自己在為審核員做正確的事情,并表明您在遵循“設計安全”和“設計隱私”的原則。
GDPR既龐大又令人恐懼。如果您不清楚GDPR到底是什么還是對您來說很重要,請看一下我的上一篇文章以獲取更多的概述。簡而言之,這意味著您必須讓用戶知道您要收集的數據,如何使用它們,盡力保護它,在發生違規時保持透明,并在他們要求時完全刪除任何用戶數據。哦,是的,如果您不遵守規定,將面臨巨額罰款。
從理論上講,GDPR僅適用于歐盟公民,但是如今,大多數商業活動在全球范圍內都需要盡力遵守全球法規。這樣,您就可以在以安全、私密的方式對待所有用戶,還是擁有針對歐盟和非歐盟客戶的完全分段的數據流之間進行選擇(例如,更昂貴的主張)。在此文中,我將說明如何利用靜態代碼分析來幫助改善數據保護和隱私。
考慮GDPR,數據保護和其他相關數據法規(例如PCI-DSS(支付卡行業數據安全標準)或HIPAA(健康保險可移植性和責任法案))時,立即想到的是需要增加測試,動態分析以及滲透測試。盡管這些測試技術是必要且重要的,但它們卻減少了發布不安全軟件的機會,而沒有真正使軟件更安全或首先確保了隱私。但是,除了質量或性能外,安全性和隱私性都不能“測試”到軟件中。因此,GDPR需要稱為“設計安全”和“設計隱私”(PbD)的概念,這意味著首先要更好地構建軟件。
“設計私密性方法的特征在于采取主動而不是被動的措施。它可以預見并防止隱私入侵事件在發生之前發生。PbD不會等待隱私風險的出現,也不會提供解決隱私違規行為的補救措施——目的是防止此類事件的發生。簡而言之,“按設計進行隱私保護”是事前的事,而不是事后的事。”
A. Cavoukian《設計隱私——七項基本原則》,2011年1月。
我提出這兩個概念是因為它們是正常的應用程序安全性活動(防火墻、滲透測試、紅隊、DAST等)之后的下一步。“根據設計”部分也可以理解為“內置”。這是一個想法,而不是戳您的應用程序并確定漏洞所在,而是首先構建一個沒有漏洞的應用程序……這是設計使然。例如,SQL注入(SQLi)仍然是最常見的漏洞利用之一。
有許多工具可以嘗試強制通過UI進行注入(滲透測試),或者在不運行程序的情況下模擬程序中的數據流,以查看污染的數據是否可以使其進入數據庫查詢(流分析)。“按設計”方法意味著在獲取輸入時,將任何輸入(來自數據庫,用戶或任何地方)包裝到驗證功能內部。這減少了數據可以繞過零的可能路徑。您仍然需要運行滲透測試以確保正確構建了軟件,但不同之處在于,如果pentest成功,則您不僅可以解決發現的一個弱點。取而代之的是,您回頭找出為什么成功進行過測試并構建您的軟件,使它不會成功。
如果pentest在您的軟件中發現許多安全漏洞,那么您并不是在“按設計”構建安全軟件。與“設計隱私”類似,我們會監視共享對象/共享對象/共享對象,并且除非另有說明,否則我們假定所有數據都很重要。同樣,通常程序員會假設數據ISN并不重要,除非特別標記。您可以在有關是否以純格式存儲數據或是否對數據進行加密的決策中看到這一點。加密所有內容是一種通過設計來保護隱私的方法。眾多的其中之一,但這是基本概念。如果您對所有內容都進行了加密,則不必擔心沒有對本應擁有的內容進行加密。
靜態分析的作用并不是要告訴我們我們的軟件容易受到攻擊(這是測試的工作)。靜態分析的作用是幫助確保軟件最初是強大的……通過設計。流分析作為安全測試技術已在過去10年中流行,但它仍然是一種測試軟件的方法,而不是一種強化軟件,內置安全性或“通過設計”進行安全性的方法。
如果正確使用靜態分析,可以將其定位為真正的預防技術。除了流程分析安全規則(即查找受污染的數據)外,我們還啟用了確保以安全方式構建軟件的規則。考慮到以上兩種情況,在設計時要進行隱私保護時,我可以使用靜態分析規則來標記何時存儲數據而不先進行加密,或者何時使用可破解的舊的不當加密方法而不是強加密,或者何時用戶嘗試訪問不適當的數據以獲得其預期的權限。
這是對示例規則的簡要說明,該規則在調用敏感方法時強制執行日志記錄。此靜態分析規則不會發現錯誤,但可以幫助您制作可記錄正在發生的事情的軟件,從而在生產中更加安全。此規則非常適合PCI-DSS和GDPR。
確保記錄了所有敏感方法調用[SECURITY.BV.ENFL]
描述:此規則標識不記錄敏感方法調用的代碼。如果使用某些敏感方法調用(例如,來自“javax.security.auth.login.LoginContext”的“login”和“logout”)未記錄,則會報告錯誤。
設計上的另一個隱私示例是此規則,該規則有助于防止您的軟件確實發生錯誤時無意中泄露個人或重要信息:
不要將異常消息傳遞到輸出中,以防止應用程序泄漏敏感信息[SECURITY.ESD.PEO]
描述:該規則標識將異常消息傳遞到輸出的代碼。當catch子句調用輸出方法并且在catch子句中捕獲的異常出現在參數列表中或用作調用對象時,將報告錯誤。
該規則涵蓋OWASP Top 10,CWE,PCI-DSS和GDPR——這意味著無論您為何嘗試進行安全保護,這都是一個好主意。
由于GDPR不是編碼標準,因此沒有簡單的靜態分析配置可以覆蓋它。通常,最好的起點是找到與您當前在測試中發現的問題(例如XSS或SQLi問題)直接相關的靜態分析規則。此類問題通常具有一些靜態分析規則,這些規則可以充當漏洞發現者,并且可以在對這些問題進行測試之前對其進行早期檢測。更重要的是,在這種情況下,在輸入驗證周圍還將有關聯的規則,這些規則可幫助您確保SQLi完全不會像我上面提到的那樣發生。
很難通過存儲從用戶輸入中追蹤數據。編程使驗證始終發生很容易。編程使加密始終發生很容易,而且易于測試。為什么要這么難?
找到并打開測試期間發現問題的規則后,您將需要走得更遠。我建議您從已經涵蓋數據隱私和保護的其他編碼標準中借鑒一些想法。OWASP,HIPAA和PCI-DSS是一些不錯的選擇。如果您在靜態分析工具中啟用了與這些標準相關的任何規則,那么GDPR將會做得很好。實際上,如果您已經符合PCI-DSS的標準,那么您至少會發現GDPR的這一部分相對較容易準備。
如果您已經有其他安全要求,例如CWE或CERT,則可以確保遵循這些要求,并通過在與數據隱私,數據相關的那些標準中找到任何項來擴展配置,以涵蓋必要的特定GDPR數據保護。保護和加密。
Parasoft可以通過幾種方式幫助您確保代碼的安全性和私密性。首先,我們所有的靜態分析引擎都具有針對OWASP,CWE,CERT,PCI-DSS,HIPPA等的配置。您可以打開一組完全適合您的組織的安全規則,然后自動執行它們。
此外,將Parasoft DTP與靜態分析集成時,您將具有完整的審核功能,可以自動記錄在哪些代碼和什么時間運行哪些規則的過程。您可以根據選擇的規則證明自己正在進行測試,甚至可以通過設計確保安全。
Parasoft DTP還具有一些非常特殊的報告,如果您選擇將安全工作基于CWE,Parasoft CWE儀表板會為您提供出色的SAST報告,例如按嚴重性、位置、類型、歷史記錄等問題。進一步并在CWE中實施了技術影響數據。技術影響力(TI)是在Miter進行的研究,是Common Weakness Risk Analysis Framework(CWRAF)的一部分,可幫助您根據SAST結果可能導致的問題對其進行分類。因此,TI告訴您緩沖區溢出可能導致拒絕服務,而不是一條消息指出您存在緩沖區溢出(有些人可能不會將其識別為安全問題)。
每個CWE發現都會告訴您可能發生什么類型的問題,并且有特殊的圖形可以幫助您根據對您最重要的問題區域(而不僅僅是嚴重性級別)導航靜態分析問題。這項突破性的技術可幫助您解決經常導致大量漏洞的情況,尤其是在使用舊代碼庫的情況下。首先關注最讓您感到恐懼的問題。
當然,當我今天專注于靜態分析作為通過設計進行安全性的一種方式時,請不要忘記Parasoft還具有滲透測試工具,API測試和服務虛擬化,所有這些都是工具的重要組成部分。全面的安全軟件開發策略。
GDPR看起來很可怕,而且確實可以,但是使用正確的工具和正確的規則正確設置靜態分析將幫助您保護軟件的安全,證明您為審計員所做的正確的事情以及表明您正在遵循設計安全和設計隱私的原則。這是滲透測試本身無法做到的。額外的好處是,您會發現,從“按設計”的角度考慮安全性比嘗試測試在質量檢查和發布之間保護軟件安全的方法要有效得多。
本站文章除注明轉載外,均為本站原創或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn