软件安全设计_安全软件设计中重要的是什么？

软件安全设计

存在许多可能会损害系统安全性的基本体系结构和设计错误：

1. 缺少安全功能中的重要内容，例如访问控制或审核，隐私和合规性要求；
2. 在理解和实施防御黑暗技术的安全性技术方面的技术错误，例如加密，管理机密和会话管理（您不了解做某事或正确做事的知识）；
3. 误解了架构责任和信任区，例如依赖于客户端验证，或者“我认为数据已经被清理”；
4. 让攻击面变得不必要的多–因为大多数开发人员不了解系统的攻击面 ，或者知道他们在更改系统时需要当心；
5. 默认情况下允许访问，因此，当发生错误或有人忘记在正确的位置添加正确的检查时，门和窗将保持打开状态，坏人可以直接进入。
6. 选择不安全的开发平台或技术栈，框架或API，并继承他人的设计和编码错误；
7. 在业务工作流程中犯愚蠢的错误，使攻击者可以绕过检查和限制并窃取金钱或窃取信息。

了解安全软件设计

如果要构建安全系统，则需要了解安全设计。 希望您不会从阅读Richardson和Thies的安全软件设计开始。 尽管它确实描述了应用程序安全性和IT安全性中的许多主要问题，以及一些常见的威胁和漏洞，但具有讽刺意味的是，它没有说明如何进行安全的软件设计。 本书中太多的“实用信息”几乎是危险的，但并不完全正确：例如，关于XSS的部分确实提到了输出转义，但没有说明如何正确执行转义，或者说它更重要而不是“清除不必要的字符并更改必要但可能危险的字符的输入”（但是您可以安全地这样做）。 或大体上是错误的：关于安全数据库设计的部分–不正确，“保护Web应用程序免受[sic] SQL注入攻击的最简单方法之一就是验证所有输入参数”，而“您还应避免动态变化”。 SQL和使用参数化存储过程 “还不够接近正确理解或正确遵循的地方。 这本书确实提高了人们对应用程序安全性问题的认识，并且作者起初确实将读者引向了CERT，SANS和OWASP，因此希望学生能够找到并使用这些资源，而不是依赖本书。

原则–母性和苹果派，或善与公，等等？

每本涉及安全软件设计的书，甚至像Merkow和Raghavan撰写的《 Secure and Resilient Software Development》一书之类的好书，都花时间研究基本的安全设计原则 ： C和I的重要性， 也许还有A。 模块化和隔离性，职责分离， 机制经济 （一种简单的表达方式），最少特权，纵深防御，但默默无闻却无法保证安全，完全调解（呵呵）和心理可接受性，以及萨尔茨和施罗德写了40年前。

所有好的，真实的，明智的和正确的想法都是可以遵循的，但是您可以整日阅读这些内容（如果您可以保持清醒的状态），它不会帮助您设计更安全的系统。 这里没有明确的内容或不可行的方法–这是讲道和高水平的挥手。 您无法判断自己是否做了足够的事情，永远不会知道自己做对了还是错过了什么，或者什么才是真正重要的，什么不是。

威胁，攻击和风险–学会害怕……某事……

其余安全设计主要涉及威胁，攻击和利用 -着眼于风险的威胁建模练习。 开发人员设计出一些不错的东西，然后安全专家进来攻击他们的设计，寻找弱点和疏忽，列举威胁并遍历攻击树和漏洞，并告诉开发人员他们错过了什么以及某些理论上的攻击者可能会利用损害系统。

这对于开发人员来说是一件很难理解的事情，并且对他们来说很难兴奋 ：您正在要求开发人员（具体的问题解决者）考虑“可能永远不会”发生的问题。 要正确地做到这一点，您不仅需要了解系统的工作方式（及其工作的技术），而且还需要了解在什么情况下（以及实际发生的可能性）什么样的攻击，这意味着您需要专门的知识。大多数开发人员没有的经验和知识，并且很难获得。

但是，即使您了解这些知识并遵循诸如STRIDE或Trike之类的结构化方法，也无法知道您是否已经很好地完成了威胁建模，是否做了足够的工作以及是否已经识别出所有重要问题，或者如果您错过了一些重要的攻击媒介或严重漏洞，无论如何都会被伪造 。

威胁建模，至少是通常所理解的方式，在昂贵的会议上，架构师，开发人员和测试人员以及安全专家和项目经理聚在一起，有条不紊地浏览设计文档，然后写出CYA文书，这与大多数开发人员实际工作的方式-尤其是敏捷团队中的开发人员，他们的大部分设计工作都是逐步进行的，并且会不断完善和填充设计。 或者，开发人员在不断施加压力的情况下维护遗留系统，以尽可能快且廉价地修复或更改已经存在的某些东西。 没有足够的时间或空间来参加威胁建模会议或所有这些文档和文书工作， 并且如果他们能找到一些时间，那可能不是最好的时间利用方式 。

甚至更轻量级的威胁建模也没有在开发商店中大放异彩 ，我也不相信这样做会如此。

安全设计清单，备忘单和样式

当开发人员设计和构建系统时，他们希望着眼于：理解他们试图解决的问题以及他们需要构建什么以及如何快速构建它。 与其回顾人们遗漏或做错的事情，不如将其作为设计的一部分，将重点放在他们应该做和可以做的事情上–更有价值，实用和更具成本效益–他们应该使用的实践，模式和工具以及应该使用的工具。不应，当他们做出设计决策和权衡时必须要注意的问题。

我之前已经讨论过清单在软件安全中的重要性和实用性 ：处理不同设计问题时要考虑的简单步骤和注意事项，以确保您不会错过重要的事情或做一些愚蠢的事情。

Microsoft的Patterns and Practices网站包括一个（不幸的是“已淘汰”） 安全的体系结构和设计检查清单 ，其中涵盖了设计安全应用程序时需要考虑的大多数问题。 万一此清单在某天消失了，它的完整副本将包含在Merkow和Raghavan的《 安全和弹性软件开发》一书中。

OWASP有一个安全的设计检查表 ，但它并非针对开发人员的，它是一种工具，可帮助审核员在文档繁多的瀑布式环境中进行安全设计审查。 有一个OWASP 应用程序体系结构速查表 （当前正在草稿中），其中包括一些在初始体系结构和高级设计中要问的好问题。 OWASP备忘单的其余部分可用于帮助设计人员和编码人员解决特定的应用程序安全性问题-只要您知道需要解决的问题即可。

关于安全模式也有一些工作，这对于采用基于模式的方法进行软件设计的开发人员可能很有用。 SEI的“安全设计模式”目录旨在将安全性纳入某些常见的软件设计模式 （“工厂”，“策略”，“构建器”，“责任链”的安全版本），或将模式应用于一些常见的软件安全性问题。 还有几本书，例如《 核心安全模式》 （一个吓人的1000多页基于大型标准的J2EE应用程序的安全模式列表）和《实践安全模式》 （刚刚出版）。 但是，这些模式尚未成为主流-我不知道许多现实生活的开发人员甚至都知道这些模式，没关系尝试应用它们。

我在安全设计领域遇到的最有用的工具之一是SD Elements ，它是一种在线软件服务，可帮助开发团队制定应用程序安全性决策。 首先，描述项目及其安全性和合规性要求以及所使用的语言/平台，然后SD元素会指导您完成一系列有关如何处理设计中重要安全方面的问题和选项，系统的实施和测试。 它可以帮助您理解需要做出的决定，并在做出决定时握住您的手。

设计中的安全性，而非安全设计

安全设计不应该涉及您不了解或无能为力的事情。 安全设计应该是了解您可以并且应该自己解决的问题以及您不应该解决的问题。

了解系统的受攻击面是什么样子以及更改时应注意的内容。

信任区如何工作。

您应该在何处，为什么以及如何使用成熟的应用程序安全框架和库，例如Shiro或ESAPI ，或者如何正确利用应用程序框架的安全功能（ Rails或Play或Spring或其他）。

第一步（也是最重要的一步）是让软件设计人员和架构师在考虑设计时就考虑安全性，就像他们考虑上市时间和开发人员便利性，性能，可靠性或未来一样。打样或技术优雅。 他们不仅应该了解其安全功能，还可以将安全性作为体系结构和设计中的一个连续线程。

当他们选择工具和语言以及框架和平台时。

当他们考虑架构责任以及层次和模式时。

当他们使用数据时：识别和跟踪并保护机密和私人信息与秘密，适当地进行数据验证，并考虑安全的数据访问和数据存储。

安全设计必须适合设计以及如何完成设计。 在制定设计决策时，它必须是决策的一部分，而不是在随后的审核和审查中附加。

参考： 安全软件设计中重要的是什么？ 来自我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。

翻译自: https://www.javacodegeeks.com/2013/06/what-is-important-in-secure-software-design.html

软件安全设计