网站做seo必要的结构,国家电网公司人力资源招聘平台,销售订单管理系统软件,做网站在线作者简介#xff1a;裴伟伟#xff0c;洞源实验室创始人#xff0c;国家网安基地网络安全行业专家#xff0c;网安加社区特聘专家#xff0c;持有CISSP、PMP证书#xff0c;曾在HITCON、可信云大会、开源产业大会等安全论坛发表演讲。曾任国内某安全实验室负责人、某互金… 作者简介裴伟伟洞源实验室创始人国家网安基地网络安全行业专家网安加社区特聘专家持有CISSP、PMP证书曾在HITCON、可信云大会、开源产业大会等安全论坛发表演讲。曾任国内某安全实验室负责人、某互金企业安全负责人、某头部SaaS企业首席信息官负责安全合规、IT审计、软件安全、基础安全、数据安全、安全运维和安全研发等工作擅长企业安全建设与运营、软件安全开发以及技术团队建设与管理。 无论是做漏洞研究还是做安全测试最终都需要以文本和图片的方式将安全漏洞的信息呈现给需要理解漏洞的人这个人可能是漏洞相关产品所在机构的审核人员也可能是漏洞所属产品的研发人员或者是产品经理之类的决策或管理人员。 在企业的安全管理中无论是通过自动化漏洞扫描还是通过人工安全测试再或者是和相关团队就安全漏洞进行反馈安全部门都需要将安全漏洞的信息传递给业务部门进行修复。 但往往出于自身的便捷以及专业理解的偏差安全团队提交的漏洞信息往往是安全产品原生的报告或者是略加修饰的报告从安全人员角度可以很容易理解的报告。对于业务方的产品经理、研发人员、运维人员在庞杂的工作压力之余查看漏洞信息就像从100份简历中用5分钟筛选值得面试的候选人“简历”的清晰、简单、易懂成为首选加之专业名词的应用使得查看漏洞信息的人可能会对这些专业的漏洞信息有一种莫名其妙、不知所云的感觉。 当然会有技术人员可以很容易或者稍加注意可以通过漏洞报告发现程序中的漏洞或缺陷但通用型的漏洞修复方案会增加漏洞修复人员的学习成本和修复成本不得不花时间和精力就漏洞修复方式进行二次沟通或者自我学习倘若是自我学习之后“发现”的修复方式可能会又会面临漏洞修复不彻底或者漏洞根本未被修复的尴尬。 笔者曾经遇到某客户的副总看着产品漏洞报告一脸疑惑的询问漏洞描述中的某专业术语是什么含义并随口问了与会的研发人员对方也支支吾吾而从安全人员的角度这个名词早已众人皆知。 因此在安全工作中安全团队反馈给其他团队或部门的漏洞信息如果足够的详实能够减少很多安全人员与非安全人员之间的沟通成本尤其是复杂的漏洞或者是危害性高但又从业务角度体现不明显的漏洞安全人员与非安全人员之间常常会对于漏洞定级产生分歧和争议比如研发人员认为是低危安全人员认为是高危又或者研发人员不认为是漏洞需要安全人员展示漏洞的危害性比如安全人员反馈的漏洞是关于SSL/TLS协议的漏洞或者是HTTP请求中使用了PUT/DELETE等不安全的请求方法这时安全团队面对研发人员关于漏洞危害性的反问会陷入无法自证的尴尬局面。 对于企业安全工作漏洞报告或漏洞信息的根本目的是方便漏洞修复人员理解漏洞并制定策略、确定优先级、执行修复、排查漏洞和预防同类漏洞再次发生将内部的协作效率尽可能提升并降低不必要的内部沟通成本以及不必要的矛盾就像用户开着车辆去4S店进行车辆保养4S店的工作人员找到用户反馈车辆保养中发现的车辆维修或配件问题用户大概会考虑 1. 怎么理解这个问题听不懂的问题没有办法判断要不要解决可能会白花钱 2. 理解问题之后问题能有多严重不严重的问题可能不用处理可能会白花钱 3. 如果问题严重怎么证明问题的存在而不是4S店瞎编只是理论上的严重也可以不用处理可能会白花钱 4. 如果问题存在且严重需要什么代价用什么方式处理如果代价过高可能不如过段时间换一辆新车否则会白花钱。 根据笔者在企业安全建设过程中做安全建设的经验以及和白帽子对漏洞进行沟通和评估的经验笔者认为无论是在企业内部的漏洞信息呈现还是安全人员作为乙方提供漏洞信息至漏洞平台或甲方公司漏洞信息或安全报告中的漏洞详情的部分需要体现以下内容 ▪ 漏洞名称即简洁、清晰、易懂的标题 ▪ 漏洞描述漏洞的上下文关系、漏洞原理以及利用成功后的影响 ▪ 漏洞位置漏洞出现的位置比如URL、参数、文件或其他资源 ▪ 影响范围漏洞利用成功后受影响的用户、客户或其他目标人群 ▪ 漏洞危害漏洞利用成功后的危害情况简短说明 ▪ 漏洞复杂度漏洞利用的条件和难度的简短说明 ▪ 发生概率发生漏洞被利用的概率比如高、中、低 ▪ 漏洞严重性结合漏洞危害和发生概率评估的漏洞严重性比如严重、高危、中危、低危 ▪ 复现过程能够复现漏洞的逐步的操作说明确保漏洞修复人员可复现漏洞 ▪ 修复建议能够帮助开发者或相关人员修复或缓解漏洞的具体方式 漏洞名称
漏洞名称是对于漏洞信息的简要说明但不建议在其中使用专业术语或名词过于简单的漏洞名称和过于专业的漏洞术语对于修复人员而言无法都无法立即了解漏洞的基本情况。 比如上图中是某漏洞扫描工具导出的扫描报告其中一个漏洞的名称是 电话号码 如果将这个漏洞名称进行口头反馈大概是“您好我们发现了一个安全漏洞它的名字叫电话号码”听到这句话的修复人员大概也会产生一个大大的问号就像早年有公司宣传的“手机号码中毒”风险。这个漏洞标题过于简单以至于需要漏洞修复人员仔细查看完整的漏洞描述之后才能注意到是应用程序的注释或错误信息页面中包含了手机号码信息。 如此这个漏洞名称应该改为 XX页面或注释存在电话号码泄露 较为清晰的漏洞名称可以帮助漏洞修复人员在看到漏洞名称后快速初步判断漏洞修复的优先级并决定是否需要进一步查看该漏洞的后续信息。 漏洞描述
漏洞描述是对于漏洞名称的更加详细的补充描述用来介绍漏洞的基本原理以及漏洞在应用程序中的上下文关系还有一旦漏洞利用成功可能产生的通用的影响即一般情况下可能会有什么影响。通过查看详细、精准的漏洞描述漏洞修复人员能够更准确理解应用程序中的漏洞情况甚至学习这类漏洞的基本情况在后续的开放过程中避免类似漏洞的发生。 以上文中的漏洞名称为例通用的漏洞描述如下 Web应用程序中错误消息或者代码注释中含有电话号码可能被用于社会工程学攻击。 这段描述中的“社会工程学”会让多数非安全人员感觉到困惑什么是社会还有工程学是一种学术么漏洞描述做人人都理解的假设会让看到漏洞信息的其他技术人员增加漏洞修复的隐性成本。 更为详细的漏洞描述如下 XX页面路径下包括XX等地址在内的页面注释或页面信息中存在手机号码的泄露该号码可能会被攻击者用于挖掘、检索更多关于企业和员工的信息造成更大范围的攻击或伪装成企业内部人员通过手机通讯诱导企业员工做出符合攻击者意图的操作。 漏洞位置
漏洞位置描述的是发现漏洞的具体位置包括应用程序中具体的地址、部分以及相应的参数且能够让修复人员根据位置信息快速定位漏洞。比如 URLhttps://example.com/news 新闻页面
参数请求参数page 在安全漏洞响应中花费时间最多的往往不是漏洞修复方法而是如何定位漏洞在企业资产中的位置大到具体的系统小到具体的代码行以及相应的责任人即漏洞响应最终需要将漏洞信息、业务、资产、人员进行关联。因此详细的漏洞位置也可以帮助技术人员快速应对漏洞的修复。 影响范围
影响范围是从应用程序的业务角度考虑的对于安全研究人员或测试人员这通常比较难获取但对于企业内的安全部门应该是易如反掌的通常应用的业务影响是由真正使用应用程序的用户或者应用程序的负责人才清除的这也是为什么安全部门也是业务支撑部门的原因如果纯粹把部门看作技术部门那和第三方的安全公司的差异便不大了。另外从漏洞所在位置的功能也能够了解大概的漏洞影响范围。比如上文描述的页面或注释信息的电话号码泄露会影响到公司的内部员工或者公司的内部信息保密性。 漏洞危害
漏洞危害是漏洞描述中漏洞利用成功后的影响结合影响范围综合评估的危害程度需要简单明了说明漏洞一旦被利用成功对于影响范围内的用户、企业或业务的危害情况危害情况的考虑要分别从以下方面着手 人身安全、业务稳定性、数据安全性、其他资产安全性、无形资产品牌、声誉、知识产权、商标等等。 比如某个应用系统中存在SQL注入漏洞可以造成数据库拖库但这些数据均是该系统的测试数据且应用也只是是所在企业边缘环境的测试应用虽然通过注入漏洞可能进一步提权植入后门进而横向移动产生更大危害但就这个SQL注入漏洞而言无论漏洞类型是什么或者漏洞描述的危害多么严重即便漏洞利用成功对于企业的用户、员工、业务、数据、资产影响也会非常有限因此这个SQL注入漏洞便不能算作高危及以上漏洞。也就是漏洞的影响和危害应当像刑法中犯罪行为危害的因果关系的判定不能无限关联否则每个漏洞都可以说牵扯到企业的生死存亡。 漏洞复杂度
漏洞复杂度是漏洞利用条件和利用难度的说明尤其是利用条件所有的受保护对象都存在漏洞最极端的攻击方式是物理攻击物理攻击的难度天花板就是热战争但对于漏洞信息或者漏洞报告而言显然其复杂度需要考虑漏洞实际的利用条件这也可以作为漏洞修复人员制定漏洞修复策略的参考之一。比如在诸如Nessus的漏洞扫描工具扫除的漏洞中常常会看到SSL/TLS的协议漏洞但这些漏洞基本都是知道是漏洞又无法有效利用或者利用条件及其苛刻又或者利用难度及其高这个适合倘若运维人员收到这样的漏洞信息一句话就可以回应漏洞的修复要不然把这个漏洞复现给我们看看 发生概率
发生概率是对于漏洞复杂度的更加直接表述即漏洞被利用的可能性有多大漏洞利用条件越低利用难度越小发生概率越大反之利用条件越高利用难度越大发生概率越小。漏洞是否进行修复根本上在于发生概率的大小和危害的大小毕竟风险等于概率Rate Of Occurrence乘以危害Single Loss Expectancy。 以上文漏洞为例无论是在企业的安全漏洞测试中还是在渗透测试过程中电话号码泄露漏洞被利用的发生概率通常是高但其危害性也需要安全人员的专业能力和经验加以判断因为对于社工能力不同的安全人员而言漏洞利用难度会不同危害性也会不同因此不同人的判断结果上也可能会不同。因此在风险评估的定性评估方法中风险结果的大小因人而异。 漏洞严重性
漏洞严重性是结合漏洞危害和漏洞发生概率综合评估的严重性描述但通常是基于安全研究人员或安全测试人员个人经验判断也是漏洞报告最容易产生争议的部分许多安全人员习惯性的按照漏洞类型进行严重性划分比如命令行执行是严重信息泄露是低危如上文漏洞危害部分的描述直接按照漏洞类型进行漏洞严重性划分并不严谨。倘若如实描述漏洞危害和发生概率漏洞严重性的描述也会相对客观。所以为了客观起见国外许多漏洞报告中需要安全人员填写CVSS评分通过CVSS评分规则来确保漏洞严重性的客观性。 复现过程
复现过程是漏洞信息中的最重要部分之一它能够帮助漏洞修复人员按照步骤一步一步重现漏洞发掘的过程进而确认漏洞的存在之所以如此说也是有安全人员曾经伪造漏洞以获得工作成果或奖金以及设计合适的漏洞修复方式。复现过程的重点在于描述的步骤和每个步骤的描述。比如 1. 访问https://example.com/news?page1。 2. 在页面中点击鼠标右键选择“查看网页源代码”。 3. 在网页源代码页面的底部可以看到存在两个企业员工的手机号码。 如果在复现过程的步骤中需要用到截图展示漏洞的证明PoC则需要在截图中通过标注等方式提示漏洞复现过程中提及的漏洞位置、请求、响应等信息。 修复建议
修复建议是从安全人员对于应用程序和漏洞信息掌握的情况对于漏洞解决方法的详细建议之所以是建议是修复人员可以不必采纳仅供参考漏洞报告中的漏洞解决思路主要包括缓解Mitigated和修正Remediated前者是降低漏洞被利用的机率后者则是彻底解决漏洞大多数情况下的漏洞修复都应该按照后一种思路设计但有时候会因为业务的约束或者资源的约束不得不选择前一种办法比如典型的情况是某个0-day漏洞被曝光后一时没有合适的修复方法通过设置WAF规则来降低漏洞被利用概率。 修复建议需要根据漏洞严重性、影响范围以及应用程序的业务和功能需要提出早年间修复建议编写的一个不良做法是粗暴的写一句“你懂的”甚至在企业内部也有安全人员习惯性的用这种高傲的语气描述修复建议又或者根据漏洞类型给出一个通用的修复方式比如上文漏洞的通用修复建议是“关闭Web服务器错误提示确保代码注释中不含有电话号码”。 企业官方网站中的电话号码信息可能是用于业务联系的按照上述的修复方法显然是和企业业务需求冲突。因此需要结合该业务需要编写修复建议 建议将页面中的员工个人手机号码修改为企业座机号码。 当安全行业对于行业外的企业、人员对于安全漏洞的不重视痛心疾首的时候或许漏洞信息或呈现方式也对于安全漏洞的“漠视”有推波助澜作用就像文章开头的例子如果用户在4S店中可以很清晰的得到关于更换汽车火花塞的必要性的详细描述或许对于用户下决心更滑配件有莫大帮助。 问题名称汽车行驶里程过大需要更换发动机火花塞 问题描述汽车火花塞的主要作用是将点火线圈产生的高压电引入发动机燃烧室内在火花塞电极之间产生电火花点燃混合气体从而推动发动机正常运转。汽车行驶里程或汽车使用时间增加火花塞会逐渐老化影响到发动机正常启动或发动机性能。 问题位置汽车发动机同时工作人员应该展示具体位置的照片。 影响范围汽车发动机启动异常或者发动机性能下降会导致汽车动力不足并可能会在汽车启动后在指示灯中提示发动机故障标识。 问题危害汽车发动时间变长反复按启动按钮无法启动或者在汽车行驶过程中踩油门发现汽车动力不够或者在汽车处于怠速时明显感觉到汽车的抖动。 问题复杂度低 发生概率高 问题严重性严重 复现过程此处应该拍视频显示火花塞的老化情况或问题情况。 修复建议花费60元更换发动机火花塞每颗火花塞15元。
