无论是否存在可能存在的残余风险（例如零日漏洞），我们的 adesso 专家和全球安全社区总体上都对 IT 安全应采取的措施有非常广泛的了解，无论是基础设施还是应用程序或其他主题。众所周知的来源（例如 OWASP、NIST 或 BSI-Grundschutz）当然包含数百个安全要求。由于数量众多，仔细处理所有这些要求（包括适当的实施）是一项挑战。
因此，在这篇博文中，我想讨论两种可能的方法，并根据我以前的经验分享我的个人观点。用非常简单的术语，我将在这里描述两种极性方法，一方面是更经典的需求工程，另一方面是迭代方法。
方法 1：经典需求工程
在经典的需求工程中，所有非功能性需求都是在项目的早期阶段收集和记录的。然后可以通过不同的方式来规划这些要求的实施 - 例如，通过待办事项确定优先级或使用专用路线图。
在我们运营的大多数敏捷世界中，这种方法似乎不再适合，因为需要 商业房地产的潜在客户 进行大量准备工作。谁想从数百个安全积压项目开始？
诚然，这是对问题的非常简短的描述，但正如您从我之前的博客文章中看到的，我更喜欢不同的方法。
这种方法的目标绝对与完全结构化的需求工程非常相似。我希望最全面地涵盖安全问题，以便我交付的产品仅包含可接受的风险。主要的区别是我
a）以不同的方式实现目标
b)考虑风险维度。
方法 2：迭代方法
第二种方法的起点是初始威胁模型，在该模型中，自上而下地分析理想情况下不太详细的架构，而不要求完整性。结果是一张“安全地图”，其中标记了关键要素（风险评估）以及后续步骤的定义和决策。一个典型的例子是公共接口的识别以及输入验证或 http 安全等高级措施的推导。
然后，迭代的细化过程从此初始活动开始。这意味着最初发现的措施被定义为积压项目（如果无法接受风险）。第一次运行的积压项目通常是用非常笼统的术语制定的，任务是在第一个冲刺中对其进行完善并得出具体的实施措施。这与您可能熟悉的“安全是一个分形问题”这一说法非常吻合。分形是因为当你放大“图像”时，会出现新的细节，而这些细节又可以分为更多的细节。不幸的是，我已经不知道这句话是谁发表的。
相反，这也意味着必须不断进行新的分析，特别是如果设计发生任何变化。因此，安全成为需要持续关注的问题。就我个人而言，我总是会将此任务委托给项目中恰好有此任务的安全工程师（他不必全职参与该项目）。为了达到目标质量（或完整性），安全工程师自然会在后台使用上面提到的知识库。例如，这还包括与现有通用要求列表进行比较。
我的项目经历
不久前我在一个项目中做了同样的事情。需求的开发是并行的，但该项目面临着时间压力。两次研讨会和第一次迭代结果报告后，客户的反馈是：“超级快、超级脏，但结果非常好”。