关注 | 全国医疗机构网络信息安全管理办法将出台 云安全

关注 | 全国医疗机构网络信息安全管理办法将出台

扫码订阅《中国信息安全》杂志权威刊物 重要平台 关键渠道邮发代号 2-786“全国医疗机构网络信息安全管理办法正在起草中,不久将会出台。”一消息人士近日在中国互联网大会上透露,新冠疫情暴发后,全球医疗健康数据频繁受到黑客攻击,国内开始重视医疗健康数据的价值,希望通过立法、加强监管等多维度方式提升医疗健康数据的整体安全水平。医疗健康数据被广泛应用医疗健康数据广泛应用在日常生活的多种场景中。比如,通过大数据高效分析用药成分、剂量时间等情况,寻找合理用药的最佳组合;通过大量临床数据进行科学分析找到病因,并进行临床病因分析和慢病监测;通过对基因序列大量分析,快速筛查和预测疾病和潜在基因缺陷的基因组学分析;对患者进行远程疾病数据采集后,结合大量临床病因数据分析,实现远程医学诊疗;通过智能可穿戴设备收集数据,实现人体生命体征检测,预警潜在健康风险,进行健康管理;应用大数据等算法,制定医保支付标准,并基于此进行精准的医保决策分析等等。卫健委医院管理研究所副所长王凯表示,医疗行业关系国计民生,医疗数据一旦遭到篡改、破坏和泄露,势必对医疗机构的声誉、医患双方的隐私及健康安全构成严重威胁,甚至影响社会的和谐稳定。中国信通院云计算与大数据研究所副所长魏凯告诉记者,基于医疗大健康数据的敏感性,2016年至今,国家相继出台了不少医疗健康数据安全政策进行规范,包括《关于促进和规范健康医疗大数据应用发展的指导意见》、《互联网诊疗管理办法》、《互联网医院管理办法》、《远程医疗服务管理规范》、《国家健康医疗大数据标准、安全和服务管理办法》、《人类遗传资源管理条例》、《数据安全法》等法律法规。“即使有如此多法规,医疗健康数据安全事件频发,数据安全形势非常严峻。”他说,尤其是疫情后,数据安全的风险进一步加剧了。疫情后健康数据安全风险加剧2020年4月,世界卫生组织发表声明称,疫情期间遭受网络攻击数量同比增长5倍。奇安信集团发布网络安全系列报告指出,2020年疫情暴发后,医疗卫生行业史上首次超过政府、金融、国防、能源、电信等领域,成为全球APT(黑客以窃取核心资料为目的,针对客户所发动的网络攻击和侵袭行为)活动关注的首要目标。全球23.7%的APT活动事件与医疗卫生行业相关。中国首次超过美国、韩国、中东等国家和地区,成为全球APT活动的首要地区性目标。安天科技集团董事长肖新光透露,抗击疫情期间,我国的卫生医疗系统、疫苗研究机构、科研院所等曾频繁遭遇网络入侵攻击。2020年4月,中国医疗公司AI检测新冠病毒技术实验数据源代码被黑客窃取并出售。在疫情期间,医疗机构个人和患者信息泄露事件更是频发。2020年1月,某市区卫生管理部门领导通过微信转发新冠病人报告。2020年11月,某市区卫生管理部门领导为提醒辖区内某单位做好防疫工作,将“疑似密接调查情况简介”微信转发,造成该辖区内单位将此信息大规模群发。此外,远程网络诊疗方式在疫情后被人们普遍接受,全国不少医院都在申请互联网医院、智慧医院。业内人士指出,由于使用网络传递诊断数据、照片等信息,医疗健康数据的不安全风险可能会进一步加剧。据悉,目前医疗健康不安全风险主要体现在八个方面,一是在线医疗数据:检验报告、诊断结果、既往病史等健康医疗数据存在因漏洞攻击、病毒感染等,导致的非法访问、窃取篡改和恶意上传等风险;二是医联体访问数据:医联体以及第三方服务机构人员在对敏感数据进行访问浏览的过程中,均可能导致医患隐私等重要信息面临泄露风险;三是临床科研数据:临床科研数据涉及人口学资料、检查信息、检验信息、药品医嘱、诊断信息、病例以及患者报告,传输过程中一旦发生泄露,后果非常严重;四是医保数据:医保数据涉及与第三方机构对接,在系统对接、数据传输、数据使用、数据存储、数据销毁等环节面临安全风险;五是医疗设备维保数据:医疗器械厂商在进行远程医疗设备维护保养时,数据将面临非授权访问、不安全链接、隐私数据泄露、维护记录保存不当等安全风险;六是健康大数据中心数据:分类分级机制缺失导致将非法登录、越权访问、异常调阅、冒名查询、批量窃取、明文泄露等数据安全隐患;七是可穿戴健康设备数据:可穿戴设备数据在采集、存储、使用阶段均存在着不同程度的安全隐患;八是医疗健康APP数据:移动应用涉及众多在线健康医疗服务、存在泄露个人健康状况数据、支付数据、卫生资源数据以及公共卫生信息的隐患。多维度提升数据安全整体水平“还有一些健康敏感数据也在非法出境。国内某知名医院领导与国外公司达成合作协议,非法启动某敏感数据科研项目,国外这家公司对该科研项目样本数据具有远程不受限制的访问权。”一位业内人士指出,面对复杂的形势,医疗机构等相关部门需要多维度提升医疗健康数据安全整体水平。魏凯指出,一方面加强监管,推动制定、完善卫生健康行业数据安全管理办法出台。另一方面,制定完善医疗健康数据安全配套标准体系,建立行业合作机制,协同创新、开放共享。“北京卫生健康委制定了北京互联网医院监管平台,要求北京市开展互联网诊疗服务的医疗机构均需与监管平台对接,接受平台监督。”北京卫生健康委信息中心副主任郑攀说,截至今年6月,北京市共审批了19家互联网医院,已全部对接监管平台。据悉,互联网医院监管平台内容包括,升级已建的医政医管电子化注册平台,实现机构、医师、护士电子证明、救护车以及医疗广告等医疗资源的管理;建设医疗服务与执业监管平台,实现互联网医院审批及互联网诊疗的实时动态监管;建设医疗服务与执业监管平台,建设医疗服务、诊疗行为等信息的采集系统以及数据展示系统,实现对实体医疗机构医疗资源与医疗服务的监管。(来源:经济参考报)扫码关注我们更多信息安全资讯请关注“中国信息安全” 本文始发于微信公众号(中国信息安全):关注 | 全国医疗机构网络信息安全管理办法将出台
阅读全文
事件管理-附录:事件时间表 安全闲碎

事件管理-附录:事件时间表

最近一段时间,我们关注在设备安全指南和事件管理相关内容知识,今天我们继续讨论这方面的知识。如何管理某些事件的示例,接下来,我们利用图片展示引导完成一组典型的事件响应。对每个阶段的活动进行了概述,并附有绿色注释,突出了事件响应 (IR) 计划的功能。我们选择涵盖四种主要事件类型。每个都说明了构成 IR 响应的各种能力和技能应该如何相互作用。它还显示了它们是如何相互依赖的。因此,在事件期间的每个点做出的决定并不是严格结构化的。相反,他们依赖于由适当权限支持的专业知识的可用性。欺诈罪恶意代码勒索软件有针对性的攻击 - 窃取客户数据事件管理-维持:建立和维持你的能力事件管理-构建:网络安全事件响应团队 (CSIRT)事件管理-计划:网络事件响应流程事件管理:事件响应概述网络安全之事件管理 原文始发于微信公众号(河南等级保护测评):事件管理-附录:事件时间表
阅读全文
漏洞管理面临三个核心问题 安全闲碎

漏洞管理面临三个核心问题

观点未能有效管理网络漏洞的后果从未如此严重。一次数据泄露可能导致严重的声誉和财务损失,而且泄露的数量每年都在不断增加,而且没有失败。确实,漏洞管理已经不再只是另一种 IT 支出——它应该是一个关键的业务目标。具体内容疫情给信息安全专业人员带来了巨大压力。随着网络安全预算紧张,数以百万计的员工已经全职或兼职转向远程办公,现在越来越复杂的威胁形势对未来提出了更加可怕的挑战。01组织在漏洞管理方面哪里出了问题?从一开始,太多组织对漏洞管理的含义就已经过时了。不仅仅是扫描您的网络是否存在威胁。漏洞管理的整体方法包括识别、报告、评估和确定暴露的优先级。至关重要的是,它还涉及风险背景。漏洞管理的综合方法不是仅仅扫描安全漏洞,而是向您展示如何利用这些漏洞以及可能发生的后果。准确地说,漏洞管理——当正确执行时——采用全局方法,其中所有方面协调工作,以降低关键业务资产的风险。这是我们都应该为之奋斗的目标。但即使你从正确的首要原则开始,在实施时你仍然可能失败。考虑到这一点,下面我们重点介绍了组织在管理漏洞时面临的三个最重要的问题。02未能正确确定威胁的优先级无法正确排列暴露是组织目前在漏洞管理环境中面临的最具破坏性的问题之一。太多组织通过扫描识别安全漏洞,然后直接进入修复阶段。在某种程度上,这种紧迫性是可以理解的。然而,归根结底,它是短视的,会带来更大的风险。聪明的组织将大量注意力集中在漏洞管理的优先级和报告阶段。未能有效地确定优先级可能会导致时间和资源的浪费,因为团队竞相解决对业务关键资产没有真正风险。更糟糕的是,它使组织以最糟糕的方式变得脆弱。一个更好的方法是专注于可以利用的风险敞口的百分之一。如果操作正确,这种优先级排序可以消除对业务敏感的系统 99% 的风险。从这种优先排序方法中受益的最佳方式是什么?使用尖端的攻击补丁管理解决方案,使用以攻击为中心的关键风险对暴露进行优先级排序。该工具超越了有限的 CVSS 评分并显示了全貌:每个漏洞被利用的可能性以及每个漏洞对您的“皇冠上的宝石”资产构成的风险。03不使用连续方法有效的漏洞管理计划是持续的,而不是偶发的。如果企业不采取持续的方法,他们将难以控制漏洞的流动并积累“漏洞债务”。这是一个严重的问题。鉴于掌握新出现的漏洞已经很困难,处理不断积压的安全问题可能会使整个情况站不住脚。使用以连续和自动化漏洞识别为中心的持续方法,而不是不定期的扫描和修复。这是开发由持续改进定义的安全态势的关键之一。04沟通不畅,组织架构不清晰当安全团队没有明确的沟通渠道和正确的组织结构时,几乎肯定会出现问题。团队成员经常没有明确的角色,他们不了解自己在整体漏洞管理框架中的位置,尤其是在职责方面。当团队成员有明确的角色定义和明确的职责时,他们可以有效地工作和协作。每个人都可以努力履行自己的职责并实现他们的特定目标,而不是孤立地工作和错过更大的图景——同时了解他们的工作如何与他人的角色和责任相关联。这种沟通需求也延伸到了最高管理层。鉴于强大的网络安全已成为一项重要的战略目标,公司领导层了解该计划并对其进行投资非常重要。05主要漏洞管理问题未能有效管理网络漏洞的后果从未如此严重。一次数据泄露可能导致严重的声誉和财务损失,而且泄露的数量每年都在不断增加,而且没有失败。确实,漏洞管理已经不再只是另一种 IT 支出——它应该是一个关键的业务目标。为了实现这一点,必须了解漏洞管理应该是一个持续的、多阶段的过程。解决困扰如此多原本聪明的 IT 部门的问题也很重要:优先级不高、管理漏洞的方法不定期以及团队和领导者之间缺乏组织和沟通。就避免这些陷阱而言,正确的方法可以带来巨大的收益。如上所述,您能做的最好的事情是结合强大的漏洞管理工具,提供适当的优先级指导和关键风险上下文。一旦您的基本战略是合理的并且您配备了正确的工具,您的企业在保护您最宝贵的资产方面将远远领先于大多数竞争对手。 本文始发于微信公众号(E安全):漏洞管理面临三个核心问题
阅读全文
信息安全服务提供方管理要求思维导图 安全闲碎

信息安全服务提供方管理要求思维导图

所谓,无规矩不成方圆。作为信息安全服务提供方,是不是手里有两把刷子,就可以直接去客户那里提供安全服务了呢?其实,要提供一次性服务,确实还是可以的。然而,要提供持续性稳定输出的服务,仅有两把刷子,没有可靠有效的管理是不行的。可能有些朋友会说,管理会造成内耗,精力内耗最终会影响效率。其实,不然。为什么呢?这里只是谈一下我粗鄙的见解。我们考虑安全服务肯定考虑服务稳定持续输出,而不是打游击战。科学管理可以提升效率,同时保障服务质量。单枪匹马式的服务,质量会波动非常大,没有体系没有持续性,为客户带来巨量不可以提前预估的各类风险。在这个过程中,安全服务提供方是一个团队,而非一人。团队讲求的是配合,讲求的是人与人分工互助之原则。信息安全服务提供方管理要求首先需要从三个大方面考虑,一是信息安全服务原则,二是信息安全服务组织级管理,三是信息安全服务项目级管理。信息安全服务原则又分合规性、数据和业务保护两个层面;信息安全服务组织级管理,即就是服务提供方公司层面的管理,又需要从制度和体系、人力资源、保密、技术能力、服务协议、服务组合、供应链几个方面进行规范;项目级管理则考虑服务方案、服务人员、服务过程、服务工具和平台、服务风险、服务变更、服务沟通、服务交付等几个方面进行规范。合规性下又需要分若干项进行细化,同理其他的各个方面也是有具体需要细化的部分。其中建立管理体系工作时需要借鉴GB/T 22080和GB/T 24405两个标准,所以信息安全有关标准是环环相扣,相辅相成的关系,脱离其他标准单独谈一个标准,其意义不能说没有,但是会大打折扣。所以,作为一个团队必然有一个团队的目标和宗旨,这个目标和宗旨要与需求方是相一致的。一旦形成组织,自然需要一个组织章程,这样在自身合规的前提下,才能为客户带来真正的合规性服务。社会本身就是需要分工协作的,作为安全服务提供方是社会一个组织,每个组织成员又是团队的一个个体。只有各司其职,做到分工互助才能将工作朝着尽善尽美的方向发展。作为信息安全服务提供方,遵循国家法律法规和国家标准,是自身合规,持续提供安全可靠稳定的安全服务,是帮助客户实现合规。合规,是散漫的无组织无纪律的杂牌军向正规军迈进,是不是正规军不在其名,不在其宣传,就看有制度有管理,是否真实在用,在促进企业向正规路上发展。参考文件:《信息安全技术 信息安全服务 分类》GB/T 30283《信息安全技术 信息安全服务提供方管理要求》GB/T 32914关键信息基础设施安全保护条例浅谈及思维导图2021年七月份恶意软件之“十恶不赦”排行榜数据安全:数据安全能力成熟度模型网络安全等级保护:应急响应计划规范思维导图红队最喜欢的18 种优秀的网络安全渗透工具 本文始发于微信公众号(祺印说信安):信息安全服务提供方管理要求思维导图
阅读全文
小蜜蜂公益译文 -- NISTIR 8011 第4卷 安全控制评估自动化支持:软件漏洞管理(上) 安全开发

小蜜蜂公益译文 -- NISTIR 8011 第4卷 安全控制评估自动化支持:软件漏洞管理(上)

概要NISTIR8011第4卷按步骤详细描述了安全控制措施的自动化评估过程,这些评估为特定评估范围(目标网络)内的漏洞管理提供了支持,并将结果应用于该网络内所有授权范围内的评估。还提供了一个流程用以评估(诊断)和响应所发现的漏洞。本文所述的与VUL能力相关的自动化控制测试与NIST的其他指南一致。NISTIR8011第4卷提供了详细的评估计划,以评估与漏洞管理相关的控制措施的有效性。其中包括支撑该计划的具体测试、测试对于特定控制措施的适用性以及缓解评估中所发现缺陷所需的资源。可以看出,针对VUL能力,在NISTSP 800-53的低-中-高基线控制措施中,87.5%的判断语句的评估可以完全或部分自动化。本文所述方法旨在客观、及时、完整地识别支持VUL能力的安全控制的有效性缺陷,用较低成本(与手动方法相比)进行风险管理。基于安全控制的缺陷信息,可以对所发现的安全缺陷以最快的速度做有效的响应一. 前言1.1目的和范围 NISTIR8011第4卷为自动化评估与软件漏洞管理(VUL)中的信息安全持续监控(ISCM)安全能力相关的NISTSP 800-53安全控制措施提供了操作方法。VUL能力符合NISTIR 8011第1卷中概述的原则。本报告的范围仅限于对NIST SP 800-53中定义的管理软件安全漏洞和编码缺陷的安全控制/控制项进行评估。1.2 目标读者NISTIR8011第4卷针对的是VUL能力,与授权、下载、安装和/或执行软件(尤其是软件补丁)的人强相关,还与设计、编写和测试软件的人员以及希望了解非软件资产中潜在软件风险的人相关。1.3内容简介 第2节简要介绍了VUL能力,确定了范围和目的,提供了VUL能力补充信息的链接。第3节详细介绍了VUL缺陷检测以及如何使用缺陷检测来自动评估支持VUL能力的NISTSP 800-53安全控制和控制项的有效性。第3节还提供了一些工具供组织使用,为支持软件漏洞管理的大多数控制项生成自动安全控制评估计划。 1.4与本NISTIR其他卷的关系本NISTIR第1卷(《概述》)提供了自动化安全控制评估的概念性信息、定义和背景,方便读者理解本卷和后续卷中内容。NISTIR8011第4卷假设读者熟悉第1卷中的信息以及NIST风险管理框架中的概念和术语。VUL能力可检测目标网络中已加载或运行中的有漏洞软件,并根据组织的策略进行响应。识别有漏洞的软件可以缓解漏洞。VUL能力依赖软件资产管理(SWAM)能力提供已安装软件的清单。后续要检查清单,确定是否存在已知漏洞和不规范编码实践。有时,特别是在没有补丁的情况下,可更改配置设置(NISTIR8011下一卷《配置设置管理》(CSM)能力的主要内容),通过禁用或以其他方式保护有漏洞的的软件功能来缓解漏洞,从而支持软件漏洞管理。实际场景中,常使用漏洞扫描软件检测有漏洞的软件。如果软件扫描所基于的元数据条理清晰,则可使用白名单中使用的数字指纹来准确可靠地识别有漏洞的代码,如2.5.2.3节所述。二. 软件漏洞管理软件漏洞管理基于这样一个认识:即使是经过组织评估和批准在系统上运行的授权软件,也可能存在已知漏洞和导致漏洞的编码缺陷(潜在未知情况)。网络设备上运行的授权软件若存在编码缺陷,也会被利用。内外部攻击者的重要攻击途径是利用软件缺陷,要么直接攻击软件本身,要么将软件作为平台,进而攻击其他资产。攻击也会利用之前未知的软件漏洞(通常称为零日漏洞),尽管攻击已知漏洞更为常见。VUL能力将存在缺陷的软件分配给个人或团队进行响应,可以降低攻击者发现和利用软件缺陷和漏洞的概率。2.1发现缺陷/确定响应优先级  运用VUL能力,组织可发现已授权或待授权软件中的漏洞。发现了漏洞,组织才能有效地管理和保护自己。VUL能力还提供了软件管理责任视图,方便相关管理人确定已识别缺陷的优先级,做出风险响应决策(例如缓解或接受)。VUL能力可识别网络上存在的软件(实际状态),并将其与期望状态的软件清单进行比较,以确定是否存在漏洞较少(通常较新)的软件版本可供部署,或者是否需要使用打补丁以外的缓解策略。VUL能力的重点是尽可能确保目标网络上运行的所有软件不受已知漏洞的影响,并应用有效的修补和响应策略。注意,NISTIR8011第3卷定义的软件包含固件。本卷使用相同的定义。这里的软件(代码)指各种资产,包括有时可能并未当作软件的资产。具体软件资产包括:2.1.1操作系统软件数据库(如Windows注册表、Linux软件包管理器)中列出的已安装软件文件和产品; 2.1.2硬盘上存在但未列示在操作系统数据库中的软件文件和产品;2.1.3移动代码;2.1.4可以修改的固件(通常包括BIOS);2.1.5内存中的代码(可以就地修改)。2.2VUL攻击场景和期望结果NISTIR8011使用攻击步骤模型总结了网络攻击的六大步骤,这里的“网络攻击”指NIST SP 800-53中的控制措施共同拦截或延缓的攻击。VUL安全能力仅限于在图1和表1所列的攻击步骤中拦截或延缓攻击。图1.  VUL对攻击步骤模型的影响                                  图1说明图1所示的攻击步骤仅限于对抗性攻击。(见NISTIR 8011第1卷3.2节)如果在步骤2中成功发起攻击,那么,正常的攻击进程中,攻击者在步骤3会立即(通过软件)在受影响的设备上建立据点。步骤5(传播、扩大控制)中,入侵某台设备后,返回到步骤2,再攻击其他设备。表1.  VUL对攻击步骤模型的影响攻击步骤目的(一般)与能力相关的防御措施(2)发动内部攻击攻击者在边界内,对边界内的某个评估对象发起攻击。 一般情况下(不限于VUL能力),包括但不限于:用户打开鱼叉式网络钓鱼邮件和/或单击附件、笔记本电脑丢失或被盗、用户安装未授权软硬件、未经授权的人员物理访问受限设施。拦截入侵:拦截或延缓利用软件漏洞实现的设备入侵  就VUL能力而言,包括但不限于:未授权软件、弱设置配置、漏打补丁。(5)扩大控制–升级或传播攻击者对评估对象获得持久性,并试图通过对评估对象提权或传播到其他评估对象来扩大控制。 一般情况下(不限于VUL能力),包括但不限于:管理员权限被劫持和/或被盗、管理员密码被非授权方使用、安全配置被更改和/或审计功能被禁用、授权用户访问与本业务无关的资源,以根权限运行的进程或程序被入侵和/或被劫持。阻止扩散:拦截或延缓利用软件漏洞进行扩散或升级   就VUL能力而言,包括但不限于:未授权软件、弱设置配置、漏打补丁。需求层级之间的可追溯性。表1显示了软件漏洞管理对示例攻击步骤的影响,但通常更有用的是观察其他需求集之间的可追溯性。为了检视这种可追溯性,可以使用表2来显示不同需求类型之间的可追溯性,方法是在对应的行和列中查找单元格,然后单击链接。例如,点击“示例攻击步骤”一列中表6的链接,可以发现该攻击步骤和子能力/缺陷检测ID、名称和目的之间的关系。控制措施和攻击步骤之间的完整可追溯性要求在路径中加上以下链接:控制到控制项(在控制项名称中提供)控制项到判断语句(见3.3节)判断语句到缺陷检测(即子能力;见3.3节)缺陷检测(即子能力)到能力(在子能力名称中提供)缺陷检测(以及能力)到攻击步骤(见表6)能力到攻击步骤(见图1(对表6的总结))表2.  需求层级之间的可追溯性a各四级标题(如3.3.1.1)为支持该能力的一个控制项。b见各缺陷检测的“支持控制项”部分的表格。2.3VUL管理和评估的评估对象VUL能力管理和评估的对象包括软件漏洞和通过软件缓解的硬件漏洞。VUL能力直接管理、评估的软件漏洞有两种:(1)在设备上使用的软件文件的特定版本和补丁级别中发现、分析并确定存在的CVE;(2)在设备上使用的软件产品和文件的软件代码中暴露出的不规范编程实践,即CWE。当设备上运行的软件中包含的CVE和CWE引起的风险若在组织可容忍的范围内,即认为设备受到保护。系统上的软件漏洞数量随着时间的推移而有增有减。发现了新漏洞,则数量增加;漏洞被修复,则数量减少。需要定期重复评估,以保持信息的时效性。 VUL能力重在防护已知漏洞,因为针对这些漏洞,潜在攻击者能够以很低的成本轻松获取攻击知识和工具。大多数已知漏洞有修补程序(否则,该漏洞被视为零日漏洞,因为该漏洞虽被披露,却没有可用的缓解措施;见2.3.1节)。遗憾的是,已知漏洞并不总能及时修补,也就是说,在任何时候,某些系统和系统组件都可能存在未修补的、可利用的软件漏洞。合理的漏洞管理程序,即使是只关注已知漏洞,也有助于抵御有钱、有干劲、有能力的攻击者。老练的攻击者会花费大量资源来发现、武器化和隐藏未知漏洞。他们在部署武器化的未知漏洞方面非常谨慎,因为这种行为有暴露漏洞的风险(即从未知变为已知),一旦暴露,可能会被防御方缓解和修复。因此,有钱、有干劲、有能力的攻击者通常更倾向于利用已知漏洞进行攻击,因为已知漏洞的攻击成本低,利用这些漏洞就不需要浪费宝贵的未知漏洞资源来实现攻击目标。因此,若软件针对已知漏洞做了保护,即使是老练的攻击者也会增加攻击成本。VUL能力还可能会处理未知漏洞,例如,扫描不规范的编码实践(如CWE)。扫描CWE可以让未知漏洞变成已知,进而处理这些漏洞。因此,虽然VUL能力主要关注的是已知漏洞(如CVE),但也会通过关注软件缺陷的常见来源(如CWE)来解决与未知漏洞相关的风险。 2.3.1  CVE CVE项目提供了漏洞列表,每条漏洞都包含唯一的标识号、描述以及至少一个公开参考链接。这些漏洞均为特定软件中发现、公开披露且上报给https://cve.mitre.org的网络安全漏洞。CVE因为具有如下重要特征,因而适用于自动评估:CVE是描述软件中包含的公开披露的网络安全漏洞的标准方法;CVE列表是一个字典,每个漏洞或暴露就是一个条目;每个CVE具有唯一标识符,可在业界各软件系统间通用;同一CVE在不同的产品、工具和服务间具有相同含义。漏洞一旦被公开且被分配CVE ID,维护软件的厂商组织就会着手开发补丁来修复该漏洞。对编码缺陷进行修复(打补丁等方法)的目的是在攻击者发现并利用它们之前发现并缓解问题。对于防御者来说,挑战在于在管理不断增加的代码复杂性的同时,还要领先于攻击者一步。从(某人)发现漏洞到软件控制组织知道漏洞并提供补丁期间,该漏洞被称为零日漏洞。在这段时间内,软件一直暴露在风险之下,直到发布并应用补丁。在暴露期间,防御攻击的选项仅限于白名单、应用常见的安全配置、隔离或删除。在评估风险时,应明白上报的软件漏洞数量不一定与软件厂商和产品中的实际软件漏洞数量相一致。攻击者希望经济高效地利用漏洞,这样,跨平台(如Acrobat和Java)实现的软件或在主流平台(如微软或思科)上实现的软件最具吸引力,因为所需要的时间最少。所以,基于主流平台的软件代码报告的漏洞最多。上报的漏洞数量多可能是由于漏洞研究和报告越来越集中于主流软件。通常情况下,某一系列软件版本中公开披露的漏洞数量越多,说明软件提供商的成熟度越高。软件平台提供商常拥有强大的漏洞披露、上报和管理程序,这些都说明软件提供商具有良好的风险管理实践。反之,没有上报漏洞的产品不一定就没有漏洞。国家漏洞数据库以标准的机器可读格式向公众发布CVE信息。就已知软件漏洞和漏洞信息分析而言,NVD是美国政府最全面的一种公开信息来源。CVE项目还维护了一个CVE数据集,该数据集可能包含更多的漏洞,但提供的漏洞相关信息较少。在本文件中,术语NVD同时指nvd.nist.gov和cve.mitre.org。有时,业界会发现尚未在NVD中分类的公开披露的漏洞,但此类来源通常是未公开的私有渠道。漏洞一般通过以下方式识别:NVD中的每条CVE由CVE编号机构分配ID。CNA可以是厂商、开源提供商或研究人员。NVD从CVE获取数据。知名的软件制造商拥有成熟强大的漏洞管理程序,它们会上报已验证漏洞。第三方道德黑客上报漏洞。有些可利用的代码漏洞未通过CVE项目公开,因此未作为CVE列入NVD。已知漏洞未公开披露的原因可能有多种,包括但不限于:只有犯罪分子和/或情报机构发现了漏洞,他们打算有朝一日利用该漏洞,因此不想披露。漏洞可能只存在于定制软件和/或工业控制系统中。由于用户数量有限且所涉及系统具有潜在敏感性,漏洞未在NVD中列出,可能的原因是披露这些漏洞或会增加攻击的风险,而不是保护受影响的系统。漏洞存在于商用现成(COTS)软件中,但在补丁出现之前不会公布,因为披露该漏洞可能会增加攻击风险,而不是保护系统。漏洞扫描提供商可能在分配CVE ID之前已发现漏洞。由于厂商和攻击者在公开漏洞方面存在的差异,再加上攻击者发现漏洞后有意瞒报,软件产品的CVE数量不一定能反映产品的实际漏洞数量。2.3.2        CWECWE是一种广为人知的分类法,针对的是生产软件过程中发现的不规范编码实践,例如“输入验证问题”,CWE网站上对此描述如下:“软件不能正确验证输入时,攻击者就能构造输入,让应用程序的其他部分无法识别,这样,系统的某些部分就会接收到意外输入,导致控制流改变、任意资源控制或任意代码执行。”缺乏充分验证的话,攻击者就能以意外方式更改程序流,造成安全漏洞。更多例子,见。与自动化评估相关的常见缺陷具有以下重要特征:代码分析器一般要么是静态,要么是动态。静态代码分析器用于检查源代码(编程语言级别)或编译代码(机器语言级别)。动态代码分析器用于观察代码执行时的行为、探测应用程序以及分析应用程序响应。虽然NVD中的CVE描述通常会提供导致CVE的不规范编码实践(即CWE)的相关信息,但CWE并不一定会导致CVE。如果没有对代码进行分析、探测,或者未检测缺陷,那么就可能忽略缺陷。这种情况下,缺陷可能最终会发展为CVE。即使对代码进行了分析且将一段代码标记为了CWE,仍不一定会实际导致CVE,因为用于检测不规范编码实践的代码分析器会有大量误报(代码分析器将代码标识为包含不规范的编码实践,而实际并非如此)。代码分析器识别出的、未验证为误报的不规范编码实践被视为软件漏洞。由于代码分析器报告经常出现误报,一般通过对所识别的不规范编码实践进行单独确认和验证进行修正。对所谓的不规范编码实践需要进一步分析,确定应该忽略(确定是误报),还是采取行动(问题确实存在),进行恰当响应或上报。CWE主要是控制、维护源代码的开发或测试人员最为关注,这类人群所在的组织主要开发COTS、政府现成(GOTS)或定制代码。此外,将软件部署到生产环境中之前需要验证软件安全性(即需要额外的软件安全保证)的组织也会关注CWE。确保代码不包含CWE的方法主要有三种,按有效性排序,分别为:招募有安全编码实践经验的开发人员,同时确保现有开发人员接受安全编码实践培训;采用流程:确保代码由具有安全编码实践经验的程序员团队独立审查;使用代码分析器:在编写或编译代码后,代码分析器常常能发现代码中的不规范代码实践;此外,代码分析器还会自动检查应用程序。2.3.3        CVE和CWE缓解角色 要理解NISTIR 8011所定义的漏洞管理角色,首先要了解组织角色。卡内基梅隆CERT的特别报告《CERT漏洞协同披露指南》描述了漏洞管理角色,如下图所示。 图2. 漏洞信息披露中的组织角色 角色有时是组织,有时是个人。最常见的个人角色包括:发现者、上报者和部署者(例如家庭用户、组织用户、系统管理员)。最常见的组织角色包括:厂商和协调者,若软件为政府或商业组织所使用,还有部署者(例如软件漏洞管理人、补丁管理人)。“厂商”这一角色需要进一步解释。这类实体指当前维护有漏洞软件的一方。正如卡内基梅隆CERT报告所述,“厂商是负责更新有漏洞产品的一方。”因此,在漏洞管理方面,厂商并非部署者(个人用户或组织)所购买软件的第三方厂商。请注意,对于定制或内部软件代码,“负责更新产品的一方”可能是部署者组织内部的员工或团队,也可能是部署者组织合作的服务提供商。图2中所示的协调者角色通常独立于评估组织,不属于NISTIR8011范围,在此不予赘述。通常,协调者角色由SEI、漏洞扫描器厂商和源文档中列出的其他团队执行。对于维护和授权的软件,NISTIR8011定义的CWE和CVE缓解角色包括软件漏洞管理人(SWFM)(与CERT定义的厂商角色对应)和补丁管理人(PatMan)(与CERT定义的部署者角色对应)。图3列举了NISTIR8011为缓解CWE和CVE而定义的角色及其职责。请注意,对于未授权软件,不会为CVE开发补丁,除了隔离或删除之外,可能没有其他的缓解办法。图3.  CVE和CWE缓解角色SWFM和PatMan角色的职责不一定是只完成图3中的任务,相反,这些任务可能是某个角色多项职责中的一部分。2.3.3.1  软件漏洞管理人(SWFM)SWFM是厂商组织角色。因此,软件漏洞管理可能是第三方厂商组织的责任,软件所有组织对此几乎没有控制权(例如,对于大多数COTS软件),也可能是软件所有组织本身的责任(例如,对于内部开发的定制软件)。 当发现并确认厂商组织维护的软件存在新漏洞时,将漏洞上报给CVE项目,以便将其列为CVE(或决定不上报漏洞或何时上报漏洞)。厂商组织(维护软件源代码的组织)内部的软件漏洞管理人(SWFM)随后开发新补丁以缓解漏洞。对于COTS或外部维护的GOTS软件,补丁由外部厂商组织的SWFM开发。对于定制或内部维护的GOTS软件,补丁由内部组织(厂商和部署者)的SWFM开发。 无论是缓解CVE还是CWE,SWFM都负责向厂商组织上报所维护软件中发现的不规范编码实践和漏洞,评估需修复的代码数量,进行必要的修复,准备补丁,进行集成,测试补丁,撰写文档,并将补丁发送给部署者组织。2.3.3.2   补丁管理人(PatMan)补丁管理人(PatMan)是部署者组织角色,存在于授权和使用软件的组织(部署者组织)中。PatMan负责检测设备和授权软件中存在的CVE,并应用补丁或临时规避方案。此处提到的软件(即代码)通常按以下级别进行分析和管理:软件文件(通过数字指纹识别)软件源代码(即版本/补丁级别的软件文件内容)软件产品(版本/补丁级别)可修改的固件(通常包括BIOS,版本/补丁级别)就漏洞管理而言,准确检测软件的具体版本和补丁级别非常重要。这是因为不同的软件版本根据所应用的补丁,包含不同的漏洞。数字指纹唯一地标识软件文件的特定版本和补丁级别。PatMan在检测系统中存在的CVE时使用的主要工具是商业漏洞扫描器。漏洞扫描器自动发现系统中各个设备上安装的所有软件文件中的CVE和所需的补丁程序。同时,补丁程序也会提供它们所缓解的CVE信息。PatMan负责从内部或外部开发组织(即厂商组织)接收补丁,测试本地系统上补丁的互通性,并将补丁应用到生产环境中的设备上。在厂商提供补丁之前,可以其他方法来缓解某些CVE。这种情况下,PatMan负责在过渡期内应用临时规避方案。补丁通常通过软件包管理系统应用,该系统自动执行软件文件的安装、升级、配置和删除。此外,也可以手动打补丁。有些软件产品的补丁必须按顺序应用,在这种情况下,应指定补丁级别。有些产品允许按不同顺序选择性应用补丁。在这种情况下,“补丁集”一词比“补丁级别”更准确。“补丁集”本质上比“补丁级别”复杂,因为补丁应用顺序有多种组合方式。本文档中,“补丁级别”一词根据实际情况可指补丁级别,也可以指补丁集。共享代码带来的修补复杂性。有些可执行文件由多个软件产品共享。动态链接库(DLL)可执行文件就是共享软件的典型例子。就修补DLL而言,一个产品可能为其他产品带来保护,也可能将其他产品暴露于风险中,具体是保护还是暴露取决于DLL最新补丁中有哪些漏洞以及依赖软件如何使用该库。例如,在OpenSSL加密库中存在“心脏出血”(Heartbleed)漏洞,但该漏洞只影响OpenSSL提供的传输层安全性(TLS)实现,OpenSSL加密算法应用程序编程接口(API)不受该漏洞影响。也就是说,OpenSSL的TLS实现暴露了“心脏出血”漏洞,但加密函数实现却没有。因此,部分软件产品的共享性增大了软件漏洞管理的难度。补丁之上摞补丁。遗憾的是,补丁本身也可能包含漏洞,后续才会发现。即使补丁当前没有已知漏洞,也有可能、甚至很可能在今后发现新的或其他的不规范编码实践,成为NVD中的新CVE条目或导致新的零日攻击。2.4VUL数据需求示例VUL能力的期望状态是:已知漏洞列表准确、完整,包含最新信息;所有设备上安装的软件产品均无已知漏洞。实际状态的VUL能力数据需求的示例见表3。期望状态的VUL能力数据需求示例见表4。表3.  VUL实际状态数据需求示例表4.  VUL期望状态数据需求示例a该值由组织根据其分配给资产的值定义。有关设备属性的说明,参见 。b组织可以为本地环境定义数据需求和相关漏洞。c有些已知漏洞可通过不安装部分代码段、可执行文件或通过配置选项有效缓解。d如果可以通过检查注册表设置、可执行哈希或配置设置来确定是否已实施替代缓解方法,则可以制定规范,自动验证是否存在漏洞。2.5VUL相关的运营实施概念 VUL识别网络设备(实际状态)中实际存在的软件(包括虚拟机上的软件),将这些软件与期望状态列表对比,明确软件中存在哪些已知漏洞(或缺陷),并安装补丁(或其他缓解方法),降低系统漏洞的可利用性。软件漏洞管理能力运营概念(CONOPS)定义了如何实现VUL能力,是自动化评估流程的核心。请参见图4。图4.  VUL运营概念(CONOPS)2.5.1    采集实际状态 ISCM数据采集流程利用工具识别补丁级别的网络设备中的软件文件(和产品),包括大容量存储器和固件中的软件。这些工具进一步提供必要信息,将实际软件与发现的补丁级别(实际状态)与授权的补丁级别(期望状态)进行比较。本节通过举例介绍用于识别实际和期望补丁级别的方法。同时,ISCM数据采集流程还会明确目标网络的监控范围和频率,最终确定完整性和及时性度量标准。设备可能因为以下各种原因而无法监控:(1)设备未联网,可能在特定扫描过程中检测不到;(2)设备关掉;扫描过程中发生错误;(3)设备位于扫描范围之外的被保护地区;(3)设备在预期IP地址范围之外(若扫描器扫描特定范围);等等。请注意,若列表数据质量可接受,可依据硬件资产管理(HWAM)能力列表检查扫描范围。需对所有能力的实际状态数据进行有效配置管理。附录G介绍如何对实际状态进行配置管理。附录G中列出的控件为VUL能力评估流程的元控件。2.5.1.1  操作系统软件数据库的实际状态数据有一些组织将操作系统软件数据库(OSSD)作为软件版本的实际状态数据的来源。不过,OSSD的多个运行特征可能会在软件版本识别过程导致如下错误:软件未列入OSSD。设备中有些软件未在OSSD中列出(即,软件由于未列入OSSD而无法被OSSD识别)。OSSD条目无法识别安装的所有软件。对于特定产品版本来说,不同安装介质实例可能会安装稍有差别的可执行文件,因此可能存在不同漏洞。OSSD可能检测不到这一点。产品卸载过程可能会删除OSSD中的软件文件条目,但不会删除所有代码。卸载过程中存在的问题可能会导致OSSD无法识别的设备仍存在漏洞代码,因此这些代码可被利用但不会被OSSD发现。OSSD不包含共享代码。使用OSSD无法解决共享代码的问题,使用共享代码开发的程序若安装了补丁,可能会导致共享代码发生变化。参见2.5.2.6节。2.5.1.2      漏洞扫描器提供的实际状态数据漏洞扫描是在实际状态中查找CVE的最常用方法之一。漏洞扫描器将存在漏洞的软件文件版本列表与系统设备上的实际软件文件版本进行对比。为确保风险识别的准确性,建议对漏洞扫描器功能进行验证,保证扫描结果的可靠性。漏洞扫描器验证过程包括以下步骤:确保组织编写的漏洞扫描器可检查大部分已知漏洞。否则,该漏洞扫描器可能会漏报漏洞。组织将扫描器发现的漏洞与NVD进行对比,明确该扫描器发现的已知漏洞的百分比,并将该百分比纳入扫描器采购流程。确保扫描器的误报率和漏报率在可接受范围内。没有任何一项测试是百分百可靠。扫描器扫描漏洞时可能会上报不存在的漏洞(误报),也可能不上报确实存在的漏洞(漏报)。采购流程中要评估扫描器的误报率和漏报率。一般情况下,误报率和漏报率成反比—一个较高,另一个必然较低。需平衡两者,也就是说,避免过多误报和过多漏报。确保新漏洞发现时,漏洞扫描器厂商及时提供更新,而且扫描器可快速更新,提供新的检测代码。请注意,检测(扫描)和响应(安装补丁)对于实现有效漏洞管理来说不可或缺。 2.5.1.3       软件白名单提供的实际状态数据若能获得有漏洞软件文件的数字指纹,我们可根据数字指纹制作软件文件列表,从而准确、可靠地识别设备中的软件数字指纹。更多详情,参见2.5.2.3节。软件白名单中数据的主要问题是:截至本文写作时,NVD或厂商对明确包含已知漏洞的软件文件尚未提供任何数字指纹。2.5.1.4      代码分析器提供的实际状态数据静态和动态代码分析器(参见术语表)用于识别可能成为漏洞的编码缺陷。通常,在软件运行前部署代码分析器(即在系统工程/系统开发生命周期早期),原因是在开发早期修复发现的缺陷成本较低。若组织无法控制源代码但希望评估购买的产品(或考虑购买的产品)是否采取了安全设计,通常会部署动态代码分析器识别和诊断安全缺陷。组织在模拟生产的测试环境中部署采购的代码(最好在最终采购决策前),根据其风险承受能力评估缺陷是否可接受。2.5.2        采集期望状态数据 VUL能力的期望状态为将可接受软件文件版本列举出来,将网络中已安装软件的已知缺陷限制在组织的风险承受范围内。因此,对于网络中的所有软件文件来说,要定义期望状态需知晓如何确定存在最少已知缺陷的最佳版本(即补丁级别)。正如下述数据采集方法所述,期望状态的识别是个持续演进过程,需纳入和整合多个来源的信息,有时,还需根据具体情况考虑组织的风险承受能力。每项能力的期望状态数据都需要有效配置管理。附录G介绍了如何对期望状态进行配置管理。附录G中的控件为VUL能力评估过程的元控件。2.5.2.1      国家漏洞数据库(NVD)VUL能力的期望状态是尽可能使用无缺陷(CVE)软件,而NVD是CVE的重要信息来源。每个CVE都有唯一标识符,NVD是CVE的权威性来源。由于NVD数据为网上公共资源,多方均通过下载NVD数据并结合其他数据识别和修复漏洞,如包含CVE的软件文件特征、CVE相关文章或CVE补丁号。2.5.2.2      漏洞扫描器除了提供实际状态数据(参见2.5.1.2节),漏洞扫描器也能提供期望状态数据。漏洞扫描器从NVD上获得CVE信息、将CVE与包含CVE漏洞的软件的标识符相关联,检查联网设备上的软件是否存在CVE缓解补丁,从而检测出系统内联网设备的软件存在的已知漏洞。就特定扫描而言,期望状态指软件中不存在CVE漏洞。说明:任一漏洞扫描器可能只检测一部分已知漏洞,所以各检测器对期望状态的定义不尽相同。2.5.2.3       开发人员包清单漏洞扫描器具备商业可行性的其中一个原因是,扫描器在扫描时,将设备上的代码与已知包含CVE的代码进行比对,提供的结果与实际情况较为接近(可接受精度范围内)。包清单若列明每个文件的数字签名,则提供了更可靠的CVE漏洞识别方法和修复补丁。开发人员一般会针对每个版本提供以下补丁级文件列表信息:版本中的CVE漏洞。列明包含每个漏洞的软件文件、含有漏洞修复的文件以及每个文件的数字指纹。若提供补丁级清单信息,扫描器可非常准确地描述设备上漏洞的实际状态(CVE漏洞)和期望状态(具体应包含哪些文件以及这些文件的补丁级别)。若采取补丁级厂商清单,非常有可能降低漏洞扫描错误率(误报和漏报)。补丁级清单可基于SWID标签编制。2.5.2.4      批准的补丁级别列表有些组织会直接编制一份已批准(和必要)补丁列表。该核准的补丁列表即为期望状态。任何缺乏必要补丁和/或其他缓解措施的软件都被标记为有漏洞软件。该补丁列表基于组织的风险承受能力编制,需要手动管理该列表。2.5.2.5      CWE(编码缺陷)信息CWE相关的VUL能力的期望状态是软件中不存在与组织的风险承受能力不一致的CWE。CWE信息采集和响应是自定义软件开发过程的重要环节。若厂商不太可能发现并上报软件漏洞,则CWE信息对于组织计划部署的商业软件至关重要。有关发现CWE(实际状态和期望状态)的工具,见2.3.2节。2.5.2.6       共享代码解决共享代码问题可进一步减少软件漏洞带来的风险。组织可识别不同产品更新的软件文件,并将所识别的软件文件与使用共享代码的一个或多个产品的漏洞列表进行比较,从而确定补丁中的共享代码文件是否达到期望状态。2.5.3        发现缺陷/进行优先级排序 VUL能力侧重于将评估边界(实际状态)内发现的软件对象版本与应该存在的最新软件对象版本列表(期望状态)进行对比,并确定响应的优先级(通常对存在漏洞的软件打补丁)。期望状态软件对象是为了将未修补漏洞的风险降至最低而选择的版本。使用商业漏洞扫描器(一般内置CVE漏洞和补丁信息)比较实际状态和期望状态是最常用的方法,但在漏洞管理中,其他缺陷(如组织明确须修复的CWE)可能会被代码分析器错误地识别为未知漏洞。无论如何,完成实际状态与期望状态比较后,都要确定的缺陷进行优先级排序,以便采取合理响应措施(如首先解决高风险问题)。2.6支持VUL的NIST SP 800-53控制措施和控制项 本节介绍如何明确支持VUL能力所需的NIST SP 800-53控制措施和控制项,并介绍用于描述各控制措施和控制项重点关注的软件漏洞的术语。2.6.1   必要控制措施确定流程本NISTIR第1卷中的3.5.2节“安全控制项与能力”中详细描述了用于明确支持能力所需的NIST SP 800-53控制措施和控制项的过程。简言之,该过程包括两个步骤:用关键字搜索NIST SP800-53中的控制措施,确定可能支持该功能的控制措施或控制项。请参见附录B中的关键字规则。手动识别确实支持该能力的NISTSP 800-53控制措施或控制项(有效告警),而忽略不支持该能力的控制措施或控制项(误报)。以上两个步骤后续会生成三套NIST SP 800-53控制措施/控制项:支持VUL能力的低风险、中风险和高风险基线中的控制措施/控制项(3.3和3.4节)。通过关键词搜索选择的低风险、中风险和高风险基线中的控制措施/控制项。不过,这些控制措施/控制项是手动确定为误报(附录C中列出)。关键词搜索后未进一步分析的基线之外的控制措施:a. 程序管理(PM)控制措施,原因是PM控制措施不适用于单个系统。b. 未选择的控制措施—NIST SP 800-53中未分配基线或基线中未选择的控制措施;和c. 隐私控制措施。组织若要开展自动化测试,参见附录D中的未分析控制措施/控制项。2.6.2   控制项术语 支持VUL能力的许多控制项还支持其他几种能力,例如,配置管理控制措施可辅助硬件资产管理,软件资产管理和配置设置管理能力。有些控制项支持多种能力,为明确其适用范围,相关描述用大括号括起来,例如,{…软件…},表示特定控制项支持VUL能力并针对(且仅针对)大括号内的内容。2.7VUL角色和责任 表5列举了VUL相关角色及其职责。图5说明了角色如何与运营概念相结合。组织若进行自动化评估,可将职责分配给承担现有角色的人员,自行定制方案。表5.  VUL相关的运营和管理角色图5.  VUL中的自动化评估涉及的主要角色2.8VUL评估范围评估范围涵盖整个计算机网络上的所有软件,“整个”是指从网络最中间到网闸所在的或与其他网络相连的边界。对于VUL能力,评估范围涉及所有设备上的软件,包括扫描时发现的可移动设备上的软件。有关评估范围相关术语的更多信息和定义,参见本NISTIR第1卷中的4.3.2节。2.9VUL的实际状态和期望状态规范有关VUL能力的实际状态和期望状态规范的信息,参见第3.2节中的缺陷检查表的评估标准注释部分。请注意,许多支持VUL能力的控制措施都引用了最新的设备软件清单(或其他清单)。SWAM能力提供软件列表。此外,还要注意,根据IST SP 800-53A对测试的定义,测试VUL控制措施时,需要同时编制实际状态清单和期望状态清单,将两者进行比较。有关比较详情,参见第3.2节中的缺陷检查表。2.10VUL授权范围和继承关于如何解决自动评估的授权范围问题,参见本NISTIR第1卷的4.3.1节。简言之,对于VUL能力,NISTSP 800-53、CM-08(5)、《信息系统组件清单》|《组件无重复登记》指出,每个设备上的软件被分配到一个且仅一个授权(系统)范围。ISCM仪表盘可提供一种机制,记录软件分配的授权范围,确保所有软件分配给至少一个授权范围,而且一个软件产品不会分配给多个授权范围。 关于如何管理公共控件的继承,请参见此NISTIR第1卷的4.3.3节。对于VUL,很多实用程序、数据库管理软件产品、Web服务器软件对象以及操作系统的某些部件为其他系统提供了可继承的支持和/或控件。ISCM仪表盘可提供一种机制,记录继承相关信息和评估系统的整体风险。2.11VUL评估标准建议的分数和风险接受阈值该NISTIR不涉及用于设置阈值的风险评分选项的常规指南。对于VUL能力,建议组织利用指标衡量每个设备的平均风险评分和最大风险评分。需要说明的是,漏洞扫描工具可能在评估发现的漏洞时进行风险评分。2.12VUL评估标准涉及的设备分组为了支持自动化评估和持续授权,应按授权范围对软件进行明确分组(请参见NIST SP 800-53中的控制项CM-8(a)和CM-8(5))。此外,还可根据人员角色(设备管理人、补丁管理人、软件管理人和软件缺陷管理人)对软件进行清晰梳理,对特定设备进行软件漏洞管理(请参见NISTSP 800-53中的控制项CM-8(4))。除了这两个重要分组,组织可能希望利用其他分组方法进行风险分析,详情请参见本NISTIR第1卷5.6节。  参考文献根据本卷中的控制分配表(CAT)得来。对于NISTSP 800-53低-中-高基线中选取的支持VUL能力的安全控制措施,48个判断语句中有42个(87.5%)可以完全或部分自动化。NISTIR8011第1卷(2017年6月)将VUL能力作为NISTIR 8011的第5卷。但是,后来发现,NISTIR 8011各功能卷的发布顺序需要优化,因此将VUL能力调整到第4卷。NISTIR 8011各能力卷的发布顺序将在第1卷的勘误版本中进行修订。条理清晰是指已知哪些软件代码文件(通过其数字指纹识别)存在漏洞,并使用软件白名单来确定是否存在有漏洞的文件。特定的软件产品得到授权后,作为组件在联网或未联网的系统上运行。而考虑到效率和有效性,系统和系统组件需要网络连接进行自动化评估。独立的系统/系统组件不适合自动评估。有关授权范围(系统)与自动评估范围(网络)的信息,参见NISTIR 8011第1卷。关于实际和期望状态的描述,见2.5.1和2.5.2节。修补和响应策略可纳入组织的漏洞管理策略。硬件漏洞通常通过软件来防护,例如为固件或操作系统打补丁,控制硬件访问或关闭硬件功能。在NISTIR 8011中,软件漏洞包括通过软件缓解的硬件漏洞。若硬件漏洞无法通过软件防护,需要对硬件进行物理修改或更换,这种漏洞不在NISTIR8011第4卷讨论之列。本文发布时,CVE项目正处于过渡期,CVE项目的管理组织和相关网站可能会发生变化。有关厂商组织的定义,参见2.3.3节。请注意,虽然恶意软件因为未授权而无法在白名单环境中运行,攻击者仍然可以通过白名单软件本身的未缓解漏洞进入环境。因此,即使在白名单软件环境中,软件漏洞管理也是高优先级事项。MITRE网站上列出的CVE描述不够完整,所以链接到NVD以提供更多信息。本文发布时,CVE项目正处于过渡期,CVE项目的管理组织和相关网站可能会发生变化。有些厂商组织选择不向CVE项目报告漏洞,而是通过本公司专有流程维护漏洞信息并提供补丁。有关支持VUL能力的各个角色,参见2.7节。注意,SWFM角色通常是软件开发/维护人员或软件开发/维护管理人的子角色,而不是完全独立的角色。这里指定SWFM角色有助于缓解软件漏洞,构成VUL能力的一部分。在他人开发的软件中查找CWE主要适用于如下情况:部署组织有内部SWFM并使用动态代码扫描器来检测他人开发的COTS或GOTS产品中的不规范编码实践(CWE)。例如,直到开发出补丁后再上报漏洞,防止在此期间被攻击。Microsoft Windows Store、Linux Red Hat RPM package Manager、Apple Mac App Store、Debian DPKG和Perl综合典藏网(Comprehensive Perl Archive Network)都是软件包管理系统。如果指定了补丁集,则补丁的应用顺序仍会影响结果(例如,当两个或多个补丁更改同一个文件时)。支持VUL能力所需的特定数据因组织平台、工具、配置等而异。完全没有已知漏洞几无可能,也不现实(例如,当尚未提供补丁或尚未修补低风险漏洞时),因此,目标是尽量降低环境中的已知漏洞数量。例如,Windows注册表或Linux包管理器由组织根据攻击者预期利用未知漏洞进行攻击的速度而定义。要求厂商基于数字指纹上报数据从而实现可靠的漏洞检测对于漏洞检测过程来说是一项重大提升。准确地说,预期状态指所有软件都安装补丁,符合组织的风险承受能力。例如,一些组织可承受其认为的低风险CVE漏洞。包清单列明了补丁发布涉及的文件。若清单列明了每个文件的数字指纹,可对补丁全部内容的完整性/真实性进行验证。因此,为了更可靠地识别CVE漏洞,软件厂商需提供包清单列明每个文件的数字指纹。对缺陷进行评分或优先级排序所必需的风险优先级排序方法不在本出版物的范围内。有关风险管理,风险评估和风险优先级的讨论,请参见和。若未明确说明该角色为自动化,则由个人或团队担任。漏洞管理过程中,利用风险评分(也称“缺陷评分”)衡量缺陷的可利用性。原文链接:https://csrc.nist.gov/publications/detail/nistir/8011/vol-4/final关于小蜜蜂翻译组公益译文项目小蜜蜂翻译组公益译文项目,旨在分享国外先进网络安全理念、规划、框架、技术标准与实践,将网络安全战略性文档翻译为中文,为网络安全从业人员提供参考,促进国内安全组织在相关方面的思考和交流。内容编辑:翻译组郝秀文 责任编辑:高深 本文始发于微信公众号(绿盟科技研究通讯):小蜜蜂公益译文 -- NISTIR 8011 第4卷 安全控制评估自动化支持:软件漏洞管理(上)
阅读全文
公告 | 国家发改委对《信用修复管理办法(试行)(征求意见稿)》公开征求意见 云安全

公告 | 国家发改委对《信用修复管理办法(试行)(征求意见稿)》公开征求意见

扫码订阅《中国信息安全》杂志权威刊物 重要平台 关键渠道邮发代号 2-786关于对《信用修复管理办法(试行)(征求意见稿)》公开征求意见的公告为规范对失信信息的信用修复工作,维护信用主体合法权益,进一步提升社会信用体系建设法治化、规范化水平,国家发展改革委起草了《信用修复管理办法(试行)(征求意见稿)》,现向社会公开征求意见。公开征求意见时间为2021年5月12日至2021年6月12日,欢迎有关单位和社会各界人士提出宝贵意见。请登录国家发展改革委门户网站(http://www.ndrc.gov.cn)首页“意见征求”专栏,提出意见建议。感谢您的参与和支持!附件:1. 信用修复管理办法(试行)(征求意见稿)2. 《信用修复管理办法(试行)(征求意见稿)》起草说明国家发展改革委2021年5月12日(来源:发改委网站)扫码关注我们更多信息安全资讯请关注“中国信息安全” 本文始发于微信公众号(中国信息安全):公告 | 国家发改委对《信用修复管理办法(试行)(征求意见稿)》公开征求意见
阅读全文
工业和信息化部 国家互联网信息办公室 公安部关于印发网络产品安全漏洞管理规定的通知 云安全

工业和信息化部 国家互联网信息办公室 公安部关于印发网络产品安全漏洞管理规定的通知

文章来源:网信中国工业和信息化部 国家互联网信息办公室 公安部关于印发网络产品安全漏洞管理规定的通知工信部联网安〔2021〕66号各省、自治区、直辖市及新疆生产建设兵团工业和信息化主管部门、网信办、公安厅(局),各省、自治区、直辖市通信管理局:  现将《网络产品安全漏洞管理规定》予以发布,自2021年9月1日起施行。工业和信息化部 国家互联网信息办公室 公安部2021年7月12日网络产品安全漏洞管理规定  第一条 为了规范网络产品安全漏洞发现、报告、修补和发布等行为,防范网络安全风险,根据《中华人民共和国网络安全法》,制定本规定。  第二条 中华人民共和国境内的网络产品(含硬件、软件)提供者和网络运营者,以及从事网络产品安全漏洞发现、收集、发布等活动的组织或者个人,应当遵守本规定。  第三条 国家互联网信息办公室负责统筹协调网络产品安全漏洞管理工作。工业和信息化部负责网络产品安全漏洞综合管理,承担电信和互联网行业网络产品安全漏洞监督管理。公安部负责网络产品安全漏洞监督管理,依法打击利用网络产品安全漏洞实施的违法犯罪活动。  有关主管部门加强跨部门协同配合,实现网络产品安全漏洞信息实时共享,对重大网络产品安全漏洞风险开展联合评估和处置。  第四条 任何组织或者个人不得利用网络产品安全漏洞从事危害网络安全的活动,不得非法收集、出售、发布网络产品安全漏洞信息;明知他人利用网络产品安全漏洞从事危害网络安全的活动的,不得为其提供技术支持、广告推广、支付结算等帮助。  第五条 网络产品提供者、网络运营者和网络产品安全漏洞收集平台应当建立健全网络产品安全漏洞信息接收渠道并保持畅通,留存网络产品安全漏洞信息接收日志不少于6个月。  第六条 鼓励相关组织和个人向网络产品提供者通报其产品存在的安全漏洞。  第七条 网络产品提供者应当履行下列网络产品安全漏洞管理义务,确保其产品安全漏洞得到及时修补和合理发布,并指导支持产品用户采取防范措施:  (一)发现或者获知所提供网络产品存在安全漏洞后,应当立即采取措施并组织对安全漏洞进行验证,评估安全漏洞的危害程度和影响范围;对属于其上游产品或者组件存在的安全漏洞,应当立即通知相关产品提供者。  (二)应当在2日内向工业和信息化部网络安全威胁和漏洞信息共享平台报送相关漏洞信息。报送内容应当包括存在网络产品安全漏洞的产品名称、型号、版本以及漏洞的技术特点、危害和影响范围等。  (三)应当及时组织对网络产品安全漏洞进行修补,对于需要产品用户(含下游厂商)采取软件、固件升级等措施的,应当及时将网络产品安全漏洞风险及修补方式告知可能受影响的产品用户,并提供必要的技术支持。  工业和信息化部网络安全威胁和漏洞信息共享平台同步向国家网络与信息安全信息通报中心、国家计算机网络应急技术处理协调中心通报相关漏洞信息。  鼓励网络产品提供者建立所提供网络产品安全漏洞奖励机制,对发现并通报所提供网络产品安全漏洞的组织或者个人给予奖励。  第八条 网络运营者发现或者获知其网络、信息系统及其设备存在安全漏洞后,应当立即采取措施,及时对安全漏洞进行验证并完成修补。  第九条 从事网络产品安全漏洞发现、收集的组织或者个人通过网络平台、媒体、会议、竞赛等方式向社会发布网络产品安全漏洞信息的,应当遵循必要、真实、客观以及有利于防范网络安全风险的原则,并遵守以下规定:  (一)不得在网络产品提供者提供网络产品安全漏洞修补措施之前发布漏洞信息;认为有必要提前发布的,应当与相关网络产品提供者共同评估协商,并向工业和信息化部、公安部报告,由工业和信息化部、公安部组织评估后进行发布。  (二)不得发布网络运营者在用的网络、信息系统及其设备存在安全漏洞的细节情况。  (三)不得刻意夸大网络产品安全漏洞的危害和风险,不得利用网络产品安全漏洞信息实施恶意炒作或者进行诈骗、敲诈勒索等违法犯罪活动。  (四)不得发布或者提供专门用于利用网络产品安全漏洞从事危害网络安全活动的程序和工具。  (五)在发布网络产品安全漏洞时,应当同步发布修补或者防范措施。  (六)在国家举办重大活动期间,未经公安部同意,不得擅自发布网络产品安全漏洞信息。  (七)不得将未公开的网络产品安全漏洞信息向网络产品提供者之外的境外组织或者个人提供。  (八)法律法规的其他相关规定。  第十条 任何组织或者个人设立的网络产品安全漏洞收集平台,应当向工业和信息化部备案。工业和信息化部及时向公安部、国家互联网信息办公室通报相关漏洞收集平台,并对通过备案的漏洞收集平台予以公布。  鼓励发现网络产品安全漏洞的组织或者个人向工业和信息化部网络安全威胁和漏洞信息共享平台、国家网络与信息安全信息通报中心漏洞平台、国家计算机网络应急技术处理协调中心漏洞平台、中国信息安全测评中心漏洞库报送网络产品安全漏洞信息。  第十一条 从事网络产品安全漏洞发现、收集的组织应当加强内部管理,采取措施防范网络产品安全漏洞信息泄露和违规发布。  第十二条 网络产品提供者未按本规定采取网络产品安全漏洞补救或者报告措施的,由工业和信息化部、公安部依据各自职责依法处理;构成《中华人民共和国网络安全法》第六十条规定情形的,依照该规定予以处罚。  第十三条 网络运营者未按本规定采取网络产品安全漏洞修补或者防范措施的,由有关主管部门依法处理;构成《中华人民共和国网络安全法》第五十九条规定情形的,依照该规定予以处罚。  第十四条 违反本规定收集、发布网络产品安全漏洞信息的,由工业和信息化部、公安部依据各自职责依法处理;构成《中华人民共和国网络安全法》第六十二条规定情形的,依照该规定予以处罚。  第十五条 利用网络产品安全漏洞从事危害网络安全活动,或者为他人利用网络产品安全漏洞从事危害网络安全的活动提供技术支持的,由公安机关依法处理;构成《中华人民共和国网络安全法》第六十三条规定情形的,依照该规定予以处罚;构成犯罪的,依法追究刑事责任。  第十六条 本规定自2021年9月1日起施行。精彩推荐黑白之道周边商城,各种精美衣服帽子鼠标垫,猛戳↓↓↓滴滴出行APP遭下架!网传疑似因着急上市,中国公路信息和用户信息遭泄露史上最高勒索费:4.52亿人民币!(附IoC)多一个点在看多一条小鱼干 本文始发于微信公众号(黑白之道):工业和信息化部 国家互联网信息办公室 公安部关于印发网络产品安全漏洞管理规定的通知
阅读全文
一图+六问 | 读懂三部门《网络产品安全漏洞管理规定》 云安全

一图+六问 | 读懂三部门《网络产品安全漏洞管理规定》

扫码订阅《中国信息安全》杂志权威刊物 重要平台 关键渠道邮发代号 2-786《网络产品安全漏洞管理规定》解读 一、《网络产品安全漏洞管理规定》(以下简称《规定》)出台的目的和意义是什么?根据《网络安全法》关于漏洞管理有关要求,工业和信息化部、国家互联网信息办公室、公安部联合制定《规定》,主要目的是维护国家网络安全,保护网络产品和重要网络系统的安全稳定运行;规范漏洞发现、报告、修补和发布等行为,明确网络产品提供者、网络运营者、以及从事漏洞发现、收集、发布等活动的组织或个人等各类主体的责任和义务;鼓励各类主体发挥各自技术和机制优势开展漏洞发现、收集、发布等相关工作。《规定》的出台将推动网络产品安全漏洞管理工作的制度化、规范化、法治化,提高相关主体漏洞管理水平,引导建设规范有序、充满活力的漏洞收集和发布渠道,防范网络安全重大风险,保障国家网络安全。二、《规定》制定过程是什么样的?2019年,工业和信息化部会同有关部门成立了专项起草组,深入开展调研、座谈、论证工作,研究分析国内外漏洞管理现状,梳理各方面漏洞管理需求,听取网络安全领域专家学者意见建议,形成《规定》征求意见稿。之后,多次面向网络产品提供者、网络运营者、网络安全企业、专业机构征求意见,并于2019年6月向社会公开征求意见,组织相关部门和企事业单位集中讨论,充分采纳各方建议,形成《规定》送审稿,经工业和信息化部和相关部门审议通过后出台。三、《规定》中网络产品提供者,网络运营者,从事漏洞发现、收集、披露等活动的组织或个人有哪些方面责任和义务?网络产品提供者和网络运营者是自身产品和系统漏洞的责任主体,要建立畅通的漏洞信息接收渠道,及时对漏洞进行验证并完成漏洞修补。同时,《规定》还对网络产品提供者提出了漏洞报送的具体时限要求,以及对产品用户提供技术支持的义务。对于从事漏洞发现、收集、发布等活动的组织和个人,《规定》明确了其经评估协商后可提前披露产品漏洞、不得发布网络运营者漏洞细节、同步发布修补防范措施、不得将未公开漏洞提供给产品提供者之外的境外组织或者个人等八项具体要求。四、《规定》中将及时修补网络产品安全漏洞作为网络产品提供者应当履行的安全义务,其主要考虑是什么?网络产品漏洞信息可通过网络平台、媒体、会议等方式在社会上快速传播,危害大量网络用户权益,有必要采取措施防止风险扩大或者避免损害发生。《网络安全法》明确指出,网络产品提供者发现其网络产品存在安全缺陷、漏洞等风险时,应当立即采取补救措施,按照规定及时告知用户并向有关主管部门报告。因此,《规定》要求网络产品提供者于2日内向工业和信息化部报送漏洞信息,并及时进行修补,将修补方式告知可能受影响的产品用户。五、《规定》对漏洞收集平台的管理要求是什么?近年来,不少专业机构、企业和社会组织等建立了从事漏洞发现和收集的漏洞收集平台,在实际工作中部分漏洞收集平台也暴露出内部运营不规范、擅自发布漏洞等问题,亟需加强管理。为此,《规定》明确对漏洞收集平台实行备案管理,由工业和信息化部对通过备案的漏洞收集平台予以公布,并要求漏洞收集平台采取措施防范漏洞信息泄露和违规发布。六、下一步如何推进相关工作?《规定》出台后,工业和信息化部将从政策宣贯、机制完善、平台建设多方面抓好落实。一是加强政策宣贯,做好对相关企业机构的政策咨询和工作指导,引导漏洞收集平台依法依规开展漏洞收集和发布。二是完善相关工作机制,建立健全漏洞评估、发布、通报等重要环节的工作机制,明确漏洞收集平台备案方式和报送内容。三是加强工业和信息化部网络安全威胁和漏洞信息共享平台建设,做好与其他漏洞平台、漏洞库的信息共享,提升平台技术支撑能力。一图读懂《网络产品安全漏洞管理规定》(来源:工信微报)扫码关注我们更多信息安全资讯请关注“中国信息安全” 本文始发于微信公众号(中国信息安全):一图+六问 | 读懂三部门《网络产品安全漏洞管理规定》
阅读全文
一图+六问,读懂三部门《网络产品安全漏洞管理规定》 云安全

一图+六问,读懂三部门《网络产品安全漏洞管理规定》

《网络产品安全漏洞管理规定》解读 一、《网络产品安全漏洞管理规定》(以下简称《规定》)出台的目的和意义是什么?根据《网络安全法》关于漏洞管理有关要求,工业和信息化部、国家互联网信息办公室、公安部联合制定《规定》,主要目的是维护国家网络安全,保护网络产品和重要网络系统的安全稳定运行;规范漏洞发现、报告、修补和发布等行为,明确网络产品提供者、网络运营者、以及从事漏洞发现、收集、发布等活动的组织或个人等各类主体的责任和义务;鼓励各类主体发挥各自技术和机制优势开展漏洞发现、收集、发布等相关工作。《规定》的出台将推动网络产品安全漏洞管理工作的制度化、规范化、法治化,提高相关主体漏洞管理水平,引导建设规范有序、充满活力的漏洞收集和发布渠道,防范网络安全重大风险,保障国家网络安全。二、《规定》制定过程是什么样的?2019年,工业和信息化部会同有关部门成立了专项起草组,深入开展调研、座谈、论证工作,研究分析国内外漏洞管理现状,梳理各方面漏洞管理需求,听取网络安全领域专家学者意见建议,形成《规定》征求意见稿。之后,多次面向网络产品提供者、网络运营者、网络安全企业、专业机构征求意见,并于2019年6月向社会公开征求意见,组织相关部门和企事业单位集中讨论,充分采纳各方建议,形成《规定》送审稿,经工业和信息化部和相关部门审议通过后出台。三、《规定》中网络产品提供者,网络运营者,从事漏洞发现、收集、披露等活动的组织或个人有哪些方面责任和义务?网络产品提供者和网络运营者是自身产品和系统漏洞的责任主体,要建立畅通的漏洞信息接收渠道,及时对漏洞进行验证并完成漏洞修补。同时,《规定》还对网络产品提供者提出了漏洞报送的具体时限要求,以及对产品用户提供技术支持的义务。对于从事漏洞发现、收集、发布等活动的组织和个人,《规定》明确了其经评估协商后可提前披露产品漏洞、不得发布网络运营者漏洞细节、同步发布修补防范措施、不得将未公开漏洞提供给产品提供者之外的境外组织或者个人等八项具体要求。四、《规定》中将及时修补网络产品安全漏洞作为网络产品提供者应当履行的安全义务,其主要考虑是什么?网络产品漏洞信息可通过网络平台、媒体、会议等方式在社会上快速传播,危害大量网络用户权益,有必要采取措施防止风险扩大或者避免损害发生。《网络安全法》明确指出,网络产品提供者发现其网络产品存在安全缺陷、漏洞等风险时,应当立即采取补救措施,按照规定及时告知用户并向有关主管部门报告。因此,《规定》要求网络产品提供者于2日内向工业和信息化部报送漏洞信息,并及时进行修补,将修补方式告知可能受影响的产品用户。五、《规定》对漏洞收集平台的管理要求是什么?近年来,不少专业机构、企业和社会组织等建立了从事漏洞发现和收集的漏洞收集平台,在实际工作中部分漏洞收集平台也暴露出内部运营不规范、擅自发布漏洞等问题,亟需加强管理。为此,《规定》明确对漏洞收集平台实行备案管理,由工业和信息化部对通过备案的漏洞收集平台予以公布,并要求漏洞收集平台采取措施防范漏洞信息泄露和违规发布。六、下一步如何推进相关工作?《规定》出台后,工业和信息化部将从政策宣贯、机制完善、平台建设多方面抓好落实。一是加强政策宣贯,做好对相关企业机构的政策咨询和工作指导,引导漏洞收集平台依法依规开展漏洞收集和发布。二是完善相关工作机制,建立健全漏洞评估、发布、通报等重要环节的工作机制,明确漏洞收集平台备案方式和报送内容。三是加强工业和信息化部网络安全威胁和漏洞信息共享平台建设,做好与其他漏洞平台、漏洞库的信息共享,提升平台技术支撑能力。一图读懂《网络产品安全漏洞管理规定》来源:工业和信息化部网络安全管理局 本文始发于微信公众号(网络安全和信息化):一图+六问,读懂三部门《网络产品安全漏洞管理规定》
阅读全文
【奇技淫巧】远程桌面反向感染管理/黑客个人电脑 安全闲碎

【奇技淫巧】远程桌面反向感染管理/黑客个人电脑

前置条件:1.mstsc需要开启驱动器C盘(win2008及以上只需剪切板即可文件传输)2.win2003 如果要复制文件必须开驱动器思路:遍历tsclient的自启动目录 -》 添加执行程序 -》个人机重启 -》 上线猥琐一些的思路:脚本找不到挂载磁盘的情况下直接结束rdpclip.exe 使管理员无法使用剪切板功能,他可能在修复时会挂载上磁盘@ptvip 老司机思路,传lpk.dll写bat脚本寻找所有挂载磁盘存在的exe文件,把每个目录都写一个lpk.dll更新关于dll劫持(lpk.dll只针对xp系统,高于xp的微软已经用KnownDLLs做了防范,需要发现其他的dll进行劫持)@Solo_LD  结合蜜罐,反向搞黑客 本文始发于微信公众号(T00ls):【奇技淫巧】远程桌面反向感染管理/黑客个人电脑
阅读全文
身份与访问管理基本概念汇总 安全闲碎

身份与访问管理基本概念汇总

身份与访问管理1:控制对资产的物理和逻辑访问身份与访问管理2:管理对人员、设备和服务的身份识别与验证身份与访问管理3:集成身份服务身份与访问管理4:实施和管理授权机制身份与访问管理4:理解访问控制攻击方式身份与访问管理5:管理标识和访问开通生命周期see also:通信与网络安全基本概念汇总 本文始发于微信公众号(网络安全等保测评):身份与访问管理基本概念汇总
阅读全文