万物互联的漏洞协调机制
作者: 日期:2014年12月08日 阅:2,759

0虽然物联网属于新生事物,但它的安全问题,还是那句老话——换汤不换药。

大多数安全专业人士都会对这个新名词嗤之以鼻。他们认为代码就是代码,而任何代码都会有安全漏洞,无论这些代码是运行在服务器、个人电脑、笔记本、平板电脑、手机上,还是运行在工控系统、汽车、胰岛素泵、健康跟踪仪、家用恒温控制系统或是冰箱上。

我们从后面提到的这些产品中,可以看到一个问题,那就是这些产品的供应商从来没有在这些设备内部运行过代码,或者没有预先向互联网公开过他们的代码。反过来讲,就是说他们的代码包含着太多诸如简单的缓冲区溢出漏洞或是跨站点脚本错误这样的“低级错误”。

即使那些新兴的物联网产品的供应商,知道需要有友好的黑客或安全研究人员向他们报告产品中的漏洞,也常常在处理安全问题上磕磕绊绊。最终的结果就是,这些对安全一无所知的供应商们注定要重蹈覆辙。

物联网产品的软件安全缺陷

对于运行在服务器、台式机和笔记本电脑上的代码,安全问题带来的教训是深刻的。因为广泛、频繁的袭击曾席卷早期的互联网,让依赖于它们的系统和组织彻底 跪地屈服。本世纪初的“千年虫”问题就迫使软件供应商重新评估优先事项,将增强安全作为他们赖以生存的底线和重要支柱。

这些老的软件 供应商开始尝试着不仅要解决安全问题,更重要的,是要从第一开始就构建安全机制。制造互联的、无处不在的、暴露在互联网的新兴的物联网产品新供应商,也应 该通过安全开发生命周期(SDLC),将他们最大的安全投资集中于主动性地尝试加强其未来产品和服务,否则他们将在设计和实现中面临安全失误的风险,而一 旦代码部署,问题将更加难以解决。

漏洞的响应和协调

那么对于已经部署的代码,一旦发现漏洞又该如何呢?这些物联网产品供应商是否有可协调的漏洞披露政策,让友好的黑客知道如何向他们报告潜在的问题呢?

这是2014年初发布的ISO新标准ISO29147中在漏洞披露方面提出的一个基本能力需求。与之相关的ISO30111标准,则对在内部测试中发现 的漏洞,或是由外部黑客组织、客户、合作伙伴乃至任何人报告的漏洞该如何进行调查、分析以及做出补救措施上,提供组织指导。

然而,大多数的组织,更别说新兴的物联网产品供应商了,对这些业已存在的能提供指导的标准要么闻所未闻,要么知之甚少。

物联,还是不物联——这就是个问题

你可能早就成了漏洞测试的试验品,只是你不知道而已。

互联网上的攻击者,从最早的开始到当今的演化,从好奇心的驱动到众所周知的黑客犯罪和诈骗,一直都如影相随。攻击者和防卫者争相竞技,由此产生并激活了一个蓬勃发展的安全行业以及更宽泛的生态系统,为攻防双方提供着商品和服务方面的支持。

我们过去的世界与随着“无处不在”这个新的热词即将进入的未来世界的唯一不同之处,就是我们可以有机会带着之前无数次的技术革新所得到的经验教训来建立这些新的系统。

物联网产品的供应商,乃至暴露到互联网上的所有其他组织都必须明白,那就是代码所包含的所有错误,即使是在安全代码开发上倾注全力,也都终将无法逃脱被攻击厄运。

要时刻准备着,准备着目标明确、卓有成效的去应对这些攻击,同时与黑客社区建立伙伴关系,它们是发现新漏洞广泛传播的前哨。接下来,就要建立一套云计算生态系统,以提供越来越好的保护,应对代价日增的攻击。

有了防卫的工具和知识,落在我们肩上的任务就是去遵循这些原则,将这些经验教训应用到新产业中去。

---

要闻、干货、原创、专业

关注“信息安全知识”

我们是安全牛!

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章