devsecops_DevSecOps：关于构建和共享信息的安全测试

devsecops

One big component of DevSecOps surrounding security testing involves how we build and deploy with shared information access of details that may be valuable to an attacker. In order to understand these risks, we must think like attacker who wants to compromise an environment that is focusing on quickly writing code, building the code, testing it, and deploying it across multiple environments. An attacker’s ultimate target will be the highest environment – often a production environment, but some attackers may target lower environments because they may be able to inject code that is deployed to production. In addition, an attacker may only be trying to learn about how an environment is laid out to attack in other ways, such as using social engineering with key information.

DevSecOps围绕安全测试的一个重要组成部分涉及我们如何通过共享信息访问来构建和部署详细信息，这些信息可能对攻击者有价值。 为了理解这些风险，我们必须像攻击者一样思考要折衷于一个环境的问题，该环境专注于快速编写代码，构建代码，对其进行测试以及在多个环境中进行部署。 攻击者的最终目标将是最高环境–通常是生产环境，但某些攻击者可能将目标锁定在较低环境，因为他们可能能够注入部署到生产中的代码。 此外，攻击者可能只想了解如何布局环境以其他方式进行攻击，例如将社交工程与关键信息结合使用。

杜曲的教训 (A Lesson From Duqu)

Duqu and Duqu 2.0 were two of the most sophisticated attacks we’ve seen in the past decade. One of the behaviors of the first version, Duqu, involved creating blank images and sending messages through these blank images. If you consider this design combined with any “temporary data” you can imagine how easy these techniques could bypass any security testing we may run to check for abnormal behavior.

Duqu和Duqu 2.0是我们在过去十年中见过的最复杂的两种攻击。 第一个版本的行为Duqu涉及创建空白图像并通过这些空白图像发送消息。 如果您将此设计与任何“临时数据”结合使用，则可以想象这些技术绕过我们可能运行以检查异常行为的任何安全测试的难易程度。

While Duqu used zero days to compromise the system, unfortunately it gives attackers ideas about how to compromise systems and one technique to combine with a Duqu-like attack is to use a software lifecycle against companies. If attackers can target lower environments with code injection, that code injection will pass to higher environments if undetected. We may have security testing that checks for this in some environments (such as lower), but depending on our configurations and where we store these configurations, an attacker may know this and place dormant code or executions where it won’t be tested.

虽然Duqu使用零天来破坏系统，但不幸的是，它为攻击者提供了有关如何破坏系统的想法，而与类似Duqu的攻击相结合的一种技术是对公司使用软件生命周期。 如果攻击者可以通过代码注入将目标锁定在较低的环境中，那么如果未被发现，则代码注入将传递到较高的环境。 我们可能会在某些环境（例如较低环境）中进行安全测试，以检查此情况，但是根据我们的配置和存储这些配置的位置，攻击者可能会知道这一点，并将Hibernate的代码或执行放置在未经测试的地方。

Even if an attacker is not able to compromise deployment security by injecting code, the attacker may be able to identify key pieces of information about the target’s environment or design that could be useful in other attacks, such as social engineering by presenting as an employee. When we consider security testing, it’s easy to overlook the social engineering side and key pieces of information from our environment can make this easier for attackers because they will appear to be employees at our company, or people deeply informed about our company’s architecture.

即使攻击者无法通过注入代码来破坏部署安全性，攻击者也可能能够通过出示员工身份来识别有关目标环境或设计的关键信息，这些信息在其他攻击（例如社会工程）中可能有用。 当我们考虑进行安全测试时，很容易忽略社会工程方面，而我们环境中的关键信息可以使攻击者更容易做到这一点，因为它们看起来像是我们公司的员工，或者是深知我们公司架构的人们。

For these reasons, we should consider this with security testing and how we create upper environments from lower environments in the context of DevSecOps:

由于这些原因，我们应该在安全测试中考虑这一点，并考虑如何在DevSecOps上下文中从较低的环境创建较高的环境：

1. Build and deploy process. We do not want unauthorized individuals understanding the details of how changes in development are deployed through production. Like we shouldn’t assign higher permissions across the board with all developers, we should not reveal this information to most developers. Some companies may have penetration testing between environment deployments, or some environments may only test one of the many environments. Attackers can inject code that may do “nothing” in some environments (dynamic) to get around our security testing – why revelation can be costly 构建和部署过程。 我们不希望未经授权的个人了解如何通过生产部署开发变更的细节。 就像我们不应该向所有开发人员全面分配更高的权限一样，我们也不应该向大多数开发人员透露此信息。 一些公司可能在环境部署之间进行渗透测试，或者某些环境可能仅测试许多环境之一。 攻击者可以注入在某些环境中（动态）可能无能为力的代码，以避开我们的安全测试–为何披露可能会付出高昂的代价
2. Shared information. If an attacker knows key details about our environment, the attack becomes easier. For this reason, we have to be extremely careful about sharing information among employees. Even what we may think of as “simple details” like our configuration file naming convention or our server names can be incredibly useful to an attacker to circumvent our security testing 共享信息。 如果攻击者知道有关我们环境的关键细节，则攻击将变得更加容易。 因此，我们在员工之间共享信息时必须格外小心。 甚至我们可能认为“简单的细节”（例如配置文件命名约定或服务器名称）对于攻击者规避我们的安全性测试也非常有用。

We’ll look at these two in more depth: being strict with both our deployment strategy and any information we use dynamically for each environment, such as variables or shared details.

我们将更深入地研究这两个方面：严格遵守我们的部署策略以及我们在每种环境中动态使用的任何信息，例如变量或共享详细信息。

我们的构建和部署过程 (Our Build and Deploy Process)

We’ll look at the below image from the viewpoint of an attacker: we know that security testing occurs in pre-production, but does not occur in development or production and we also know each environment uses its own configuration file. If we wanted to inject code, but skip an environment using the config, which environment would we skip?

我们将从攻击者的角度看下图：我们知道安全测试发生在预生产中，但是没有发生在开发或生产中，我们还知道每个环境都使用自己的配置文件。 如果我们想注入代码，但是使用config跳过环境，我们将跳过哪个环境？

We know the answer is pre-production – it’s running tests for a possible attack, whereas the other two environments are not. Also, to bypass the security testing, we can use the configuration file based on this design by attacking the dev.config and prod.config files. The purpose of this exercise is to think like an attacker and imagine how an attacker might use our design against us.

我们知道答案是预生产–它正在运行测试以防可能的攻击，而其他两种环境则不是。 另外，为了绕过安全测试，我们可以通过攻击dev.config和prod.config文件来使用基于此设计的配置文件。 本练习的目的是像攻击者一样思考，并想象攻击者如何对我们使用我们的设计。

How easy is this information to access? In addition, how many of our developers know this is our design? Even with appropriate high-level developers, are there ways where this design could be compromised – such as shoulder surfing at a remote location? These are considerations for how we create our design and how we think about who should have access.

该信息的访问有多容易？ 另外，有多少开发人员知道这是我们的设计？ 即使有了合适的高级开发人员，是否仍有可能折衷该设计（例如，在远程位置进行肩膀冲浪）？ 这些是我们如何创建设计以及如何考虑谁应该拥有访问权限的考虑因素。

共享关键信息 (Shared Access of Key Information)

In some cases, companies may use deployment tools with information or variables that store information about all the environments from development to production. For an example, suppose that we have 3 environments of development, preproduction and production and we manage 20 database servers in each environment. One technique for dynamically using the values based on environments is using a key-value type storage technique where we use the appropriate value for the key based on the environment – using the below image, if we’re adding ServerOne to a connection string for Production, it would be ProdServerOne and if it was another environment, it would automatically pick up the value. Some do this with spreadsheets (shown in the below image) and other use tools that have derivatives of this and these allow convenient and fast deployments – an alternative example of maintaining separate configs per environment instead of dynamic switching could cost more on the development side.

在某些情况下，公司可能将部署工具与信息或变量一起使用，这些信息或变量存储有关从开发到生产的所有环境的信息。 例如，假设我们有3个开发，预生产和生产环境，我们在每个环境中管理20个数据库服务器。 动态使用基于环境的值的一种技术是使用键值类型存储技术，其中，我们根据环境使用适当的键值-如果将ServerOne添加到用于生产的连接字符串中，则使用下图，它将是ProdServerOne，如果是其他环境，它将自动获取该值。 其中一些使用电子表格（如下图所示）和其他使用此衍生工具的使用工具来完成，这些工具可以方便快速地进行部署-在每个环境中维护单独配置而不是动态切换的另一示例在开发方面可能会花费更多。

Because spreadsheets like this or some deployment tools can store detailed information about our environments from the servers to the configuration to the database, they can become targets for attackers. To an attacker, a spreadsheet or deployment tool with this information is like a map that can also show where and how to possibly make an attack from code injection to social engineering. In addition, when we think of security testing, we may overlook deployment spreadsheets or tools such as these since we’re fundamentally using them to conveniently deploy changes across our environments.

因为像这样的电子表格或某些部署工具可以存储从服务器到配置再到数据库的有关我们环境的详细信息，所以它们可能成为攻击者的目标。 对于攻击者而言，具有此信息的电子表格或部署工具就像一张地图，还可以显示从代码注入到社交工程的攻击地点和方式。 此外，在考虑安全测试时，我们可能会忽略诸如此类的部署电子表格或工具，因为我们从根本上使用它们来在我们的环境中方便地部署更改。

We should be aware of the risks of tools like these and how we use them. While it’s understandable that we want fast and convenient deployments with environments that mirror each other as close as possible, it may not be wise to allow developers to access these shared of information even if it makes their troubleshooting quick. We may also want to consider if we want some of a development team to have access, or allow access to only lower environments. For security testing, it’s not only the software, but the tools we may use that create our software that we should consider.

我们应该意识到此类工具的风险以及如何使用它们。 可以理解的是，我们希望在尽可能接近彼此的环境中进行快速便捷的部署，但允许开发人员访问这些共享的信息可能是不明智的，即使这可以使他们快速地进行故障排除。 我们可能还需要考虑是否要让某些开发团队具有访问权限，或者只允许访问较低的环境。 对于安全测试，不仅要考虑软件，还要考虑我们可以使用的工具来创建我们的软件。

降低风险的原则 (Principles to Reduce Risks)

As we consider security testing in the context of shared information for deployments, the below principles can help us prevent some of the compromises we’ve discussed.

当我们考虑在部署的共享信息的上下文中进行安全测试时，以下原则可以帮助我们避免所讨论的某些妥协。

1. Relative to our security testing requirements, share the least amount of information required to complete a request. Because high-level information can (and often is) used in social engineering as “proof” of identity, very few people should know this information. We may consider managers of development teams appropriate, or we may consider some keys from our example as inappropriate to share
   相对于我们的安全测试要求，共享完成请求所需的信息最少。 因为高级信息可以（并且经常）在社会工程中用作身份的“证明”，所以很少有人应该知道此信息。 我们可能认为开发团队的经理是合适的，或者我们可能认为示例中的某些关键不宜共享
2. If compatible with security testing requirements, whether custom or through a tool, maintain shared information separately by environment when developers need to have access to how lower environments function for debugging. This can achieve the balance of development convenience and development security – we want developers to do their work efficiently, but by reducing the risks of a compromise
   如果符合安全测试要求（无论是自定义的还是通过工具的），则当开发人员需要访问较低环境的调试功能时，可以按环境分别维护共享信息。 这可以实现开发便利性和开发安全性之间的平衡–我们希望开发人员有效地完成工作，但要减少妥协的风险
3. We must use extreme caution with shared information – whether spreadsheets or a tool – as a compromised computer with even appropriate access could result in the leak of information. When we talk about compromise here, it could be a compromise as simple as shoulder surfing, or an attack as complex as malware
   对于共享信息（无论是电子表格还是工具），我们必须格外谨慎，因为即使使用适当的访问权，遭到破坏的计算机也可能导致信息泄漏。 当我们在这里谈论折衷时，它可能像肩膀冲浪一样简单，也可能像恶意软件一样复杂。
4. In rare situations, requiring strict security testing compatibility, use an inconvenient design that requires delay. Delay can be a strong security feature. Attackers know that urgency is one of the easiest ways to attack a company
   在极少数情况下，需要严格的安全测试兼容性，请使用不便的设计，需要延迟。 延迟可以是强大的安全功能。 攻击者知道紧迫性是攻击公司的最简单方法之一

结论 (Conclusion)

In our security testing, under the umbrella of DevSecOps, we want to consider access to information that an attacker could use to compromise us further. Unfortunately, shared information that we use for dynamic deployments can sometimes contain this type of information – such as server names, config files names, etc. If compromised, this can result in a broad range of attacks from a technical attack like code injection to a non-technical attack like social engineering where the attacker appears to be an employee. We want to design for convenient deployments by providing developers what they need, while also keeping key information secure.

在我们的安全测试中，在DevSecOps的保护下，我们希望考虑访问攻击者可能用来进一步危害我们的信息。 不幸的是，我们用于动态部署的共享信息有时可能包含此类信息，例如服务器名称，配置文件名称等。如果遭到破坏，这可能会导致从技术攻击（例如代码注入）到攻击的广泛攻击。非技术攻击，例如社会工程学，攻击者似乎是雇员。 我们希望通过为开发人员提供所需的信息，同时确保关键信息的安全性来设计方便的部署。

目录 (Table of contents)

DevSecOps: Developing with Automated Security Testing

DevSecOps: Security Testing Around Builds and Shared Information

DevSecOps：使用自动安全性测试进行开发

DevSecOps：关于构建和共享信息的安全测试

翻译自: https://www.sqlshack.com/devsecops-security-testing-around-builds-and-shared-information/

devsecops