使用静态分析,帮助实现GDPR的“设计安全”和“设计隐私”

使用正确的工具和正确的规则正确地设置静态分析,将帮助你保护软件安全,证明自己在为组织做正确的事情,并表明你在遵循“设计安全”和“设计隐私”的原则。

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还可以为你做什么?

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看起来很可怕,而且确实也是很可怕,但是使用正确的工具和正确的规则正确设置静态分析将帮助你保护软件的安全,证明你为组织所做的事情是正确的以及表明你正在遵循设计安全和设计隐私的原则。这是***测试本身无法做到的。除此之外,你会发现,从“按设计”的角度考虑安全性比尝试测试在质量检查和发布之间保护软件安全的方法要有效得多。要深入探讨和研究,可以评价留言或私信我哟。

猜你喜欢

转载自blog.51cto.com/11855672/2577116