如何轻松启动您的appsec程序-CSDN博客

A practical guide to building a scalable Application Security Design Review process through threat modeling and empowerment.

通过威胁建模和授权构建可扩展的“应用程序安全性设计审查”流程的实用指南。

By: James Chiappetta

创建人： James Chiappetta

Disclaimer: The opinions stated here are my own, not necessarily those of my employer.

免责声明：这里所说的观点是我自己的，不一定是我雇主的观点。

背景 (Background)

Developers and product owners often think about the happy path. They get locked in on what should go right (a monetary success), and it’s easy to forget what can go wrong. So, how do you influence the culture of a broad engineering population and actively prevent the unhappy path?

开发人员和产品所有者通常会想到幸福的道路。他们锁定了应该做对的事情(金钱上的成功)，并且很容易忘记会出错的地方。那么，您如何影响广泛的工程人员的文化并积极预防这种不愉快的道路？

This post will provide you with a practical guide to building a scalable security design review process from scratch to avoid last minute security roadblocks and get people thinking like attackers.

这篇文章将为您提供从头开始构建可扩展安全性设计审查过程的实用指南，以避免最后一刻的安全障碍，并使人们像攻击者一样思考。

第一件事第一 (First Things First)

There are various places you could start building your AppSec processes. One of the better places is at the beginning of any new project or initiative in the software development life cycle (SDLC). It is well known that it’s cheaper to account for security earlier in the development process, rather than right before something ships, or worse, already in production. This is known throughout the industry as shifting security left.

您可以在许多地方开始构建AppSec流程。更好的地方之一是在软件开发生命周期( SDLC )中任何新项目或计划的开始。众所周知，在开发过程中尽早考虑安全性要比在即将发布的产品或更糟的是已经投入生产的过程中考虑安全性便宜。这在整个行业中被称为向左转移安全性。

碎片 (The Pieces)

Secure design review questionnaire — Create a lightweight set of questions that can be added on to an engineer’s technical design document (example). Having it included in the developer’s documentation template will create a more seamless process and will serve as the nudge needed to get them thinking about the unhappy path. Eventually at scale, you will want the developers and engineers doing this work with a security champion or lead engineer performing the peer review.

安全的设计评审调查表-创建一组轻量级的问题，这些问题可以添加到工程师的技术设计文档中(示例) 。将其包含在开发人员的文档模板中将创建一个更加无缝的过程，并将使他们思考不愉快的道路。最终，您将希望开发人员和工程师与安全支持者或首席工程师一起执行此工作，进行同行评审。

Questions can include:

问题可以包括：

What network will the product or service live in?
产品或服务将驻留在哪个网络中？
What data types will be handled and where will the data be processed/stored?
将处理哪些数据类型以及将在哪里处理/存储数据？
What are the availability requirements?
可用性要求是什么？
What cloud infrastructure is required?
需要什么云基础架构？
What are the internal dependencies, such as internal services or applications?
什么是内部依赖性，例如内部服务或应用程序？
Will there be any third party dependencies (SaaS, third party libraries)?
是否存在任何第三方依赖项(SaaS，第三方库)？
Where will the source code live?
源代码将存放在哪里？
Who is the product owner?
谁是产品负责人？

Threat model — Part of the security design review process should be a well defined threat model. New to threat modeling? See these links for technical and non-technical guides.

威胁模型-安全设计审查过程的一部分应该是定义明确的威胁模型。威胁建模新手？请参阅这些链接以获取技术和非技术指南。

To keep threat modeling as lightweight as possible use something like draw.io to create a basic data flow diagram. The objective is to understand the attack surface of assets (software/systems/APIs/etc.) in the design and then highlight what threats could exist and what controls could mitigate them.

为了使威胁建模尽可能轻巧，请使用诸如draw.io之类的东西来创建基本数据流程图。目的是了解设计中资产(软件/系统/ API /等)的攻击面，然后重点介绍可能存在的威胁以及可以减轻威胁的控件。

This will help create the set of security requirements in a pragmatic way, rather than a pessimistic “doom and gloom” approach to security.
这将有助于以务实的方式创建一套安全要求，而不是悲观的“灰蒙蒙的”安全方法。
The security requirements formula: Assets + Threats + Mitigations = Requirements!
安全需求公式：资产+威胁+缓解=需求！

Pro Tip: Teach people to fish. Show product owners and engineers how a threat model comes together. They can learn to think defensively as they build. Engineering will always outnumber and outpace the growth and capacity of security. You need to scale with education, empowerment, and accountability.

专家提示：教人钓鱼。向产品所有者和工程师展示威胁模型如何组合在一起。他们可以在建立过程中学会防御性思考。工程技术将永远超过并超过安全性的增长和容量。您需要通过教育，授权和问责来扩展规模。

Security Requirements — A list of security requirements comes after you have decomposed the system and software architecture, mapped out threats, and identified potential mitigations.

安全要求-在分解系统和软件体系结构，确定威胁并确定潜在的缓解措施之后，将列出安全要求。

Security requirements are important to prioritize in the development phase. Example: There is an “account sign up” function and you want to limit or prevent programmatic attacks against it, so you can recommend the dev team implement a reCaptcha as a primary control and a throttling function based on IP/session as a secondary control. The dev team only has the capacity to implement one of these controls so distinguishing between the two is important.

安全要求对于在开发阶段确定优先级很重要。示例：有一个“帐户注册”功能，您想限制或防止针对它的编程攻击，因此您可以建议开发团队将reCaptcha作为主要控制实现，将基于IP /会话的限制功能作为次要控制实现。开发团队只能执行这些控件之一，因此区分两者很重要。

These requirements should be the beginning of a conversation with the developers — it should be made clear to them why things are being added and what they’re protecting against.
这些要求应该是与开发人员进行对话的开始-应该向他们明确说明为什么要添加内容以及要保护哪些内容。
They should be generic with examples, promoting the desired control, not the desired implementation.
它们应与示例通用，以促进所需的控制，而不是所需的实现。

Presenting the requirements as a table can help organize the data so that sorting on high risk / high priority can be done efficiently. Everyone needs to gain alignment on a list of release blockers and which can be done at a later date.

将需求显示为表格可以帮助组织数据，从而可以有效地对高风险/高优先级进行排序。每个人都需要在释放阻止程序列表上进行对齐，并且可以稍后进行。

If you get to the point where you need to release and one of these requirements weren’t done you have a quick way to have a business stakeholder accept it. Accountability!

如果您到达需要发布的地步，并且没有满足其中一项要求，则可以通过一种快速的方法让业务利益相关者接受它。问责！

Pro Tip: Have a peer review of the secure design review before sharing with any stakeholders.

专家提示：在与任何涉众共享之前，对安全设计审查进行同行审查。

Review handoff meeting — Review the output of the secure design review and the proposed requirements with your stakeholders. Set up a 30 to 60 min meeting with them to go over the threat model and the list of requirements. Take note of anything that needs to be updated as the team reviews it. Most importantly, be sure they understand and agree to (not necessarily with) the requirements; both why they’re needed and what they mean. At the end of this, the requirements should be filed as tickets and planned into upcoming sprints or development cycles.

审查移交会议—与利益相关者一起审查安全设计审查的输出和建议的要求。与他们进行30至60分钟的会议，以了解威胁模型和要求列表。在团队审核时，请注意任何需要更新的内容。最重要的是，确保他们了解并同意(不一定同意)要求；为何需要它们以及它们的含义。最后，需求应作为工单归档，并计划到即将到来的sprint或开发周期中。

Pro Tips:

专业提示：

Being a partner to your internal stakeholders is foundational and making well informed recommendations is key for building trust. Be an empathetic partner and provide transparency in your decision making!
成为内部利益相关者的合作伙伴是基础，而明智的建议是建立信任的关键。成为富有同情心的合作伙伴，并为您的决策提供透明度！
Don’t feel shy to ask for feedback on the process. Survey your stakeholders for feedback. Did you ask the right questions, did the requirements have the right level of detail, etc.?
不要害羞地要求过程提供反馈。调查您的利益相关者以获取反馈。您是否提出了正确的问题，要求是否具有适当的详细程度等？

流 (The Flow)

Scrum board — Whether you are using Trello, Jira, or something else; it’s important to keep track of the flow of work for any team and these reviews are no exception.

Scrum board —无论您使用的是Trello，Jira还是其他工具；跟踪任何团队的工作流程非常重要，这些审核也不例外。

Application Inventory — Figure out who your stakeholders are and what products they own. Get their help building the critical product and services inventory. Keep track of everything that needs to be reviewed and re-reviewed on an ongoing basis. Send out a spreadsheet for folks inside the business to keep updated.

应用程序清单-找出您的利益相关者是谁以及他们拥有什么产品。获得他们的帮助，以建立关键的产品和服务库存。持续跟踪需要审查和重新审查的所有内容。发送电子表格给企业内的人员以保持更新。

价值 (The Value)

Secure design review dashboard — Create a basic dashboard to capture throughput of secure design reviews and the requirements either met before release, planned for a later one, or will never be implemented.

安全设计审查仪表板-创建一个基本的仪表板，以捕获安全设计审查的吞吐量以及发布之前满足的要求，计划在以后发布的要求或永远不会实现的要求。

Primary things to keep track of:

要注意的主要事项：

Number of design reviews you are capable of doing per sprint is variable.
每个Sprint可以进行的设计审查的数量是可变的。
Number of requirements closed before release (risk avoidance).
在发布之前关闭的需求数量(避免风险)。
Number of requirements not met before release (risk acceptance).
发布前未满足的要求数量(风险接受)。

Secondary measures include the number of peer reviews conducted by each team member, or time to complete each secure design review.

次要措施包括每个团队成员进行的同行评审的次数，或完成每次安全设计评审的时间。

Remember: AppSec is the business of revenue protection.

切记：AppSec是收入保护业务。

拿走 (The Take-a-ways)

Practical tools that you should now have at your disposal:

您现在应该拥有的实用工具：

Create a lightweight security design review process that is purposefully added to the beginning phase of the SDLC.
创建一个轻量级的安全设计审查过程，该过程有目的地添加到SDLC的开始阶段。
Develop a basic set of questions that will help collect necessary data to prioritize and perform the review.
提出一系列基本问题，这些问题将有助于收集必要的数据，从而确定优先级并进行审核。
Create threat models and store them centrally as an artifact for future reference.
创建威胁模型并将其集中存储为工件，以备将来参考。
Have a standard way to define security requirements (functional and non-functional) for any new development/engineering project.
采用标准方法为任何新的开发/工程项目定义安全要求(功能和非功能)。
Track those security requirements as tickets visible to developers.
将这些安全要求作为对开发人员可见的票证进行跟踪。
Determine what level of risk a new development project may present AND what future work (ongoing code review, product dev support) is needed.
确定新开发项目可能带来的风险等级以及未来需要开展的工作(正在进行的代码审查，产品开发支持)。
Build a dashboard to track team work output and risk. This solidifies the value of your team and program!
建立仪表板以跟踪团队工作的输出和风险。这巩固了您的团队和计划的价值！

注意的话 (Words Of Caution)

The security design review shouldn’t be treated as a panacea for security. It’s an important part of the overall process of creating secure products and services, but there should be additional processes to check for security weaknesses of the software before release.

安全设计审查不应被视为安全的灵丹妙药。这是创建安全产品和服务的整个过程的重要组成部分，但是应该有其他过程在发布之前检查软件的安全弱点。

Plan to do a Production Readiness Assessment in the testing phase. The goal is to aggressively attack the product under test. Knock things out of place (in a safe environment), because your adversaries will do this against your product in the real world.

计划在测试阶段进行生产准备评估。目的是积极攻击被测产品。 (在安全的环境中)将事情弄乱，因为您的对手会在现实世界中对您的产品造成伤害。

Remember, you’ll want to be engaged early, but not before the appropriate stakeholders who support all of the pieces the developers plan to use have been engaged.

请记住，您将希望尽早参与，而不是在支持开发人员计划使用的所有组件的合适的利益相关者参与之前。

Check out OpenSAMM to better assess your full program’s level of maturity.

查看OpenSAMM，以更好地评估整个程序的成熟度。

Want to know how to embed security into a centralized build and release system? Check out my post 4 Steps to Scale Application Security Successfully.

是否想知道如何将安全性嵌入到一个集中的构建和发布系统中？查看我的文章成功扩展应用程序安全性的4个步骤。