Github是目前相对最大的、使用人数最多的“男性交友平台”,呸!说错了,是“代码托管交流平台”,上面充斥着各种各样的代码和信息,可谓“宝藏平台”。对于渗透测试人员来说,Github最大的价值是在于渗透测试时利用其进行信息搜集工作,比如查找目标系统的源码、数据库地址、用户名口令等等敏感信息。但是对于工作在甲方或者说担任安全工作的各工程师、负责人来说,这无疑是最痛苦的和需要投入大量人力、物力的地方。

很多介绍企业安全建设或者安全架构体系之类的文章和书籍都会讲到关于Github监控的事情,越来越多的安全人员开始去关注Github上面是否有自己单位业务的相关代码和信息被泄露,监控和巡检形式多种多样,如人工登录按照关键字筛查,也可以利用开源工具进行自动化监控巡检,如VIPKID的Github Monitor以及Hell0W0rld0的Github-Hunter等等。但是难点和痛点其实不是前面说的这些工作,而是发现泄露后的排查分析和人员定位,如果泄露的内容中有上传者的相关信息那还好办,能够联系上,让其删掉。但是对于任何上传者信息都找不到的情况怎么办呢?

这时候我们就要另辟蹊径了,如果花费了很多时间后仍然找不到上传者本人信息,无法联系进行删除,那么就需要联系Github官方进行申诉了,让Github官方进行核实和删除,避免信息被大范围的泄露。

01

首先,Github官方提供了一些列删除政策的说明。这里我介绍下我常用的两种DMCA删除政策和敏感数据删除政策。链接如下:

https://docs.github.com/cn/github/site-policy/dmca-takedown-policy

https://docs.github.com/cn/github/site-policy/github-sensitive-data-removal-policy

什么是DMCA

DMCA 为托管用户生成内容的服务提供商提供了安全港。 仅仅一项侵犯版权的索赔就可能导致高达 150,000 美元的法定赔偿,因此,对用户生成的内容承担责任可能对服务提供商非常不利。 如果面向数以百万计的用户,这种潜在损失将不可估量,可以说,假如没有 DMCA,则 YouTube、Facebook 或 GitHub 等云计算和用户生成内容的网站可能就不会存在或者至少会将部分成本转嫁给用户)。

DMCA 通过为托管涉嫌侵权用户生成内容的互联网服务提供商建立版权责任安全港,解决了这一问题。 从本质上讲,只要服务提供商遵守 DMCA 的通知和删除规则,就不会对基于用户生成内容的侵权行为承担责任。 因此,对 GitHub 而言,保持其 DMCA 安全港状态非常重要。

什么是敏感数据?

就本文档而言,“敏感数据”是指符合以下条件的内容:应该保密,并且一旦公开,会对您或您的组织造成特定安全风险。

敏感数据删除请求适用于:

  • 可访问您组织的服务器、网络或域的访问凭据,例如用户名与密码组合、访问令牌或其他敏感密钥。
  • 可代表您访问第三方的 AWS 令牌和其他类似访问凭据。 您必须能够证明该令牌确实属于您。
  • 对组织构成特定安全风险的文档(例如网络图)。 内部服务器名称、IP 地址和 URL 本身不够敏感;您必须能够证明内部服务器名称在特定文件或代码段中的使用构成了安全威胁。

两者的区别是:DMCA删除政策偏向于涉嫌版权侵权的申诉,只接受针对受版权保护的作品并且标识出具体版权,涉及面可能是整个仓库,而敏感数据删除政策偏向于一些应该保密但是被公开且易造成安全风险的信息,比如用户名和密码、网络拓扑图等,基本上是一些代码片段和部分内容,很少会涉及整个仓库。

02

如果内部员工或者外部恶意人员上传了本组织内部拥有版权的一些产品或者系统的源代码,在无法定位的情况下可以通过向Github官方提交DMCA删除的请求。

流程:

DMCA 框架有点像课堂上传纸条。 版权所有者向 GitHub 提交对某个用户的投诉。 如果书写正确,我们会将该投诉转达给用户。 如果用户对投诉有异议,他们可以回传“纸条”表达异议。 除了确定通知是否符合 DMCA 的最低要求外,GitHub 在此过程中几乎不行使酌处权。 当事方(及其律师)应负责评估其投诉的合理性,并注意,此类通知受伪证处罚条款约束。

流程步骤:

  • 版权所有者调查

版权的所有者即代码被泄露的组织必须要进行初步调查,确保github上的内容是未经授权的且侵权的内容。

  • 版权所有者发送通知

在进行初步调查后,需要编写删除通知并发送到Github官方。如果符合法律要求并且内容填写足够详细,将会将该通知发布到公共仓库https://github.com/github/dmca,同时将连接发给受影响的用户(上传者)。之前Github提供了两种发送通知的方式:邮件和在线提交,但是目前邮件发送的方式取消了,不再支持了,所以只有在线提交删除通知这一种形式了。后面会详细介绍如何提交这些内容。

  • Github要求上传者进行更改

如果删除通知指明整个仓库内容都涉及侵权,那么将会直接到步骤6迅速禁用整个仓库。否则会联系上传人,给其1个工作日的时间来删除或修改删除通知中指定的内容,同时通知版权所有者。

  • 上传者向Github通知更改

上传者如果选择进行制定内容的更改,必须要在1个工作日内告知githuba官方,否则会禁用整个仓库,如果上传者更改了,也会发送通知给版权所有者。

  • 版权所有者修改或撤回通知

上传者进行更改后,版权所有者必须进行审查,如果认为更改不充分,可以重申或者修改删除通知。除非版权所有者联系github重申或修改通知,否则github不会采取任何进一步的动作。如果版权所有者对更改感到满意,可以提交正式的撤回声明,或者什么都不做,静默期超过两周,github将默认撤回删除通知。

  • Github可能禁止访问内容

在以下情况下,Github将会禁用上传者的内容:(1)版权所有者生成对整个仓库拥有版权;(2)上传者在收到整改通知后并没有进行任何更改;(3)版权所有者在上传者更改后重申了删除通知。

  • 上传者可发送反通知

上传者收到整改通知后如果认为错误指认而被禁用,可以向Github发起反通知,当然内容也要最够详细。也会发布到github官方的公共仓库,并且通知给版权所有者。

  • 版权所有者可提出法律诉讼

如果版权所有者在收到反通知后,如果希望继续删除或禁用该内容,则可以发起法律诉讼,需求法律帮助制止上传者从事的相关侵权互动。如果版权所有者10-14天内没有想Github发出通知(向法院提交的诉讼副本),Github将重新启用被禁用的内容。

03

按照02章节的流程步骤,我们进行初步调查后,确定是自己组织内产品或系统的代码或者相关信息后,就可以向Github官方提出申诉了。Github对于提交DMCA删除有以下要求指南:

开始前…….

  • 说实话

这个很重要。DMCA要求对版权投诉中陈述的事实宣誓,捏造事实会受到伪证处罚。在宣誓中故意说谎是一种违反联邦法律的罪行。提交虚假信息还可能导致民事责任,也就是说可能被起诉经济赔偿。所以在进行DMCA删除申诉前一定要认真核实代码等信息,百分百确定是被侵权的内容且有相关版权的证明。

  • 调查

DMCA投诉是一种严重的法律质控,所以在提交删除申诉前一定要认真调查。

  • 先问清

在发送删除申诉前尝试直接联系用户,是一个良好的开端。当然,在没有上传者信息的情况下,可以在仓库中新建issue,取得联系。这个不是强制要求,但是却很有效果,如果没有提前联系,官方处理时间会延迟10天左右,不会优先处理。

  • 发送正确请求

只接受针对受版权保护的作品并标识出具体版权作品的DMCA删除通知。如果要投诉商标滥用、删除敏感信息请参考其对应的政策要求。

  • 代码不同于其他创意内容

Github是软件代码写作的平台。因此,在这里识别有效的版权行为,比识别照片、音乐或视频等方面的版权侵权行为要复杂的多。

  • 不要使用自动程序

应该让专业人员来评估发送的每个删除通知申诉的内容。也不要使用自动化程序和工具进行批量申诉提交,这些提交往往是无效的。

  • 版权问题难以确定

比如一些字词短语、URL和域名通常不受版权保护,所以提交之前建议咨询下律师等专业人士,给出一些参考意见。

  • 你可能会收到反通知

前面第02章节提到,如果上传者认为是被错误指认的,可以提出反通知,也会发送给版权所有者

  • 你的投诉将被公布

投诉被接受后,会将投诉公布在https://github.com/github/dmca这个仓库中。

  • Github不是法官

Github在整个过程中,除了确定是否符合DMCA最低要求外,几乎不行使酌处权。当事方(及其律师)应负责评估其投诉的合理性,并注意,此类通知受伪证处罚条款约束。

投诉必须包括如下内容:

  • 包括以下声明:“我已阅读并理解Github的《提交DMCA通知指南》。”如果申诉未包括此声明,但是其他内容完整,Github不会拒绝处理,但是会要求先完成阅读指南。
  • 标识出被侵权的作品。这条就是说版权所有者要把自己的版权信息具体标识出来,如果是已经发布的,需要将链接发出来,如果是尚未发布的专有信息,可以对其进行详细描述并说明他是专有信息。如果已经在版权局注册,则应提供注册号。当然了如果托管的内容完全是直接复制作品,也可以只阐述这一事实,但如果只写这一句话,处理时间估计会延长。
  • 标识声称侵犯了上述第2条中所列版权作品的材料。这一步就是说要详细的把侵权的内容标识出来,要让Github官方能够找到所指的内容。比如应该包括涉嫌侵权的URL。如果不是整个仓库都侵权,需要标识出具体的文件或者文件中的行号和具体信息。当然,如果所有该URL的所有内容都侵权也需要明确说明。需要注意的是,Github在禁用父仓库时,不会禁用fork的内容,如果调查分析了fork的内容也涉嫌侵权,需要明确标识出涉嫌侵权的fork。
  • 说明侵权用户需要采取哪些补救措施。这个就是一旦查明上传者侵权属实,那我们版权所有者需要上传者做的动作和要求。比如,用户只需添加归属声明、删除代码中的某些行、删除整个仓库等都需要明确说明。
  • 提供申诉人的联系信息。包括电子邮件地址、姓名、电话号码和实际地址。
  • 提供涉嫌版权者的联系信息(如果知道)。一般是通过提供上传者的Github用户名来满足要求,当然如果知道更多的信息也可以提供出来。
  • 最后声明:“我坚信,在侵权网页上使用上述版权材料,未经版权所有者、其代理人或法律的授权。我已考虑合理使用的情况。”以及宣誓:“本人谨此宣誓,本通知中的信息准确无误,对于涉嫌受到侵犯之专有权,本人是所有者或者所有者的授权代表,如有不实,愿接受伪证处罚。”
  • 提供手写或电子签名。

04

之前,Github还接受邮件申诉,但是现在不支持了,前几天发了一封申诉邮件,发完立刻收到回信,表示邮件方式已经不再受理了。

所以,只能使用在线申诉。。

地址:https://support.github.com/contact/dmca-takedown

这里面的内容和第03章节中投诉必须包括如下内容:是一致的,可能顺序稍微有点不太一样,但是影响不大,只要按照每个标题提示输入相应的内容即可,在这里明确一点,我提供的截图是翻译成中文版的,原始页面是英文,而且大家在申诉填写相关内容时也要填写英文,不能输入中文,毕竟老美看不懂。遇到不会的词或句子可以通过翻译工具翻译后贴上。

成功提交后,很快会收到Github的回信。类似这样:

然后等着就行了。

05

接下来,再总结下敏感数据删除的一些过程内容。

敏感数据删除主要指的是一些保密铭感信息,比如组织的网络拓扑图、系统的用户名和密码等等,如果这些信息数据被上传者上传到了Github,无法定位上传人员的情况下,可以向Github官方发起敏感数据删除申诉。敏感数据的删除要求和流程步骤基本上和DMCA删除的差不多,也是调查分析、发起请求、不能使用自动程序、用户整改等等,但是比DMCA的稍微简单点,这里不再赘述,详细了解可参考https://docs.github.com/cn/github/site-policy/github-sensitive-data-removal-policy

敏感数据删除请求需要包括如下内容:

  1. 每个包含敏感数据文件的可点击的有效链接。不能是搜索的结果、示例或者截图。
  2. 每个文件中包含敏感数据的具体行号。
  3. 描述每条敏感信息对你或者组织构成的安全风险。不仅要指出敏感数据,还要解释这些数据如何构成安全风险,这个很重要。
  4. 如果您是代表面临安全风险之组织行事的第三方,需要附上声明,表面具有代表该组织行事的合法权利。
  5. 可选:如果请求非常急迫,需要说明原因。

在线删除请求的地址https://support.github.com/contact

根据要求在输入框中输入敏感数据要求包括的内容和期望的动作即可。同样也是必须要使用英文填写的。

以上就是在处理Github代码和信息泄露时,如果定位不到上传人时,经常用到的两个删除申诉的过程要求和一些需要注意的点。如果不按官方的要求来,要么会拒绝处理,要么是等待时间很长很长,所以一定要把申诉内容准备的充分一点。希望我总结分享能够帮助到有需要的人。

最后,也希望大家积极和我交流,共同提高!

Github是目前相对最大的、使用人数最多的“男性交友平台”,呸!说错了,是“代码托管交流平台”,上面充斥着各种各样的代码和信息,可谓“宝藏平台”。对于渗透测试人员来说,Github最大的价值是在于渗透测试时利用其进行信息搜集工作,比如查找目标系统的源码、数据库地址、用户名口令等等敏感信息。但是对于工作在甲方或者说担任安全工作的各工程师、负责人来说,这无疑是最痛苦的和需要投入大量人力、物力的地方。

很多介绍企业安全建设或者安全架构体系之类的文章和书籍都会讲到关于Github监控的事情,越来越多的安全人员开始去关注Github上面是否有自己单位业务的相关代码和信息被泄露,监控和巡检形式多种多样,如人工登录按照关键字筛查,也可以利用开源工具进行自动化监控巡检,如VIPKID的Github Monitor以及Hell0W0rld0的Github-Hunter等等。但是难点和痛点其实不是前面说的这些工作,而是发现泄露后的排查分析和人员定位,如果泄露的内容中有上传者的相关信息那还好办,能够联系上,让其删掉。但是对于任何上传者信息都找不到的情况怎么办呢?

这时候我们就要另辟蹊径了,如果花费了很多时间后仍然找不到上传者本人信息,无法联系进行删除,那么就需要联系Github官方进行申诉了,让Github官方进行核实和删除,避免信息被大范围的泄露。

01

首先,Github官方提供了一些列删除政策的说明。这里我介绍下我常用的两种DMCA删除政策和敏感数据删除政策。链接如下:

https://docs.github.com/cn/github/site-policy/dmca-takedown-policy

https://docs.github.com/cn/github/site-policy/github-sensitive-data-removal-policy

什么是DMCA

DMCA 为托管用户生成内容的服务提供商提供了安全港。 仅仅一项侵犯版权的索赔就可能导致高达 150,000 美元的法定赔偿,因此,对用户生成的内容承担责任可能对服务提供商非常不利。 如果面向数以百万计的用户,这种潜在损失将不可估量,可以说,假如没有 DMCA,则 YouTube、Facebook 或 GitHub 等云计算和用户生成内容的网站可能就不会存在或者至少会将部分成本转嫁给用户)。

DMCA 通过为托管涉嫌侵权用户生成内容的互联网服务提供商建立版权责任安全港,解决了这一问题。 从本质上讲,只要服务提供商遵守 DMCA 的通知和删除规则,就不会对基于用户生成内容的侵权行为承担责任。 因此,对 GitHub 而言,保持其 DMCA 安全港状态非常重要。

什么是敏感数据?

就本文档而言,“敏感数据”是指符合以下条件的内容:应该保密,并且一旦公开,会对您或您的组织造成特定安全风险。

敏感数据删除请求适用于:

  • 可访问您组织的服务器、网络或域的访问凭据,例如用户名与密码组合、访问令牌或其他敏感密钥。
  • 可代表您访问第三方的 AWS 令牌和其他类似访问凭据。 您必须能够证明该令牌确实属于您。
  • 对组织构成特定安全风险的文档(例如网络图)。 内部服务器名称、IP 地址和 URL 本身不够敏感;您必须能够证明内部服务器名称在特定文件或代码段中的使用构成了安全威胁。

两者的区别是:DMCA删除政策偏向于涉嫌版权侵权的申诉,只接受针对受版权保护的作品并且标识出具体版权,涉及面可能是整个仓库,而敏感数据删除政策偏向于一些应该保密但是被公开且易造成安全风险的信息,比如用户名和密码、网络拓扑图等,基本上是一些代码片段和部分内容,很少会涉及整个仓库。

02

如果内部员工或者外部恶意人员上传了本组织内部拥有版权的一些产品或者系统的源代码,在无法定位的情况下可以通过向Github官方提交DMCA删除的请求。

流程:

DMCA 框架有点像课堂上传纸条。 版权所有者向 GitHub 提交对某个用户的投诉。 如果书写正确,我们会将该投诉转达给用户。 如果用户对投诉有异议,他们可以回传“纸条”表达异议。 除了确定通知是否符合 DMCA 的最低要求外,GitHub 在此过程中几乎不行使酌处权。 当事方(及其律师)应负责评估其投诉的合理性,并注意,此类通知受伪证处罚条款约束。

流程步骤:

  • 版权所有者调查

版权的所有者即代码被泄露的组织必须要进行初步调查,确保github上的内容是未经授权的且侵权的内容。

  • 版权所有者发送通知

在进行初步调查后,需要编写删除通知并发送到Github官方。如果符合法律要求并且内容填写足够详细,将会将该通知发布到公共仓库https://github.com/github/dmca,同时将连接发给受影响的用户(上传者)。之前Github提供了两种发送通知的方式:邮件和在线提交,但是目前邮件发送的方式取消了,不再支持了,所以只有在线提交删除通知这一种形式了。后面会详细介绍如何提交这些内容。

  • Github要求上传者进行更改

如果删除通知指明整个仓库内容都涉及侵权,那么将会直接到步骤6迅速禁用整个仓库。否则会联系上传人,给其1个工作日的时间来删除或修改删除通知中指定的内容,同时通知版权所有者。

  • 上传者向Github通知更改

上传者如果选择进行制定内容的更改,必须要在1个工作日内告知githuba官方,否则会禁用整个仓库,如果上传者更改了,也会发送通知给版权所有者。

  • 版权所有者修改或撤回通知

上传者进行更改后,版权所有者必须进行审查,如果认为更改不充分,可以重申或者修改删除通知。除非版权所有者联系github重申或修改通知,否则github不会采取任何进一步的动作。如果版权所有者对更改感到满意,可以提交正式的撤回声明,或者什么都不做,静默期超过两周,github将默认撤回删除通知。

  • Github可能禁止访问内容

在以下情况下,Github将会禁用上传者的内容:(1)版权所有者生成对整个仓库拥有版权;(2)上传者在收到整改通知后并没有进行任何更改;(3)版权所有者在上传者更改后重申了删除通知。

  • 上传者可发送反通知

上传者收到整改通知后如果认为错误指认而被禁用,可以向Github发起反通知,当然内容也要最够详细。也会发布到github官方的公共仓库,并且通知给版权所有者。

  • 版权所有者可提出法律诉讼

如果版权所有者在收到反通知后,如果希望继续删除或禁用该内容,则可以发起法律诉讼,需求法律帮助制止上传者从事的相关侵权互动。如果版权所有者10-14天内没有想Github发出通知(向法院提交的诉讼副本),Github将重新启用被禁用的内容。

03

按照02章节的流程步骤,我们进行初步调查后,确定是自己组织内产品或系统的代码或者相关信息后,就可以向Github官方提出申诉了。Github对于提交DMCA删除有以下要求指南:

开始前…….

  • 说实话

这个很重要。DMCA要求对版权投诉中陈述的事实宣誓,捏造事实会受到伪证处罚。在宣誓中故意说谎是一种违反联邦法律的罪行。提交虚假信息还可能导致民事责任,也就是说可能被起诉经济赔偿。所以在进行DMCA删除申诉前一定要认真核实代码等信息,百分百确定是被侵权的内容且有相关版权的证明。

  • 调查

DMCA投诉是一种严重的法律质控,所以在提交删除申诉前一定要认真调查。

  • 先问清

在发送删除申诉前尝试直接联系用户,是一个良好的开端。当然,在没有上传者信息的情况下,可以在仓库中新建issue,取得联系。这个不是强制要求,但是却很有效果,如果没有提前联系,官方处理时间会延迟10天左右,不会优先处理。

  • 发送正确请求

只接受针对受版权保护的作品并标识出具体版权作品的DMCA删除通知。如果要投诉商标滥用、删除敏感信息请参考其对应的政策要求。

  • 代码不同于其他创意内容

Github是软件代码写作的平台。因此,在这里识别有效的版权行为,比识别照片、音乐或视频等方面的版权侵权行为要复杂的多。

  • 不要使用自动程序

应该让专业人员来评估发送的每个删除通知申诉的内容。也不要使用自动化程序和工具进行批量申诉提交,这些提交往往是无效的。

  • 版权问题难以确定

比如一些字词短语、URL和域名通常不受版权保护,所以提交之前建议咨询下律师等专业人士,给出一些参考意见。

  • 你可能会收到反通知

前面第02章节提到,如果上传者认为是被错误指认的,可以提出反通知,也会发送给版权所有者

  • 你的投诉将被公布

投诉被接受后,会将投诉公布在https://github.com/github/dmca这个仓库中。

  • Github不是法官

Github在整个过程中,除了确定是否符合DMCA最低要求外,几乎不行使酌处权。当事方(及其律师)应负责评估其投诉的合理性,并注意,此类通知受伪证处罚条款约束。

投诉必须包括如下内容:

  • 包括以下声明:“我已阅读并理解Github的《提交DMCA通知指南》。”如果申诉未包括此声明,但是其他内容完整,Github不会拒绝处理,但是会要求先完成阅读指南。
  • 标识出被侵权的作品。这条就是说版权所有者要把自己的版权信息具体标识出来,如果是已经发布的,需要将链接发出来,如果是尚未发布的专有信息,可以对其进行详细描述并说明他是专有信息。如果已经在版权局注册,则应提供注册号。当然了如果托管的内容完全是直接复制作品,也可以只阐述这一事实,但如果只写这一句话,处理时间估计会延长。
  • 标识声称侵犯了上述第2条中所列版权作品的材料。这一步就是说要详细的把侵权的内容标识出来,要让Github官方能够找到所指的内容。比如应该包括涉嫌侵权的URL。如果不是整个仓库都侵权,需要标识出具体的文件或者文件中的行号和具体信息。当然,如果所有该URL的所有内容都侵权也需要明确说明。需要注意的是,Github在禁用父仓库时,不会禁用fork的内容,如果调查分析了fork的内容也涉嫌侵权,需要明确标识出涉嫌侵权的fork。
  • 说明侵权用户需要采取哪些补救措施。这个就是一旦查明上传者侵权属实,那我们版权所有者需要上传者做的动作和要求。比如,用户只需添加归属声明、删除代码中的某些行、删除整个仓库等都需要明确说明。
  • 提供申诉人的联系信息。包括电子邮件地址、姓名、电话号码和实际地址。
  • 提供涉嫌版权者的联系信息(如果知道)。一般是通过提供上传者的Github用户名来满足要求,当然如果知道更多的信息也可以提供出来。
  • 最后声明:“我坚信,在侵权网页上使用上述版权材料,未经版权所有者、其代理人或法律的授权。我已考虑合理使用的情况。”以及宣誓:“本人谨此宣誓,本通知中的信息准确无误,对于涉嫌受到侵犯之专有权,本人是所有者或者所有者的授权代表,如有不实,愿接受伪证处罚。”
  • 提供手写或电子签名。

04

之前,Github还接受邮件申诉,但是现在不支持了,前几天发了一封申诉邮件,发完立刻收到回信,表示邮件方式已经不再受理了。

所以,只能使用在线申诉。。

地址:https://support.github.com/contact/dmca-takedown

这里面的内容和第03章节中投诉必须包括如下内容:是一致的,可能顺序稍微有点不太一样,但是影响不大,只要按照每个标题提示输入相应的内容即可,在这里明确一点,我提供的截图是翻译成中文版的,原始页面是英文,而且大家在申诉填写相关内容时也要填写英文,不能输入中文,毕竟老美看不懂。遇到不会的词或句子可以通过翻译工具翻译后贴上。

成功提交后,很快会收到Github的回信。类似这样:

然后等着就行了。

05

接下来,再总结下敏感数据删除的一些过程内容。

敏感数据删除主要指的是一些保密铭感信息,比如组织的网络拓扑图、系统的用户名和密码等等,如果这些信息数据被上传者上传到了Github,无法定位上传人员的情况下,可以向Github官方发起敏感数据删除申诉。敏感数据的删除要求和流程步骤基本上和DMCA删除的差不多,也是调查分析、发起请求、不能使用自动程序、用户整改等等,但是比DMCA的稍微简单点,这里不再赘述,详细了解可参考https://docs.github.com/cn/github/site-policy/github-sensitive-data-removal-policy

敏感数据删除请求需要包括如下内容:

  1. 每个包含敏感数据文件的可点击的有效链接。不能是搜索的结果、示例或者截图。
  2. 每个文件中包含敏感数据的具体行号。
  3. 描述每条敏感信息对你或者组织构成的安全风险。不仅要指出敏感数据,还要解释这些数据如何构成安全风险,这个很重要。
  4. 如果您是代表面临安全风险之组织行事的第三方,需要附上声明,表面具有代表该组织行事的合法权利。
  5. 可选:如果请求非常急迫,需要说明原因。

在线删除请求的地址https://support.github.com/contact

根据要求在输入框中输入敏感数据要求包括的内容和期望的动作即可。同样也是必须要使用英文填写的。

以上就是在处理Github代码和信息泄露时,如果定位不到上传人时,经常用到的两个删除申诉的过程要求和一些需要注意的点。如果不按官方的要求来,要么会拒绝处理,要么是等待时间很长很长,所以一定要把申诉内容准备的充分一点。希望我总结分享能够帮助到有需要的人。

最后,也希望大家积极和我交流,共同提高!

2020年突如其来的疫情,导致很多事情搁置,整个国家仿佛按下了慢放键。原本计划要和大家分享的数据安全的最后一部分,由于疫情的工作安排,也没有时间进行总结。随着疫情防控态势逐渐好转,终于能抽出时间来梳理之前计划分享的内容了。另外提醒大家,疫情还没结束,大家一定要做好个人防护。

言归正传,截止到目前,已经介绍和分享了六个部分,分别为DSMM开篇交流、数据采集安全、数据传输安全、数据存储安全、数据处理安全、数据交换,各过程阶段链接如下:

DSMM开篇总结与交流

DSMM数据采集安全

DSMM数据传输安全

DSMM数据存储安全

DSMM数据处理安全

DSMM数据交换安全

今天就来说一说数据安全生命周期的最后一个阶段——数据销毁安全。

一、背景

数据生命周期分为采集、传输、存储、处理、交换、销毁几个阶段,同样,数据销毁安全也是数据安全生命周期的最后一个阶段。数据销毁的定义是:计算机或设备在弃置、转售或捐赠前必须将其所有数据彻底删除,并无法复原,以免造成信息泄露,尤其是国家涉密数据。那我理解数据销毁主要包括物理层面销毁和逻辑层面的销毁,这与 DSMM标准中关于数据销毁安全包含数据销毁处置和介质销毁处置两个安全过程域是一致的。

DSMM标准对每个安全过程域都分为5个成熟度等级,分别为:非正式执行、计划跟踪、充分定义、量化控制、持续优化;安全能力的维度包括组织建设、制度流程、技术工具、人员能力。我们在落地执行的时候一般按照等级3即充分定义级进行相关的工作,因为在充分定义级里面完整的包含了安全能力维度的四个方面,而等级1和等级2是没有覆盖完全的,至于等级4和等级5就是进行一些量化细化和持续改进的,可以在DSMM体系建设完成后进行拔高。每个过程域都是按照这样的思路进行要求的,所以接下来介绍的数据销毁安全的各过程域也都是按照这个思路进行建设的。

二、过程域

2.1数据销毁处置

数据销毁是通过建立针对数据内容的清除、净化机制,实现对数据的有效销毁,防止因对存储介质中的数据内容进行恶意恢复而导致的数据泄漏风险。

数据销毁有两个目的,一是合规要求,国家法律法规要求重要数据不被泄漏;另外就是组织本身的业务发展或管理需要。日常工作过程中,用户往往采取删除、硬盘格式化、文件粉碎等方法销毁数据,但是这些方法并不是完全安全。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一负责数据销毁管理的岗位和人员,负责制定数据销毁处置规范,并推动相关要求在业务部门落地实施。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

依照数据分类分级建立数据销毁策略和管理制度,明确数据销毁的场景、销毁对象、销毁方式和销毁要求。

建立规范的数据销毁流程和审批机制,设置销毁相关监督角色,监督操作过程,并对审批和销毁过程进行记录控制。

按照国家相关法律和标准销毁个人信息、重要数据等敏感信息。

技术工具:

针对网络存储数据,建立硬销毁和软销毁的数据销毁方法和技术,如基于安全策略、基于分布式杂凑算法等网络数据分布式存储的销毁策略与机制。

配置必要的数据销毁技术手段与管控措施,确保以不可逆方式销毁敏感数据及其副本内容。

人员能力:

负责数据销毁安全工作的人员熟悉数据销毁的相关合规要求,能够主动根据政策变化和技术发展更新相关知识和技能。

以下是我们在数据销毁处置过程中具体落地实践的内容。

1. 定义出数据销毁的场景,根据数据分类分级,结合业务和数据重要性需要,采用不同的数据销毁方法,比如覆写法、消磁法、删除、硬盘格式化、文件粉碎等。

2.制定数据销毁的审批和监督流程,对重要数据的销毁要进行合理性和必要性评估及会议评审,还要在销毁时进行监督管理,确保数据销毁符合要求。我们这里其实涉及数据销毁的的不太多,几乎数据就没销毁过,不过有相应的销毁流程,目前审批数据销毁的是主管副总裁。如果有销毁这种级别操作,在我们这都是要至少两个人在场的,同时所有的操作会有相应的日志记录和变更记录。

2.2介质销毁处置

存储介质在被替换或淘汰掉不再使用是,需要对介质进行彻底的物理销毁,保证数据无法复原,以免造成信息泄露,尤其是国家涉密数据。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一负责介质销毁管理的岗位和人员,整体制定组织机构介质销毁管理的制度,并推动相关内容在业务团队实施落地。

组织建设要求和数据销毁处置过程域中组织建设要求类似,这里不再赘述。

制度流程:

建立介质销毁处理策略、管理制度和机制,明确销毁对象和流程。

依据介质存储内容的重要性,明确磁介质、光介质和半导体介质等不同类存储介质的销毁方法和机制。

建立对存储介质销毁的监控机制,确保对销毁介质的登记、审批、交接等介质销毁过程进行监控。

按照国家相关法律和标准销毁存储介质,加强对介质销毁人员监管。

技术工具:

组织机构提供了统一的介质销毁工具,包括但不限于物理摧毁、消磁设备等工具,能够实现各类介质的有效销毁。

针对闪存、硬盘、磁带、光盘等存储介质数据,建立硬销毁和软销毁的数据销毁方法和技术。

人员能力:

负责该项工作的人员能够依据数据销毁的整体需求明确应使用的介质销毁工具。

以下是我们在介质销毁处置过程中具体落地实践的内容。

1.定义出介质销毁的场景,根据实际的数据保密性要求高低,采用不同的介质销毁方法,比如捣碎法/剪碎法、焚毁法等。

2.制定介质销毁的审批和监督流程,对重要数据的销毁要进行合理性和必要性评估及会议评审,还要在介质销毁时进行监督管理,目前审批介质销毁的是IT负责人。如果有销毁这种级别操作,在我们这都是要至少两个人在场的,甚至要求主管领导亲临现场监督介质销毁状况与进度,落实数据安全的最后一步。

三、总结

数据销毁安全作为数据安全生命周期的最后一个阶段,其实我们平常涉及的并不是太多,但是重要性很高,特别是对于国家涉密信息。各单位要根据不同要求和需要采取不同的数据销毁策略和技术手段,已实现对数据的有效销毁,防止因对存储介质中的数据内容进行恶意恢复而导致的数据泄漏风险。

以上就是DSMM数据销毁安全过程的要求以及我们在实际落地执行过程中的一点心得和体会,内容不是太多,希望能够给大家带来一些启发,也算是抛砖引玉。

*本文作者:kirazhou,转载请注明来自FreeBuf.COM

前段时间很多人给我发私信,想要交流下DSMM的相关内容,并追问下一篇文章什么时候分享。在这里给大家说声不好意思,因为这阵子工作太忙了,没时间进行总结和整理,所以每天晚上抽出点时间整理下,形成本文。以后尽量定期进行更新。

截止到目前,已经介绍和分享了五个部分,分别为DSMM开篇的总结与交流、数据采集安全、数据传输安全、数据存储安全、数据处理安全,各地址如下:

DSMM开篇总结与交流

DSMM数据采集安全

DSMM数据传输安全

DSMM数据存储安全

DSMM数据处理安全

过年了,祝大家新年快乐,也希望大家和我多多交流,多提宝贵意见。下面开始本次分享的核心内容——DSMM之数据交换安全。

一、背景

数据安全生命周期分为采集、传输、存储、处理、交换、销毁几个阶段,其中数据交换阶段涉及数据的转移,信息安全风险很高,所以数据交换安全的重要性不言而喻。数据交换安全包含四个过程域,分别为:数据导入导出安全、数据共享安全、数据发布安全、数据接口安全。

DSMM分为5个成熟度等级分别为:非正式执行、计划跟踪、充分定义、量化控制、持续优化;安全能力的维度包括组织建设、制度流程、技术工具、人员能力。我们在落地执行的时候一般按照等级3即充分定义级进行相关的工作,因为在充分定义级里面完整的包含了安全能力维度的四个方面,而等级1和等级2是没有覆盖完全的,至于等级4和等级5就是进行一些量化细化和持续改进的,可以在DSMM体系建设完成后进行拔高。每个过程域都是按照这样的思路进行要求的,所以接下来介绍的数据处理安全的各过程域都是按照这个思路进行建设的。

二、具体内容

2.1数据导入导出安全

数据导入导出广泛存在于数据交换过程中,通过数据导入导出,数据被批量化流转,加速数据应用价值的体现。如果没有安全保障措施,非法人员可能通过非法技术手段导出非授权数据,导入恶意数据等,带来数据篡改和数据泄漏的重大事故,由于一般数据导入导出的数据量都很大,因此相关安全风险和安全危害也会被乘倍放大。所以,需要采取有效的制度和工具措施控制数据导入导出的安全风险。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一的数据导入导出安全管理岗位和人员,负责制定规则和提供技术能力,并推动在组织机构内业务场景落地执行。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

依据数据分类分级要求建立符合业务规则的数据导入导出安全策略,如授权策略、流程控制策略、不一致处理策略等

建立数据导出安全评估和授权审批流程,评估数据导出的安全风险,并对大量或敏感数据导出进行授权审批。

如采用存储介质导出数据,需建立针对导出介质的标识规范,明确介质的命名规则、标识属性等重要信息,定期验证导出数据的完整性和可用性。

制定导入导出审计策略和日志管理规范,并保存导入导出过程中的出错数据处理记录。

技术工具:

记录并定期审计组织内部的数据导入导出行为,确保未超出数据授权使用范围。

对数据导入导出终端、用户或服务组件执行有效的访问控制,实现对其身份的真实性和合法性的保证。

采取数据加密、访问控制等技术手段,保障数据在传输中的保密性、完整性和可用性。

在导入导出完成后对数据导入导出通道缓存的数据进行清除,以保证导入导出过程中涉及的数据不会被恶意恢复。

人员能力:

负责数据导入导出安全工作的人员能够充分理解组织机构的数据导入导出策略,并根据数据导入导出的业务场景执行相应的风险评估,从而提出实际的解决方案。

以下是我们在数据导入导出安全过程中具体落地实践的内容。

1.设置专门的负责导入导出的人员,并对导入导出安全负责,当然也可能不止一个人,我们这是一个数据团队。

2.定义数据导入导出的场景,明确数据导入导出的范围、内容、格式等,场景很重要,不同的场景,安全策略是不同的,不能一概而论。

3.建立数据导入导出安全规范,并依据不同的场景,制定不同的安全策略,如访问控制策略、审核策略、处理策略等。这些策略应该细化可执行,并经过评审才可以实施。

4.制定数据导入导出的安全审核策略,明确导入导出的数据内容、涉及的部门组织、及数据用途、授权审核同意/否决等。

5.对导出的数据存储的介质进行标识,明确介质命名规则,统一编号格式,定期对数据的完整性和可用性进行验证。如果这些数据不再使用,建议还是进行删除销毁,避免数据泄漏。

6.对导入导出的数据采取必要的安全技术措施,如木马检测、加密传输、加密存储、完整性校验等,确保导入导出数据的安全。其实,这更多的偏向于导入的安全检测防护,因为对于导入的数据,是不可信的。当然导出的数据也需要进行完整性校验等措施。

7.对导入导出的过程进行日志记录,以便溯源和监控工作的开展,并定期进行审计发现存在的安全风险。这是数据安全整个生命周期所有阶段都需要的。

8.对导入导出的人员采用必要的认证措施,防止假冒。身份认证是数据安全防护的基础。

9.对导入导出的数据进行机器和人工双重校验,保证数据的完整性和可用性。

下图是我们对数据导入导出安全的梳理。

2.2数据共享安全

在数据交换环节中,业务系统将数据共享给外部组织机构,或者以合作方式与第三方合作伙伴交换数据,数据在共享后释放更大价值,并支撑数据业务的深入开展。

数据共享过程中面临巨大安全风险,数据本身存在敏感性,共享保护措施不当将带来敏感数据和重要数据的泄漏。因此,需要采取安全保护措施保障数据共享后数据的完整性、保密性和可用性,防止数据丢失、篡改、假冒和泄露。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一的数据共享交换安全管理的岗位和人员,负责相关原则和技术能力的提供,并推广相关要求在相关业务场景的落地执行。

组织建设要求和数据导入导出安全过程域中组织建设要求类似,这里不再赘述。

制度流程:

制定数据共享的原则和安全规范,明确数据共享内容范围和数据共享的管控措施,及数据共享涉及机构或部门相关用户职责和权限。

明确数据提供者与共享数据使用者的数据安全责任,确保共享数据使用者具备与数据提供者足够或相当的安全防护能力。

制定数据共享审计策略和审计日志管理规范,明确审计记录要求,为数据共享安全事件的处置、应急响应和事后调查提供帮助。

使用外部第三方的SDK/组件/源码前进行安全评估,确保第三方获取的数据符合组织机构的数据安全要求。

技术工具:

采取多种措施确保个人信息在委托处理、共享、转让等对外提供场景的安全合规,如数据脱敏、数据加密、安全通道、共享交换区域等。

对共享数据集数据共享过程进行监控审计,确保共享的数据属于共享业务场景需求且没有超出数据共享使用授权范围。

建立共享数据格式规范,如提供机器可读的格式规范,确保高效获取共享数据。

人员能力:

负责该项工作的人员能够充分理解组织机构的数据共享策略,并根据数据共享的业务场景执行相应的风险评估,从而提出实际的解决方案。

以下是我们在数据共享安全过程中具体落地实践的内容。

1.明确数据共享的场景,如内部业务系统之间的共享、基于业务需要的对外共享等,细化数据共享涉及的数据范围、数据类型、数据内容及数据格式等。要区分内外共享场景,评估不同场景的数据共享风险。

2.在提供数据共享时要明确数据提供者和数据使用者的安全责任,如建立书面的安全责任说明/协议,明确双方责任义务、对数据保护采取加密、完整性校验技术防护要求等。提前说明责任和义务以及相应的要求。

3.建立数据共享的审核流程,包括共享的数据内容、涉及的部门和组织、授权审批同意/否决、归档记录等。尤其对于向外部提供的共享数据,一定要有严格的审核流程。

4.制定数据共享审计日志管理规范,所有的数据共享内容和过程需要提供日志记录并保存,以便应急处置和溯源。

5.对于涉及第三方数据交换加工平台的场景,如使用外部第三方的SDK、组件、源代码等,需要制定明确的安全评估要求和流程,确保符合数据共享安全要求。

6.在数据共享交换过程中需要采取必要的措施对重要的数据、个人隐私敏感数据等进行防护,做到“可用不可见”,如电话信息可不见但是可以直接拨打、***信息不可见,但是可以进行比对认证等。电子商务和O2O业务的企业在这方面做的很不错,本人也有切身体会。

下图是我们对数据共享安全的梳理。

2.3数据发布安全

数据发布是指组织内部数据通过各种途径向外部组织公开的一个过程,如数据开放、企业宣传、网站内容发布、社交媒体发布、PPT资料对外宣传等。通过在对外部组织机构进行数据发布的过程中对发布数据的格式、适用范围、发布者与使用者权利和义务执行的必要控制,实现数据发布过程中数据安全可控与合规,防止出现违规对外披露造成对组织的名誉损害,资产损失等不良影响时间发生。数据发布安全保障发布内容的真实性、正确性、实效性和准确性。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构指定专人或设立相关岗位人员,负责组织机构的数据公开发布信息,并且对数据披露人员进行安全培训。

组织建设要求和数据导入导出安全过程域中组织建设要求类似,这里不再赘述。

制度流程:

建立数据资源公开发布的审核制度,严格审核数据发布符合相关法律法规要求。

明确数据资源公开内容、适用范围及规范,发布者与使用者权利和义务。

定期审查公开发布的数据资源中是否含有非***息,并采取相关措施确保发布数据使用的合规性。

技术工具:

建立数据资源公开数据库,通过数据发布平台服务实现公开数据资源登记、用户注册等发布数据和发布组件的验证互认机制。

采取必要措施建立数据资源公开事件应急处理机制。

人员能力:

负责数据发布安全管理工作的人员充分理解数据安全发布的制度和流程,通过了岗位能力测试,并能够根据实际发布要求建立相应的应急方案。

以下是我们在数据发布安全过程中具体落地实践的内容。

1.建立数据发布审核制度和流程,包括数据待发布内容、涉及的部门和组织、审核批准/否决、数据发布应急处理流程等,确保发布内容可以公开的并且符合法律法规要求。这需要和市场部门一起进行会议协商、评审,确保制度和流程的合理可行。

2.发布的数据内容应明确适用范围、发布者和使用者的权利和义务。如所有权归属,未经同意禁止转载、禁止商业使用等。

3.建立定期审核检查制度,对已发布的数据进行监控,确定符合数据发布安全管理规定,同时对有效性进行监控,及时检查已发布数据在现有情况下是否仍然有效。

下图是我们对数据发布安全的梳理。

2.4数据接口安全

在数据共享交换中,通过API数据接口获取数据是常见的方式。如果对于数据接口进行攻击,将导致数据通过数据接口泄漏。通过建立组织机构的对外数据接口的安全管理机制,防范组织机构在数据接口调用过程中的安全风险。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一负责数据接口安全管理的岗位和人员,由该岗位人员负责制定整体的规则并推广相关流程的推行。

组织建设要求和数据导入导出安全过程域中组织建设要求类似,这里不再赘述。

制度流程:

制定数据服务接口安全控制策略,明确规定使用数据接口的安全限制和安全控制措施,如身份鉴别、访问控制、授权策略、签名、时间戳、安全协议等。

明确服务接口安全规范,包括接口名称、接口参数、接口安全要求等。

与数据接口调用方签署了合作协议,明确数据的使用目的、供应方式、保密约定、数据安全责任等。

技术工具:

采用技术工具实现对数据服务接口调用的身份鉴别和访问控制。

具备对接口不安全输入参数进行限制或过滤的能力,为接口提供异常处理能力。

具备服务接口访问的审计能力,并能为大数据安全审计提供可配置的数据服务接口。

对跨安全域间的服务接口调用采用安全通道、加密传输、时间戳等安全机制。

人员能力:

负责数据接口安全工作的人员充分理解数据接口调用业务的使用场景,具备充分的数据接口调用的安全意识、技术能力和风险控制能力。

常见的接口安全攻击方式如下:

伪装攻击。例如:第三方有意或恶意的调用。

篡改攻击。例如:请求头/查询字符串/内容 在传输过程被修改。

重放攻击。例如:请求被截获,稍后被重放或多次重放。

数据信息监听。例如:截获用户登录请求,截获到账号、密码等敏感信息。

针对这些常见的安全威胁,以下是我们在数据接口安全过程中具体落地实践的内容。

1.制定接口开发规范,对涉及的接口类型、编码格式、变量名称、变量类型、长度、大小等内容进行规范定义。

2.制定接口安全策略,包括但不限于接口身份鉴别token、访问控制权限、签名防抵赖、时间戳、安全传输协议HTTPS等。

3.与接口调用方签订安全责任声明书,包括双方权利义务、数据使用目的、调用频次、责任归属等。

4.建立统一的数据接口管理平台,实现对数据接口的管理和审核,保证开放的接口符合安全规定要求。

5.对接口进行大量的安全测试,包括非授权登录、重放攻击、数据篡改、假冒伪装等,确保接口安全。

6. 应提供接口调用的日志记录,包括日期、时间、调用人/ip、状态、返回内容等,方便后期进行溯源,同时对接口异常事件进行告警通知。

下图是我们对数据接口安全的梳理。

三、写在最后

大数据时代,数据只有“活”起来,才能发挥出应有的价值,企业进行数据共享交换才会带来更大的经济效益,所以数据交换会发生的的很频繁,随之产生的安全风险也非常高,在这样的场景下,数据交换安全显得尤为重要。

虽然在文中,很多制度和技术工具是分开叙述,但是在实际工作中可能是混在一起的,同时很多具体实现的部分也不仅仅只是应用在一个过程域或者一个生命周期阶段,甚至可以应用在整个生命周期过程中。比如各过程域都提到了要进行相应的审计,保留日志记录,以便进行溯源和事件问题追踪,这在其他各阶段,如采集、传输、存储、处理等也有相应要求。

以上就是DSMM数据交换安全过程的要求以及我们在实际落地执行过程中的一点心得和体会,希望能够给大家带来一些启发,也算是抛砖引玉,欢迎大家和我进行沟通交流,提出宝贵意见,一起进步。

*本文原创作者:LJ_Monica,本文属于FreeBuf原创奖励计划,未经许可禁止转载

有人想看数据安全能力成熟度模型(DSMM,以下简称DSMM)的数据处理安全部分,今天它来了….

前段时间整理了DSMM的一系列内容,已经介绍和分享了三个部分,分别为DSMM开篇的总结与交流、数据采集安全、数据传输安全、数据存储安全,各过程阶段链接如下:

DSMM开篇总结与交流

DSMM数据采集安全

DSMM数据传输安全

DSMM数据存储安全

天气逐渐变冷了,小伙伴们注意添加衣服保暖了。这段时间单位的事情也比较多,一直没有时间继续分享DSMM的相关内容,趁着下班的时间,将数据处理安全过程的相关内容进行了总结。也希望各位小伙伴能够和我多多交流,多提宝贵意见。废话不多说,开始本次分享的核心内容——DSMM之数据处理安全。

一、背景

数据安全生命周期分为采集、传输、存储、处理、交换、销毁几个阶段,其中数据处理阶段是整个周期的核心阶段,数据处理安全与否直接关系到整体数据安全。那么今天分享内容就是数据处理安全的相关要求和实现目标。

我们知道DSMM分为5个成熟度等级分别为:非正式执行、计划跟踪、充分定义、量化控制、持续优化;安全能力的维度包括组织建设、制度流程、技术工具、人员能力。我们在落地执行的时候一般按照等级3即充分定义级进行相关的工作,因为在充分定义级里面完整的包含了安全能力维度的四个方面,而等级1和等级2是没有覆盖完全的,至于等级4和等级5就是进行一些量化细化和持续改进的,可以在DSMM体系建设完成后进行拔高。每个过程域都是按照这样的思路进行要求的,所以接下来介绍的数据处理安全的各过程域都是按照这个思路进行建设的。

二、定义

数据处理,顾名思义,就是对数据进行操作、加工、分析等过程,此阶段对数据接触的最深入,所以安全风险也比较大。数据处理安全过程就是为了解决数据处理过程中的安全问题,降低该阶段的安全风险,该过程包含四个过程域,分别为:数据脱敏、数据分析安全、数据正当使用、数据处理环境安全。

2.1数据脱敏

数据作为一种重要的生产资料,充分分析与挖掘数据的内在价值成为了现代企业创新成长的必经之路,但同时敏感数据的泄露风险也与日俱增。严格意义上来讲,任何有权限访问数据的人员,均有可能导致敏感数据的泄露。另一方面,没有数据访问权限的人员,也可能有对该数据进行分析挖掘的需求,数据的访问约束大大限制了充分挖掘数据价值的范围。数据脱敏技术通过将敏感数据进行数据的变形,为用户提供虚假数据而非真实数据,实现敏感隐私数据的可靠保护。这样就可以在开发、测试和其他非生产环境以及外包环境中安全地使用脱敏后的真实数据集,既保护了组织的敏感信息不泄露,又达到了挖掘数据价值的目标。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一的数据安全岗位和人员,负责制定数据脱敏的原则和方法,并提供相关技术能力。

在数据权限的申请阶段,由相关人员评估使用真实数据的必要性,以及确定该场景下适用的数据脱敏规则及方法。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

建立组织机构的数据脱敏规范,明确数据脱敏的规则、脱敏方法和使用限制等。

明确需要脱敏处理的应用场景、脱敏处理流程、涉及部门及人员的职责分工。

技术工具:

组织机构提供统一的数据脱敏工具,实现数据脱敏工具与数据权限管理平台的联动,以及数据使用前的静态脱敏。

提供面向使用者的数据脱敏定制化功能,可基于场景需求自定义脱敏规则。

数据脱敏后应保留原始数据格式和特定属性,满足开发与测试需求。

对数据脱敏处理过程相应的操作进行记录,以满足数据脱敏处理安全审计要求。

人员能力:

熟悉常规的数据脱敏技术,能够分析数据脱敏过程中存在的安全风险,基于数据脱敏的具体场景保证业务和安全之间的需求平衡。

具备对数据脱敏的技术方案定制化的能力,能够基于组织机构内部各级别的数据建立有效的数据脱敏方案。

以下是我们在数据脱敏过程中具体落地实践的内容。

在数据脱敏之前一定要按照之前的数据分类分级表对需要脱敏的敏感数据进行定义,并不是所有的数据都要脱敏。,于采用的脱敏技术根据具体的场景进行选择。数据脱敏的核心是实现数据可用性和安全性之间的平衡,既要考虑系统开销,满足业务系统的需求,又要兼顾最小可用原则,最大限度的防止敏感信息泄露。所有的数据脱敏操作都需要进行审计,留存审计日志记录,这点很重要。具体如下:

1.应结合数据分类分级表对敏感数据进行识别和定义,明确需要脱敏的数据信息,一般包括个人信息数据、组织敏感信息、国家重要数据(非涉密信息)等。

2.应定义不同等级的敏感数据的脱敏处理场景、流程、方法和涉及的部门及人员分工,脱敏技术一般包括:泛化、抑制、扰乱、有损等。

3.应根据数据使用者的职责、权限及业务范围采取不同的数据脱敏方式,如对开发人员使用的数据,可采用扰乱技术在脱敏后保留数据属性特征等;对投屏展示用的数据,可以选择掩码方式隐藏敏感的信息。

4.应配置统一的数据脱敏工具,提供静态脱敏和基于场景需求的自定义脱敏规则的动态脱敏功能,满足不同业务需求。

5.应在数据脱敏的各阶段加入安全审计机制,对数据脱敏过程的操作行为进行记录,用于后续问题排查分析和安全事件取证溯源。

2.2数据分析安全

在大数据环境下,企业对多来源多类型数据集进行关联分析和深度挖掘,可以复原匿名化数据,进而能够识别特定个人,获取有价值的个人信息或敏感数据。数据分析安全旨在规范数据分析的行为,通过在数据分析过程采取适当的安全控制措施,防止数据挖掘、分析过程中有价值信息和个人隐私泄露的安全风险。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立统一负责数据分析安全的岗位和人员,负责整体的数据分析安全原则制定并提供相应技术支持。

组织建设要求和数据脱敏过程域中组织建设要求类似,这里不再赘述。

制度流程:

制定数据处理与分析过程的安全规范,覆盖数据清洗、转换、加载、构建数据仓库、建模、分析、挖掘展现等方面的安全要求,明确个人信息保护、数据获取方式、访问接口、授权机制、分析逻辑安全、分析结果安全等内容。

建立数据分析安全审核流程,对数据分析的数据源、数据分析需求、分析逻辑进行审核,以确保数据分析目的、分析操作等的正当性。

采取必要的监控审计措施,确保实际进行的分析操作与分析结果使用与其声明的一致,整体保证大数据分析的预期不会超过相关分析团队对数据的权限范围。

建立数据分析结果输出和使用的安全审核、合规风险评估和授权流程,防止数据分析结果输出造成安全风险。

技术工具:

在针对个人数据的大数据分析中,组织采用多种技术手段以降低数据分析过程中的隐私泄露风险,如差分隐私保护、K匿名(K-Anonymity)等。

记录并保存数据处理与分析过程中个人信息、重要数据等敏感数据的操作行为。

提供组织机构统一的数据处理与分析平台,并能够呈现数据处理前后数据间的映射关系。

人员能力:

能够基于合规性要求、业界标准对大数据安全分析中所可能引发的数据聚合的安全风险进行有效的评估,并能够针对分析场景提出有效的解决方案。

以下是我们在数据分析安全过程中具体落地实践的内容。

对数据分析过程中能够涉及的活动尽可能多的进行风险评估,对权限进行限制,去除数据分析结果中的敏感信息等。具体内容如下:

1.应明确定义数据获取方式、访问接口、授权机制、数据使用等内容,明确数据分析工具使用的算法,以及该算法如何具体使用数据,使用哪些数据,并对算法本身进行风险评估,以确定该算法输出的分析结果不会涉及到用户个人隐私和组织的敏感信息。如数据来源验证、接口token、分析算法输出结果的内容分析等。

2.应明确哪些人员可以使用数据分析工具,开展哪些分析业务,限制数据分析工具的使用范围,根据最少够用原则,允许其获取完成业务所需的最少数据集。

3.应制定数据分析结果审核机制,采取必要的技术手段和管控措施,保证分析结果不泄露敏感信息。如规定数据分析的结果需经过二次评估后才允许导出,重点评估分析结果是否与使用者所申报的使用范围一致。

4.应对分析算法的变更重新进行风险评估,以确保算法的变更不会导致敏感信息和个人隐私的泄露。

5.应明确规定数据分析者不能将分析结果数据用于授权范围外的其他业务。

6.应选择具有个人信息去标识化的数据分析工具,确保能够断开这些信息和个人信息主体的关联。

7.应对数据分析过程进行日志记录,以备对分析结果质量和真实性进行溯源,确保数据分析事件可被审计和追溯。

2.3数据正当使用

大数据时代,数据的价值越来越高,容易导致组织内部合法人员被数据的价值吸引而违规、违法的获取、处理和泄露数据。该过程域基于国家相关法律法规对数据使用和分析处理的相关要求,通过对数据使用过程中的相关责任、机制的建立保证数据的正当使用。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立相关岗位或人员,整体负责组织内身份和权限管理。

组织建设要求和数据脱敏过程域中组织建设要求类似,这里不再赘述。

制度流程:

采取措施确保数据使用和分析处理的目的和范围符合国家相关法律法规要求。

建立数据使用正当性的内部责任制度,保证在数据使用声明的目的和范围内对受保护的个人信息、重要数据等数据进行使用和分析处理。

技术工具:

依据数据使用目的建立相应强度或粒度的访问控制机制,限定用户可访问数据范围。

完整记录数据使用过程的操作日志,以备潜在违约使用者责任的识别和追责。

人员能力:

负责该项工作的人员能够按照最小够用等原则管理权限,并具备对数据正当使用的相关风险的分析和跟进能力。

以下是我们在数据正当使用过程中具体落地实践的内容。

对数据的使用要有明确的权限授权管理,数据使用目的必须遵守国家相关法律法规和行业安全规范。数据访问权限严格控制最小化并建立惩罚措施,对过程进行审计记录。具体内容如下:

1.应建立组织的数据权限授权管理制度,明确授权审批的整个流程以及关键节点的人员职责。

2.基于国家相关的法律法规(《网络安全法》、《个人信息保护法》等)要求及组织数据分类分级标准和处置方式等,对数据使用进行严格规范管理。如,当使用个人信息时,必须征得个人信息主体的明示同意。

3.数据授权过程应遵循最少够用原则,即给与使用者完成业务处理活动的最小数据集。

4.应定期审核当前的数据资源访问权限是否合理。如,当人员岗位调动或者数据密级变更后是否对访问权限及时进行了调整,避免数据不正当使用。

5.应建立数据使用的违规处罚制度和惩罚措施,对个人信息、重要数据的违规使用等行为进行处罚,强调数据使用者安全责任。

6.应配置成熟的数据权限管理平台,限定用户可访问的数据范围。

7.应配置成熟的数据使用日志记录或审计产品,对数据使用操作进行记录审计以备责任识别和追责。

2.4数据处理环境安全

数据处理的安全是指如何有效的防止数据在录入、处理、统计或打印中由于硬件故障、断电、死机、认为的误操作、程序缺陷、病毒或黑客等造成的数据库损坏或数据丢失现象,某些敏感或保密的数据可能被不具备资格的人员或操作员阅读,而造成数据泄密等后果。本过程域设定就是为组织机构的数据处理环境建立安全保护机制,提供统一的数据计算、开发平台,确保数据处理的过程中有完整的安全控制管理和技术支持。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构内设立的统一的岗位和人员,负责数据处理环境安全管控。

组织建设要求和数据脱敏过程域中组织建设要求类似,这里不再赘述。

制度流程:

数据处理环境的系统/平台的设计、开发和运维阶段均制定了相应的安全控制措施,实现对安全风险的管理。

建立数据处理环境(如大数据平台)的安全管理规范,明确数据处理分析的数据采集、存储、处理、导出、删除等方面的安全要求。

大数据加工平台建立分布式处理安全策略和规范,对外部服务组件注册与使用审核、分布式处理节点间可信连接认证、节点和用户安全属性周期性确认、数据文件鉴别和访问用户身份认证、数据副本节点更新检测、及防止数据泄露等方面进行安全要求和控制。

建立分布式处理节点间可信连接策略和规范,采用节点认证等机制来确保节点接入的真实性。

建立分布式处理过程中数据文件鉴别和访问用户身份认证的策略和规范,确保分布式处理数据文件的可访问性。

建立适合数据处理环境的数据加密和解密处理策略和密钥管理规范。

技术工具:

数据处理平台与数据权限管理平台实现了联动,用户在使用数据平台前已获得了授权。

基于大数据处理平台的多租户的特性,对不同的租户保证其在该平台中的数据、系统功能、会话、调度和运营环境等资源实现隔离控制。

建立数据处理日志管理工具,记录用户在数据平台上的加工操作,以备后期追溯。

针对基于云平台的数据处理平台,需保证各工作节点的功能稳定,实现对工作节点的伪装风险监测、恶意篡改风险监测。

记录用户在大数据平台上的加工操作以备后期追溯,提供数据在平台上加工计算的关联关系以保证对数据源的有效追溯。

建立分布式处理过程中的数据泄露控制机制,防止数据处理过程中的调试信息、日志记录等不受控制输出导致受保护个人信息、重要数据等敏感信息的泄露。

人员能力:

负责该项工作的人员了解在大数据环境下的数据处理系统/平台的主要安全风险,并能够在相关的系统设计、开发阶段通过合理的设计以及运维阶段的有效配置规避相关风险。

以下是我们在数据处理环境安全过程中具体落地实践的内容。

平台化、分布式的安全处理环境已经成为趋势,构建统一的访问控制策略,各分布式处理节点之间采用身份认证等措施,保证可信接入。对整个处理环境进行加解密管理,同时对所有的操作行为进行审计记录。具体内容如下:

1.应建立统一的数据计算、开发平台,在平台上实现统一的安全管理措施。

2.应通过数据处理平台进行统一管理,采取严格网络访问控制、账号和身份认证、授权、监控和审计来保证数据处理安全。

3.应建立分布式处理节点间可信连接策略和规范,采用节点认证来确保节点接入的真实性。

4.应建立分布式处理节点和用户安全属性的周期性确认机制,确保预定义安全策略的一致性。

5.应建立分布式处理过程中数据文件鉴别和访问用户身份认证的策略和规范,确保数据文件的可访问性。

6.应建立分布式处理过程中不同数据副本节点的更新检测机制,确保这些节点数据拷贝的完整性、一致性和真实性。

7.应建立分布式处理过程中数据泄露控制规范和机制,防止数据处理过程中的调试信息、日志记录、不受控制输出等泄露受保护的个人信息、重要数据等敏感信息。

8.应建立数据处理环境的数据加密和解密处理策略和密钥管理规范。如对于应用层可采取SSL证书形式加密、对于存储可采取AES等对称加密等。

三、总结

DSMM之数据处理安全主要内容就是上述四个部分,侧重对数据的后生命周期的安全管理。大数据时代,海量数据的处理安全直接决定数据整体安全,个人隐私信息和重要业务数据更是重中之重,稍有不慎,很可能对组织单位带来毁灭性的影响。

虽然在文中,很多制度和技术工具是分开叙述,但是在实际工作中可能是混在一起的,同时很多具体实现的部分也不仅仅只是应用在一个过程域或者一个生命周期阶段,甚至可以应用在整个生命周期过程中。比如数据处理环境安全过程域,制度和技术工具都是要求要构建统一的平台,在平台上实现统一安全管理。再比如对数据访问权限的管理,不仅仅是在数据脱敏、数据分析安全、数据正当使用、数据处理环境安全这几个过程域有要求,在其他各阶段,采集、传输、存储等也有相应要求。另外,现在都是大数据时代了,相应的安全管理和技术也要提升,切实贴合大数据业务,真正做到大数据安全。同时,也利用好大数据技术服务于安全,提升安全能力,做到安全大数据。只有这样相辅相成,才能做好当前大数据时代的安全。

以上就是DSMM数据处理安全过程的要求以及我们在实际落地执行过程中的一点心得和体会,希望能够给有真正有DSMM需求的组织和人员带来一点儿启发,也欢迎大家和我进行沟通交流,多提宝贵意见!

*本文原创作者:LJ_Monica,本文属于FreeBuf原创奖励计划,未经许可禁止转载

此为DSMM的续篇…..

前段时间整理了DSMM的相关内容,分成了数据安全能力成熟度模型总结与交流、数据采集安全两部分。

DSMM开篇交流

DSMM数据采集过程安全

今天介绍DSMM另一阶段的具体内容——数据传输安全。

一、背景

在DSMM数据安全能力成熟度模型总结与交流一文中介绍了DSMM针对数据安全不同生命周期提出了不同的安全要求,数据安全生命周期分为采集、传输、存储、处理、交换、销毁。今天来聊一聊数据安全生命周期的第一个阶段——数据采集安全。

在第一篇文章中,我们讲述了DSMM分为5个成熟度等级分别为:非正式执行、计划跟踪、充分定义、量化控制、持续优化;安全能力的维度包括组织建设、制度流程、技术工具、人员能力。我们在落地执行的时候一般按照等级3即充分定义级进行相关的工作,因为在充分定义级里面完整的包含了安全能力维度的四个方面,而等级1和等级2是没有覆盖完全的,至于等级4和等级5就是进行一些量化细化和持续改进的,可以在DSMM体系建设完成后进行拔高。每个过程域都是按照这样的思路进行要求的,所以接下来介绍的数据传输安全过程的各过程域都是按照这个思路进行建设的。

二、定义

数据传输安全是对数据进行网络传输的安全的管理,这是数据安全重要的阶段,也是发生数据安全事件,如数据泄露、窃取、篡改等比较频繁的过程,所以该阶段的重要性不言而喻。该过程包含四个过程域,分别为:数据传输加密和网络可用性管理。

2.1数据传输加密

官方描述为根据组织机构内部和外部的数据传输要求,采用适当的加密保护措施,保证传输通道、传输节点和传输数据的安全,防止传输过程中数据被截取所引发的数据泄漏。

数据在通过不可信或者较低安全性的网络进行传输时,容易发生数据被窃取、伪造和篡改等安全风险,因此需要建立相关的安全防护措施,保障数据在传输过程中的安全性,而加密是保证数据安全的常用手段。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立了管理数据加密、密钥管理的岗位和人员,负责整体的加密原则和技术工作,由各业务的技术团队负责实现具体场景下的数据传输加密。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

建立数据传输安全管理规范,明确数据传输安全要求(如传输通道加密、数据内容加密、签名验签、身份鉴别、数据传输接口安全等),确定需要对数据传输加密的场景。

建立密钥管理安全规范,明确密钥生成、分发、存取、更新、备份和销毁的流程和要求。

技术工具:

有对传输通道两端进行主体身份鉴别和认证的技术方案和工具。

有对传输数据加密的技术方案和工具,包括针对关键的数据传输通道统一部署传输通道加密方案(如采用TLS/SSL方式),及对传输数据内容进行加密。

有对传输数据的完整性进行检测并执行恢复控制的技术方案和工具。

有对数据传输安全策略的变更进行审核和监控的技术方案和工具,已部署对通道安全配置、密码算法配置、密钥管理等保护措施进行审核及监控的技术工具。

已建设密钥管理系统提供数据的加密解密、签名验签等功能,并实现对密钥的全生命周期(生成、存储、使用、分发、更新、销毁)的安全管理。

人员能力:

了解主流的安全通道和可信通道建立方案、身份鉴别和认证技术、数据加密算法和国家推荐的数据加密算法,基于具体业务场景选择合适的数据传输安全管理方式。

负责该项工作的人员了解数据加密的算法,并能够基于具体的业务场景选择合适的加密技术。

以下是在数据传输加密过程中具体落地应该重点关注的内容。

1. 建立数据传输安全管理规范,明确数据传输安全要求(如传输通道加密、数据内容加密、签名验签、身份鉴别、数据传输接口安全等),确定需要对数据传输加密的场景。

2. 需要加密的场景应该根据国家法律法规要求、行业监管部门要求及单位自身业务数据的保密性和完整性要求。结合数据分类分级的内容,通常包括但不限于系统管理数据、鉴别信息、重要业务数据和重要个人隐私等完整性和保密性要求高的数据。

3. 由于加密技术的实现都依赖密钥,所以需要建立密钥管理安全规范和密钥管理系统,明确密钥的生成、分发、存取、更新、备份和销毁的流程。即什么安全级别的数据,应该采取什么加密算法(国密算法还是国际算法,对称加密算法、非对称加密算法还是哈希算法)以及使用多少位强度的密钥,密钥的有效期是多久,怎么备份密钥,怎么删除密钥等一系列内容。

4. 在选择加密类型及密钥强度时需要结合业务类型和网络现状,有选择地实行加密,避免对业务造成影响。

5. 对于负责加密策略配置和密钥管理的人员,必须有一个审核监督机制,确保其加密算法的配置和变更都是得到授权和认可的,目前通常采用堡垒机的方式进行监督管理。

2.2网络可用性管理

官方描述为通过网络基础链路、关键网络设备的备份建设,实现网络的高可用性,从而保证数据传输过程的稳定性。

数据在网络传输过程中依赖网络的可用性,一旦发生网络故障或者瘫痪,数据传输也会受到影响甚至中断。

DSMM标准在充分定义级要求如下:

制度流程:

在关键的业务网络架构应考虑网络的可用性建设需求,对关键的网络传输链路、网络设备节点实行冗余建设。

技术工具:

部署负载均衡、防入侵攻击等设备进一步强化对网络可用性风险的防范

人员能力

负责该项工作的人员具有网络安全管理的能力,了解网络安全中对可用性的安全需求,能够根据不同业务对网络性能需求制定有效的可用性安全防护方案。

以下是在数据采集安全管理阶段具体落地应该重点关注的内容:

1. 对关键业务网络的传输链路、网络设备节点进行冗余建设。包括:硬件冗余(电源冗余、引擎冗余、模块冗余、设备堆叠、链路冗余、设备冗余、负载均衡)、软件冗余(链路捆绑技术)和路由冗余(VRRP、动态路由协议)。

2. 借助负载均衡、防入侵攻击等安全设备来降低网络的可用性风险。

三、总结

DSMM之数据传输安全其实就是为了保证数据从前端采集之后到业务处理系统之间传输过程的安全,主要的目标就是实现数据保密、防篡改和高可用,对网络安全的要求也是基于数据加密和网络冗余可用。

虽然在文中,很多制度和技术工具是分开叙述,但是在实际工作中可能是混在一起的,同时很多具体实现的部分不仅仅只是应用在一个过程域或者一个生命周期阶段,甚至可以应用在整个生命周期过程中。比如要求对重要或敏感数据进行加密存储和传输,在生命周期各阶段都适用。

以上就是DSMM数据传输安全过程的要求以及我们在进行实际落地执行过程中的一点心得和体会,希望能够给有真正有DSMM需求的组织和人员带来一点儿启发,也希望对DSMM感兴趣的小伙伴一起来交流,并给出一些意见,共同将DSMM做的更好。

欢迎私信我一起交流网络安全相关的内容!

*本文原创作者:LJ_Monica,本文属于FreeBuf原创奖励计划,未经许可禁止转载

上个月投稿了DSMM数据安全能力成熟度模型总结与交流,主要简单地介绍了DSMM的内容以及个人的思考,作为DSMM的开篇交流。今天是从数据安全的生命周期阶段介绍DSMM的具体内容。

一、背景

在DSMM数据安全能力成熟度模型总结与交流一文中介绍了DSMM针对数据安全不同生命周期提出了不同的安全要求,数据安全生命周期分为采集、传输、存储、处理、交换、销毁。今天来聊一聊数据安全生命周期的第一个阶段——数据采集安全。

在上一篇文章中,我们讲述了DSMM分为5个成熟度等级分别为:非正式执行、计划跟踪、充分定义、量化控制、持续优化;安全能力的维度包括组织建设、制度流程、技术工具、人员能力。我们在落地执行的时候一般按照等级3即充分定义级进行相关的工作,因为在充分定义级里面完整的包含了安全能力维度的四个方面,而等级1和等级2是没有覆盖完全的,至于等级4和等级5就是进行一些量化细化和持续改进的,可以在DSMM体系建设完成后进行拔高。每个过程域都是按照这样的思路进行要求的,所以接下来介绍的数据采集安全过程的各过程域都是按照这个思路进行建设的。

二、定义

数据采集安全是数据安全生命周期的第一个过程,是对数据来源安全的管理,这是整个DSMM能够落实好的基础阶段,所有的后续工作都是以此为基础。所以该阶段的重要性不言而喻。该过程包含四个过程域,分别为:数据分类分级、数据采集安全管理、数据源鉴别及记录、数据质量管理。

2.1 数据分类分级

官方描述为基于法律法规以及业务需求确定组织机构内部的数据分类分级方法,对生成或收集的数据进行分类分级标识。

数据分类分级是数据采集阶段的基础工作,也是整个数据安全生命周期中最基础的工作,它是数据安全防护和管理中各种策略制定、制度落实的依据和附着点。

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立负责数据分类分级工作的管理岗位和人员,主要负责定义组织机构整体的数据资产分类分级的安全原则以及相关能力提供。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作,数据分类分级也是这样的要求。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

建立数据资产分类分级原则、方法和操作指南。

对组织机构的数据资产进行分类分级标识和管理。

对不同类别和级别的数据建立相应的访问控制、数据加解密、数据脱敏等安全管理和控制措施。

建立数据分类分级变更审批流程和机制,通过该流程保证对数据分类分级的变更操作及其结果符合组织机构的策略要求。

在建立制度流程的时候,首先应要建立组织/公司自己的的数据分类分级原则和方法,将数据按照重要程度进行分类,然后在数据分类的基础上根据数据安全在受到破坏后,对组织造成的影响和损失进行分级,如果组织层面已经具有相关的分类分级标准,可酌情进行参考。在实际执行时如果一下子做不到完全细粒度区分,可以多步实现,循序渐进,不要设计过度复杂的方案。在进行数据分类分级后需要有针对性地制定数据防护要求,设置不同的访问权限、对重要数据进行加密存储和传输、敏感数据进行脱敏处理、重要操作进行审计记录和分析等。在进行分类分级工作中要明确相关内容和操作流程的审核和审批机制,保证数据分类分级工作符合组织的分类分级原则和制度要求。

技术工具:

建立数据分类分级打标或数据资产管理工具,实现对数据资产的分类分级自动标识、标识结果发布、审核等功能。在技术层面需要建立数据管理平台,按照数据分类分级原则和制度要求对数据打标签,进行数据分类和分级区分,并依据此设置访问控制策略和加解密策略,还要能够对新增数据根据要求进行自动打标签处理。

人员能力:

负责该项工作的人员应了解数据分类分级的合规要求、能够识别哪些数据属于敏感数据。

在编制数据分类分级的制度时可以参考以下关键点:

1.png

下面给出我们在进行分类分级时制定的一个模板,欢迎提出更好的意见。

2.png

2.2 数据采集安全管理

官方描述为在采集外部客户、合作伙伴等相关方的数据的过程中,需明确采集数据的目的和用途,确保数据源的真实性、有效性和最少够用等原则要求,并规范数据采集的渠道、数据的格式以及相关的流程和方式,从而保证数据采集的合规性、正当性和执行上的一致性,符合相关法律法规要求。

数据采集过程中涉及包含个人信息及商业数据在内的海量数据,现今社会对于个人信息和商业秘密的保护提出了很高的要求,需要防止个人信息和商业数据滥用,采集过程需要信息主体授权,并应当依照法律、行政法规的规定和与用户的约定,处理相关数据;另外还应在满足相关法定的规则的前提下,在数据应用和数据安全保护见寻找适度的平衡。

数据采集.jpg

DSMM标准在充分定义级要求如下:

组织建设:

成立组织机构的数据采集安全合规管理的实体/虚拟团队,负责制定相关的数据采集安全合规管理的制度规范,并推动相关要求、流程的落地。

设立组织机构的数据采集风险评估小组,对具体业务场景下的数据采集进行风险评估并制定改进方案,组织机构负责数据安全合规的团队提供对各业务团队风险评估小组工作的咨询和支持。

数据采集安全管理在组织机构设置方面包括两部分:数据采集安全合规管理团队和数据采集风险评估团队。这两个团队分别负责制定数据采集安全合规管理制度并落实和对数据采集阶段进行风险评估。

制度流程:

制定组织机构的数据采集原则,定义业务场景的数据采集流程和方法,明确数据采集的目的、方式和范围。

明确数据采集的渠道及外部数据源,并对外部数据源的合法性进行确认。

明确数据采集范围、数量和频度,确保不收集与提供服务无关的个人信息和重要数据。

组织机构内建立数据采集的风险评估流程,针对采集的数据源、制度、渠道、方式、数据范围和类型进行风险评估,对涉及采集个人信息和重要数据的业务场景进行进一步合规评估。

明确数据采集过程中个人信息和和或重要数据的知悉范围和安全控制措施,确保采集过程中的个人新和中友好数据不被泄露。

数据采集安全管理的制度规范需要包含三方面内容:一是明确数据采集的目的、用途、方式、范围、渠道等;二是建立数据采集的风险评估流程;三是明确数据采集过程中的个人信息和重要数据的安全控制措施。

技术工具:

在涉及数据采集的业务系统中建立统一、规范的数据采集流程,以保证组织机构数据采集流程实现的一致性,相关工具应具有详细的的日志记录,确保授权过程的有效记录。

采取技术手段保证数据采集过程中个人信息和重要数据不被泄露。

详细技术工具实现在后面落地重点关注中介绍。

人员能力:

负责该项工作的人员能够充分理解数据采集的法律要求、安全和业务需求,共能够根据组织机构内的业务场景提出针对性的解决方案。

以下是在数据采集安全管理阶段具体落地应该重点关注的内容:

法律要求

采集的数据及采集过程严格按照《网络安全法》、《个人信息安全规范》等相关国家法律法规和行业规范执行。

基本要求

a) 采集的数据信息,包括但不限于数据、文本、文件、图片、音频和视频等;

b) 采集数据的的传输方式,包括但不限于有线通讯传输、无线通讯传输和数字通讯传输等方式;

c) 数据采集者(信息系统服务方)应设置专人负责信息生产或提供者的数据审核和采集工作;

d) 数据采集者(信息系统服务方)应明确数据来源、采集方式、采集范围等内容,并记录存档;

e) 数据采集者(信息系统服务方)应制定标准的采集模板、数据采集方法、策略和规范,采集策略参数配置应包括采集周期、有效性、检测时间、入口地址和采集深度等;

f) 对于初次采集的数据,应采用人工与技术相结合的方式根据其来源、类型或重要程度进行分类;

g) 最小化采集数据,仅需要完成必须工作即可;

h) 对采集的数据进行合理化存储,依据数据的使用状态进行及时销毁处理。

采集方式

数据采集包括实时监测收集(系统运行数据、威胁数据等)和系统生产基础数据(人员信息、财务账单、采购供应商等)。可包括手工录入填报、权限获取、传感器收集、格式化的数据导入及数据ETL等。

采集周期

数据采集周期分为两种:

1) 对于实时监测数据,采集周期应按照实际工作条件下,系统连续进行10次采集,10次采集时间的平均值作为系统的数据采集周期;

2) 对于系统生产基础数据采用固定期限加动态调整。变化不大的数据信息采集周期为6个月,涉及数据信息变动的调整的可根据需要动态调整。

技术工具

1) 加密:在数据采集前端和采集传输路径安全方面,至少对秘密级以上数据采用加密措施,包括但不限于采集程序本身的加密(如DES、3DES)、传输过程加密(SSL)、网络层加密(VPN)、链路加密(专线)等方式;

2) 完整性:在数据采集前后采取校验码等技术对数据完整性进行校验,包括但不限于:数字签名、Hash算法校验、文件大小比对、人工复验等方式;

3) 匿名:对采集数据在采集和传输过程及存储过程中涉及展示的情景下,对数据进行脱敏和匿名模糊,包括但不限于数据信息替换、数据内容截取、模糊处理等方式;

4) 审计日志:数据从采集开始的整个过程,提供所有采集操作的日志记录,日志记录内容包括但不限于日期、时间、操作类型(动作)、主体(操作者)、客体(被操作对象)、状态等;

5) 断网自动保护:在进行采集的过程中,如遇网络中断,需将已采集的数据缓存在采集前端设备,保证15天内继续对数据进行采集且系统不丢失数据,待网络恢复后自动续传采集的数据。

风险评估

在对数据进行采集的过程中,应组织风险评估小组,对采集过程进行风险评估,评估内容包括但不限于:

a) 采集过程是否合规:是否有采集负责人进行审核等相关采集操作、采集的数据是否最小化、采集等;

b) 采集过程过程安全要求:是否采用了加密、完整性校验、匿名、日志和断网保护等措施;

c) 采集其他相关工作。

2.3 数据源鉴别及记录

官方定义为对产生的数据源进行身份鉴别和记录,防止数据仿冒和伪造。数据源鉴别是指对收集或产生数据的来源进行身份识别的一种安全机制,防止采集到其它不被认可的或非法数据源(如机器人信息注册等)产生的数据,避免采集到错误的或失真的数据;数据源记录是指对采集的数据需要进行数据来源的的标识,以便在必要时对数据源进行追踪和溯源。

鉴别.jpg

DSMM标准在充分定义级要求如下:

组织建设:

组织机构具有负责数据源追溯的团队或人员,提供组织机构统一的数据源管理策略和方案。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作,数据源鉴别及记录亦如是。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

制定数据源管理的制度规范,定义数据溯源策略、溯源数据表达方式和格式规范、溯源数据安全存储与适用的管理制度等,明确要求对核心业务流程的相关数据源进行鉴别和记录。

数据源管理制度规范需要包含两方面的内容:一是要对数据采集来源的管理,包括采集源识别和管理、采集源的安全认证机制、采集源安全管理要求等内容;二是对针对采集的数据在数据生命周期过程中进行数据溯源的管理,把数据流路径上的每次变化情况保留日志记录,保证结果的可追溯,以及数据的恢复、重播、审计和评估等功能。总结为“对来源认证,对变化溯源”

技术工具:

采取技术手段对外部收集的数据和数据源进行识别和记录,即通过数据溯源的机制,保证数据管理人员能够追踪与其加工和计算数据相关的数据源。

对关键溯源数据进行备份,并采取技术手段对溯源数据进行安全保护。

具体的技术手段措施在后面落地重点关注中介绍。

人员能力:

负责该项工作的人员应理解数据源鉴别鉴别标准和组织机构内部数据采集的业务场景,能够结合实际情况执行。

以下为在数据源鉴别和记录阶段实际落地应重点关注的内容:

1) 在进行数据采集时,需要专人或专门团队对数据源进行鉴别和溯源管理,提供数据源管理策略和方案。

2) 在进行数据采集时,需要对数据采集源进行识别和标识。可采取数据标签的形式,确保数据唯一性。

3) 在进行数据采集时,需要对数据采集源进行身份鉴别,防止数据源假冒和伪造。包括但不限于使用用户名/口令认证、指纹识别、人脸识别、动态口令卡、短信(语音)验证码、USB-Key等鉴别方式。

4) 在数据生命周期整个过程中,需要对采集的数据进行溯源管理,将数据每次操作前后的情况和状态进行日志记录和保存,以便对数据进行溯源。可采用源数据管理系统Apache Atlas、数据血缘管理工具Cloudera Navigator Data Management等。

5) 在对溯源数据进行传输和存储时,需要采取加密和完整性校验技术保证数据安全。包括但不限于SSL、VPN、MD5、RSA、RC4等。

6) 在溯源数据过程中,需要对关键溯源数据进行备份,并采取加密和完整性校验技术进行安全保护。

2.4 数据质量管理

官方描述为建立组织机构的数据质量管理体系,保证对数据采集过程中收集/产生的数据的准确性、一致性和完整性。

数据安全保护的对象是有价值的数据,而有价值的前提是数据质量要有保证,所以必须要有数据质量相关的管理体系。目的是保证对数据采集过程中收集和产生的数据的准确性、一致性和完整性。

 数据质量.jpg

DSMM标准在充分定义级要求如下:

组织建设:

组织机构设立数据质量管理岗位和人员,负责制定统一的数据质量管理规范,明确对数据质量进行管理和监控的责任部门或人员。

在DSMM的要求中这个几乎都是一样的,每个过程域都需要指定专人和专岗负责该项工作,并能够胜任此工作,数据质量管理亦如是。在实际工作中,可能所有的过程域在这个维度上都是同样的一个或多个人,可以单独任命,也可以在相应的制度章节中进行说明。

制度流程:

制定数据质量管理规范,包含数据格式要求、数据完整性要求、数据质量要求、数据源源质量评价标准,以及对异常事件处理的流程和操作规范。

建立数据采集过程中质量监控规则,明确数据数据质量监控范围及监控方式。

在数据质量管理制度中需要定义什么是“数据质量”,数据质量的属性一般包括一致性、完整性、准确性和失效性等;要明确数据质量的校验方法,比如校验的层次(人工比对、程序比对、统计分析等)和校验方法(时效性、完整性、原则性、逻辑性等);定义数据质量管理实施流程,比如在产品研制中植入数据质量控制手段、涉及需求、系统设计、开发、测试、发布与运维;制定数据采集质量管理规范,包含数据格式要求、数据数据完整性要求、数据质量要素、数据源质量评价标准等;

技术工具:

利用技术工具实现对关键数据进行数据质量管理和监控,实现异常数据及时告警或更正。

在进行数据质量管理方面需要的技术工具应包括以下内容:一是对数据资产进行分类和等级划分,这个在数据分类分级中已有更好的定义和介绍;二是对在线数据的质量监控,比如针对业务数据库实时产生的数据,这就要求需要对业务数据进行定义并对流程进行改造实现实时监控;三是离线数据质量监控,比如针对数据仓库或数据开发平台的离线数据;四是提供数据质量事件的处理流程,一旦发现数据质量异常及时进行告警和上报,积极采取纠正措施。

人员能力:

负责该项工作的人员对数据质量管理规范有一致性理解,能够基于组织机构的实际数据质量管理需求开展相关工作。

以下是在数据质量管理阶段实际落地中应该重点关注的内容:

1) 对数据质量进行管理要贯穿数据全生命生命周期。

2) 对数据质量进行管理时,需要设置专门的岗位和人员,负责制定数据质量管理规范及对数据质量进行管理和监控。

3) 对数据质量进行管理时,需要对数据完整性进行定义和监控。如人员信息要完整覆盖姓名、性别、年龄等,保证没有遗漏。

4) 对数据质量进行管理时,需要对数据规范性进行定义和监控。如日期信息都以yyyy-mm-dd格式存储,保证数据规范统一。

5) 对数据质量进行管理时,需要对数据一致性进行管理和监控。如同一个人的性别信息在从不同的数据库表中取过来应该是一致的。

6) 对数据质量进行管理时,需要对数据准确性进行定义和监控。如人员信息的年龄应该在0-120,超出此范围即为不合理不准确。

7) 对数据质量进行管理时,需要对数据唯一性进行管理和监控。如同一个ID应该没有重复记录,确保数据唯一不重复。

8) 对数据质量进行管理时,需要对数据关联性进行管理和监控。如两张数据库表建立的关联关系存在,不丢失数据。

9) 对采集数据进行管理时,应尽量避免用户自己输入,尽量提供选择,设定字典表。如人员性别设置男、女选择菜单等。

10) 对数据质量进行管理时,需要设置数据质量校验和监控方法。如人工比对、程序比对、统计分析等。

11) 对数据质量进行监控时,需要设置数据质量异常上报流程。如监控发现-上报-评估-更正-监控。

三、总结

虽然在文中,很多制度和技术工具是分开叙述,但是在实际工作中可能是混在一起的,同时很多具体实现的部分不仅仅只是应用在一个过程域或者一个生命周期阶段,甚至可以应用在整个生命周期过程中。比如要求对重要或敏感数据进行加密存储和传输,在生命周期各阶段都适用,可以一劳永逸。

以上就是DSMM对于数据生命周期第一阶段数据采集安全过程的要求以及我们在进行实际落地执行过程中的一点心得和体会,希望能够给有真正有DSMM需求的组织和人员带来一点儿启发,也希望对DSMM感兴趣的小伙伴一起来交流,并给出一些意见,共同将DSMM做的更好。

*本文作者:LJ_Monica,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

*本文作者:LJ_Monica,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

最近在搞DSMM,问了很多人,也没有具体的、系统的、完整的落地实施方案,也都是在摸石头过河,所以根据自己的理解简单总结下吧。如果哪位朋友在这方面做了一些工作或者对这个感兴趣的,可以一起交流下。

DSMM(Data security capability maturity model)数据安全能力成熟度模型,由阿里巴巴作为主要起草单位编制的一份关于数据安全管理的标准,目前是报批稿状态,即将成为国家标准。反观现在大规模数据泄露事件不断发生,对用户个人和企业都造成了恶劣的影响,导致经济损失,甚至有生命危险,DSMM必将成为各企业数据安全建设的依据指南。

DSMM借鉴能力成熟度模型(CMM)的思想,将数据按照其生命周期分阶段采用不同的能力评估等级,分为数据采集安全、数据传输安全、数据存储安全、数据处理安全、数据交换安全、数据销毁安全六个阶段。DSMM从组织建设、制度流程、技术工具、人员能力四个安全能力维度的建设进行综合考量。DSMM划分成了1-5个等级,依次为非正式执行级、计划跟踪级、充分定义级、量化控制级、持续优化级,形成一个三维立体模型,全方面对数据安全进行能力建设。

下图为引用的标准的模型图:

组织建设:数据安全组织机构的架构建立、职责分配和沟通协作。(数据安全治理的领导决策机构)

制度流程:组织机构数据安全领域的制度规范和流程执行。(数据安全治理的指南)

技术工具:通过技术手段和产品工具落实安全要求或自动化实现安全工作。(数据安全治理的具体实现)

人员能力:执行数据安全工作的人员的安全意识及相关专业能力。(数据安全治理的相关人员)

下图为引用的标准的等级描述:

数据生命周期各阶段

数据采集阶段:组织机构内部系统中新产生数据,以及从外部系统收集数据的阶段。

数据传输阶段:数据从一个实体通过网络流动到另一个实体的阶段。

数据存储阶段:数据以任何数字格式进行物理存储或云存储的阶段。

数据处理阶段:组织机构在内部针对数据进行计算、分析、可视化等操作的阶段。

数据交换阶段:组织机构与组织机构及个人进行数据交互的阶段。

数据销毁阶段:通过对数据及数据存储介质通过相应的操作手段,使数据彻底消除且无法通过任何手段恢复的过程。

注:各个企业在进行DSMM落地时可根据具体的业务场景决定需要经历的生命周期阶段,不一定都会完整经历六个,也可以把其中的阶段进行合并。

每个阶段又细分了几个过程域,再加上一些通用的过程域就构成了数据安全过程域体系,见下图(引用)

在这里我想对标准的起草者提个意见,图中把PA14数据导入导出安全归到了数据处理安全阶段,但是在下面的具体阐述中,又把PA14数据导入导出安全归到了数据交换安全阶段,希望起草者能看到并给个合理解释。我个人理解应归到数据交换安全,然后我们也是这么归类的。

数据作为企业最具有核心价值的资产,一直以来是网络安全工作的重点,所有的安全工作也都是围绕数据安全开展的。DSMM是对数据全生命周期进行安全防护,提高数据安全保护能力,如果都能很好地落地,那么对企业数据安全能力将是极大地提升。

从DSMM的体系来看,在数据安全领域需要“组织-制度-工具-人”这四类能力结合才能更好地实现数据安全治理,当然其他安全这个一个层次架构应用到其他安全方面也是可行的。组织和领导重视安全是第一位,我在甲方安全建设规划那篇文章的讨论区中和很多人都讨论了领导的作用,领导不重视,你就得不到应有的资源支持,所有的规划和理想都只是泡影;再说制度和工具,有人说“三分技术,七分管理”,也有人说“三分管理,七分技术”,这大概是做管理和做技术人互相争夺存在感的一个说辞吧,就好像在论坛中有人说“PHP是世界上最好的开发语言”,马上就会有人站出来不服气,认为Java、C、C++等等是最好的开发语言,我认为不应该厚此薄彼,应该五五开(瞬间想到某鱼游戏主播),两者同等重要,管理是技术的指导,技术是管理的实现,要想做的好,两者皆不可少;最后谈下人,这就涉及太多了,我还记得好像是2017年ISC大会的主题就是“人,是安全的尺度”,安全本质是人与人的对抗,同时人也是影响安全的重要因素,人员的能力决定了安全的高度,人员的意识决定了安全的水平。集齐这四种因素就可以召唤神龙了,就可以将DSMM做好了。

今天就是先简单的聊下DSMM这么个东西,针对具体的生命周期阶段中应该完成的工作内容放在后续的文章中吧。

也希望有DSMM具体落地的或感兴趣的朋友来一起交流,共同提高!

*本文作者:LJ_Monica,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

*本文原创作者:LJ_Monica,本文属FreeBuf原创奖励计划,未经许可禁止转载

一年一度的跳槽季又到了,很多圈内的朋友之前是在安全公司这样的乙方工作,随着年龄的增加,手速变慢,头发变少,身体感觉被掏空。等下,好像有点跑题。那么言归正传,再加上加上家庭的压力,所以很多小伙伴都有跳槽到甲方的想法。

图片.png

0×01背景

这种想法产生的原因无外乎以下几点:

1.当了那么多年乙方,被甲方爸爸虐的体无完肤,也想转变下体会下当“爸爸”的滋味。

2.进入甲方可能会挣的比在乙方多一些,如果是热门行业或者新兴行业说不定还能拿到一定得股权。

3.逐渐有了家庭的压力,希望能够有更多的时间陪陪家人,而不是无休止的给客户加班做项目。

图片.png那从乙方到甲方,虽说都是干安全的工作,但是其实关注的重点是不一样的,有的甚至在面试的时候碰壁,有的勉强面试通过,可是初入甲方,开始新工作后也不适应,也有的伙伴所在公司安全就一人,只要是跟安全相关甚至不想关的工作都必须干。那么甲方安全到底怎么开展?应该做些什么工作呢?

首先,先确定甲方企业安全建设的目标。

甲方企业安全建设的目标就是要实现业务的整体安全,赋能业务产线,将安全从传统的成本中心转变成业务中心(部门),使安全工作可管、可控、可视,最大化的保证业务运行。

围绕这个目标开展以下工作。

0×02企业安全建设的三方面

围绕企业安全建设的目标,应该从技术、管理、合规三个大的方面进行工作开展。

一、安全技术层面:物理安全、网络安全、主机安全(服务器和终端)、应用安全、数据安全(大数据安全)、云安全

二、安全管理层面:安全管理机构、安全管理制度、人员安全管理、系统建设安全管理、系统运维安全管理

三、安全合规层面:信息安全等级保护、GDPR、ISO/IEC27001、BCMS、PCI-DSS等。

图片.png通过对安全技术层面的建设,可以确保企业线上业务的整体技术防护能力达到一个新的高度,形成纵深防御技术架构;通过对安全管理层面的建设,可以形成成熟的安全管理体系,使成功经验变得可复制;通过对安全合规层面的建设,既可以符合国家层面或行业层面的安全要求也可以检查自身是否存在安全风险和短板。三者结合,相辅相成,共同组成了整体企业安全体系,使得企业在安全方面能够实现风险看得见、事件管得住、管理落了地。

0×03企业安全建设的阶段

企业如果在安全方面基本是空白的话,那么可以按阶段、分步骤有序的进行,循循渐进,避免眉毛胡子一把抓,到头来什么也做不好。针对安全工作开展,我总结了以下三个阶段。

图片.png一、“救火”阶段

此阶段重点关注外部安全威胁、关注网络攻击、资产识别、入侵、漏洞、病毒、安全事件的处置和应急响应。

图片.png对于中小型企业或者安全工作刚起步的企业,第一步工作是要做好外部网络攻击的防护,因为此时外部威胁对企业造成的损害远大于内部或其他方面造成的损害。此阶段要以信息系统资产为基础开展如下工作:

Ø  发现识别所有资产,对资产进行分类梳理,查找脆弱点,降低风险,做到资产可控、风险可视。

Ø  购买或采用开源安全设备如防火墙、WAF、IDS/IPS、防病毒、VPN等进行网络、主机和应用层面的安全加固,提升防护的基线水平。

Ø  进行基线配置核查和加固,如口令口令复杂度和生存周期核查加固、访问控制策略(ACL、文件和目录的权限、账户权限)核查和加固、端口开放核查和加固、系统版本核查和升级等。

Ø  开展渗透测试,分为外部互联网访问节点、内网办公节点和业务生产网节点,发现存在的脆弱点,有针对性地进行加固。

二、稳定阶段:

此阶段重点关注内部安全和数据安全,同时不断更新完善外部安全。包括终端安全、上网行为管理、数据安全各生命周期、安全审计、SDLC、攻防演练平台(红蓝军对抗)、应急演练等。

图片.png当第一阶段取得阶段性成果后,企业业务系统基本能够安全地运行,抵御大部分恶意代码或网络攻击。此时,我们需要将工作重心由外部安全威胁防护转移到内部安全和数据安全层面。俗话说:“家贼难防”,如果出现“内鬼”,那么一切防护措施就形同虚设,而且会造成严重危害。同时,不断完善第一阶段的外部安全防护工作,形成闭环。

1.部署终端安全管控和上网行为管控系统,针对不同的业务部门或岗位职责设置设置不同的安全策略,尤其是掌握高密级数据或核心资料的人员(如财务、高管、运维、人力、开发等)。

2.采用网络准入和域控对接入企业内部网络进行限制,防止非法人员非法接入企业内网进行渗透和数据盗取。

3.对数据各生命周期(数据采集、数据传输、数据处理、数据分析、数据共享、数据销毁)阶段进行安全防护,开展SDLC活动,保证数据安全。

4.对整体网络架构和业务系统及数据系统进行优化,设置冗余架构和备份容灾系统,包括:电力、网络线路、服务器、应用系统、数据备份。

5.考虑安全审计功能,开启设备或系统本身的审计功能以及部署专门的审计设备,对进出网络的流量和行为进行审计,保证发生安全事件后能够溯源追踪,同时为下一阶段做态势感知、威胁情报和大数据分析提供基础数据。

6.关注安全动态,特别是已公布的漏洞、病毒预警等信息,进行验证和复盘,同时对标企业自身进行检查和防护。

7. 建立攻防演练平台,开展红蓝对抗。目的是提高内部人员安全技术能力的同时也提高业务系统的安全性,培养人员和发现安全风险一举两得。

8. 制定应急预案,并定期进行应急演练,包括模拟实际业务中断和沙盘推演或桌面演练。

三、提升阶段:

此阶段重点是精细化和可视化的安全运营。基于前两个阶段的安全建设和能力提升,实现安全业务工作的常态化和可视化。包括:构建可视化的态势感知平台、ISOC、SRC(安全应急响应中心)、威胁情报库、自研安全系统(WAF、完整性检测及防篡改、堡垒机、资产管理、漏洞扫描平台等)、安全比赛、安全教育培训、合规等。

图片.png前两个阶段将外部安全和内部安全进行了整体建设,安全能力水平基本上达到了优秀水平,那么为何还要进行这个阶段呢?这个阶段就是提升和拔高的阶段,就是要将安全能力进行聚合并向外输出,将安全这个传统的“成本中心”向“业务中心”进行转变。同时,实现安全的终极目标:安全可视化和安全工作日常化。

1. 利用前两阶段的日志和审计信息、告警信息、运行信息、收集的漏洞、病毒信息、设备的运行信息等构建企业自身的安全管理系统(SOC)和态势感知系统以及威胁情报系统,并将结果再次输入到企业安全建设发展工作中去,形成良性循环。

2.组建安全应急响应中心(SRC),对内部和外部进行开放,以获得更多的安全情报和安全体检,发现业务更多的安全风险,丰富自身的态势和威胁情报系统。

3.开展自行研发安全系统工作,这个时候为了更大程度提高安全防护水平,需要针对具体的业务系统自行研发有针对性的安全防护系统,加固业务安全。比如自行开发WAF、防篡改、堡垒机、资产管理和漏扫系统。

4.主办或承办安全比赛,开展安全培训工作,提升知名度吸引更多的安全人才,同时将安全能力向外输出,获得经济收益。

5.开展各种国家或行业层面的安全合规工作,比如等保、GDPR、PCI-DSS等,确保符合法律法规要求。

0×04安全技术

安全技术是企业安全建设的基石,只有将安全技术的各个方面都覆盖到,才能保证不会出现业务安全短板。

图片.png

物理安全:物理访问控制、防雷、防潮防水、防静电、防火、温湿度控制、电磁干扰(电磁屏蔽)、电力供应、物理防盗防破坏、监控等。

物理安全可以说是所有业务系统安全的支撑,如果在物理层面发生安全问题,那将是将是直接性或者毁灭性的打击。物理安全基本上说的就是机房或数据中心的物理层面的安全,尤其是防潮防水和防火方面,因为之前做项目见识了太多的机房被水侵蚀和被火侵蚀的案例,直接造成了大量的经济损失,甚至是刑事责任。其他方面参照机房建设标准严格执行,并落实到位。

网络安全:链路冗余、带宽和设备性能、系统版本升级、CDN、高防、流量清洗、安全基线配置、ACL规则细化、IDS/IPS、WAF、审计(网络审计、数据库审计)、边界安全、远程访问加密、资源监控等。

网络作为业务系统运行的桥梁和通道,其安全的重要性不言而喻。虽然随着安全设备的部署及安全防护水平的提高,传统的网络攻击变得门槛更高,但是安全攻防永远是进行互相博弈的,不能放松。在网络安全层面需要从从可用性、完整性、保密性三方面进行建设。

可用性:设置冗余链路,保证业务不因运营商的事故而中断;保证带宽和网络设备的吞吐量能够满足业务高峰需要,避免出现网络拥堵和瘫痪的情况。

完整性:设置详细的ACL、配置IDS/IPS、waf、审计等设备,保障数据在网络中不被非法篡改。

保密性:提供网络加密设备如VPN或加密机等,确保在网络传输过程中对数据进行加密,不被非法窃取。

主机安全:身份鉴别和认证加强(堡垒机和多因子鉴别)、账号权限控制、文件权限分配、安全审计、冗余备份、防病毒、资源监控限制、远程访问限制、端口和服务关闭、完整性和入侵检测、系统版升级、终端安全(准入、安全管理、DLP)等。

主机安全方面,做好自身安全基线核查和自身加固,为业务运行提供高效、安全、稳定的计算环境和存储环境。

应用安全:基于web的安全包括防sql注入、xss攻击防御、CSRF及SSRF攻击防御、文件上传、文件包含防护、越权防护、逻辑漏洞防护、敏感信息泄露防护等。基于APP的安全包括:数据传输加密、代码混淆、加壳、完整性校验、身份认证等。

在应用层面,建议开展SDL工作,从系统生命周期全面考虑安全。同时,对应用系统采用代码审计和安全测试两方面,最大化发现各种安全漏洞。针对OWASP Top 10漏洞和常见的其他漏洞检测和防护这里不一一细述,以后可以做个专题。

数据安全:遵循DSMM涉及数据采集安全、数据传输安全、数据存储安全、数据分析安全、数据共享安全、数据销毁安全、数据备份恢复安全等。

数据安全遵照数据安全生命周期安全开展建设工作,保证从数据产生到销毁整个链条的安全,不放过任何一个环节。

0×05安全管理

安全管理架构:设置网络安全委员会(领导牵头等)、汇报机制、安全管理机构的支持等。

安全管理制度:制定各种安全管理制度和奖惩措施、构建安全体系。

人员安全管理:从入职到离职的安全意识教育、安全技能普及和提升、安全制度执行和考核。

系统建设安全管理:系统建设工程安全管理(安全设计架构、安全模型建立和评估、安全编码、安全测试等)生命周期的安全管理。

系统运维安全管理:上线后系统运维的安全管理从网络、主机、应用和数据的安全防护来执行安全制度和要求。

图片.png俗话说:“安全是三分技术,七分管理”,可见安全管理的重要性,对于安全管理机构、人员安全、安全管理制度、安全建设和安全运维体系和制度的建立,可以参照ISO/IEC27001等要求。但是安全管理最重要的不是制定许多安全制度,然后束之高阁,而是要能够有效的落地和执行。

以上就是我的一点关于企业安全建设的看法和总结,或多或少会有不足的地方,只要有一点或几点能够对大家带来作用,就不白费我亲手码这么多字。欢迎各位多多指出不足之处并和我进行交流,一起提高,一起进步。

*本文原创作者:LJ_Monica,本文属FreeBuf原创奖励计划,未经许可禁止转载

*本文原创作者:LJ_Monica,本文属于FreeBuf原创奖励计划,未经许可禁止转载

2018年,欧盟发布实施了GDPR,一时间引起了轩然大波,先后一些科技巨头公司纷纷被控诉举报违反GDPR,遭到罚款处罚。本文主要是结合条例和日常工作,做一个简单的分析总结。

一、什么是GDPR

GDPR,英文全称:General Data Protection Regulation,中文翻译为:通用数据保护条例。是欧洲联盟的条例法规,其前身是欧盟在1995年制定的《计算机数据保护法》。

内容就是针对近年来用户隐私被泄露造成的一系列问题,要求对欧盟所有成员国个人信息进行收集、存储、处理及转移等活动时,要按照要求,采取技术和管理手段对个人敏感隐私数据进行保护。

二、适用范围

条例原文:

1.本条例适用于在欧盟内部设立的数据控制者或处理者对个人数据的处理,不论其实际数据处理行为是否在欧盟内进行。

2.本条例适用于如下相关活动中的个人数据处理,即使数据控制者或处理者不在欧盟设立:

(a)为欧盟内的数据主体提供商品或服务——不论此项商品或服务是否要求数据主体支付对价;

(b)对发生在欧洲范围内的数据主体的活动进行监控。

条例本身比较不好理解,总结一下就两点:1.欧盟成员国的相关企业和组织在对个人数据进行处理时要遵守该条例。2.不属于欧盟成员国的企业组织(比如咱们中国的企业)只要提供的商品或服务以及相关项目涉及到了处理欧盟成员国的公民个人数据就也必须遵守该条例

三、违规处罚

条例规定,对违反法规的企业、单位或组织的罚金最高可达2000万欧元(约合1.5亿元人民币)或者其上一年全球总营业额4%的金额罚金,两者取其最高。

是的,你没听错,也没有看错,如果违反相关规定就是要罚这么多,这么重的处罚对一个公司或单位必将是重磅的一击,一般的公司或单位可能根本经受不了这么重的处罚,大公司的心肝也是颤抖的。

在GDPR刚实施后不久,一些国际巨头公司如Facebook(脸书)和Google(谷歌)等遭到了举报和投诉,成为GDPR法案的第一批被告。一些公司甚至直接关闭了针对欧盟用户的业务。

四、国内动作

在有了Google这样的大公司被罚的先例后,国内企业也加快了对GDPR学习和执行的步伐,紧锣密鼓地进行着,生怕也上了被罚的名单。同时,国内近几年不断爆出用户个人隐私信息被泄露的消息,大量的个人信息流经黑市,也因此出现了一系列冒名顶替、电信诈骗等刑事案件。可以预判,国内网络安全监管机构很有可能效仿欧盟,照搬或者自己出台相关法规,加强对公民个人信息的保护。

五、条例重点分析

那么,对于企业或者说企业的安全负责人,如何来实施相关措施来保证符合GDPR的相关规定呢?在这里,我分享下我个人的见解。

1.数据处理原则

要求企业在进行数据收集、存储和处理时要提供收集的目的用途、存储的时间、收集的方式、收集的数据类型、存储和处理数据的安全技术保障措施、数据操作审批权限、取得用户同意、签订契约以及针对儿童的相关条件等等。

企业在进行用户数据的相关活动中必须要了解上述内容要求,并作出相关承诺,在收集之前就要提供类似用户隐私声明一类的内容,同时明确自己的责任和义务。

2.禁止的特殊类型数据

除GDPR法规第9条、第10条例外规定的情形,其他情况下应禁止处理这些特殊类型的数据,包括:种族或民族出身、政治观点、宗教或哲学信仰、工会成员身份、基因数据、为了特定识别自然人的生物性识别数据、和自然人健康、个人性生活或性取向相关的数据等以及涉及犯罪定罪与违法相关的个人数据。

企业在进行用户数据处理时一定要明确这些禁止的特殊类型数据,除非符合法规规定的例外情形,否则千万不要试图去收集和处理这些数据,以免受到影响。

3.数据主体访问权

数据主体应该具有或者说企业应该提供给数据主体访问个人信息的处理目的、数据类型、数据接收者和接收者的类型、存储的期限和依据标准、数据来源信息、数据转移保障措施等。

不管是系统提供的隐私说明或是签订的合同必须能让数据主体或用户能够随时访问到这些信息,只有这样才能保障数据主体的访问权。

4.数据主体更证权

数据主体要能够或者说企业应该提供给数据主体对其个人数据更正和完善的权利。

当个人信息被收集、存储和处理时,要提供相关接口和入口让数据主体或用户随时能够对自己的个人数据进行修改,比如常见的用户个人中心,可以对个人的资料进行修改更新。

5.数据主体擦除权(被遗忘权)

除条例第17条21(3)规定的情形,企业要提供给数据主体或用户擦除其个人数据的权利。

大部分企业提供的应用或服务不会让数据主体或用户直接删除个人数据的,基于此,可以提供接收数据主体擦除请求的通道,帮助用户擦除一些不再必要的数据。

6.数据主体限制处理权

当数据主体对个人数据的准确性有争议、认为处理是非法的、为了提起法律辩护等情形时,企业要提供给用户限制处理权。

当发生这些情况时,用户如果提出要求不让企业继续处理其个人数据时,企业必须接收,停止对其个人数据的处理,可以采取冻结账号及切断和其关联的所有活动。

7.数据携带权

数据主体要能够或者企业应该提供将已经经过整理、普遍使用和机器可读的数据无障碍地从一个数据控制者到另一个控制者。

就是说企业收集、处理的用户数据要进行格式化整理,并且能够支持格式化导出且机器可读。

8.数据主体反对权

当企业为了一些直接营销的目的,而未经数据主体或用户同意的情况下直接使用与其相关的用户画像时,数据主体或用户有权反对。

无论采取管理手段或技术手段,在使用用户画像进行营销之前都必须征得用户同意,以免造成不必要的影响。

9.合规认证

企业要进行相关的隐私认证,积极参与GDPR合规认证,选择有资质的、规范的认证机构,而不是简简单单随便找个“所谓的隐私认证机构”或自认证,通过之后将徽章资质放到官网上面,一定得是GDPR的认证且是权威认证机构。

10.签署协议

无论数据控制者或者数据处理者,在对个人数据进行处理时,必须签订保密协议。以及在涉及对用户数据进行共享、传输和处理时与第三方或其他合作方进行合作时,必须签订相关的协议,明确责任,确保个人数据的保护得到应有的保证。

11.数据处理安全

企业在对数据进行收集、处理等活动时应该采取如下安全措施保证个人数据安全。

数据脱敏技术:要对个人数据进行匿名化。

数据加密技术:要对个人数据在存储和传输过程中进行加密。

数据完整性技术:要对个人数据在存储和传输过程中的完整性进行校验,避免被篡改。

数据访问控制技术:要对个人数据设置合理的访问控制策略,避免未授权访问和不正当的访问。

数据备份技术:要对个人数据进行备份,保证可用性。

数据恢复和响应技术:要对个人数据及时进行恢复和响应测试,确保恢复和响应的可行性。

12.设立数据保护官

企业需要雇佣设立专门的数据隐私保护官员来监督GDPR的执行,以及对涉及的个人数据进行相关的安全防护。

以上,就是我结合GDPR相关条例和我工作当中实施执行的相关分享和心得总结,当然还有很多小的细节没有一一列出来,大家可以以这个为参考继续去详细了解法规内容。以上纯粹个人理解,如有不当之处,请留言或私信我,一起交流,一起提高。

*本文原创作者:LJ_Monica,本文属于FreeBuf原创奖励计划,未经许可禁止转载