分类: 今日推送

Google 的 Tink 库让你丢掉手中成百上千页的密码学书籍

近日,谷歌在其安全博客中详细介绍了其开源的一款多语言、跨平台加密开发库Tink。一直以来,加密技术就是保护用户数据的有效手段,但是加密技术涉及到了非常艰深的密码学知识,开发者如果想要理解如何正确去实施密码学,这个过程将会花费他们大量时间去研究目前积累了数十年的学术文献。在当下高强度的开发工作下,显而易见,通常开发者都难有这样富足的时间。这样就给产品的安全带来了致命威胁,怎么办呢? Google 为此开发了一款多语言、跨平台的加密软件库,用以帮助内部开发人员提供安全的加密代码。谷歌介绍,在内部,Tink 已经被用于保护许多产品的数据,如 AdMob、Google Pay、Google Assistant、Firebase 与 Android Search App 等。Google 在两年前将 Tink 于 GitHub 上开源,此次借着其第一个支持云、Android 与 iOS 的 1.2.0 版本发布,谷歌为开发者介绍了它的特性、意义与使用示例等内容。 谷歌描述,Tink 旨在提供安全、易于正确使用且难以滥用的加密 API,它建立在现有安全相关的库之上,如 BoringSSL 和 Java Cryptography Architecture,但谷歌专门的团队 Project Wycheproof 发现了这些库中的一些弱点,Tink 进行了跟进,使之更加安全。 使用 Tink,许多常见的加密操作,如数据加密、数字签名等只需几行代码就可以完成,以下是使用 Java 中的 AEAD 接口加密和解密的 demo: import com.google.crypto.tink.Aead;    import com.google.crypto.tink.KeysetHandle;    import com.google.crypto.tink.aead.AeadFactory;    import com.google.crypto.tink.aead.AeadKeyTemplates;    // 1. Generate the key material.    KeysetHandle keysetHandle = KeysetHandle.generateNew(        AeadKeyTemplates.AES256_EAX);    // 2. Get the primitive.    Aead aead = AeadFactory.getPrimitive(keysetHandle);    // 3. Use the primitive.    byte[] plaintext = ...;    byte[] additionalData = ...;    byte[] ciphertext = aead.encrypt(plaintext, additionalData); Tink 希望消除尽可能多的潜在误用。例如,如果底层加密模式需要 nonce(密码学中只被使用一次的任意或非重复的随机数),但重用 nonce 的话会产生安全问题,那么这时 Tink 将不允许用户传递 nonce。 Tink 的功能很多,大概有如下几个方面: 可以安全抵御选择密文攻击,允许安全审计员和自动化工具快速发现那些与安全要求不匹配的代码。 隔离了用于潜在危险操作的 API,例如从磁盘加载明文密钥。 为密钥管理提供支持,包括密钥轮换和逐步淘汰已弃用的密码。 可以通过设计进行扩展:可以轻松添加自定义加密方案或内部密钥管理系统,以便与 Tink 的其它部分无缝协作。Tink 的任何部分都难以更换或移除,所有组件都是可组合的,并且可以以各种组合进行选择和组合。例如,如果只需要数字签名,则可以排除对称密钥加密组件,以最大限度地减少应用程序中的代码大小。 这个开发库为广大开发者带来了极大便利,如果你还没体验过,赶快去试试吧: https://github.com/google/tink       稿源:开源中国,封面源自网络;

Cookie 机制问题多 Chrome 工程师提出改造方案

日前 Chrome 工程师 Mike West 发表了一篇文章提议改造 Cookie 标准,以强化 HTTP 状态管理。Mike 分析了目前 Cookie 存在的几个方面的问题,包括很难安全使用、浪费用户资源,以及隐私问题,通过它可以以令人惊讶的方式跟踪用户在网络上的活动。   关于浪费用户资源,Mike 解释,服务器可以为一个注册域名存储大量 Cookie,并且很多 Cookie 可以通过 HTTP 请求发送。例如 Chrome 允许为每一个域名存储大约 180 个 Cookie,相当于约 724kB 数据。在众多 Cookie 中,其请求头大小的中位数是 409 字节,但是其中却有 90% 有 1589 字节,95% 占了 2549 字节,99% 甚至达到了 4601 字节,另外有约 0.1% 的 Cookie 头非常大,超过了 10kB。如此滥用,效率低下。 隐私方面,众所周知 Cookie 可以用于身份验证,但它同时也可以用来悄悄跟踪用户的相关信息。 而关于安全使用的难处,Mike 列出了几条在开发中安全使用 Cookie 遇到的问题: Cookie 对 JavaScript 默认是可用的,这使得一次 XSS 可以获取持久凭证。虽然十年前引入了 HttpOnly 属性,目前也只有大概 8.31% 的人使用 Set-Cookie 进行相应设置。 默认情况下,Cookie 会被发送到非安全的源,这会导致凭据被盗。Secure 属性虽然可以标记安全的 Cookie 源,但目前只有大概 7.85% 的人使用 Set-Cookie 进行了设置。 Cookie 经常在请求发送者毫不知情的情况下被发送。SameSite 属性可以减少 CSRF 风险,但是目前只有大概 0.06% 的人使用 Set-Cookie 进行了设置。 Mike 认为,一方面 Cookie 采用的缓解安全问题的属性很差,Cookie 根本不符合我们决定对其它类型的 Web 可访问数据强制执行的安全边界。它们在给定的可注册域中流过源,它们忽略端口和方案,这意味着它们可以被网络攻击者轻易伪造,并且它们可以缩小到特定路径,这些特征使得它们难以推理,并制定激励措施来削弱平台其它部分的同源策略。 Mike 给出了一套新方案,他解释,用户代理可以通过为用户访问的每个安全源生成唯一的 256 位值来控制它代表用户表示的 HTTP 状态,此 Token 可以作为结构化 HTTP 请求头传递到源: Sec-HTTP-State:token = * J6BRKagRIECKdpbDLxtlNzmjKo8MXTjyMomIwMFMonM * 此标识符或多或少类似于客户端控制的 Cookie,但有一些值得注意的区别: 客户端控制 Token 的值,而不是服务器。 Token 只能用于网络层,而不能用于 JavaScript(包括类似网络的 JavaScript、例如 Service Workers)。 用户代理每个源只生成一个 256 位 Token,并且只将 Token 暴露给生成它的源。 不会为非安全源生成或传递 Token。 默认情况下,Token 将与同一站点请求一起提供。 Token 一直存在,直到服务器、用户或用户代理重置为止。 在些基础上,将为开发人员提供一些可通过 Sec-HTTP-State-Options HTTP 响应头触发的控制点,有如下选项: 1、某些服务器需要跨站点访问其 Token,其它服务器可能希望将交付范围缩小到同源请求,服务器可以指定任一选项: Sec-HTTP-State-Options: ..., delivery=cross-site, ... 或者: Sec-HTTP-State-Options: ..., delivery=same-origin, ... 2、某些服务器希望限制 Token 的生命周期,可以允许它们设置 TTL(以秒为单位): Sec-HTTP-State-Options: ..., ttl=3600, ... 时间到期后,Token 的值将自动重置。同时服务器也可能希望明确触发 Token 的重置行为(例如,在注销时),这可以通过设置 TTL 为 0 来实现: Sec-HTTP-State-Options: ..., ttl=0, ... 在任何一种情况下,都可以向当前运行的页面通知用户的状态变化,以便执行清理操作。当发生重置时,用户代理可以将消息发送到名为 http-state-reset 的源的 BroadcastChannel(并且可能唤醒源的 Service Worker 以响应用户驱动的重置): let resetChannel = new BroadcastChannel('http-state-reset'));resetChannel.onmessage = e => { /* Do exciting cleanup here. */ }; 3、对于某些服务器,客户端生成的 Token 足以维持状态,它们可以将其视为不透明的会话标识符,并将用户的状态绑定到服务器端。其它服务器需要额外的保证,他们可以信任 Token 的出处,为此,服务器可以生成唯一密钥,将其与服务器上的会话标识符相关联,并通过 HTTP 响应头将其传递给客户端: Sec-HTTP-State-Options: ..., key=*ZH0GxtBMWA...nJudhZ8dtz*, ... 客户端将存储该密钥,并使用它来生成某些数据集的签名,从而降低 Token 被捕获的风险: Sec-HTTP-State: token=*J6BRKa...MonM*, sig=*(HMAC-SHA265(key, token+metadata))* Mike 同时也表示,该方案并不是一个完全与 Cookie 不同的新东西,并不是要在目前替换掉 Cookie,虽然弃用 Cookie 是应该的,但是当下该方案只是提出了一种在 Cookie 同时存在的情况下也能发挥作用的补充机制。     稿源:开源中国,封面源自网络;

Mozilla:云端 DOH 比传统 DNS 更安全 性能差别不大

Mozilla 今年 3 月时,在 Firefox Nightly 版本进行了 DOH(DNS Over HTTPS)与传统 DNS 的比较实验,探讨后者是否能被前者取代,结果显示虽然 DOH 服务平均比传统 DNS 慢6毫秒,但是相比之下,DOH 不止服务更安全,而且在极端情况下,甚至能比传统 DNS 的回应还快几百毫秒。 现在的浏览器用户依赖不够安全的传统 DNS 协议来访问目标网站,可能面临被追踪(Tracking)或是欺骗(Spoofing)等风险。Mozilla 引用了 2018 年 Usenix 安全研讨会的论文,研究显示 DNS 服务现在正受到严重的干扰,而且面临各种资料收集的隐私威胁。Firefox 开发了 DOH 技术,让浏览器从一个或多个可信任的服务中获取 DNS 信息,以提供高安全与高隐私的 DNS 服务。 由于以可信任的 DOH 云端服务取代传统 DNS 是一个剧烈的改变,在选择 DOH 服务器时需要考虑很多因素,因此 Mozilla 对此展开了测试,主要想了解两个问题,第一个,使用 DOH 是否能取代传统 DNS?第二个,使用 DOH 是否会出现额外的连接错误?在 7 月的时候有约 25000 名 Firefox Nightly 63 使用者参与了 Cloudflare 与 Mozilla 共同举行的测试,测试总共收集到了超过十亿条的 DOH 数据,目前测试已结束。 结果显示,与传统 DNS 相比,和云端服务供应商合作使用 HTTPS 发出 DNS 请求,在无缓存的 DNS 查询上,性能影响很小,大多数的查询只慢了约 6 毫秒,但从权衡安全性和保护隐私数据的角度出发,这是可以被接受的成本。而且在某些情况下,甚至能比传统 DNS 还快几百毫秒。 另外,这个测试除了解性能方面的影响,还考虑了连接错误率,在软故障(Soft-fail)模式下使用 DOH 云端服务的用户,和传统 DNS 用户相比,错误连接率并没有明显差异。软故障模式主要使用 DOH,当域名无法正确解析或是 DOH 提供的地址连接失败时,便退回使用传统 DNS。 Mozilla 提到,他们正努力于创造一个可信任的 DOH 供应商生态,以满足较高标准的数据处理需求,后续会在一组供应商中或是依照地理位置划分 DNS 传输,这项试验可能会在不久之后进行。     稿源:开源中国,封面源自网络;

PHP 现反序列化漏洞,或使 WordPress 遭远程攻击

英国安全公司 Secarma 的研究主管 Sam Thomas 本月在 Black Hat 和 BSides 安全会议上展示了 PHP 编程语言的安全漏洞,并指出该漏洞影响了所有接受用户资料的 PHP 应用程序和库,包括 WordPress 等内容管理系统(CMS),并将允许远程程序攻击。 序列化(Serialization)与反序列化(Deserialization)是所有编程语言都具备的功能,序列化将对象转换为字符串,以将数据迁移到不同服务器,服务或应用程序上,然后通过反序列将字符串还原到对象。 安全研究员 Stefan Essar 在 2009 年就透露了 PHP 中反序列化黑客控制的数据带来的风险,而相关的漏洞不仅存在于 PHP 中,还存在于其他编程语言中。 Thomas 公布的是 PHP 的新攻击技术,可用于各种场景,例如 XML External Entity(XEE)漏洞或服务器端伪造请求(SSFR)漏洞等。 Thomas 表示,过去外界认为 XXE 漏洞带来的最大问题是信息外泄,但现在可出发程序执行。相关攻击分为两个阶段。 首先,将包含恶意对象的 Phar 存档上传到攻击目标的本地文件系统,然后触发一个基于 phar:// 的文件操作,就可能导致恶意程序执行。 Thomas 已利用 PHP 的反序列化程序成功攻击了 WordPress 与 Typo3 内容管理平台,以及 Contao 所采用的 TCPDF 库。   稿源:开源中国社区,封面源自网络;

连年上涨,全球信息安全支出明年或超 1240 亿美元

(原标题:Global Information Security Spending To Exceed $124B In 2019, Privacy Concerns Driving Demand) 网易科技讯  8 月 20 日消息,据福布斯杂志报道,研究公司 Gartner 最新预测,2018 年的全球信息安全产品和服务支出将超过 1140 亿美元,比去年增长 12.4% 。该公司还预测,2019 年市场规模将增长 8.7% ,达到 1240 亿美元。相比之下,2017 年的支出为 1015.4 亿美元。 Gartner 研究总监悉达多·德什潘德(Siddharth Deshpande)表示:“安全公司正努力帮助自己的组织安全地使用技术平台,提高竞争力,推动业务增长。持续存在的技能短缺和欧盟《全球数据保护条例》(GDPR)等监管规则的变化,正在推动安全服务市场持续增长。” Gartner 在去年 9 月至 10 月间进行的调查显示,安全支出的三大驱动力分别是安全风险、业务需求以及行业变化。此外,调查发现,隐私问题也成为企业关注的“关键因素”。Gartner 认为,到 2019 年,隐私问题将“推动安全服务市场需求增长至少 10%” ,并影响到身份和访问管理(IAM)、身份治理和管理(IGA)以及数据丢失预防(DLP)等多个领域。 调查结果还显示,从 2017 年到 2022 年,信息安全市场的收入将以每年 7.8% 的复合增长率(CAGR)增长,以恒定汇率计算将达到 1430 亿美元。到 2019 年,在安全服务方面的支出将占全球整体安全支出的 51.75% 。德什潘德表示:“安全与风险管理必须成为任何数字业务计划的关键组成部分。”       稿源:网易科技,封面源自网络;

谷歌追踪位置记录做法 或将面临欧盟又一笔天价罚单

本周早些时候,美联社报道称,即使用户关闭位置记录,谷歌仍然会追踪用户位置。报道称,如果关闭这个设置,谷歌仍然会追踪用户的位置,只是不会在谷歌地图时间线上进行记录。如果用户希望完全关闭位置追踪,那么需要通过其他设置选项,即网页和应用活动。 而由于欧盟已经实施了严格的 GDPR 数据隐私法案,欧洲立法者对谷歌的做法不可能坐视不管。即使是在 GDPR 生效之前,谷歌对用户数据的收集使用做法一直遭到欧洲多项调查。最新曝光的在关闭位置记录后谷歌仍然会追踪用户位置的做法可能涉及误导用户,如果此做法在调查后确认违反了 GDPR 法规,欧盟立法者可对谷歌处以营业额 2%-4% 的出发,谷歌去年的营业额为 1096.5 亿美元,如果按照这一数额估算,谷歌或将面临 45 亿美元的天价罚单。当然谷歌 并不同意自己存在误导用户的行为,在一起声明中谷歌表示谷歌明确告知“位置记录”用户,当他们在关闭位置记录后,我们仍然可能使用位置信息来增强谷歌产品的体验,例如谷歌搜索或者导航。     稿源:cnBeta.COM,封面源自网络;

McAfee 发现 Windows 10 Cortana 漏洞 可操控锁屏后的系统

McAfee 刚刚宣布,他们在 Windows 10 中的 Cortana 数字助理身上发现了一个新的漏洞,且其竟然可以获得锁定后的系统的物理访问权限。万幸的是,这两个新漏洞已经作为微软 8 月 Windows 10 更新的一部分而得到了解决,因为 McAfee 实验室的高级威胁研究团队在第一时间向微软通报了此事。 该公司称,使用 Cortana 锁定的 Windows 10 设备,可能允许具有物理访问权限的攻击者,在未修补的系统上机型两种未经授权的浏览: ● 攻击者可以强制 Microsoft Edge 导航至被攻击者控制的 URL; ● 攻击者可以使用受保护的受害者凭据,使用首先版本的 IE 11 浏览器。 两位研究人员(Cedric Cochin 和 Steve Povolny)在博客文章中解释道: 第一种情况下,Cortana 权限提升会导致锁屏上的强制导航。该漏洞不允许攻击者解锁设备,但它却是允许具有物理访问权限的人,强制 Edge 在设备仍处于锁定状态时,导航到攻击者指定的页面。 这与 BadUSB bug、中间人或流氓 Wi-Fi 等攻击方式不同,只是简单的语音命令、以及与设备的触屏或鼠标交互。 McAfee 还披露了在最新的 Patch Tuesday(每月第二个周二)更新中解决的其它发现: ● McAfee 研究人员发现,在处于锁定状态时,Cortana 可能被迫打开受攻击控制的页面。恶意人员可以利用它来操纵危机百科页面(Cortana 经常在锁定模式下作为‘可信站点’来引用),以包含恶意链接和信息。 ● 研究人员还发现,攻击者可以通过 Internet Explorer 引擎(而不是整个 IE 浏览器)来访问和导航,即便 JavaScript 和 Cookie 都一起用。利用此方法,当设备仍处于锁定状态时,攻击者可以通过其它用户的设备,在公共论坛上发表评论、或者利用已缓存的凭据而冒充他人。       稿源:cnBeta.COM,编译自:Windows Latest,封面源自网络;

英特尔 Foreshadow 芯片漏洞曝光 或被窃取安全锁定区的敏感数据

近日,安全研究人员发现了影响英特尔处理器的 “Foreshadow” (预兆)新漏洞,其能够绕过该公司内置的芯片安全特性,使得攻击者可能获得存储在处理器“安全封锁区域”的敏感数据。外媒 Wired 指出,Foreshadow 会攻击英特尔处理器上一项名叫“安全警卫扩展”(Secure Guard Extensions)的功能,后者亦被简称为 SGX 。 SGX 旨在帮助保护处理器中保存的用户数据,即便整个计算机都已被攻击者所控制。但实际上,SGX 是在芯片上创建了一个用于保存敏感的数据的安全内存区域,这部分内容无法被恶意代码直接读取。 虽然 SFX 之前被认为能够抵御投机性执行攻击,例如今年早些时候曝光的‘熔毁’(Meltdown)和‘幽灵’(Spectre)漏洞。 但 Foreshadow 漏洞不仅利用了类似的技术,还可以访问受 SGX 保护的 L1 缓存、甚至提取目标的私有证明密钥 —— 这也是用于 SGX 完整性检查的加密密钥。 鉴于 SGX 内置隐私保护,外界很难知晓由谁签署了“飞地”。而知晓了“证明密钥”,就可以允许创建“看似真实”的 SGX 签名 —— 但事实并非如此。 由于证明密钥被泄露,意味着同一生态系统中的多台计算机‘可能同时受到攻击’,而不仅限于一台。 推测性执行攻击,依赖于处理器猜测将要执行的操作,并为之做好准备。 这么做的原意是为了节省资源,但同时,其产生的信息可能对攻击者插入自有指令起到了实质性作用,从而获得对系统的控制。 此外,研究人员发现了两个被叫做“Foreshadow-NG”的类似变体。它们也会攻击 SMM 代码、操作系统、管理程序软件、以及其它微处理器。 研究人员称,这可能会影响云服务上的虚拟机,包括使用恶意访客 VM 读取虚拟机管理程序的内存、甚至是属于另一台虚拟机的内存。 最早发现这一漏洞的,是来自 KU Leuven 的研究人员。其对 Meltdown 和 Spectre 展开了独立研究,并于 2018 年 1 月 3 日向英特尔通报。 来自 Technion、密歇根大学、阿德莱德大学、思科旗下 Data61 等机构的其他研究人员,也分别发现了这些问题,并于 1 月 23 号向英特尔警示了此事。 研究人员建议,所有 Skylake 和 Kaby Lake 处理器都会受到 Foreshadow 攻击的影响,因为它们都是用了 SGX 。 攻击发生后,只会在日志中留下些微的痕迹,而且它也可以在‘用户空间’中启动。换言之,攻击者无需深层系统访问,即可执行攻击。 好消息是,由于执行攻击的前提是针对支持 SGX 的处理器,大多数桌面用户不大可能受到 Foreshadow 的影响。 与新发现相比,其它攻击途径(包括分发恶意软件和网络钓鱼企图)反而更有可能受到攻击者的青睐。 英特尔已经通过软件修复和微码更新,提供了缓解 Foreshadow 攻击的措施。 该公司称之为‘L1 终端缺陷’(L1 Terminal Fault),并且从 5 月份开始,就已经携手各大科技企业来发布相关补丁了。   稿源:cnBeta.COM,编译自:Apple Insider,封面源自网络;

最新研究发现智能空调可能会拖垮电网

据外媒报道,你可能不会经常想起家里的空调,或许只有当你在炎热夏天到来的时候才会想到它。然而黑客们却可能时刻惦记着它,因为他们利用它来摧毁电网。据了解,来自普林斯顿大学的安全研究人员发现,由数千台联网但却可攻击的家电如空调、热水器能够形成一个僵尸网络,而这可能会导致电网供电量严重不足进而导致大面积停电的现象发生。 普林斯顿大学的研究小组在巴尔的摩举行的 Usenix 安全大会上展示了这一研究成果。 他们在研究报告中写道:“我们希望我们的工作能够提高人们对这些攻击对电网运营商、智能设备制造商以及系统安全专家的重要性的认识,进而使电网(以及其他相互依赖的网络)在对抗网络攻击上变得更加安全。在不久的将来,当更多联网智能设备被制造出来之后,这一点将尤为关键。” 这一发现颠覆了人们对黑客和电网的传统担忧。通常情况下,研究人员担心专业黑客会直接侵入关键的基础设施如电网,然后切断电源、制造混乱。 如果这样的攻击成功了,那么黑客们可能会发现在发电站职工恢复电力供应时摧毁电网这件事情变得更加容易。 很显然,大规模的停电可能会极其危险,因为像执法部门、医院等重要机构都将同时遭到断电的情况。 去年曾经有专家发出了网络攻击导致的停电可能会成为未来网络战模样的警告。 研究人员在报告中写道:“不安全的物联网设备可能会带来毁灭性后果,它将远远超过个人安全/隐私的损失。这就需要严格控制物联网设备的安全性,包括监管框架。”     稿源:cnBeta.COM,封面源自网络;

工信部组织开展电信和互联网行业网络安全检查

新浪科技讯 8 月 13 日下午消息,工信部印发关于开展 2018 年电信和互联网行业网络安全检查工作的通知,以强化电信和互联网行业网络安全风险防范和责任落实,提升行业网络安全保障水平。 检查对象为依法获得电信主管部门许可的基础电信企业、互联网企业、域名注册管理和服务机构建设与运营的网络和系统。重点是电信和互联网行业网络基础设施、用户信息和网络数据收集、集中存储与处理的系统、企业门户网站和计费系统、域名系统、电子邮件系统、移动应用商店、移动应用程序及后台系统、公共云服务平台、公众无线局域网、公众视频监控摄像头等重点物联网平台、网约车信息服务平台、车联网信息服务平台等。 重点检查网络运行单位落实《中华人民共和国网络安全法》《通信网络安全防护管理办法》《电信和互联网用户个人信息保护规定》等法律法规情况,电信和互联网安全防护体系系列标准符合情况,可能存在的弱口令、中高危漏洞和其他网络安全风险隐患等。 以下为通知原文:        工业和信息化部办公厅关于开展2018年电信和互联网行业网络安全检查工作的通知 工信厅网安函〔2018〕261号 各省、自治区、直辖市通信管理局,中国电信集团有限公司、中国移动通信集团有限公司、中国联合网络通信集团有限公司、中国广播电视网络有限公司,互联网域名注册管理和服务机构,互联网企业,有关单位: 为深入贯彻习近平总书记在全国网络安全和信息化工作会议上的重要讲话精神,落实关键信息基础设施防护责任,提高电信和互联网行业网络安全防护水平,根据《中华人民共和国网络安全法》、《通信网络安全防护管理办法》(工业和信息化部令第 11 号)、《电信和互联网用户个人信息保护规定》(工业和信息化部令第 24 号),决定组织开展 2018 年电信和互联网行业网络安全检查工作。现将有关要求通知如下: 一、总体要求 紧紧围绕加快推进网络强国建设战略目标,深入学习领会习近平总书记关于网络安全的系列重要讲话精神,加快落实《中华人民共和国网络安全法》,坚持以查促建、以查促管、以查促防、以查促改,以防攻击、防病毒、防入侵、防篡改、防泄密为重点,加强网络安全检查,认清风险现状,排查漏洞隐患,通报检查结果,督促整改问题,强化电信和互联网行业网络安全风险防范和责任落实,全面提升行业网络安全保障水平,保障公共互联网安全、稳定运行。 二、检查重点 (一)重点检查对象。检查对象为依法获得电信主管部门许可的基础电信企业、互联网企业、域名注册管理和服务机构(以下统称网络运行单位)建设与运营的网络和系统。重点是电信和互联网行业网络基础设施、用户信息和网络数据收集、集中存储与处理的系统、企业门户网站和计费系统、域名系统、电子邮件系统、移动应用商店、移动应用程序及后台系统、公共云服务平台、公众无线局域网、公众视频监控摄像头等重点物联网平台、网约车信息服务平台、车联网信息服务平台等。 (二)重点检查内容。重点检查网络运行单位落实《中华人民共和国网络安全法》《通信网络安全防护管理办法》《电信和互联网用户个人信息保护规定》等法律法规情况,电信和互联网安全防护体系系列标准符合情况,可能存在的弱口令、中高危漏洞和其他网络安全风险隐患等(法律法规和标准依据详见附件)。 三、工作安排 (一)定级备案。各网络运行单位要按照《通信网络安全防护管理办法》的规定,在工业和信息化部“通信网络安全防护管理系统”(https://www.mii-aqfh.cn)对本单位所有正式上线运行的网络和系统进行定级备案或变更备案。 (二)自查整改。各网络运行单位要对照法律法规和本次检查重点,对本单位网络安全工作进行自查自纠,对自查发现的安全问题逐一做好记录,能立即整改的,要边查边改,无法立即整改的,要采取防范措施,制定整改计划,确保整改落实。2018 年 9 月 31 日前,基础电信企业集团公司、域名注册管理和服务机构应将本单位自查工作总结报告报部(网络安全管理局),基础电信企业省级公司和互联网公司形成自查工作总结报告报当地通信管理局。 (三)开展抽查。电信主管部门选取部分网络和系统,委托专业技术机构采取现场询问、查阅资料、现场检测、远程渗透、代码检测等方式进行检查。对省级基础电信企业和专业公司网络和系统的检查分别按照《 2018 年省级基础电信企业网络与信息安全工作考核要点与评分标准》《2018 年基础电信企业专业公司网络与信息安全工作考核要点与评分标准》进行量化评分,评分结果分别作为 2018 年省级基础电信企业和专业公司网络与信息安全责任考核依据。各地通信管理局除抽查省级基础电信企业外,至少抽查当地十家以上增值电信企业,将检查工作总结报告于 10 月 31 日前报部(网络安全管理局)。 四、工作要求 (一)加强领导,落实责任。各地电信主管部门、网络运行单位应严格落实工作责任制,精心组织制定工作方案,落实机构、队伍和工作经费,确保检查工作不走过场,确保检查发现的问题得到及时有效整改。发现问题的单位要举一反三,健全网络安全问题闭环管理机制,加强定期巡查、整改核验、考核问责,以检查为契机,不断完善电信和互联网行业网络安全保障体系。 (二)规范检查,严明纪律。各单位要规范检查方法和程序,避免检查工作影响网络和系统的正常运行,检查工作中发现重大问题应及时报我部。采用随机抽取检查对象、随机选派检查队伍的“双随机”方式安排实施检查。任何部门不得向被检查单位收取费用,不得要求被检查单位购买、使用指定的产品和服务。委托专业技术机构进行安全检查,要进行严格审查,签订保密承诺书,并明确专业技术机构及人员的安全责任。要严格遵守有关保密规定,检查结果除按规定报送外,不得提供给其他单位和个人。 (三)加强防范,及时整改。专业检测机构对检查发现的薄弱环节、安全漏洞和安全风险,要现场告知网络运行单位,并指导其防范整改。抽查发现的重大网络安全风险和隐患,电信主管部门可通过《网络安全问题整改通知书》等形式书面向网络运行单位通报,督促其限期整改。网络运行单位要对检查发现的薄弱环节和安全风险进行深入整改,对相关责任部门和责任人进行问责处理,并及时向电信主管部门报告问题整改和问责情况。 (四)强化协同,协调配合。各地通信管理局要强化与网信、公安等部门的协调沟通,按照网络安全工作责任制和中央网信办《关于加强和规范网络安全检查工作的通知》(中网办发文〔2015〕7号)要求,坚持跨部门、跨行业的网络安全检查应由当地网信部门统筹协调,其他部门对电信和互联网行业的网络安全检查应当会同电信主管部门进行,加强协同沟通,提倡开展联合检查,避免交叉重复,基础电信企业向非电信主管部门提供网络安全相关资料和数据的,应征得当地通信管理局同意,或由通信管理局统一协调提供。 特此通知。 工业和信息化部办公厅 2018 年 8 月 6 日         稿源:新浪科技,封面来源于网络;