0x1本周主题

主题一：市场上有没有成熟的产品可以识别并展示组织的网络安全风险？

问：目前市场上有没有成熟的产品可以识别并显示组织的网络安全风险？如果风险方面有不足之处，请帮忙补充。 （想到的风险包括：漏洞、端口异常开放、业务异常开放、中间件经常暴露漏洞、使用开源组件、缺乏必要的安全防护措施、代码泄露、敏感信息泄露、供应链风险等.)

A1：从这些功能来看，都是比较相似的。现在金融业的供给侧管理实施得怎么样了？

A2：这些是外部暴露的风险。如果想评估一个公司的安全状况，还可以了解一些供应链安全管理的思路，看看内部安全和流程安全，比如是否有专门的安全组织和内部运行机制。

A3：你说的是完整的风险评估。我们主要是想从外部的角度建立一个组织的风险观。

A4：只要你有这些风险探针，能收集数据，剩下的就够买个BI工具，自己做两次开发做报告了。困难的是如何收集这些风险数据。风险认知不全面、不准确、不及时。说到底，它只是一个态势感知大屏，一个向领导和来访者炫耀的形象工程。

A5：我理解，为了安全运营，不就是要把所有的风险都梳理出来，然后一一解决吗？所以大家应该都已经实现了，而且市场上应该有很多这样的产品。

A6：我这么多年用过的最有效的大型监控屏幕其实就是减法。正常状态下没有任何信息。只要有信息出现，就必须立即处理，必须清屏。

A7：两个角度，一个从外部，一个从内部。

A8：从行业实践来看，攻击面管理作为威胁识别的第一个输出，至关重要。如果错过了攻击面，无论后续的措施有多强，都无法覆盖，所以这是一个很好的问题。

无论是20年前还是最新的书籍，都会提到安全资产管理。还记得之前君哥在讲这个问题的时候，特别提到了公众号等容易被忽视的资产（攻击面）。我没有考虑到这一点，所以当时的思维导图给我的印象特别深刻。它不仅包括域名、IP、端口、API、中间件、供应链、漏洞等传统资产，还包括账户、数据、权限等容易被忽视的资产。我可以在公众号和书籍中看到这些内容。

从我自己的实践来看，确实，安全态势感知是企业的要求、必然性，也是我们的价值输出。传统资产最常见的就是定期主动扫描。例如，如果地址池中多了一个活跃IP地址，则需要响应端口、接口、指纹等。同时也需要相应的管理要求和卡点。尝试在卡点处更新白名单。

除了主动方法外，被动监测也是一种有效的对比方法作为补充。此外，还有一些假冒网站、暗网情报、泄露和爬行感知等内容，需要定期人工研判，也在监控范围之内。这样，攻击面管理就基本成型了。

接下来我觉得主要还是靠攻防演练，因为你自己做威胁识别的时候，无论你经验再多，也只是一个推演。尚未经过实战测试。如果你进行演练，你可能不会发现有些人在外面拥有经过身份验证的公司帐户。某个团队购买了奇维SaaS服务……这些可能构成攻击面，需要通过实战进行迭代。

金融为何难打？我认为关键的区别在于我们注重结果，能够落实管理方法，能够支持业务投资。归根结底，攻击面小，所以很难战斗。也就是说，这个现状，都是战斗造成的。

因此，我的结论也得出：虽然有产品可以帮助我们节省一些重复工作，特别是互联网监控部分，通过采购社会总成本较低，但如果想用一个产品来映射所有的自己公司的风险，地图还是不现实。产品必须通用才能产生社会效益并生存。这是规则。甲方只能在普遍性的基础上叠加自己的个性。做一些开发和集成可能会更好。

主题2：贵公司对强密码的具体要求是什么？例如： 1. 大写字母、小写字母、数字、特殊字符：您从四个中选择三个还是都满意？ 2. 密码不能与过去五个密码更改周期内的密码相同？

A1: 还有一件事，任何系统的初始密码都必须更改，否则某些服务的默认密码是相同的，尽管它们是强密码。 1是的，大多数人默认都遵循这一点。二高一弱有弱密码规则的解释，可以作为基础。

A2：建议添加额外的规则，比如……满足第一个复杂度要求，但还是容易爆炸。

Q：如果大写字母、小写字母、数字、特殊字符都满足的话，有要求的来源吗？从四个中选择三个。事实上，满足复杂性要求的弱密码有很多，比如键盘顺序。有什么规则禁止这样做吗？

A3：我们现在拥有的内容如下：

A4：这也行不通。需要使用强密码，并且不能重复过去使用过多次的密码。有些人因为记不住密码而将密码写在便利贴或记事本上，这会带来新的风险。

问：金融现在有推广刷脸识别登录系统吗？

A5：密码复杂度系统写起来很容易，但是自动检测并禁止它确实很难，无论是开发者的意识还是算法本身。弱密码仍然是当今最大的安全风险。

A6：是的，我们现在维护统一身份认证部门的规则，并在设置时检测它们。多种因素也可以达到这个目的。银行的取款和查询密码只有6位，更多的必须通过其他方式保证。银行不要求用户使用强密码，多重身份验证就足够了。

A7：人脸只能作为辅助认证。必须综合考虑业务场景和用户体验，安全性不能太极端。现在如果是一个不安全、只有密码认证的金融产品，我会很担心它是否安全。安全现在是必须的。微信、支付宝每次启动都可以直接使用，无需用户感知的额外身份认证步骤。这不是很棒吗？安全性是让用户感觉不到的。

A8：微信、支付宝底层非常安全，反正大家都信任。因此，如果国家推行统一的身份认证，比如使用微信、支付宝，那就更方便了。现在银行也支持面部识别。

A9：现在有些人要求按键不能串联，以避免键盘串联字典爆炸。这就需要有基本的安全基础，后端需要投入很多基础能力。这不是一般企业能够满足的，然后通过增加用户壁垒来妥协。

A10：仅支持单点登录认证。这是一项非常成熟的技术。 SSO可以支持弱口令排除、验证码、短信验证。如果没有，可以通过绑定常用设备等方法。而且SSO依赖于统一的认证平台，不需要收集太多的用户信息。

A11：密码策略是基础。参考政策的力度也差不多。无论多强，都会影响体验。密码策略是包含特殊字符、数字、大小写，仅此而已。而如果你现在看的话，符合这个规则的密码都是弱密码，因为它们在列表中。

话题3：我想问一个问题。 A是一家2C公司，拥有用户手机号码。 A与B合作，需要传输手机号码。然后：1.哈希（手机号码）2.加密（手机号码）。

问：从技术和实用角度来看，没有太大区别。从法律角度看，有什么区别？

A1：直接咨询公司法务部感觉比较权威。现在很多都不是直接传递的，尤其是金融的。看来与碰撞相关的手机号码都是直接加密的。取决于电话号码是否需要解密，如果不需要，哈希就足够了。

A2：哈希不属于加密。如果你愿意并且有计算能力，你可以将所有号码的手机号码进行散列，形成字典，然后将截获/泄露的散列手机号码进行碰撞来恢复，这样散列就无法保证。数据机密性只能用于验证数据的完整性和一致性。

A3：使用Hash时，添加Salt很难恢复，碰撞也很难。加密意味着可以解密，这是不一样的。从法律的角度来看，哈希也可以通过碰撞来恢复。

A4：都需要证明。加密需要证明密钥存储和交换的可靠性。对于插件KMS来说，Hash需要证明你的哈希算法的不可逆性。

A5：HASH算法是标准的并且已经被证明的。有人创建了自己的算法吗？这与技术无关。比如你泄露了1000万条数据，包括姓名、假名手机号、假名银行卡号，假名无论是对称的还是散列的都是一样的，不会因为你说是就认为是错的一个哈希值。可能会给顾客带来不良影响。

如果我知道你的算法和盐，并且知道你的算法和密钥，那么条件是相同的。即使每个客户都有一个单独的密钥，成本要高得多，但它仍然是假名的，而不是匿名的。

A6：算法可以理解，但是Salt很难。主要原因是散列存在撞库风险，因此欧洲GDPR、美国FTC以及中国的个人保护法均不认为无盐散列是法律意义上的匿名数据。

A7：salt是必须的，算法一般使用or。盐用于验证密码。这是盐，传送给对方的字段毫无意义，根本不可能合作。

A8：法律意见是，由于A把密钥给了B，B有能力逆向，所以加密并不是去标识化个人信息，风险比给Hash要高。

A9：这是对称加密。但如果你的法律事务部门说散列是不可能的，那么你应该使用散列。

A10：所以，我提到从技术角度来看没有区别。您对法律实践有何看法？哈希确实有一个借口。名义上是不可逆的，穷举是技术手段。当哈希值达到一定数量时，任何加密都可能被破解。

A11：有直接可逆和不可逆之分。由于手机的位数是固定的，所以用空间来换取时间。如果不是手机号码，有人说手机号码范围太窄了。这不是技术问题，而是法律实践问题。每个人都知道技术的影响。

A12：在法律实践中，请询问法务部门。确实，这是一个责任问题。从我们的法务部门和我接受的认证培训来看，您的情况很常见。对方无需借助额外手段即可定位到特定个人，不构成去标识化。改变。

Q：首先判断是否是为了防止B或者通讯被第三方窃听？如果是前者，那么添加加盐哈希就没有意义了。如果对方有盐和彩虹表，就可以逆转B本身。您有这些用户的手机号码吗？是为了匹配用户，还是为了获取手机号码的明文？如果B没有手机号码数据，并且不想让B知道，那么传递手机号码字段有什么意义呢？

A13：他不防b。我了解他需要b返回一些风控信息之类的。本应被视为假名的内容，但最终被视为去识别化/匿名化。法律事务部门听取法律事务。如果是我，我不会评论。我最多会在中间添加一些手段，比如添加一层标记化。施放50%毒药等等。

A14：换句话来说，这里的目标是，如果A想要和B交互，需要发送他的手机号码，哪个法律风险最低？

A15：这仍然是哈希值，但不是 md5。有私人约会吗？

A16：我的义务是：即使b的裤子被脱掉，密文密钥被拿走，我仍然有办法保护客户的隐私。

问：了解企业的​​需求很重要。例如，B需要知道手机号码吗？或者它只是一个代号？

A17：是的，添加一层标记化意味着给出一个代号。如果您决定它是去识别化和匿名的，则根本不需要这样做。匿名是不可减少的。如果不需要恢复，也不想做识别，直接创建一个对应的Hash和数字表，交给对方即可。这样别人去碰数据库就没用了。

A18：那么有没有专业的产品可以解决这个问题？这不正是联邦计算的意义所在吗？还有同态加密。

A19：你所说的是以手机号码作为标签的。在实际业务中，需要使用原始手机号码来发送短信等。只有加密通道传输就足够了，可靠传输。但涉及个人隐私，应告知用户。

Q：如果是这个业务，是否可以只给出手机号码，不给出用户名，做成单一元素？

A20：我认为法律界有意见认为，理论上，无法对应到没有外部能力的个人的单因素手机号码，不应该算作个人信息。确实有一定道理，但一般还是参考金标，根据个人信息进行管理比较好。

A21：我们已经就此事咨询了监管部门。只有单一元素是个人信息，但不被视为个人敏感信息。转换的界限非常模糊。它是一堆数字中毫无意义的数字。刚买房的人的标签属于敏感信息。判断并不那么机械。

主题四：请问在各种防病毒技术下，内部如何防止终端中毒？

A1：白名单，执行程序白名单去匹配哈希等，操作起来会很累。各种白名单和与互联网隔离的终端中毒概率极低。

A2：加入白名单是理所当然的事，不上网是事后的想法。两者都是有效的，而且两者结合起来威力更大，但是却无法避免各种安全介质的抄袭。

A3：提前做什么？

A4：你可以获取信息什么的。当你不再在线时，中毒的危害就集中在勒索软件和蠕虫上。远程控制已经可控了，再把程序列入白名单，复制到嘴里风险就小很多了。

A5：禁止USB、禁止外部网络、禁止程序白名单、禁止USB白名单。三大杀手解决99%的内网问题。

A6：没有办法禁止，总有业务需要抄进来。事实上，除了敲诈勒索带来的危害和少数人漏网索取第三方专线网络之外，实际危害并不大。但我经常看到我们在外展方面确实无能为力。

A7：这意味着中毒、扫雷，并利用结果来限制生意。您是否实施了程序白名单？

A8: 很难，不可能，而且数量太大。就算收集起来也很头疼。每次软件更新时，都必须重复进行哈希匹配。有复印机，有专门的摆渡系统，系统自带防病毒，但无助于躲避防病毒。

A9：不上网就不存在所谓的杀脸病毒。无法上网+程序白名单，如何免杀进入。如果可执行，则不在白名单中，不允许执行。换句话说：如果你不能上网，不杀人就进不去，也无法对外连接。此时只剩下蠕虫和勒索软件了。

A10：在没有互联网连接的情况下，通过其他媒介感染的病毒不具备高级的防病毒能力，也不存在多种病毒的可能，因此没有防病毒能力。至于银行，控制应该到位，稍微推动一下应该就能做点什么吧？

A11：白名单很难，但隔离是必要的。无法通过C2传播的病毒危害相对可控。当然，有些顽固的蠕虫病毒也有可能利用内网漏洞，但防病毒软件毕竟不是免费的。

A12：防病毒是下一步的准备和前提。如果互联网已经被禁用，没有了与外界接触的可能，那么防病毒的意义基本上可以被忽略。

A13：加密数据段直接释放勒索不可行吗？

A14：有可能，但是这种一次性病毒的成功率极低，除非是裸机。没有绝对的安全。

A15：AV+EDR 异构是您的解决方案。如果这还不能缓解焦虑，那么唯一的解决办法就是白名单。非异质的人都在抱怨，到了一定程度就卡住了，但异质的人就会发疯。或者升级换内存或者SSD。

问：进一步来说，您如何确定如何向程序中添加白色？尤其是对于操作系统来说，每一次配置往往都需要一个额外的过程。当EDR拉出列表时，如何筛选哪些是正常的并查看签名？

A16：先安装一个干净的，加全白，然后覆盖正版软件。当然，这个干净的里面不能有任何微软虚拟机云盘什么的。你必须粗略地看一下。如果无法连接到互联网，也不是主要风险。

A17：但是不同配置下可能会不一样，比如刚才的RDL服务。如果分组做得比较好，还可以全局添加美白。毕竟，您要防止的是病毒，而不是授权。

A18：主要是征求意见，看看难度如何，然后考虑轻重缓急。

A19：点数越多难度越大，版本越多难度越大。但在银行，这并不罕见。你已经被禁止上网了，还有人中毒。如果领导不接受这个风险，那我们就得提供解决方案，或者提前控制入口。如果入口无法控制，只会发生这种情况。

A20：这个里面也有一台标准机。除了8和8.1之外，我们基本上还有其他各种尺寸的版本。

A21：可以考虑先从入口开始尝试，同时推推第一道防线的责任。一旦除去第一线责任，你可以通知他们，你就可以把它和麻烦结合起来。别乱来。如果合并一个责任，也许就能在入口处控制住。最好不要把服务和管理绑在一起，至少名义上，职责是分开的。

A22：这个问题无法回避。就“最低要求”的必要性而言，无论是做服务还是管理。

A23：循序渐进，先使用互联网白名单，然后慢慢禁止外部网络，然后对白名单进行编程，创建互联网白名单。基本上局部AV+EDR的延迟会减少很多。太多的滞后无非就是外部连接问题。更多的东西进来，触发更多的扫描。

A24：有外网和USB管理，但传统的三级解决方案是白名单。白名单与黑白加白的方式也缺乏对抗效果。还有一些项目还没有实施，我们只能尽力而为。如果没有外部c2，PS无文件的这种可能性就不存在。

主题5：请告诉我哪个统一日志审计平台更好？ （XXYi的SIEM平台太贵了。）

Q：有没有邀请大数据分析厂商收集分析日志的案例？

A1：开源elk+；免费麋鹿付费。

A2：elk有本地化要求，但我不敢再用了。

A3：这样的人不也是这样做的吗？或者通过SOC平台做统一的日志审计？

A4：最初我想通过SOC来访问，但是SOC需要访问这些日志，额外的主机和存储资源以及日志解析和报警功能都比较昂贵。我就想着找一家做大数据分析的公司看看能不能做。他们在字段解析、存储和查询方面有更多的经验。

问：你们的SOC厂商如何进行系统日志分析和报警？

A5：一般是允许厂家自己写规则，但也支持视野分析，所以常见问题不大。解析日志或实现它们非常简单。有些制造商做了更多的调整，有更多的现成规则，而另一些制造商则较少。经验丰富没有问题，主要是厂家服务能跟上。

A6：我见过某联盟、某服务器的日志审计平台。只有主机上安装了插件才能解析。它们都无法解析，因此您必须编写自己的规则。如果你在主机上安装插件，你不觉得还不够麻烦吗？

A7：一般不配置，直接发送到日志服务器即可？

A8：不可以，无法解析。需要适应。这意味着您需要单独调整规则。

A9：规则分析肯定是需要的，但是大多数厂家基本都支持通用的。有了AI，帮助编写解析语句是相当方便的。我看了上面两家公司，他们都支持。不过看场景的话，需要安装控件来支持。你必须编写自己的规则。

问：厂家支持写规则吗？

A10：我们不需要安装在SOC端，直接发送到服务器端即可。

A11：感觉他们只是做了存储和简单的查询。如果以后要发出警报，没有日志分析是无法完成的。国内的过于依赖厂商来适应和制定规则。调整数据源可能需要几天时间。结构化的还可以，但是当我遇到很多非结构化的时，有些会让人困惑或者根本不支持。

A12：应用系统的日志解析非常麻烦。如果应用系统是自主开发的，则可以统一字段和格式。