软件开发安全的重要性，您是否要求软件安全性
强大的软件安全要求可帮助您锁定软件的功能，以便仅可按预期使用它。了解如何建立自己的。
有哪些软件安全要求？
您是否听过一句老话：“得到的就是得到的，却不会生气”？尽管这可能适用于课余零食和生日礼物，但软件安全性却不应该如此 。软件所有者不仅仅接受已部署的任何新软件功能；还应该接受新的软件功能。在部署功能之前，必须经过批判，论证和分析的战略过程。您的团队应该对安全性一视同仁。毕竟，安全软件不只是偶然发生的，还必须是战略开发过程的要求。为了有效地部署安全软件，您需要明确，一致，可测试和可测量的软件安全要求。
为什么需要软件安全性要求？
传统上，需求定义什么可以做什么或可以做什么。锤子需要打钉子。门锁需要保持门关闭，直到用特定的钥匙将门解锁为止。汽车需要沿着国家的道路将旅客从A点移动到B点。它还需要使用现代汽油配方。这些类型的要求对物理对象来说很好用，但对软件来说却不足。
另外，人们可以将这些对象用于其预期目的以外的目的，或者完全规避其目的。例如，您可以使用锤子砸碎窗户，可以选择门锁，还可以使用汽车运输被盗的货物。同样，软件可能会被滥用或变得易受攻击。关键区别在于，通用汽车将其汽车用作度假车时不承担责任。但是，有人破坏了您软件的功能和权限，而您（作为软件所有者）就是受苦的人。
安全漏洞允许软件以开发人员从未想过的方式被滥用。想象一下，能够设计出只能锤打钉子而没有其他任何东西的锤子。通过建立可靠的软件安全性要求，您可以锁定软件的功能，以便仅可按预期使用它。
如何创建安全要求？
安全要求是应用程序从一开始就设定的目标。每个应用程序都满足需求。例如，一个应用程序可能需要允许客户在不致电客户服务的情况下执行操作。正如您将这些操作和结果列为最终应用程序的目标一样，您必须包括安全性目标。
软件安全要求并不是您可以在应用程序上挥舞的魔杖，并且说：“您绝不能受到黑客的损害。”除新年的决议外，您还可以挥舞自己以减轻体重。就像减肥的决心一样，含糊不清是失败的秘诀。多少体重？您将如何失去它？您会运动，节食还是两者兼而有之？您将在此树立哪些里程碑？
在安全性方面，存在相同类型的问题。您希望预防哪些类型的漏洞？您将如何衡量您的要求是否得到满足？您将采取哪些预防措施以确保代码本身没有内置漏洞？
建立软件安全性要求时，请具体说明要防止的漏洞类型。以这个需求为例：“ [应用程序X]不应执行用户提供的数据中嵌入的命令，该命令会迫使应用程序以意想不到的方式操作数据库表。” 这是一种很好的说法，即应用程序不应受到 SQL注入攻击的攻击。您可以通过拒绝或清除用户的不良输入，使用精心设计的类型的数据库查询（将数据标记为数据而不是要执行的命令）以及修改数据库调用的输出来防止用户输入错误，来防止这些攻击。恶意攻击功能造成的不良数据。然后，您可以在源代码和已编译的应用程序上使用特定种类的软件测试来测试此需求。
您的要求的要求
为了建立良好的需求，请确保您正在回答有关需求的问题。软件安全性要求应该与功能性要求非常相似。它不应该含糊不清或无法实现。预期开发人员的问题并提前回答。就是这样：
- 这可以测试吗？我们可以在最终应用程序中测试此要求吗？“安全”不是可测试的要求。是“对所有用户提供的输出进行编码”。
- 这可以测量吗？当我们对此进行测试时，可以确定覆盖范围和有效性吗？
- 完成了吗 我们忘记了什么吗？我们是否要求对用户提供的数据进行检查，而不是对日志进行检查？
- 这清楚吗？负责设计，实施，测试和交付此需求的人员是否会理解该需求的意图？
- 这是明确的吗？有人可以用其他任何方式解释这一要求吗？
- 这些要求是否一致？我们是否以相同的方式满足每个安全要求，以确保安全措施在整个系统中得到一致应用？
建立需求时，请记住这是某人必须实现的目标。除非您创建特定且可实现的要求，否则设计人员和开发人员无法满足应用程序的安全性目标。
安全要求类型
如果您根深蒂固于需求或契约世界中，那么您已经知道基本的需求种类：功能需求，非功能需求和派生需求。软件安全性要求属于同一类别。就像性能要求定义了系统必须按照规范执行和要执行的操作一样，安全要求也定义了系统必须执行和安全执行的操作。
在定义功能性非安全性要求时，您会看到诸如“如果按下扫描按钮，则激光器应激活并扫描条形码”之类的语句。这就是条形码扫描仪需要做的。同样，安全性要求描述了系统必须执行哪些操作以增强安全性。例如：“收银员必须使用磁条卡和PIN登录，然后收银机才能处理销售。”
功能需求描述了系统必须执行的操作。因此，功能安全要求描述了强制执行安全性的功能行为。功能需求可以直接测试和观察。与访问控制，数据完整性，身份验证和错误的密码锁定有关的要求属于功能要求。
非功能性需求描述了系统必须具备的功能。这些是支持可审核性和正常运行时间的声明。非功能性安全要求是诸如“审核日志应足够详细以支持取证”之类的声明。支持可审核性不是直接的功能要求，但它支持可能适用的法规中的可审核性要求。
派生的需求受功能和非功能需求的启发。例如，如果系统具有用户ID和PIN功能要求，则派生的要求可能会在锁定帐户之前定义允许的不正确的PIN猜测数。对于审核日志，派生的需求可能支持日志的完整性，例如防止日志注入。
衍生的需求是棘手的，因为这些源于 滥用案例。需求设计人员不仅必须像用户和客户那样思考，而且还必须像攻击者那样思考。对于提供给用户的每项功能，攻击者可能会滥用它。例如，登录功能可能会成为密码猜测尝试，上载文件可能会打开一个系统来托管恶意软件，接受文本可能会打开跨站点脚本 或 SQL注入的大门 。
制定要求
在需求和早期设计阶段，软件安全需求可能来自许多来源。在定义功能时，必须安全地定义功能或提供支持要求以确保业务逻辑是安全的。您应该根据行业最佳实践和法规要求量身定制通用指南，以满足特定的应用程序要求。
滥用案例是像攻击者一样思考的一种方式。设计师将用例付诸实践，并分析如何滥用功能。如果允许用户使用敏感数据生成报告，未经授权的用户将如何获得这些报告及其敏感数据的访问权限？滥用案例通常可以通过行业最佳实践得到解答，您可以使用这些最佳实践来建立有关应用程序如何处理对特权数据的访问的要求。
软件安全性要求也可以来自通过体系结构风险分析进行的设计 分析。如果Web应用程序使用特定的框架或语言，则需要应用有关攻击模式和漏洞的行业知识。如果某个框架在某些情况下阻止跨站点脚本编写，而在其他情况下则不允许，则您需要定义一个要求，以说明开发人员如何在不安全的情况下阻止跨站点脚本编写。
每个安全要求都应满足特定的安全需求，因此了解应用程序中可能存在的漏洞至关重要。普通的指导和知识是不够的。特定的安全要求将来自特定的应用程序要求。
需求可以为我做些什么？
无论是内部构建软件还是将软件外包给第三方供应商，都没有关系。建立健全的安全要求可以使您受益。通过尽早定义您的安全要求，您可以在以后避免麻烦。完善的安全性要求可为开发人员提供清晰的路线图，从而在内部为您提供帮助。它们还有助于满足外部法规要求。采取措施防止软件被黑客入侵是一个不错的策略，而安全性要求则是让您满意的绝妙起点。
