当安全产品企业本身也需要利用种种途径来购买其产品的漏洞描述时，事态到底会变成什么样？正如我们近期不断听到的关于HBGary，RSA以及Comodo攻击的新闻，安全产品如今也已沦为缓冲区溢出及目录检索等攻击方式的牺牲品。
当安全产品企业本身也需要利用种种途径来购买其产品的漏洞描述时，事态到底会变成什么样？正如我们近期不断听到的关于HBGary，RSA以及Comodo攻击的新闻，安全产品如今也已沦为缓冲区溢出及目录检索等攻击方式的牺牲品。
大多数人都会误以为我们的安全保障工具本身是安全的。但实际情况是，安全产品与那些经常遭受0day漏洞困扰的桌面应用程序并没有本质上的不同——它们都是由程序员编写的。程序员也是人，而人总会犯下错误并由此形成漏洞。
推荐阅读：安全产品不安全？NSSLabs评测：83%的防火墙有漏洞
残酷的现实是：安全产品同任何一款软件或设备一样，在实际应用之前都要经历类似的检验过程。
企业不应该盲目地引进一个全新的安全解决方案。正如在选择那些与安全无关的产品时一样，他们最好是根据IT组织对该款新安全工具所做出的相关风险评估来进行判断。评估内容包括检查其代码在开发过程中是否安全以及部署一套模拟解决方案以进行渗透测试。
检验的第一步是要进行风险评估工作，以确保设备的安置及软件的安装不会对环境安全产生负面影响。有这样一个值得思考的重要问题：如果攻击者成功利用了安全软件中的某个漏洞，会带来何种程度的后果？攻击者到底能通过获取企业系统访问权限来破坏或窃取到哪些信息？
早在2006年末，"BigYellow"蠕虫病毒就为上述问题提供了一些极具威胁性的回应。攻击者能够在运行着赛门铁克杀毒软件的Windows系统上轻松获得远程访问及管理的全部权限。借由这种途径，蠕虫病毒得以利用僵尸网络的形式渗入系统，进而使攻击者获得了对系统的远程控制能力。
如果事先做过风险评估工作，各类机构可能会在如何更好地选择安全产品方面得出较为明确的结论。被利用于远程管理的漏洞端口本应只限于与管理服务器间沟通，有了这些清醒的认识，我们就可以大大降低蠕虫病毒的传播机率与造成的损失。
许多打算采购安全产品的企业压根忘记了向供应厂商询问其产品是否遵循安全编码规范。他们是否具备一套包括安全性测试在内的标准软件开发周期（简称SDLC）。显然，如果我们问起，电话那头的工作人员往往会给出肯定的答案，别松懈，继续从他那里套出更多信息。他们的源代码进行过审核吗？有没有第三方给出的分析结果及渗透测试报告？
当然，在这种情况下，大家恐怕不得不姑且听信供应商的口头承诺。不过多进行交谈并了解其处理过程（只要不触及核心技术，工作人员是会进行介绍的）可以让我们更安心。话题还应该涉及到在未来的应用中遇到问题时的情况--供应商如何避免产品缺陷，又会以何种方式来解决突发情况？
在产品的评估阶段进行渗透测试--或是模拟一次小型攻击--也同样有机会暴露那些在风险评估过程中没有被注意到的细小问题。例如该产品在安装时可能需要利用访问控制，而这一步骤会削弱当前运行环境的安全性；该产品可能包含一个能够避过识别扫描的漏洞；应用协议内容模糊不清等等。
如今许多安全解决方案都会提供基于页面的管理界面，而这将会导致另一个安全隐患，专家如是说。该管理界面所存在的缺口有可能使整个企业遭受攻击。经由该页面管理（或者是任何页面应用程序）漏洞，我们可能会受到包括跨站点脚本（简称XSS）、伪造跨站请求（简称CSRF）、SQL注入或未经授权的远程命令执行等各种我们不希望见到的侵害。
有时漏洞来自于同安全产品捆绑在一起的底层页面服务。说起这个话题，我先举两个实例：案例一中，某位供应商由于使用了过时的目录安装结构而导致了安全漏洞，进而使数十万名病人的病历遭到曝光。这个安全问题很有意思，因为它的后果对客户而言极其严重，而避免的办法只需在安全解决方案部署之前进行一次评估即可。
第二个案例是在一台JBOSS服务器上发现了类似的漏洞。在一次渗透测试中，服务器被发现有遭受入侵的迹象，该漏洞导致攻击者能够在运行着JBOSS服务的Windows主机上能够获得全部远程访问权限。在这种情况之下，客户在购买并部署这套安全工具之前，向供应商提交了问题报告及修复建议。
没人希望一款安全产品中存在着漏洞，但这种情况却无法完全避免。进行风险评估、向供应商正确发问以及做好渗透测试可以帮助降低--甚至消除--漏洞造成巨大损失的可能性。请记住，我们付费购买产品是为了保护自己的计算机运行环境，而不是使其更不安全。采取适当的预防措施，才能确保安全产品发挥其应有的保护作用。
网友评论