杂谈渗透测试

围观次数:346 views

近几年信息安全成为一个越来越热的话题,无论是国家层面的重视还是企业的持续投入以及个人的职业发展,呈现出一派欣欣向荣的景象,遥想刚到NS公司的时候,信息安全还是少数专业人士的事情,圈子里的人就那么多,跳来跳去也就那么几个公司,即使在金融、互联网等对信息安全风险认知较高的行业,也就是那么几个人在维护着全公司的安全,或者是IT部门的信息安全岗或者最好情况也就是有个信息安全小组,其他人员包括IT技术人员很少对信息安全有足够的重视,更别说高级管理层人员了。十几年的时间,信息安全的概念与意识已经逐步渗透到生活的很多方面,从个人隐私保护到安全支付,每个人都会或多或少的接触到信息安全。

对非信息安全专业人员来说,很多的信息安全技术与专业术语还比较晦涩难懂,不过提到渗透测试,稍稍接触过信息安全服务的人员都会或多或少有一些了解,尤其近几年信息安全得到前所未有的重视,一些高级管理人员也开始要求“做做渗透测试吧”,为什么一个很专业的词语能够被大众所认知呢,也许和“黑客”这个词的普及有直接关系,渗透测试就是假扮黑客进行攻击,大多数人最直白的解释,甚至很多专业人员也有这样的印象,从基本的套路来说确实很相似,但细细品味却又有一些很不一样的地方。

“渗透测试 (penetration
test)
并没有一个标准的定义,国外一些安全组织达成共识的通用说法是:渗透测试是通过模拟恶意黑客的攻击方法,来评估计算机网络安全的一种评估方法。” 这是百度百科给出的定义。

最近接触一些公司提出希望做渗透测试,也看了不少专业公司的渗透测试报告,有发现一堆问题的,有拿到一定级别权限甚至提权成功的,也有找出长长的Web应用漏洞的,整体感觉渗透测试人员的专业能力确实有不小的提升,能够实施测试的人员基数应该也比以前有了较大的增加,从报告内容和分析过程与结果来看,大部分还是就事论事,对发现的问题进行了验证,提供了改进建议,比如发现有SQL注入问题,所以提出建议对语句与字符串进行过滤,从解决一个问题的角度,这个是可行的,不过似乎在什么地方有不妥的,有什么不妥呢?从个人经验上看,安全很长一段时间仅仅停留在安全部门和IT部门的层面上,无法和高层进行沟通引起高层的重视甚至共鸣,因为太专注在问题本身了,缺少从业务和风险管理的角度进行分析与追根溯源,安全公司一直不缺少技术人员,至少总有一些人拿得出手,但缺乏懂得行业特点与业务逻辑甚至全面风险管理的信息安全人员,试想如果和公司的C级别人员(CEOCFOCOO等)去讨论如果预防SQL注入效果会是什么样?还是以SQL注入问题为例,如果在渗透测试报告与分析活动中,更深入的去做一些假设与问题根源分析,是开发人员能力不足还是缺少开发管理,是没有编码规范还是人员培训不够,业务逻辑是否存在容易导致注入的接口交互,存在注入问题那么对业务的影响有多大,可能影响的业务范围,可能威胁的业务逻辑与业务运营有多严重?举例也许不一定准确,想把这样一个观点表达出来,我们在做信息安全的时候,在深入到细节的时候,能否把视角在拉回来一些,试着从业务管理甚至高级管理者角度去理解与分析一些看似深奥的技术问题其中蕴含的运营、管理、业务等内容,也许这样能把一些枯燥的技术演绎的更加生动一些,工作还是那么多,但不同的视角也许能够带来不一样的价值。不一定针对某项具体的工作,单从个人职业发展角度也会有不一样的空间。

一点杂谈,无所谓对错,陆续写一些有关业务风险、信息安全、运营管理等方面的内容,算是把一些自己的感受和经验做个小结吧。

有兴趣交流的随时联系我: wally0522@hotmail.com 

2人评论了“杂谈渗透测试”

  1. 渗透测试一般也是作为风险评估的一个工作开展的,所以从风险的角度来看,本来就需要做这个。
    但是此前国内提供安全风险评估的市场被做烂掉了。国内IT视角的风险评估方法也过度痴迷于方法论,根本无法操作。实施的人也没几个真懂评估风险的,就是实施人员拿着模板抄。不是从业务高度进行的风险评估,不是从企业自上而下建立的风险评估体系,单纯从IT安全来搞风险评估成为了一件完全不靠谱的事。如果业务都没有建立风险体系,单独的IT风险评估也注定了无法操作。
    在这个背景下,风险评估逐渐变成了安全评估(不搞那些没用的风险了),渗透测试也回归了实质,就是找漏洞。
    但是随着管理体系的逐渐完善,尤其是企业全面风险管理的建立,风险评估作为一个成熟的管理方法,还是会逐渐回归的。
    因此既懂安全,又懂IT,又懂业务,还懂公司治理的人,以后会逐渐紧俏的。同志们加油!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Time limit exceeded. Please complete the captcha once again.

广告赞助