冰山订单_devsecops冰山

冰山订单

Security is a complicated topic. There are countless of attack vectors and threat models to take into consideration when designing a security strategy.

安全是一个复杂的话题。 设计安全策略时，要考虑的攻击媒介和威胁模型不计其数。

Over the last year, we’ve spoken to companies of different sizes about their security strategies and practices. Based on these discussions, we’ve come up with something we call the DevSecOps Iceberg. The idea behind this is that too many organizations tend to only focus on the application layer or the network layer and turn a blind eye to everything else. This is a dangerous approach. Neglecting the other layers means that you may end up putting your entire infrastructure and data at risk.

在过去的一年中，我们与不同规模的公司就其安全策略和实践进行了交谈。 基于这些讨论，我们提出了一种称为DevSecOps Iceberg的东西。 其背后的想法是，太多的组织倾向于只专注于应用程序层或网络层，而对其他所有事物视而不见。 这是一种危险的方法。 忽略其他层意味着您可能最终会使整个基础架构和数据面临风险。

To begin, let’s define the three layers of the DevSecOps Iceberg and then explore what you can do to protect them:

首先，让我们定义DevSecOps Iceberg的三层，然后探索如何保护它们：

• Application Layer
  应用层
• Container Layer
  容器层
• Operating System Layer
  操作系统层

(Do however note that this article is by no means a comprehensive security checklist. It is merely an overview of the common layers.)

(但是请注意，本文绝不是全面的安全检查表。它只是常见层的概述。)

应用层 (The Application Layer)

Let’s start with the Application Layer, as this is likely the layer developers are most familiar with. Application security is a vast field by itself, but for the sake of this article, let’s limit the scope to vulnerable dependencies.

让我们从应用程序层开始，因为这可能是开发人员最熟悉的层。 应用程序安全性本身就是一个广阔的领域，但是出于本文的考虑，让我们将范围限制为易受攻击的依赖项。

It’s not an understatement to say that open source libraries are essential to modern developers. Regardless if you’re working on front-end or back-end services, you are most likely relying on a plethora of libraries to simplify (and speed up) your development. As a case in point, from Snyk’s The state of open source security (2019) reports that there was an astonishing 317 billion JavaScript packages downloaded from npm in 2018.

毫不夸张地说开源库对于现代开发人员至关重要。 无论您使用的是前端还是后端服务，您都最有可能依赖大量的库来简化(并加快)开发过程。 例如，来自Snyk的《开源安全状况》(2019年)报道称，2018年从npm下载了惊人的3170亿个JavaScript软件包。

With a larger reliance on 3rd party packages in our source code, we are exposing ourselves to new risks. For instance, last year the popular npm package “event-stream” was compromised and as a consequence was able to pollute the entire supply chain of packages depending on this package. With more than 1.5m weekly downloads, this breach had a significant impact. As we are relying more on libraries, these types of attacks are likely to increase in the future.

由于我们在源代码中更加依赖第三方软件包，因此我们正面临新的风险。 例如，去年流行的npm软件包“事件流” 遭到破坏 ，因此有可能污染依赖于此软件包的整个软件包供应链。 每周下载量超过150万，此漏洞产生了重大影响。 由于我们越来越依赖于库，因此将来这类攻击可能会增加。

So how can you protect yourself against attacks like this? This largely depends on your development workflow. If you’re a modern company with frequent releases (daily or more) and a fully automated release pipeline using Continuous Integration (CI) and Contentions Delivery (CD), the best solution would be to include a dependency check as part of this pipeline. If a CVE is detected, the CI run should fail.

那么，如何保护自己免受此类攻击呢？ 这在很大程度上取决于您的开发工作流程。 如果您是一家拥有频繁发布(每天或更多)且使用持续集成(CI)和竞争交付(CD)的全自动发布管道的现代化公司，最好的解决方案是将依赖项检查包括在该管道中。 如果检测到CVE，则CI运行将失败。

If you are releasing less frequently, using a service where you can submit your dependencies for ongoing audit, which will then alert you might be a better choice for you.

如果发布的频率较低，请使用一项服务，在该服务中您可以提交依赖项以进行持续审核，这将提醒您，这可能是您的更好选择。

合适的工具 (Suitable tools)

• Snyk

  斯尼克

• GitHub’s Security Alerts

  GitHub的安全警报

容器层 (The Container Layer)

Dependency vulnerability is usually where developers stop paying attention. This is why we have put the next layer under the surface in our illustration. While container layer security is no less important, it’s often neglected.

依赖漏洞通常是开发人员不再关注的地方。 这就是为什么我们在插图中将下一层放置在表面之下。 尽管容器层安全性同样重要，但它经常被忽略。

Too many developers view containers as a Panacea that addresses all their issues, including security. While containers can help with security through isolation, attention still needs to be paid to security. If not, you may actually end up in a worse security state than without containers. For instance, most developers would consider it reckless to run a service as root on their host machine, but the same developer might run the same service as root inside a Docker container. By doing so, s/he opens up an attack vector that would not have existed otherwise.

太多的开发人员将容器视为解决其所有问题(包括安全性)的灵丹妙药。 尽管容器可以通过隔离来帮助提高安全性，但仍然需要注意安全性。 如果没有，那么实际上您可能会比没有容器时处于更糟糕的安全状态。 例如，大多数开发人员会认为在其主机上以root用户身份运行服务是鲁re的，但是同一位开发人员可能在Docker容器内以root用户身份运行相同的服务。 通过这样做，他/他打开了一个否则将不存在的攻击向量。

If you’re building your own images, you should follow security best practices for the image themselves. Aqua’s Docker Security Best Practices provides a good guideline for this. However, it doesn’t stop there. You need to build in vulnerability checking into your build pipeline. Tools like Aqua’s MicroScanner makes this a painless process, and it helps you catch vulnerable packages in your Docker images.

如果要构建自己的映像，则应遵循映像本身的安全最佳做法。 Aqua的Docker安全最佳实践为此提供了一个很好的指南。 但是，它并不止于此。 您需要将漏洞检查内置到构建管道中。 诸如Aqua的MicroScanner之类的工具使此过程轻松进行，并且可以帮助您在Docker映像中捕获易受攻击的软件包。

Also, be careful when pulling Docker images from Docker Hub. In 2018 Docker pulled 17 compromised Docker images from Docker Hub.

另外，从Docker Hub提取Docker映像时要小心。 在2018年，Docker从Docker Hub中删除了17个受损的Docker映像 。

合适的工具 (Suitable tools)

• Aqua MicroScanner

  Aqua MicroScanner

• Sysdig Secure

  Sysdig 安全

• CoreOS (Now Red Hat) Clair

  CoreOS(Now Red Hat) 克莱尔

操作系统层 (The Operating System Layer)

Last, but no less important, we have the perhaps most neglected layer in recent time: the operating system. As the focus of developers have moved higher up in the abstraction layers, many companies have forgotten to patch their servers. Yes, it might not be as sexy as the latest JavaScript framework, but if an attacker can gain root access on your VM, none of the other security layers considerations matter.

最后但同样重要的是，我们在最近一段时间中可能是最被忽视的层：操作系统。 随着开发人员的注意力在抽象层上移得更高，许多公司都忘记了修补服务器。 是的，它可能不如最新JavaScript框架那么诱人，但是如果攻击者可以在您的VM上获得root用户访问权限，那么其他安全层注意事项都不重要 。

Remember Heartbleed, Spectre and Meltdown? All of these affected the actual operating system. While containers could help mitigate some of these (to some degree), the actual operating system still needed to be patched. What we found surprising when talking to a number of companies was that they assumed these things were taken care of by their cloud provider (e.g. AWS). Cloud providers usually offer some form of shared responsibility model that puts some onus on the user. AWS for instance describes security ‘of the cloud’ as their responsibility and security ‘in the cloud’ as the user responsibility.

还记得Heartbleed ， Spectre和Meltdown吗？ 所有这些都影响了实际的操作系统。 尽管容器可以(在一定程度上)缓解其中的某些问题，但仍需要修补实际的操作系统。 与许多公司交谈时，我们感到惊讶的是，他们认为这些事情已由其云提供商(例如AWS)负责。 云提供商通常会提供某种形式的共享责任模型，给用户带来一些负担。 例如，AWS 将 “云安全” 描述为责任，将“云安全” 描述为用户责任。

You can partially mitigate the problem by using ephemeral servers (i.e. the ‘Cattle’ in the Pet vs Cattle analogy), and have short-lived and frequently replaced VM. This however assume that all new VMs always use the latest (patched) upstream, and that provision of the instances using something like CloudFormation, Terraform, CloudInit or a configuration management software (e.g. Puppet, Chef, Ansible). If however, you have long-lived servers (i.e. ‘Pets’), you need to monitor the ongoing security posture of your servers. Yet, even if you are using short-lived servers, there is an attack window available.

您可以通过使用临时服务器(即Pet与Cattle类比中的“牛”)来部分缓解该问题，并且具有短暂且经常更换的VM。 但是，这假定所有新VM始终使用最新的(已修补)上游，并且使用CloudFormation，Terraform，CloudInit或配置管理软件(例如Puppet，Chef，Ansible)提供实例。 但是，如果您的服务器(例如“宠物”)寿命长，则需要监视服务器的持续安全状态。 但是，即使您使用的是寿命短的服务器，也存在可用的攻击窗口。

While operating security doesn’t fully fit into the CI/CD pipeline, it is important to continuously monitor the server state. This includes, but is not limited to:

尽管操作安全性未完全适合CI / CD管道，但是连续监视服务器状态很重要。 这包括但不限于：

• Service configuration (e.g. OpenSSH)
  服务配置(例如，OpenSSH)
• Server hardening (i.e. the operating system itself)
  服务器强化(即操作系统本身)
• Scan all installed packages against known vulnerabilities (i.e. CVE scan)
  针对已知漏洞扫描所有已安装的软件包(即CVE扫描)

To solve the pipeline problem, we at WoTT have solved with things like our GitHub integration.

为了解决管道问题，我们的WoTT解决了GitHub集成之类的问题 。

合适的工具 (Suitable tools)

• WoTT

  沃特

• Red Hat Satellite

  红帽卫星

• Aqua Security for Cloud VMs

  适用于Cloud VM的 Aqua Security

• Ubuntu Landscape

  Ubuntu 景观

结论 (Conclusion)

We hope that this article has provided a good overview of the different layers of security. As stated in the introduction, this is by no means a comprehensive security guide, but merely an overview. The takeaway is that you really should be using one tool in each category to improve your security posture, not just for the tip of the iceberg.

我们希望本文能够很好地概述安全性的不同层次。 如导言所述，这绝不是全面的安全指南，而只是概述。 结论是，您确实应该在每个类别中使用一种工具来改善安全状况，而不仅仅是在冰山一角。

Update 1: Added more information to improve clarity on concept.

更新1：添加了更多信息以提高概念的清晰度。

Originally published at https://wott.io.

最初发布在 https://wott.io 。

翻译自: https://medium.com/wottsecurity/the-devsecops-iceberg-fd1518ea12cd

冰山订单