0x1 本周话题TOP3
话题1：咨询个敏感数据链路跟踪的问题，如下图，APPKEY之间互相调用的关系比较复杂，在trace的时候，就很难知道字段级的链路了。这个问题我知道也是业界难题，就看看大家有啥方法？
A1:简单链路场景下可以appkey之间抓包…如果有10W+，也不是不行，就是成本跟收益不对等。
A2:这里指的不是服务链路调用关系，是敏感字段级别的。对api打标了，用的规则库和扫描db的敏感数据规则库相同。api的req和rsq，这对于api和db当然没问题，但无法trace出调用关系了。
比如根据一些业务标签对应一些api的标签然后与敏感数据资产查分，看百分比。这就首先要有标签，其次再有api输出的明细，最后逐行在DB对比，活也很大。
A3:有个做法是拿到内部各类存储介质的元数据，从源头表开始做字段关联匹配，串出链路流转；还有个办法就是拿mysql-hive的sql做解析，a字段从mysql落到hive中映射的字段是什么可以从sql中看出来。
目前能想出来的就这两种，不过在复杂环境下做这个活就很累了，因为内部环境很复杂五花八门啥都有，tracing不好做（我理解在我们安全场景下也只是个使用方，这块更多是基础架构的活）
A4:hive这部分倒是不难，用atlas hook 增删查改，但有2个难点是：
-
-
trace建立关系没有问题，但是要跟踪字段级关系，还是有难度的，本来trace就是采样数据，存在漏报的可能。还有trace只是req，没有rsp，误报也比较大
另外有rsp也行，抽样200条扫敏感信息，得去试试看能不能搞到rsp。结合加密一起，appkey未经审批备案，就不应该有明文敏感数据。
A5:我们尝试用iast在测试环境打最后接近db的那一层API信息，用iast获取db、table、字段和分类分级关联，对API打标，然后利用一些有trace系统的反推链路调用链，有点像倒推java调用栈差不多的意思，把最外层的API抓出来。单纯扫req、res前期搞搞还可以，到后期运营维护成本比较高。
据多家台湾媒体报道，11月25日，包括中国台湾头部券商元大证券在内的多家券商的交易系统，疑似遭到了黑客的“撞库攻击”，大量客户的证券账户被自动“下单”、批量买入港股。
撞库失陷，券商需要承担多少百分比的责任呢？想请教大佬，这种情况下，法律上支持入侵阶段的交易为合法交易吗？
A1:券商此类案例太多了，去年不就有同花顺，搜到的客户的起诉，法院认为客户全责，券商无责。还有的是第三方揽客，让大家注册，拿你的密码直接看规律撞，一样是客户全责。虽然指责券商为何没异地登录识别、二次检验、风控拦截的声音层出不穷，但也没有证据表明券商没给客户提示和选择，终究是客户没保管好自己的凭证。如果有券商担责的案例欢迎讨论。
“更为诡异的是，首位发帖的投资者明确表示，11月25日，自己并没有购买港股，也没有开港币或外币帐户，但证券账户中的交易纪录显示，确实在当天下午3点购买了深蓝科技控股的股票”—没开账户都能买，就不是撞库这么简单了。
客户账号登录有没有商业解决方案呢？自研的系统在这一块好像都没有很好的防护措施。
A2:很多国外机构考虑到用户体验，对密码强度设置没要求，但针对不符合强度的用户，会增设安全问题验证，比如说母亲姓名之类的，或其中一张信用卡的尾号。
针对ip跨市、设备名称、系统版本降低等情况出特殊应答，这个可以提给自研，但小程序、网页、公众号等登录接口各个端都不是统一的，各自实现。
A3:各个业务系统逐步统一到IAM平台进行登录认证鉴权审计，应该是趋势，可以整体上确实能增强安全性，同时降本增效。
那如何推动IAM落地呢？个人觉得30%靠产品，30%流程设计，30%靠审计，10%靠环境复杂度。这仅是B2E IAM，B2B IAM考虑的更多。
IAM的一个服务叫注册应用。有一个iam平台，也有一个应用，怎么把这个应用集成到iam平台上。理想的做法是有人申请onboard，有人落地。这个服务应该是bau，从申请到结束，需要设计一套流程，应用为了快速onboard，在开发的时候就要符合一定标准，iam要维护这套标准。并不是所有应用都需要被iam平台管，只需要一个监管机制，对于没有被iam管理的应用，需要出示证据，证明他复合了iam的监管，只是没有onboard到iam平台。
这样，从iam的角度，这个功能对于企业的合规性的价值才会得以体现，也能够量化的评估他的成熟度。这样，对于iam平台，或者对于某一个小功能的优化，可以从iam整体中单独拿出来进行考虑。可以自研，也可以购买，要做投资分析。
A4:各个层面需求不同，对于入门的统一管理和外网访问控制，单纯这一层不重，可能和国内云，解决方案等深度定制等都有关，还没有催生类似okta单独这块可以做大的企业，比如泛微oa有很多漏洞，如果有统一iam，放在外网也有iam这层可以作为web前置的防护手段，相对账户的统一管理（离职等），以及web漏洞都有一些保障了。统一IAM作为web前置是一个不错的解法，目前已有类似的商业方案，国内现在也有一些零信任方案也在往这个方向做的。
话题3：请教个问题，现在开始建设是搞SOC还是XDR 目前XDR成熟度如何？
A1:衡量这个问题只有一个标准，那就是搞这个能解决你的、安全团队的、公司的什么问题，soc既然是c，那需要一堆的辅助，这些辅助就位没，有没有soc的痛点。 xdr其实是从edr演变过来的，可以说是围绕点扩展的线，如果在这两者之间选，一般选xdr，因为没有终端的soc是缺失的，而且做着就部分实现了siem、soar，不用追词，还是先解决眼下问题。
A2:如今，越来越多的安全厂商宣称能够提供XDR解决方案，数量远远超过了端点检测和响应(EDR)供应商。XDR现在能从更多的数据源收集、处理和分析遥测数据，例如来自云访问安全代理(CASB)、SaaS应用程序和IAM系统的数据。XDR市场不仅厂商众多，而且抱团竞争和对标准的争夺也愈加激烈，网络安全业界如今已经成立了至少3个XDR“联盟”，一个由CrowdStrike领导，另一个由Exabeam、Extrahop、Mimecast、Netskope和SentinelOne等供应商发起，而第三个则基于开放网络安全联盟的标准，参与者包括IBM和McAfee。
随着XDR扩展性和功能迭代不断取得进展，一些安全厂商不再满足于XDR填补中型企业SOC空白市场的最初定位，认为随着组织越来越依赖智能化、自动化工作流和对分析师流程的决策支持来实现其SOC的现代化，XDR完全能够覆盖整个安全运营中心（SOC）技术环境，取代现有的主流SOC技术方案，包括安全信息和事件管理 (SIEM)、安全编排、自动化和响应(SOAR)以及威胁情报平台(TIP)。由于XDR的概念和定位不断演化，虽然每个人都在谈论XDR，但每个人讲的故事却又不尽相同。
再深入讨论XDR与SOC现代化的演进关系之前，我们不妨回顾一下ESG给出的XDR定义：XDR作为跨混合IT架构的集成安全产品套件，旨在对威胁预防、检测和响应方面进行互操作和协调。XDR将控制点、安全遥测、分析和操作统一到单一的企业系统中。
XDR与SOC现代化，XDR在SOC现代化中到底可以发挥什么作用？
在最近的一个研究项目中，ESG调查了339位企业安全专业人员，以下是亮点数据：58%的安全专业人士表示，XDR可以通过增强/改进/聚合当前的安全分析功能来实现SOC的现代化。这当然是XDR的主要任务，通过跨网络杀伤链的数据分析提供高保真警报。这可以通过自动执行一级分析师任务（如警报分类）来实现SOC现代化，从而大幅提高SOC效率和分析师生产力。55%的安全专业人士表示，XDR可以通过与SOAR集成来实现安全流程自动化，从而使SOC现代化。
这个目标几乎没有那么明确。XDR系统编纂了简单的任务自动化（例如将文件哈希与VirusTotal匹配），而SOAR确实是为端到端自动化流程而构建的，甚至集成到ITSM系统中（例如SOAR和ITSM的ServiceNow）。换句话说，XDR和SOAR在今天充其量是松散耦合的，这种情况暂时不会改变。最好的XDR系统将继续执行基本任务自动化，而无需SOAR。37%的安全专业人士表示，XDR可以通过充当查询和调查的数据湖来实现SOC的现代化。这是可能的，也是CrowdStrike收购Humio和 SentinelOne收购Scalyr的原因——两者都是基于云的大数据分析引擎。
尽管如此，许多组织已经在使用SIEM作为数据湖，而且大多数SIEM供应商（即Elastic、Exabeam、IBM、Splunk、SumoLogic等）已经基于云。在这个领域还有大型的、可扩展的、基于云的平台，比如Chronicle和Devo，可以摄取其他数据进行调查和威胁追踪。鉴于此，XDR最终可能更像是一个数据流，而不是数据湖。
总结，因人而异，量力而行。目前来看，大型企业和机构正在同时做两件事：采用XDR技术和对SOC进行现代化改造。XDR用于在整合点工具的同时提高威胁检测效率，而SOC现代化的主题是关于检测即代码、与MITRE ATT&CK保持一致、固化分析师工作流程和端到端流程自动化，在这个进程中，XDR与基于SIEM的运营方案二者有重叠部分，也有冲突部分。
总的来说，XDR将成为SOC现代化的一股不可忽视的推动力量，当下XDR供应商正在忙于开发高级分析、整合新数据源、自动化任务，使用机器学习和威胁情报来关联数据，并将所有不同的数据维度相互关联并针对风险评分，以提供更快、更高保真度的检测，同时减少分析师。正如Forrester所指出的那样，XDR已经开始与SIEM和SOAR发生正面冲突，对于不同安全态势的企业来说，企业需要考虑其长期业务目标侧重点（检测与响应还是合规与运营）和自身安全资源（预算、人才等）来选择这两种不同的技术路径。
曾有人问了一个关于root账号管理的问题：之前由于安全团队没有介入，导致都使用root账号安装应用。现在安全团队感觉这样风险很大，也不符合各种合规要求，虽然和运维团队商量了很久，但他们仍旧不知道如何改变现状。在这种情况下，有没有办法破局？
本周群里共有 150 位群友参与讨论，群发言率为 35.97 %，群发言消息数为916条，人均发言数为 6.10 条。
本周群里共有 83 位群友参与讨论，群发言率为 18.08 %，群发言消息数为314条，人均发言数为 3.78 条。
——————————————————————————–
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
如何进群？
原文始发于微信公众号（君哥的体历）：APPKEY互相调用时，敏感数据链路如何跟踪？现在安全从0到1建设是搞SOC还是XDR？目前XDR成熟度如何？| 总第123周
