mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-27 02:30:10 +08:00
commit
60b49c6d61
@ -1,75 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
How to Manage the Security Vulnerabilities of Your Open Source Product
|
||||
============================================================
|
||||
|
||||
|
||||

|
||||
In his upcoming talk at ELC + OpenIoT Summit, Ryan Ware, Security Architect at Intel, will explain how you can navigate the flood of vulnerabilities and manage the security of your product.[Creative Commons Zero][2]Pixabay
|
||||
|
||||
The security vulnerabilities that you need to consider when developing open source software can be overwhelming. Common Vulnerability Enumeration (CVE) IDs, zero-day, and other vulnerabilities are seemingly announced every day. With this flood of information, how can you stay up to date?
|
||||
|
||||
“If you shipped a product that was built on top of Linux kernel 4.4.1, between the release of that kernel and now, there have been nine CVEs against that kernel version,” says Ryan Ware, Security Architect at Intel, in the Q&A below. “These all would affect your product despite the fact they were not known at the time you shipped.”
|
||||
|
||||
|
||||

|
||||
|
||||
Ryan Ware, Security Architect at Intel[Used with permission][1]
|
||||
|
||||
In his upcoming presentation at[ ELC][6] + [OpenIoT Summit,][7] Ryan Ware, Security Architect at Intel, will present strategies for how you can navigate these waters and successfully manage the security of your product. In this preview of his talk, Ware discusses the most common developer mistakes, strategies to stay on top of vulnerabilities, and more.
|
||||
|
||||
**Linux.com: Let's start from the beginning. Can you tell readers briefly about the Common Vulnerabilities and Exposures (CVE), 0-day, and other vulnerabilities? What are they, and why are they important?**
|
||||
|
||||
Ryan Ware: Excellent questions. Common Vulnerabilities and Exposures (CVE) is a database maintained by the MITRE Corporation (a not-for-profit organization) at the behest of the United States government. It’s currently funded under the US Department of Homeland Security. It was created in 1999 to house information about all publicly known security vulnerabilities. Each of these vulnerabilities has its own identifier (a CVE-ID) and can be referenced by that. This is how the term CVE, which really applies to the whole database, has morphed into meaning an individual security vulnerability: a CVE.
|
||||
|
||||
Many of the vulnerabilities that end up in the CVE database started out life as 0-day vulnerabilities. These are vulnerabilities that for whatever reason haven’t followed a more ordered disclosure process such as Responsible Disclosure. The key is that they’ve become public and exploitable without the software vendor being able to respond with a remediation of some type -- usually a software patch. These and other unpatched software vulnerabilities are critically important because until they are patched, the vulnerability is exploitable. In many ways, the release of a CVE or a 0-Day is like a starting gun going off. Until you reach the end of the race, your customers are vulnerable.
|
||||
|
||||
**Linux.com: How many are there? How do you determine which are pertinent to your product?**
|
||||
|
||||
Ryan: Before going into how many, everyone shipping software of any kind needs to keep something in mind. Even if you take all possible efforts to ensure that the software you ship doesn’t have known vulnerabilities in it, your software *does* have vulnerabilities. They are just not known. For example, if you shipped a product that was built on top of Linux kernel 4.4.1, between the release of that kernel and now, there have been nine CVEs against that kernel version. These all would affect your product despite the fact they were not known at the time you shipped.
|
||||
|
||||
At this point in time, the CVE database contains 80,957 entries (January 30, 2017) and includes entries going all the way back to 1999 when there were 894 documented issues. The largest number in a year to date was 2014 when 7,946 issues were documented. That said, I believe that the decrease in numbers over the last two years isn’t due to there being fewer security vulnerabilities. This is something I’ll touch on in my talk.
|
||||
|
||||
**Linux.com: What are some strategies that developers can use to stay on top of all this information?**
|
||||
|
||||
Ryan: There are various ways a developer can float on top of the flood of vulnerability information. One of my favorite tools for doing so is [CVE Details][8]. They present the information from MITRE in a very digestible way. The best feature they have is the ability to create custom RSS feeds so you can follow vulnerabilities for the components you care about. Those with more complex tracking problems may want to start by downloading the MITRE CVE database (freely available) and pulling regular updates. Other excellent tools, such as cvechecker, allow you to check for known vulnerabilities in your software.
|
||||
|
||||
For key portions of your software stack, I also recommend one amazingly effective tool: Get involved with the upstream community. These are the people who understand the software you are shipping best. There are no better experts in the world. Work with them.
|
||||
|
||||
**Linux.com: How can you know whether your product has all the vulnerabilities covered? Are there tools that you recommend?**
|
||||
|
||||
Ryan: Unfortunately, as I said above, you will never have all vulnerabilities removed from your product. Some of the tools I mentioned above are key. However, there is one piece of software I haven’t mentioned yet that is absolutely critical to any product you ship: a software update mechanism. If you do not have the ability to update the product software out in the field, you have no ability to address security concerns when your customers are affected. You must be able to update, and the easier the update process, the better your customers will be protected.
|
||||
|
||||
**Linux.com: What else do developers need to know to successfully manage security vulnerabilities?**
|
||||
|
||||
Ryan: There is one mistake that I see over and over. Developers always need to keep in mind the idea of minimizing their attackable surface area. What does this mean? In practice, it means only including the things in your product that your product actually needs! This not only includes ensuring you do not incorporate extraneous software packages into your product, but that you also compile projects with configurations that turn off features you don’t need.
|
||||
|
||||
How does this help? Imagine it’s 2014\. You’ve just gone into work to see that the tech news is all Heartbleed all the time. You know you include OpenSSL in your product because you need to do some basic cryptographic functionality but you don’t use TLS heartbeat, the feature with the vulnerability in question. Would you rather:
|
||||
|
||||
a. Spend the rest of your work working with customers and partners handholding them through a critical software update fixing a highly visible security issue?
|
||||
|
||||
b. Be able to tell customers and partners simply that you compiled your products OpenSSL with the “–DOPENSSL_NO_HEARTBEATS” flag and they aren’t vulnerable, allowing you to focus on new features and other productive activities.
|
||||
|
||||
The easiest vulnerability to address is the one you don’t include.
|
||||
|
||||
_Embedded Linux Conference + OpenIoT Summit North America will be held on February 21-23, 2017 in Portland, Oregon. [Check out over 130 sessions][5] on the Linux kernel, embedded development & systems, and the latest on the open Internet of Things._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/event/elcna/2017/2/how-manage-security-vulnerabilities-your-open-source-product
|
||||
|
||||
作者:[AMBER ANKERHOLZ][a]
|
||||
译者:[译者ID](https://github.com/译者ID)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/aankerholz
|
||||
[1]:https://www.linux.com/licenses/category/used-permission
|
||||
[2]:https://www.linux.com/licenses/category/creative-commons-zero
|
||||
[3]:https://www.linux.com/files/images/ryan-ware01jpg
|
||||
[4]:https://www.linux.com/files/images/security-software-vulnerabilitiesjpg
|
||||
[5]:http://events.linuxfoundation.org/events/embedded-linux-conference/program/schedule?utm_source=linux&utm_campaign=elc17&utm_medium=blog&utm_content=video-blog
|
||||
[6]:http://events.linuxfoundation.org/events/embedded-linux-conference
|
||||
[7]:http://events.linuxfoundation.org/events/openiot-summit
|
||||
[8]:http://www.cvedetails.com/
|
@ -0,0 +1,74 @@
|
||||
如何管理开源产品的安全漏洞
|
||||
============================================================
|
||||
|
||||
|
||||

|
||||
在即将举行的 ELC + OpenIoT 峰会上,英特尔安全架构师 Ryan Ware 将会解释如何解决大量漏洞,并管理你产品的安全性。
|
||||
|
||||
[Creative Commons Zero][2]Pixabay
|
||||
|
||||
在开发开源软件时, 你需要考虑的安全漏洞可能是大量的。常见漏洞枚举(CVE)ID、零日和其他漏洞似乎每天都在公布。随着这些大量的信息,你怎么能跟上最新消息?
|
||||
|
||||
英特尔安全架构师 Ryan Ware 表示:“如果你发布了基于 Linux 内核 4.4.1 的产品,该内核截止今日已经有 9 个针对该内核的 CVE。这些都会影响你的产品,尽管事实上它们在出货时不知道。”
|
||||
|
||||

|
||||
|
||||
英特尔安全架构师 Ryan Ware [经许可使用][1]
|
||||
|
||||
在即将举行的 [ELC][6] + [OpenIoT 峰会][7]上,英特尔安全架构师 Ryan Ware 的演讲将介绍如何实施并成功管理产品的安全性的策略。在他的演讲中,Ware 讨论了最常见的开发者错误,跟上最新的漏洞的策略等等。
|
||||
|
||||
**Linux.com:让我们从头开始。你能否简要介绍一下常见漏洞和曝光(CVE),零日以及其他漏洞么?它们是什么,为什么重要?**
|
||||
|
||||
Ryan Ware:好问题。常见漏洞和曝光(CVE)是由美国政府的要求由 MITR Corporation(一个非营利组织)维护的数据库。目前由美国国土安全部资助。它是在 1999 年创建的,以包含有关所有公众安全漏洞的信息。这些漏洞中的每一个都有自己的标识符(CVE-ID),并且可以被引用。这就是 CVE 这个术语,已经演变成一个单独的安全漏洞: 一个 CVE。
|
||||
|
||||
CVE 数据库中的许多漏洞最初是零日漏洞。这些漏洞出于不管什么原因没有遵循更有序的披露过程,如负责披露。关键在于,如果没有软件供应商能够通过某种类型的修复(通常是软件补丁)来进行响应,那么它们已经成为公开和可利用的。这些和其他未打补丁的软件漏洞至关重要,因为在修补软件之前,漏洞是可以利用的。在许多方面,发布 CVE 或者零日就像是开枪。在你比赛结束之前,你的客户很容易受到伤害。
|
||||
|
||||
**Linux.com:有多少漏洞?你如何确定那些与你的产品相关?**
|
||||
|
||||
Ryan:在探讨有多少之前,任何以任何形式发布软件的人都应该记住。即使你采取一切努力确保你发布的软件没有已知的漏洞,你的软件*也会*存在漏洞。他们只是不知道而已。例如,如果你发布了一个基于 Linux 内核 4.4.1 的产品,那么截止今日,已经有了 9 个CVE。这些都会影响你的产品,尽管事实上它们在出货时不知道。
|
||||
|
||||
此时,CVE 数据库包含 80,957 个条目(2017年1月30日),包括追溯到 1999 年的记录,当时有 894 个已记录问题。迄今为止,一年中最大的数字是 2014 年,当时记录了 7,946 个问题。也就是说,我相信过去两年的数字减少并不是因为安全漏洞的减少。这是我将在我的谈话中说到的东西
|
||||
|
||||
**Linux.com:开发人员可以使用哪些策略来跟上这些信息?**
|
||||
|
||||
Ryan:开发人员可以通过各种方式跟上漏洞信息。我最喜欢的工具之一是 [CVE Details][8]。它以一种非常容易理解的方式展示了来自 MITRE 的信息。它最好的功能是创建自定义 RSS 源的能力,以便你可以跟踪你关心的组件的漏洞。那些追踪更复杂问题的人可能希望从下载 MITR CVE 数据库(免费提供)开始,并定期更新。其他优秀工具,如 cvechecker,可以让你检查软件中已知的漏洞。
|
||||
|
||||
对于软件栈中的关键部分,我还推荐一个非常有用的工具:参与上游社区。这些是最理解你发布的软件的人。世界上没有比他们更好的专家。与他们一起合作。
|
||||
|
||||
**Linux.com:你怎么知道你的产品是否涵盖了所有漏洞?有推荐的工具吗?**
|
||||
|
||||
Ryan:不幸的是,正如我上面所说,你永远无法从你的产品中移除所有的漏洞。上面提到的一些工具是关键。但是,我还没有提到一个对你发布的任何产品来说都是至关重要的软件:软件更新机制。如果你无法在当场更新产品软件,则当客户受到影响时,你无法解决安全问题。你的软件必须能够更新,更新过程更容易,你的客户将受到更好的保护。
|
||||
|
||||
**Linux.com:开发人员还需要知道什么才能成功管理安全漏洞?**
|
||||
|
||||
Ryan:有一个我反复看到的错误。开发人员总是需要牢记将攻击面最小化的想法。这是什么意思?在实践中,这意味着只包括你的产品实际需要的东西!这不仅包括确保你不将无关的软件包加入到你的产品中,而且还可以关闭不需要的功能的配置来编译项目。
|
||||
|
||||
这有什么帮助?想象这是 2014 年。你刚刚上班就看到 Heartbleed 的技术新闻。你知道你在产品中包含 OpenSSL,因为你需要执行一些基本的加密功能,但不使用 TLS 心跳,该问题与该漏洞相关。你愿意::
|
||||
|
||||
a. 花费时间与客户和合作伙伴合作,通过关键的软件更新来修复这个高度安全问题?
|
||||
|
||||
b. 只需要告诉你的客户和合作伙伴,你使用 “-DOPENSSL_NO_HEARTBEATS” 标志编译 OpenSSL 产品,他们不会受到损害,你就可以专注于新功能和其他生产活动。
|
||||
|
||||
最简单解决漏洞的方法是你不包含这个漏洞。
|
||||
|
||||
_嵌入式 Linux 会议 + OpenIoT 北美峰会将于 2017 年 2 月 21 日至 23 日在俄勒冈州波特兰举行。查看关于 Linux 内核、嵌入式开发和系统,以及最新的开放物联网的[超过 130 个会话][5]。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/event/elcna/2017/2/how-manage-security-vulnerabilities-your-open-source-product
|
||||
|
||||
作者:[AMBER ANKERHOLZ][a]
|
||||
译者:[geekpi](https://github.com/geekpi)
|
||||
校对:[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/aankerholz
|
||||
[1]:https://www.linux.com/licenses/category/used-permission
|
||||
[2]:https://www.linux.com/licenses/category/creative-commons-zero
|
||||
[3]:https://www.linux.com/files/images/ryan-ware01jpg
|
||||
[4]:https://www.linux.com/files/images/security-software-vulnerabilitiesjpg
|
||||
[5]:http://events.linuxfoundation.org/events/embedded-linux-conference/program/schedule?utm_source=linux&utm_campaign=elc17&utm_medium=blog&utm_content=video-blog
|
||||
[6]:http://events.linuxfoundation.org/events/embedded-linux-conference
|
||||
[7]:http://events.linuxfoundation.org/events/openiot-summit
|
||||
[8]:http://www.cvedetails.com/
|
Loading…
Reference in New Issue
Block a user