安全建设经验

## 0x01 cose. 提问：星主您好 目前本人一直从事甲方网络安全体系建设工作 只有网络基础 不具备攻防基础 略懂一些基础渗透知识 目前一直自己在做一个安全运营中心构建思路 从阶段性分为 基础建设阶段 安全运维阶段 深度感知阶段 自主自研阶段 目前基础建设和安全运维阶段我觉得已经都具备能力 最近一直在思考深度感知阶段要具备未知威胁感知能力 但是目前不知道整体建设框架和思路 如果有好的建设体系 麻烦指教

### 回答

你这个问题很高级，以我目前的甲方安全建设的经验，可能无法给出很好的建议，我也是在这个方向摸索，只能建议你多看一些甲方大佬的演讲ppt，关于安全建设的，对于未知威胁，你说的是目前入侵无感知，还是0day漏洞啥的，问题太宽泛了，不太好说，或者你可以说一下，你目前建设到了什么阶段，自己目前遇到了什么瓶颈，做了哪些东西，还想做哪些，欢迎一起交流！

### 讨论

cose.：我觉得未知威胁感知的方向是不是应向APT这块去研究， 因为目前来看 合规性的东西我们都具备了 例如EDR、态势感知平台等 但是没有体现出真正的效果 EDR的话没有办法结合漏扫进行一个很好的工作  态势感知平台也不尽人意
2019/11/6
myh0st 回复 cose.：有了这些设备需要专业的人来运营，安全事件的处理，哪些是误报，哪些是真实攻击事件，提升自身的入侵检测和应急响应的能力，这两方面又特别依赖资产管理，那个系统有问题，需要找到对应的负责人来确认，中毒以后，需要有能力去排查是否是真的事件，建设期间买设备貌似只要有钱有预算就可以搞定，但是有了设备，事件告警的运营才是考验实力的地方，更需要人才的专业性，否则需要靠乙方的服务，比如安服驻场这些人来运营设备，处理安全事件。
2019/11/6
myh0st：真正出成果的就是运营期间产生的安全事件，处理的安全事件，有一定的感知威胁的能力之后，将威胁处理完，保证相同的威胁不再出现，持续运营，做到闭环。
TsengDuke：我感觉你目前处于外部防护基本完善需要建设内部安全防护体系的阶段，内部安全建设可以参考情报驱动应急响应这个思路，建立内部检测监测拦截机制，收集内部情报，关注内外威胁，做到全方位监测，最后要注意就是，是否有这个预算和人力去维护，以及整个感知体系的目标，我给客户定的目标就是发现已知问题，及时响应，并没有抗apt的意思，最后推荐一本书《网络态势感知：威胁提取理解预测》，明确目标制定计划一步一步完成，越到后面你制定的目标会越来越小，越来越精细

### fw/ngfw

对于防火墙的功能大家选型从业务功能（并发，流量处理，包处理）和安全功能分别考虑哪些因素呢？换个说法，fw/ngfw安全功能方面大家都用些？

技术支持，响应是否及时，比如说发生重大漏洞限时提供补丁，故障响应时间，功能这块，主要是 ACL 和访问日志，还有一些针对特定攻击的检测和防护，比如说伪造源地址、端口扫描之类的， 没啥好选的吧，国外就 cisco、juniper、chackpoint，pa 国内…天融信、天清…等吧，生产还是建议用国外的虚机防拷贝方案

客观来说国外产品整体性能稳定性各方面不错，但如果量不大的情况，国内的也可以，比如山石，天融信等，量不大，山石、天融信尽管用，许多金融企业都在用了，选型建议在厂家报的参数基础上下调 30% 左右

### 设备运维

在下抛一个问题啊，大家觉得要做好安全工作，安全设备的运维职责怎么切分比较好？我们现状是ips waf这些都是网络团队负责，到有不少弊端，想听听大家的意见。

有啥弊端？都可以负责，谁有最高权限，谁就担起该部分的安全风险运营。

网络的人又不一定了解安全 分析WAF、IPS日志肯定困难   即使加上绩效驱动感觉意义也不大

网络就是日常运维，策略、审计安全需要审核和把关，建议把日志弄 SOC 或态势感知上去。

人少的时候挑重点做，考虑的是风险度，从高风险的问题处理，再就是投入产出比，每个方向做到100%挺难，但做到60%-80%其实不需要太大精力

### 齐安信天眼

天眼功能优化，进行了一点点思考，提出来大家指正：

1、天眼告警溯源：天眼联动天擎，在天眼告警信息中显示威胁的文件名称和路径，同时显示威胁文件跑沙箱后的检测结果；联动终端管控和邮件系统，钻取查询文件传输途径，定位最初节点使用人。

2、天眼威胁分析功能优化：天眼威胁大部分为疑似威胁，需要人工排查确认，建议对每一种类威胁标注确认程度（1-5），对每一个告警，用户分析过程中可在告警上加标签（标签方便被搜索到）和批注，搜索引擎支持对告警结果的查询，慢慢形成威胁分析结果的知识沉淀，下一次遇到同类型告警，能够节省分析时间，推动厂商持续优化规则，两者结合，提高告警准确度，提高分析速度和质量。

我对天眼的一点思考就是场景化分析这一块，用的标准版的天眼，提供的三个场景分别是内网安全，账号安全，邮件安全，不同的甲方需要的流量分析场景不太一样，这一块可能需要定制

可以看看上网行为管理里面的一些场景，可以借鉴一些，网康和深信服都有做独立的模块做这类，一般试用上网行为管理试用不全，在上面还有很多的独立模块，很不错

### 日志采集

![](/media/202201/2022-01-17_152056_877683.png)

先接安全设备事件日志，系统安全日志，web 流量日志，系统登录日志，这样基本上外防内控的风险可以最小迭代了

看需要，我们当时的项目把业务日志也收集了，不过一般业务日志主要是做内部风险控制角度考虑去做规则，黑客一般都是直接针对网络设备、服务器和数据库，不过像之前 swift 银行那个案件，黑客不是也掌握银行员工应用系统账户，然后进行分析了么，给后面银行转账、平账做准备

### 安全思考

安全圈，不能只奉攻防、实战为干货，还有很多管理，合规，治理，审计，风控，市场，生态，合作，创新等诸多方面。。。

#### 合作共赢

突然感觉 it 行业做了大量重复的事情，比如 hids 每家都做一遍都踩坑。很多漏扫大家都整合过一次，但这些能力有很难输出。好像也没有啥好办法，利用开源也有很多坑，也有很多做过二次开发，整合内部工具，这些很难复用。目前复用最好的开源文档，你说的这个确实是个资源浪费，如果企业需求相同相近的，可以节省一部分社会资源，不过更难解决的是：各企业的情况和需求可能就不同，需求不同的地方肯定有，但可以复用的应该更多。有持续投入的就没有问题，有很多间歇投入的就浪费了。

以前对成本考虑的很少，曾经在公司忽悠过老板上了一个项目，后面由于技术跟不上，就放弃了。现在感觉挺亏欠老板的。我以前纯做技术的时候，有时候做事情是为了满足技术的好奇心，并没有从整体公司收益考虑问题。所以会走很多弯路。所以我有时候在想是否可以形成一个联盟，免费输出这些技术。这个免费是指不盈利的组织。以前听说过国外的一个大拿做公益，要做头等舱主办方出钱。他的逻辑是我出场费不要了已经是很好的支持公益了

联盟的比较实际的难点在，大家都是有本职工作的，除非公司想挣名声，或者主办方已经财务自由想做点提升整体水平的事，或者有个靠谱的中心来牵头，否则的话，可行性还不如“帮助”乙方做强做完善

#### 安全定位

我是觉得，文字表达能力和真正看到的人可能是两个。文字表达能力强的，在单位里面生冷硬倔，也会被边缘化。安全是得罪人的岗位，得圆滑，又得有底线，还得分清楚哪些重要哪些不重要，主动替业务担待一点。潜伏者和琅琊榜参考一下。得拉同盟，朋友搞得多多的，敌人呢，最后都搞成统一战线好了，安全的真正估值是有钱有势的领导认为你值钱，所以情商太重要。安全搞得好的，都是 cso 情商高，能要到资源，团队也能不停壮大，毫无例外，情商和智商虽是大白话，但没办法。

会写报告的，会写文的，不一定表达强，不一定合群；极可能存在太高傲或自卑的因素

安全不能闭门造车，公司内部能不能信任、业务能不能与安全协调配合，大家愿不愿意为安全成本（不只是直接成本，也包括因为安全而放弃的一些便利性等间接成本）埋单，取决于能不能建立“安全感”以及对安全价值的正确认知下的品牌效应。当业务要冲锋陷阵的时候，安全是在旁边拍拍业务兄弟的肩膀，告诉他“一切别怕，我和你一起”，还是用“千里传音”之术躲得远远的说“我们有最先进的技术、最好的产品，你放心去吧”，当然有时连传音这个事情都省了，安全何在、价值何在？品牌树立很难，信任崩塌很快，且行且珍惜。

除了智商 情商 还有逆境商 ，工作性质不能按照这个维度分类，还要看能力分布 ，如果想锻炼自己的智商、情商、逆境商可以看陈树文老师《领导哲学智慧六讲》

方向型指导。一般同步考虑业务和it战略而实施安全战略。但个人认为最难的还是价值落地。这点上方法论往往误导性大，甚至比不上安全负责人与数据中心研发中心各领导的关系。有些非红线指标尤其如此，故此情商对于安全从业人员的重要性，要合群，除非是监管或风险坐北朝南的企业

情商主要是如下能力：1、自我认知 2、自我控制 3、内驱力 4、同理心 5、社交能力

情商没毛病，结果导向，责任第一，都是情商高的表现。情商不等于耍滑头，推卸责任

问题是责任原则一看企业文化，二要人为树立

安全团队不仅要当医生，检查出系统病症，也得学会开药方医治病患，并时刻跟踪系统病情变化

#### 安全方向选择

选择安全作为工作方向，考虑职业生涯发展，通过自己的努力将来拥有选择的权利，选择有意义、有时间的工作，而不是被迫谋生。当你从事的安全工作方向在你心中有意义，你就有成就感，当你的工作给你时间，不剥夺你的生活，你就有尊严。成就感和尊严，给你快乐。

未来之于我不再是恐惧，而是充满挑战的征途，因为心中有了明确的目标和努力的方向，让我的内心变得亮堂，我知道成功是可期的，而不再是如中彩票般的小概率事件。

“从比较积极的角度看，过早的放弃高 P 路线转向中小企业安全负责人，犹如放弃攀爬一座 1000 米高的山，转而爬一座 600 米的山，会舒服一阵，但会更早的迎来半衰期的中点，更早的迎来下坡路。”特别是这句，从前有个机会放在面前没有珍惜，感触很深

1、要明确安全团队在整个公司的价值和定位。价值就是你在公司独一无二的作用、帮公司解决什么问题，定位就是你和其他团队、部门的关系，哪些干、哪些不干、哪些是合作干、哪些是支撑其他部门。说白了，就是把安全团队的工作边界说明白。

2、我认为管理框架应该在篇章上位于“需求和目标”之后。管理框架是为目标服务的，如果不是，则目标和手段不一致，框架的选择可能存在问题。

3、目标里面最好说明评价方法，做到怎样才是好。规划3年之后回头再看，也有个评价、判断依据。

#### 团队建议

给甲方团队的个人建议：安全可以分两类，一类是做好了不出彩，但出了事责任很大的，这种是团队的基本盘，力保不失。一类是做了可以添彩增加团队地位的。团队需要留大半的精力去保基本盘，因为基本盘不保团队就会挂，但很难让团队有成就感。所以每年还必须结合业务需求，寻找一两个出彩点，投入一些资源去打，给团队在企业更多成长的空间。

低头拉车，抬头看路。团队分四个象限，研发孵化 p，项目建设 d，运营服务 a，持续优化 c。运营是基础，研发学习孵化是为了未来考虑，项目建设是每年的工作。运营服务中间，能外包的运维全部外包，形成运维资源池让外包干，其余的就是各类服务和应急。人员梯队中间，新人从运维服务入手，以后转到项目建设和研发。每年通过项目和应急找机会，数据泄露，拖库，大面积运行故障和病毒事件导致对外服务异常，被篡改，就准备检讨吧。

一个人的安全：和技术部搞好关系，把安全思想灌输给技术

以前我是从各个业务分支挑选一个安全负责人做接口，每周一次5-10分钟的会议，把平台遇到的安全问题做简单沟通，通用问题通用解决

要积极主动，让上级看到你的执行力和落地能力，尽力争取资源，前提是遇到深明大义的上级

领导懂管理就行，懂如何领导更是加分，懂不懂安全，没多大关系。能当领导的都不傻，谁能干活谁是吹牛拍马的，不可能不知道

不懂安全很正常，关键是懂战略和用人，有一定话语权，彼此信任、默契，更重要的是能争取重要资源。

大老板现在抓思想，企业核心价值观，企业文化，小考，大考不断，还写心得

#### 安全人员占比

各位大佬，请教下安全人员配置问题。类金融公司（2000人），IT规模200人，To B 业务为主，To C 业务为辅，有集团监管，只要搞定系统层以上安全。这种情况下，安全人员数量和角色有啥好建议不？

先规划工作，才能确定需要多少人，确实，有平安集团背景，5-10 人应该初步够了，技术和管理人员可按照 1：3 或是 1：4 比例配比

常规 6 个人差不多，开发人员多的话适当上调，主管一人，合规 1-2 人，架构运维技术 3-4 人，其他按业务条线和开发 SDLC 配团队

安全运维的运维部门帮着做，安全规划、安全实施、安全监控和响应，安全合规自己做

看要做多少活吧，如果只是一般的安全评审测试漏洞发现分析与推动这类活，5-10 个人不能再多了。

如果安全设计与安全架构要交付组件的话，那需要有安全开发的人员。

另外就是日常安全测试的活是安全干还是测试干，这个也会消耗比较多的人数。

还有就是搞不搞对外的安全运营，一般TOB安全运营做得相对少，TOC的多。

最低配，1个主管，专门到处PK抢福利，2个安全设计评审，参与开发项目的安全把关，2个安全渗透，到处找揸以及问题修复的推动，1个专门跟进通用的安全问题，如系统补丁，安全规则，事件跟进，对集团推下来的问题单跟进。。。

人少就集中做合规和安全运营，这块人必须保证；然后视人手情况况开展安全设计，安全测试和全面的SDLC；再多人就安全组件服务统一开发。

很多公司跟风成立大数据部门，基础平台基本靠买，合适的应用场景自己也买想清楚，怎么落地也没想清楚，投入肯定没有回报

#### 大数据分析

这里有这么几个问题：1、样本的选择是否具有代表性；2、匿名化是否符合真实的匿名要求；3、有没有以偏盖全的问题？

只要拥有足够多的原始数据，不管个人信息怎么匿名化，我都能给你定位出来是哪个人

那么，这样定位出一个人的成本有多大，带来的价值有多大？另外，我认为也肯定存在这样的技术，只要匿名化做的好，是不可能被还原的。

只要技术成熟，定位一个人和N个人成本来说没啥区别，价值还是看这个信息怎么被使用了

攻击方法是无穷的且变化的，但是做为守方，了解越越深刻，对设计防护措施和优化细粒度越有思路。

企业的资源是有限的，人员的精力也是有限的，重点放到防守上，有余力的研究点攻击，已经强于80％的企业了。在海选过程中，只要自己不是跑得最慢的人，就不怕，但是谨防被盯上，低调一点，各位甲方大佬

重视工具还是要等到人力继续增加的时候才会好些。比如美国工具的使用明显高很多。

#### 护网思考

hw我的几点体验，第一要有人，第二要明确资产，第三要加强监控，判断攻击，第四要及时响应攻击。

hw前一定要加强培训教育，社工很好用，我们自己扫描弱口令就找出来了几十个。

对于安全漏洞造成的危害，可以口语化的描述可能导致的公司用户数据，商业数据泄露，可能带来的pr，业务风险，可能会被竞品公司拿到什么信息，这样的危害对于高层来说更好理解

如果习惯于用技术用语去描述风险，没有安全背景的人往往理解不到问题所在

还有如果安全推不动业务整改时，可以考虑类似hw的方式，邀请外部审计评测机构对公司系统做检查和出具报告。外来的和尚会念经，有时候可以起到助力的作用

### 安全监控

做好流程编排和事件追踪，还有责任人定期追债，我在做监控内容设计和流程编排，想从安全告警的数量、范围、严重程度和对象的重要性级别为维度设计阈值，超过阈值形成告警事件，启动相应的处置机制和跟踪机制。

工作内容和绩效目标需要清晰具体可量化，在一定范围内可灵活浮动，而且有成功案例，否则就是画饼，现在小朋友越来越不好骗了，特别是名校和高学历的，互相之间都会攀比，我自己也是被各种套路骗过来的，一般来说半年到一年，是一个被骗周期，连续两到3个周期如果没有明显改善，就很难留住了

刚刚看到说产品应不应该只告警10条的话题，重点是理解什么叫做告警吧。告警的确只能控制在人能处理的过来的数量。就算你被黑了1万次，你也只能处理你能处理的top N。发出来不闭环的东西别发了，留在log里等数据分析的同学慢慢提炼有价值的吧，哪儿来这么多有价值的告警，攻击尝试几乎没意义，成功的攻击几乎是个位数一年

这是两件事情，真实的有价值的告警与你能处理的过来的告警，你不能说我处理的过来的告警就是N，要混为一谈，就跟咱国内考核自己管辖区内上访次数不出过多少有什么区别呢，哟 照你这么讲 中行这么大系统 有价值的告警一年还个位数，到底是中行的安全水平高还是什么，你不清楚的话我也清楚。输出倒逼输入的方法，用来做学习是好的。

有价值的告警，需要根据组织和业务特点划分范围，分析是有余力的事，不是“该做的事”，比如说安全隐患、违规操作、资产统计不到位的点、不经过安全评审变更上线的内容，

说到这 大家内部入侵类的事件 和内部运维流程是怎么结合的，当成一个普通的事件还是问题

比如前段时间顺丰 华住 数据泄露事件，把这个作为一个告警，那么在这种告警出现之前，之前会出现多少值得分析的内容，多少类告警，多少条告警，涉及多少系统，时间跨度多长。以此来倒逼输入，看看到底在这件事出来之前，我们到底能有多少次机会发现前置告警。我特别想听听在这方面有实践经验的。

以前好像有个啥原理，任何一个事故前面都会有多少条以上的警告被忽略了，对，这些就要看违规和隐患了，就像发生重大刑事案件以后通过追溯案发之前发现踩点一个道理

需要付出行动的，才叫告警。只是分析的，叫做日志。告警一定是人肉可以处理的过来的，否则你根本没人，分析类的不用发告警出来，找个地方存着展示，方便分析人员以及挖掘就够了。

我讨厌把分析类的日志用告警的形式发出来，造成无用信息湮没有价值的信息，并且每一次人肉跟进，不仅仅是你一个安全工程师的成本，上下游一大堆人都要付出努力。我极度鄙视这种行为，本身是自己不专业繁殖的人力浪费而已。

挖掘是挖掘，告警是SOP，是一定有响应和结果的，以现在国内企业安全管理的水平，每年至少出现一次重大事故，以此作为目标去做努力。由此输出去倒逼输入，看看到底有多少有价值的值得分析的。真的每年都没有一次，那我才说安全做的确实好。才给老板说，我们安全做的就是牛逼，就是没有一起。

我是老板，就以每年出现一次重大安全事件，去做考核，没有，说明你不达标，绩效达不到。真的没有，给我证明下你到底做了什么，做的如此牛逼。经不经得起同事，同行，专家的考验。

请蓝军做模拟攻击，提前把风险消除了，或者通过大数据方法，从海量信息分析到隐患，及时干预调整，消除了

互相选择吧，如果管理层是这种思路，大家根本尿不到一壶，何必一起共事呢。这就好比洪水来的时候一个村领导带头抗洪各种奔跑，疏散，堵缺口，一个村平时干得好屁事没有领导啥都没做，你非得要看每年抗洪你出场率是啥，那就真没法了。

### 红蓝对抗

除了蓝队成员以外，理论上所有it人员都是红方，只要有一个人多留个心眼，或者意识比较强，说不定整条攻击链就断了，不过初期肯定不止一条，后面要看业务发展速度，还有安全建设是否能随业务发展，前提是攻击链是否能完整形成，然后看能够影响多少资产，主机，系统，业务，数据……，最后复盘分析原因，也是检验各大厂商防护设备，策略和技术支持响应能力的好时机

首要目标是发现问题，其次是演练防守的实战协作能力，完整的过程这块在符合规则的情况下可以推进，目前就是这么个考虑。

现在的演练还是单点突破，红队蓝队能力靠外协，还没有完整攻击链，以发现威胁为主，可视化展现为辅

小弟觉得演练的目标，是共同承诺，共同承担，责任共识。至于发现多少问题，能有多少优化改进，协作是否更顺畅了，这些只是表象，但也没错，这些便于直接评价和考核。我的不靠谱理解，个人看法哦，可能偏题了 ，通过演练，让个体意识到每个岗位都值得尊重，不要互相鄙视，有了这个前提，才能提高协作

对于内部因公出国所携带的手机电脑是否有检查或者控制手段，换新手机和电脑？----这个只有换新电脑或者新手机是最靠谱的，或者干脆不带。不要想着换硬盘，删除 app，这些鬼子都是有办法的，鬼子在边境也是有权收缴或复制你的设备。翻了好多层楼，只能回答这一个问题。

比如说情报，企业不需要大量的情报数据，而是结合甲方自身情况，只要给我能 actionable 的情报；又如检测技术，只要准确率高的、高风险的、可运营的告警。

### 安全建设

#### 基础安全和运维安全

大家觉得基础安全和运维安全建设范围和着重点、方向有什么主要区别？基础安全应该是包括运维安全的吧

基础安全应该是一个可以保障企业业务正常运转的安全保障体系，往体系上靠可以分为（基础的）运维安全、业务安全、数据安全、终端安全等等，而这些子类其实有其高级版本。所以个人觉得基础安全和运维安全属于两个有交叉的领域，不是前者包含后者的关系。运维安全至少包括物理安全、系统安全（补丁、访问控制）、网络安全（抗D、网络隔离）等，总体上应该是面向基础架构的安全保障的。

网络安全和运维安全，感觉这里的网络安全又是说的比较小的那种了吧，讨论这些也是为了更好的做事情，人员分工定制定则之类的

信息安全->IT安全->运维安全、开发安全->网络安全，之前做27001的时候根据自己情况做的一个划分。

这里的网络安全指的是狭义的概念，网络架构自身的安全、网络访问控制、路由安全等等。

从实务角度看，安全有自身的产品和系统，对应着开发和运维。此类运维是否可做为运维安全的一部分内容，另外运维安全也可包含所有系统运维管控的安全，如用户管理，授权等，主要任务还是识别安全事件并处置。

Cyber security 延伸到国家概念了，网络空间安全的核心是国家主权在网络的扩展，已经不是企业管理能涵盖的了，所以在企业安全里面不适用。

支撑运维安全体系运转的产品（hids/waf等），相关的研发是应纳入运维安全范畴，才能形成闭环

一般所指的网络安全广义概念，是把网络攻击和病毒传播加了进来

IT安全、物理安全、供应链安全，是一个维度。开发运维安全是IT安全下的分支，这样更合理一些。IT、CT、OT这个层面，我理解是技术概念，不是安全活动（要干的事）

做企业安全的话，员工终端电脑安全也很重要，这个是否划分到其他分类去了

#### 建设范围

大佬们讨论的 OA 直接面向互联网  转为双因子验证的方案   由于公司高层略显麻烦  被叫停了  所以应该先给高管们上上强化安全意识的基础知识普及工作

CTO 和 CRO 的职业要划分清楚，CISO 和 IT 的职业要划分清楚，当我看到 Legal 都在安全范畴的时候，就晃了，千万别把自己坑了。

从什么角度构建维度，得看你所在的公司给安全部门的定位。如果只是 IT 下的一个部门，就考虑开发运维安全就好了，别的考虑了就是伤心。

所以我们想去把安全做的更专业，更细致。我们的价值在安全，而不是牵头分派工作

从什么角度构建维度，得看你所在的公司给安全部门的定位。如果只是IT下的一个部门，就考虑开发运维安全就好了，别的考虑了就是伤心。

所以我们想去把安全做的更专业，更细致。我们的价值在安全，而不是牵头分派工作

任何组织都有能力很强的人，把自己部门经营成明星部门，工资待遇全面倾斜，同时又把自己部门保护的很好。再大的公司都是看人定岗，规则是用来推进落地用的武器，有没有这个武器，会不会用这个武器，都分人。

如果老板不清楚我应做什么，我就给老板清楚的告诉部门职责，跟他讨论确定，比如提供3种服务，每种的定义，sla，流程，事件升级，培训，都做成闭环，出了问题，责无旁贷。在范围之外的，一率免责，多做了，兄弟们不能白做，没做到位，任何人也不能说什么。

先救火，顺带观察主营业务，观察主营业务，发现安全缺口大，产能不足，要多加杠杆，安全猛招人，等过几年产能盛，又要供给侧改革，安全全都下岗。

我这几天让基建部门怼的很郁闷，在安全屋里放了个配电箱，需要频繁操作，按理说他有权这么做，我不同意，他不理我。这下好了，需要进门操作了，我发现只有我的人能进，就不给开门，拖了一周了，丫告到全球VP。问我违反规则，我翻了规则，说密钥守卫计划中有一条，密钥守卫者可根据个人经验评估并采取保护措施。

他说灯泡坏了怎么办，着火了怎么办。我说我们都有预案，只有变电箱和这个房间目的不符，说句不好听的，紧急情况下这里面的东西都毁了是允许的。

安全干的很累啊，物理安全有专人负责就可以，只要制定好制度，后期检查审计就可以，要不安全啥都要深入感觉没有关注到重点。

没必要这样怼，做个评估流程领导签字，转移责任；加视频监控，做补偿性控制，基本也就OK了！

这个话题确实有意思，负责基建的是老外，我说拿出去容易吗，他说这不是容易不容易的问题，是需要看到白纸黑字，哪里有写，安全屋里不能放配电箱，我说没有，问题是维修的人现在进不去了，你们着急，我不着急。

大公司复杂就在这里，明明一个下午能搞定的小活儿，非得让新加坡的项目经理协调印尼的基建部门，找欧洲的总包联系中国的施工队，这还不算丫找到了美国西岸的VP，把我东岸的全球安全屋老板拉进来。

哈哈 流程复杂，效率低下，权力分散 大企业病突出，边际成本曲线会随着企业规模扩大而升高，这就是管理成本的大幅提高。管理半径在决策深度上最好不要超过4层，互联网公司从某种意义上讲就是扁平化管理，决策和执行效率快。

我觉得没有创始人的公司，都在被职业经理人玩，创始人和合伙人都还在的一般还行，就创始人在 合伙人全滚蛋的不好说

#### 攻防演练

作为攻防演练，一定是需要有明确的对手，对手的战略目的，对手的能力与持续支持假设的。对抗apt，对抗黑产和内鬼，对抗泄愤的小毛孩，对抗意外事故和天灾.....，攻击者手段，目标都不一样，防守者重点和责任也不一样。

攻击有成本与约束条件，防御也有成本和约束条件。对手的手段，是和这些对手战略意图和，预期收益，成本相关的。就如你不会演练一场假设和蒙古的海战

这次攻防演练并不限方式和手段，只是有说明攻入内网后原则上不能影响信息系统的正常运行

我对演练的看法：任何防御都是有成本约束必然有重点的，演练的目的不是秀出各种不计约束条件和成本突破的技巧，而是从攻击者视角（这个词一直被做攻防的曲解为攻击技巧或能力，攻击者视角是围绕自己战略目的，在各种成本约束条件下找到的最经济的突破路径可能），而防御者则根据自己的核心防御目标，责任确定自己最佳的（能力和责任、经济平衡）防御策略

比如演练保护领导人出行的安保，你担心坏人埋伏在高楼窗口打狙击，但演练保护节日大规模人群的恐袭安保时，理论上坏人也可以埋伏在高楼窗口打狙击，但却很难成为你防范的重点（无论对你和坏人，这种模式成本收益都不大），你更担心自杀炸弹，近距离扫射这些大规模杀伤的威胁，虽然理论上高楼窗口打狙击的手段依然存在，扮演攻击者的人依然可以用这种方式证明你的安保还是有漏洞。

如果没有针对性的演练，就只是一场大规模的脆弱性检查，用巨大的成本找到一些脆弱性，但很难给组织提供更上层的最佳防御策略的依据，价值有限。

对国家关键信息基础设施来说，被控制拿权限，怎么都是不可接受的红线，此外还有窃取用户数据，破坏可用性，都不在此次演练范围内，就是拿权限，攻击路径是线上攻击，原则上不允许物理攻击，但前提是自己能发现和举报，这限制手段和黑客没有本质区别，没有让从内网进行攻击，范围还不够明确吗？

1.这次hw只针对cii吗？cii现在范围明确了吗？2.如果是cii，那假想敌就是境外apt。对cii来说，对抗国家级apt，是一个组织独立的责任还是？组织的防御目标边界和目标是什么？

在统一安全策略下防护系统免受外来有组织的团体、拥有较为丰富资源的威胁源发起的恶意攻击、较为严重的自然灾难和其他相应程度的威胁所造成的主要资源损害，能够发现重要的安全漏洞和安全事件，在系统遭受攻击损害后，能较快恢复绝大部分功能。

不敢提反制。前期通过疯狂增加防护投入，能够增加攻击成本，让攻击方知难而退，就很难得了。后续可以适当控制防护成本，维持一个攻防相对平衡的状态。说白了，你不愿意费劲打我，我也就睁一只眼闭一只眼。但是你一旦打我，我就不惜成本跟你拼命。反正谁也不能把谁怎么样，日子凑合过吧。

溯源就是一个网络版的抓小偷过程，理论上肯定能抓住，但和现实抓小偷一样，一是价值低，警察不愿管，二是成本高，一般人耗不起。三是没有执法权，第三方不配合。反制就是抓到小偷后胖揍一顿，处理的好叫正当防卫，处理不好就是滥用私刑

#### 日志分析

第一阶段叫siem，第二阶段叫soc，第三阶段叫态势感知，其实干的是同一件事，包装包装。十年前叫siem的时候，难道就不关联了？干soc的时候，难道不收集？

soc侧重联动，siem侧重日志关联，态势感知缺少了自动化编排

siem可以是一个产品，soc基本不会，要联动要自动化编排，首先得各个模块支持接口，而这一点目前大多数厂商做得都很差，都要不少的开发量……实在没接口的，说不定就要模拟登录去执行

splunk支持rest api方式，调用很方便的，我认为splunk很灵活，可以快速验证各种场景并交付，定位于大数据os级别的产品

制造一个此时此刻能躲比杀毒软件的木马是很容易的。制造一个感染一万台电脑后仍无法被检测出的木马才是困难的。

同理，能“未知威胁感知”的系统必然具有一个特性：写“未知威胁”的人没有拿到并分析这个系统。

日志解析对arcsight是挺简单的事，但国内很多安全产品日志有很多问题，比如某信的防火墙，多条日志塞在一条syslog的字段里，而且随机（美其名曰为了性能考虑），日志解析简直没法写。

要不要把应用服务器接进日志服务器，还是要看你想看的重点是什么，而不是为了收集而接入。如果只是看交易日志，可以考虑做接口，但这要跟业务口沟通好（难度很大），如果只是看系统监控日志，是成熟的，但也是大坑，里面涉及到的细节很多，各种软件的运行日志，格式匹配的问题，语义的问题，都需要逐个解决，头痛

主要目的能够对绕过waf的应用层漏洞利用进行告警，比如注入脱裤行为。这方面坑确实很多，还很容易掉进去，soc部署上了新的问题就来了。

就像风控模型一样，需要针对不同的场景设置不同的模型，安全我觉得也是同样的问题，不太好构建统一模型来适配各种场景

比如一个简单的场景，密码猜测，三分钟发生10次以上的密码错误事件。这个有个潜台词是同一个源ip同一个目标ip，同一个登录账号。如果是定时统计就会存在窗口期的问题。如果是时时分析，就会存在资源的问题。你想想从代码把他写好，在加上各种因素，还是比较复杂的。这个还算是比较简单的场景了。大多数soc都能做到

这种场景还算简单的了，当年我们用的arcsight的产品，就发现多次登陆失败，然后登陆成功的情况了，虽然后来核实是运维人员忘了密码了

跨设备、跨场景的关联分析不好做，比如发现有针对web服务器的扫描，然后该服务器有异常登录或是异常进程这种场景

这个是简单场景。可以是同一个应用，也是类似的，不同ip就变成分布式猜测了，那是不同的规则

针对这一种场景可以，关联分析很多时候场景不是确定的。而且在大数据量下频繁写和查询消耗的资源也比较大。因为你需要对每条日志，所有场景做分析。判断这条日志是否需要处理。

现在技术比以前好很多，尤其是大数据技术的成熟。但主要大数据技术也就这几年才成熟的。很多公司的大数据平台就是一堆开源的整合，没有个128g都跑不好，最低也要64。

比如登录失败告警，大多都是运维忘记密码多次尝试，导致告警过多，要从里面找出真的异常，无异于大海捞针，简单但有效的规则，都需要甲方自己慢慢摸索，更不要说关联规则

比如网络出口的密码猜测就可以不管，太多了，而且发现也没有用，但登录成功的，尤其是异常时间登录成功的，要关注。这种数据其实不多。这就是要根据业务定规则

先把基础的告警规则做好，如系统登录失败、集中扫描、新建账号等，再慢慢做。需要根据实际设备、场景慢慢关联。还是能做些事情的。

全流量+日志（网络设备日志+服务器日志+应用日志）          场景才能覆盖全

我也来补充几个，目前我们再做的有sso相关的，异地登录，ip变化，敏感账号被使用，svn账号大量拉取代码，非常用机登录，异常时间拉取 ，还有些回头我也整理下

现在不是已经有自动编排，自动化响应的SOAR平台，做快速检测，快速响应的。

我们做的偏应用层多，不少跟业务场景绑定的，也划分的细致。比如账号，除了大家说的这些，还有特权账号、vpn账号的策略；对文件上传和下载也细分了，比如批量导出、账单下载的。

非业务人员电脑在工作时间利用业务账号登录业务系统查看下载、业务人员电脑在非工作时间登录业务系统查看下载  这些都应该定义为异常信息   可以在平台定义规则  视为告警

还有一个很大的问题是日志源降噪，日志源降噪对商业安全产品来说比较难搞

风控的同学对画像和分类更为擅长，如果能够把安全需求较清楚的描述出来，他们可以给到一些建议，只是安全数据的中有效的太少，如何选取变量建模是需要试验的

安全数据的有效变量少，其实还是数据维度不够。比如内部数据泄露，光一个人的角度，就很多样性。只看局部的几个动作是不够的，还有更丰富的数据，例如关系圈，常用设备，黑产匹配，业务行为关联，同设备同支付账号同WIFI同ip，使用数据的特征等等

#### 资源对抗

攻防的本质是知识对抗。一旦不是知识对抗，就必然会变成资源对抗。资源对抗就没咱们什么事儿了。

比如拒绝服务。早年攻击方用 Syn Flood，Ping of Death 这样的技术，防守方针对性检测化解。这就是知识对抗的阶段。现在就是上流量硬干，比的主要就是双方手上的资源了。

就以拒绝服务为例子，手里能控制很多肉鸡资源，到了一定的规模，也考验技术吧……以前我们用的木马上线个1000台，控制端就有点卡了，现在要求几十万上百万的傀儡网络……

控制大量肉鸡确实需要技术，不过属于性能优化领域的技术了，可能除了知识，也比工程化资源了。不过的确不是纯安全领域的。

抗D领域的知识对抗有个经典案例。当年传奇私服特别挣钱，相互之间竞争激烈。就有一家找了私服的实现漏洞，发一个包就能打掉别人。所以根本不可能在流量检测层面知道是怎么干的，只能知道服务器崩了。后来一个同事通过分析私服协议和服务器实现，找到了这个问题，才在产品里添加了对应的检测规则。

一般肉鸡会不断的掉，所以黑产应该也会想办法不停的抓新鸡补数量吧。这个过程还要不被大面积发现掉线，隐藏自身之类的应该也是术业有专攻

曾经做过一次模拟CC的测试，发现很多肉鸡存活时间只有十分钟左右

不断掉也有一部分黑产自己的因素，比如说隐藏自己，避免被受害者acl以后降低效果，保持一定的质量和新鲜度

这种策略源自“打一枪换一个地方”的思想，目的是为了保持肉机的长期作战能力

连主控端都能放弃，何况是肉鸡，而且有一键转移功能，被端掉也能恢复

说到这个，我们前段时间也出现这种情况，服务器有异常情况，用了好几个查杀工具都检查出正常，但是我们在边界的IPS上又能发现异常的流量，设备CPU也经常标高，为了保险起见，我们直接数据备份后重装了

#### 安全意识

如何理解安全人员的“做恶”合理化，或者说设置规则和合理化规则的人却合理化自身的为恶行为，并在规则下，自我辩解合理性。简单说，让他人少知，需知，自身都要知，且知越深越好。其人性和行为的解释。

安全的负责人在口令和补丁这俩事上一定要强势，其他都可忍。弱口令默认口令，严重补丁必须解决，否则安全基本等于零。

其中非常不可思议的案例是，他破解密码登入兴业证券系统主页，随后竟然冒充公司董事长、信息技术部等人身份进入兴业证券OA系统、VPN系统，获取证券交易的身份认真信息14组以上，并下载导出公司员工通讯录及个人信息数据5963组。

多年的甲方经验告诉我，越是高管越忙，要记得东西越多，密码一般都是简单的，一年都不会改，最好是短信码认证加密码，领导们一般还接受。毕竟日常生活中很多场景，比如登录网银都是类似方式，他们接受起来比较容易，现在刷脸识别，拿照片通过的概率大不大？

都高管了，天天忙着记密码，公司还有发展吗？看来不是高管的问题，是科技人员给出的解决方案有问题

也行，不过要考验产品经理和程序猿的业务流程设计能力了，不要被绕

董事会成员有终极权限可以看任何东西修改任何东西，还不好好记密码？

年纪大的领导们，连操作系统的密码都忘。别说他们了，咱们也都是指纹登录手机、微信等等，密码也都忘的差不多了。统一身份认证可能是唯一解决出路。

高层领导可以让秘书帮忙记密码，能帮忙处理公文了，密码交给秘书也没问题。现实中办公室钥匙应该也在秘书或者警卫手里。

高管的密码秘书确实有很大可能知道，大企业的高管秘书往往要帮助高管处理邮件、审批工单，但高管秘书的安全意识往往并不强，社会工程学攻击经常拿秘书当攻击突破点

国内某大型互联网公司曾经对高管秘书做过一次邮件钓鱼测试，中招率高达60%，测试团队都震惊了

社工确实是最直接的途径，人性也是最大的弱点，密码泄漏是最简单也是最有效的方法，，，，，，

还不完全是，领导会多，很多审批操作如果等领导就会耽误，秘书口头询问后代为审批，确实能提高工作效率，有些接待客户或领导的会议，中间几个小时都无法看手机——假设审批流程可以走到手机上，还有企业恐怕还要用电脑做审批

大部分的企业和部门都是统一认证，只需要认证一次，所有的系统都可以直接访问，这也是出问题最多的地方

我们现在系统都要求一个人一个账号密码 otp 不允许把密码给别人。如果要秘书通过 需要业务上做授权功能

要求躲避监管肯定是不对的，我觉得安全团队不应该屈服于这些压力，实在不行，给他们一台翻墙终端，连网络链路都是独立的，但不允许与内网接起来

还有一些领导，不知道怎么想的，实际上 他自己的账号并不需要多的权限，就非要让你给他开放贼鸡儿多的权限

既然做了统一认证，就可以在统一认证系统上加风控模块了，不能只依赖于大门钥匙（认证环节），还要对路径、行为，还要监控留痕

社工、钓鱼测试，越来越重要，需要直接逼真的实战测试，才会有效果。

关键是引人（高管）关注，多宣导、融入企业文化。用之前陈建总说的：老板们关心被监管约谈、关心被公安抓，关心财务损失、关心公司奖金被扣，关心业务不能做。   信息安全培训要多涉及此类利益风险。

企业文化不一样，崇尚技术的公司搞一搞可以。官僚的老板搞一下试试，不好好工作搞老板密码，直接开除

我们也去掉高管，有个员工问我们某高官日常工作是怎么一个状态。他说每个月有一周是连续开会从早到晚拍桌子做决策，剩下三周就是市场拜访。决策都在第一周会上做，听起来对系统权限要求不高。

但是领导说，我密码记不住，弄复杂了我要写纸上，我记不住你也要保护我，这个是没问题的，所以对高管不是说你意识不行，而是我们这个系统保护不好你，看，有被攻击者破解的记录，我们还要加强建设

做这种事 不外乎几个结果 ：

1. 领导觉得可以做，做了有效果，领导也意识到了；

2. 领导觉得可以做，做了没有效果，领导就意识不到；

3. 领导觉得不可以做，你没有做，就没有结果；

4. 领导觉得不可以做，你做了，领导接受了还好，不接受就走人

安全是帮助大家做建设，能捅但不捅，不要树敌

金融的朋友们，可以在排除掉高管后的名单里，找最有价值的进行测试，比如办公室、战略规划部、财务部、法务、投融资等部门

有一个真实故事：给财务的朋友做了安全钓鱼，从那以后 报销一拖再拖

其实得到老板授权以后可以进行一些常规钓鱼，不要大规模的去通报批评，可以私底下勾兑一下，然后合理写报告；

管企业大小，安全其实是个治理工程，甲方落地不讲地政治艺术手段只能孤立部门和自己

安全管控措施涉及到总裁级别的，一般分管领导第一件事情就是关注其名单，下面做的最娴熟的措施就是例外高层了。

我觉得先保证好自己很重要，如果自己被搞得很孤立，都混不下去了，你有再多的理念，都不可能真正得到实施。

这个有点离题了，就是当你作为cso入职，本身有平等对话权，弱密码和控制权限的漏洞是有助于为推行后续工作排除障碍，如果本身没有平等对话权，需要上级去沟通，那么上级要权衡关系，我们就做好本职工作，培训也能尽职，钓鱼也能尽责，不是一件非得跨越阶级强行去做的事，还是那句话，安全有能力，是帮助，不是树敌，做这件事的目的是给自己后面要做的事加砝码，不是为了批评

弱密码是安全毒瘤，个人看法最好的办法是没有静态密码登陆项，把业务集中到sso，移动工作台上，从入口处取消静态密码登陆，员工入职即要求绑otp

看了大家的话题，突然在想，通过安全措施知道了老板、、财务、秘书们的密码，再告诉他们，是否他们会对我们有芥蒂，想着我们是否有看过他们什么隐私，或见不得人的 .........找个理由把我们开除了，或者总给我们挖坑

是这么个理，但话不能这么直白说 ，可说对外部黑客是这样的，对于我们内部安全人员，只看允许看的，不该看的，不该知道的一律说NO。我们是对抗外部的，检查风险并督促进行加固，起保障作用的

直接告诉高管们，再美的美女，在妇科医生面前也得脱光了，但妇科医生也是被管理和监督的，并不能为所欲为，所有行为被审计，犯错照样报案抓人

安全还是寻找价值，而不是寻找武力，武力就像核武器，拿在手里，但是不是用来横的

业务部门强势要收集过多个人信息、安全部门除了法律武器，还有什么招数？何况有时候业务部门老大真的是不care什么网络安全法的

正常的回答，可能是，安全不要和业务对立，而是揭示风险，让法律起草隐私协议，确保获得用户同意，然后收集到了用户信息也能保护好，帮公司赚钱，而不是背锅，但是有些场合，是明知违法，不违法赚不到钱，比如给非法机构提供支付渠道啥的，如果看到的是这种迹象还是赶紧跑吧，监管那么严，公司倒闭或者合伙人被抓的案例最近两年不是没有

安全首要责任是保护公司的安全，而不是消费者的，这是守土有责，保护消费者是保护公司的途径

做安全的我觉得还是要掌握平衡之道 不能越权 但也不能一味迁就而卸掉责任 我是觉得 一方面尽可能让安全能匹配业务发展需要并对外合规 另一方面 也要尽可能摘清自身责任承担 避免沦为背锅侠（尽管背锅本身也许正是做安全的部分宿命，但还是有程度区别的）

#### 外包服务

咱们还是研究下防守技术吧。请教个问题，针对外包驻场开发，终端管理或者说开发机管理，大佬们有啥落地的解决方案不？云桌面？求不吝赐教

封了u口和互联网，大半不用愁了

瘦客户机是嵌入式系统，也能做？802.1x下的mac白名单么？还是把agent直接装到嵌入式windows?

我们用的联软。华为云桌面也可以打屏幕水印，不过定制性有点弱。

#### 服务器监控

我想知道 当服务器量级大了，如何做到近乎实时监测，那种业务量级，估计要么是自研的分布式的扫描系统，这样实时分析几乎可以实现，要么就是通过主机安装agent了

主要大家场景不一样，我们思考的是面向未来的数据中心百万服务器、亿级实例、细粒度到函数级的云计算场景，海量攻击，主客体资源持续变化

基本就是分级分布式扫描的思路，其实设计上不难，实现和优化需要一些功夫，在调度和数据汇总上

端口/指纹/漏洞扫描分级异步，对于海量资源来说，速度和覆盖率是关键指标，精确度不是

多发现一起违例比少发现好，海量数据首先看宏观趋势和高频策略，解决掉80%大家再来细谈一两个特例怎么处理，反正你不搞坏人也会搞，你比他快就是了，思维要从按例清除想持续对抗转化

深有同感，甲方安全不再是纯做防御的工作。系统总会有新增的漏洞，机器总有想不到的口子，人总有想不到的安全意识，没办法全部给消除干净。记得之前发过一张图，说的『保护、监测、识别、响应』的流程，保护是一方面，监测和识别是需要持续对抗和运营的工作

此类中台建设和价值输出，未来对安全的预定义：1、安全逐渐转变为业务属性；2、业务上线或可持续发展的要塞；3、真正由成本中心螺旋式成为业务部门，自带业务属性。

全运营中心的角色在改变或者说从另一个角度服务集团、用户。个人理解现在中台指的是运营中心的赋值，当然未来一定会改变，不过可能仍是个概念罢了。

对于安全中台，最后的关键是，云厂商提供的中台服务是不是能帮甲方安全团队解决问题，至于是支撑前台的中台，还是大包大揽的全栈，最后还是市场导向的

因为提质量问题仿佛是一件很低级的事情，那不是你应该做好的么，你让100w的机器都装上openrasp试试，这件事情做完了又怎么样。。。说覆盖率99.9%，so what？资产永远找不齐，黑客能看到的自己就是看不到，东西永远没装，装上去了总是有bug，日志采集不回来，有了日志告警99%是误报，1%去跟进了，可能还会跟丢，以为是误报，结果是真的，全弄完了，发现黑客的姿势千奇百怪，你做的策略黑客就是不碰，黑客来的时候永远是你不认识的新姿势，再搞定了，一年到头抓到几个真实的case，也是小喽啰，老板说，哦，完全没感觉，碰到一个大点的case，别人一进来你踢出去了，回到上一条，别人进来没发现，你们啥水平。。

降噪真是个技术活，传统企业购买商业安全产品，收集的很多日志都是噪音，但是没有降噪音的技术，所以收集的日志搞日志分析都比较假牙

#### 开源产品

今天在研究hids，突然想到了前两年有人比较关注的开源驭龙 HIDS，实际情况不太乐观，基本没有维护了。这就是国内开源的现状，没有大公司背书，只靠个人兴趣的开源很难走长远。

中国并没有形成真正的开源文化，很多人还要为了生活而奔波。所有只有有大公司愿意背书的开源才能走的更远些，比如百度的开源。

选择开源产品有利有弊，不同阶段选择考虑重点不一样，小公司初创公司，多因没钱，大都采用免费搭建防护体系，当企业慢慢做大，也逐步有钱，会逐步进行自研或采购成熟商业产品。走科技之路，自研有知识产权，有专利，可控可信，往后还可对外输出。架构都是慢慢演进的。

开源之路漫漫，好在现在思维都放开了，国内开源可谓百花齐放 。也确实存在很多个人开源的产品，1 、2 年就不再维护，对于没法深入研究开源产品的使用方来说会非常痛苦，无法升级，痛点更是在于功能bug、安全bug无法修复

企业用开源产品 应该购买商业服务 这个和普通商业产品没有本质区别 不能又要马儿跑 又让马儿不吃草，把开源等价于应该免费享受服务 这个是误人误己 自己给自己挖坑

开源用于企业内部非主营业务，非核心数据或非关键信息系统节点的工具性质的场景还是挺好的，比如，安全监控，告警，邮箱系统安全日志提取，业务系统访问可达健康性检查等辅助性质。

这个理自然是懂的，要不投人，要不投钱，这里只是说出了小企业或初创企业在使用大多开源软件的痛点哈

讲个故事，某次做安全规划评审，邀请了各部技术负责人，产品负责人等一起，其中某技术负责人说了句，我们产品这一年也没发生系统因安全不可用的现象，感觉某某防护还不是很需要的时候

当你系统被攻击不可用时，方才开始建设，得到的只能是血与泪的教训。但安全也是讲究投入产出比的，所以在做方案时，还要阐述这方面的内容，以便评审时有数据支撑做决策!

#### 权限划分

1、说的是“三权分立，分权制衡”吧，如：系统管理员创建安全审计员，安全管理员授予安全审计员相关权限，安全审计员能对“系统管理员创建安全审计员，安全管理员对安全审计员进行授权”的操作进行安全审计，彼此互相制约。

2、前台业务操作与系统后台管理分离：创建一个业务管理员对前台业务进行管理，后台管理用户不具备该权限，超级管理员除外。

运维堡垒机上不是都有审计员这个角色么？其它信息系统的日志可以统一收集管理、由审计员角色的人员查看

安全类设备一般都是三权分立，不过其他设备有缺失的。理论上要求三权分立，不过很多都是超级管理员和普通管理员，审计员倒是很少单独建立，尤其是操作系统。

紧急情况 就应该具体看待问题了  。。。。不能让流程卡住人，我一直觉得，我们的对手是人，所以最重要的，就是能灵活，随机应变

加了特权账号管理系统后必须安全人员登陆的系统里给授权后运维的人员才能使用

企业的安全风险评估，大家一般是怎么做的啊？参照了哪些标准？找第三方风险评估机构做，出风险评估报告吗?

企业整体的风险评估每年一次，内部有团队可以自己做，规模大有钱需要背书可以找外部公司做，专项风险评估可以按系统做，每季度一次，主要思路还是 20984 标准的思路，具体内容可以参考等保，行业监管内容等，挑重点去做脆弱性评估

上次不修，黑客会进来搞其他人，这次不修，业务自己挂了自己担着，但是你不提，业务可能会甩锅

#### 办公安全

HW 期间，每天用漏扫全网跑一遍，发现没有。昨天内部检查，突然冒出来两个，一查，是最近poc从厂商借的服务器，授权都过期了还没下线。反思，一是扫描频次要提高到周级别，最好能结合资产属性做专项扫描。二是管理办法要完善，外部来测试的系统也要扫描完再对外开放。

我们管理上要求设备/系统入网前，安全要同步规划，同步建设和同步验收。为了保证落地，主要采用准入手段，包括和it部门协同，没有安全验收报告不给配数据入网。也有利于网内新增资产管理。

IT 资产安全太重要了但不易做好。首要是能实时统计资产数据，基于此才能做好资产安全监控和预警，如开放端口、服务、使用开源组件、漏洞情况、弱口令，攻击监测等。现状是很多企业没有好的手段做资产统计和监控，包括我这边也差不多，这资产管理主要在运维部门，做好IT资产安全管理需要安全和运维联动才行。

流量和日志发现大部分资产ip还是可以做到的,就是很多人说的太重要不好做，而且这个功能点也一点都不高大上。上了全流量检测，或日志集中化管理才行，但这俩个估计在不少企业也都没上,资产统计发现相对资产长期监测维护更新简单。抽空汇报下资产里非法边界资产的监测与发现一点心得。

其实不用全流量，netflow就可以发现绝大多数设备,就像你说的，大多数做起来麻烦还不一定能看到好的业绩。或者太基础，不太重视,一句话基础安全，多数企业不屑于做，说太基础了，不太重视，但往往就死在基础安全防护上。

企业内网蜜罐部署有什么经验可以分享吗  比如哪几个安全域最需要部署蜜罐?

互联网接入区，第三方外联区,Ip 最好混入现有规划 ip 段，靠近真实业务 ip,只有一个经验，没有连环计，千万别玩蜜罐，害人害己。内网部署，只是为了监控内网扫描，不是放到互联网,重点覆盖DMZ、IDC，和一些关键业务区域

#### 安全指标

安全主管可以根据各项指标作出决策，只要指标不属于以下糟糕指标范畴即可。下面 20 条就是日夜与安全为伍的专业人士给出的网络安全领域最糟糕指标。

1、太过复杂的指标；

2、震慑型指标；

3、 质性指标；

4、 一个攻击风险指标走天下；

5、安全项目增长；

6、 基于 CVSS 的风险评分；

7、能力成熟度模型集成 (CMMI) 得分；

8、平均检测/响应时间；

9、完成培训的员工占比；

10、 被泄记录数量；

11、 平均故障时间；

12、 安全控制措施封堵的威胁数量；

13、 漏洞数量；

14、网络钓鱼链接点击率；

15、 漏洞修复天数；

16、处理事件数；

17、 每员工缓解事件数；

18、 事件开放时间/完结时间；

19、 安全项目控制覆盖百分比；

20、分析师待处理工单

这个好多指标不敢苟同啊。只谈指标是耍流氓，指标结合使用场景，结合具体企业环境，才有意义。所以不能说指标是否差劲，而是指标用的是否妥当。漏洞修复天数，这个指标无论规模大小，不同行业，都是非常好的指标。我说一种场景，漏洞修复天数毫无意义，一堆待下线系统，明天将下先，今天做漏洞修补，你去考核漏洞修复天数有意义吗？和场景关系不大，我觉得漏洞数量，修复天数，漏洞评分，都很有价值。哪怕要下线的，外网高危漏洞也得临时处理。我们探讨的是指标的意义，不是是否可能被打穿，我们讨论a时你总要说b，没个聊，你就是修复天数都是0.5天，被打穿了呢？这个话题，可以参考一句古话，尽信书不如无书，但是，这不代表，书，没有意义。

指标没有完美的，只要能够指导工作，提升能力，不要畸形追逐指标，为了指标做错误的事情，就可以。比如修复时间，它不仅仅是安全能力的体现，甚至是公司技术能力的体现。有很多公司，外包开发的代码，老员工离职了，没人知道怎么改。修都修不了。有些做的好的业务，可以热更新，或者快速降级。

还是客观看待吧，只能说不同阶段需求指标不一，单一指标或综合指标。讲个极端案例，比如勒索病毒，刚重装完系统，网线没拔，洞还在修复过程瞬间又被感染了，如何计算漏洞修复天数

在没有那么较真的情况下，就看平均修复能力，自己跟自己比，跟同行比，趋势上，有没有提升。比如说，脏牛，熔断，fastjson，同学们扪心自问，修了多久。这些漏洞的响应速度，修复完成花的时间，能不是参考指标么？

我说的那种极端场景，指标的值都是1，假设100个系统，考核也是100个系统，下线也是100个系统，修复也是100个系统，最终修复天数指标都是1，不用算。这种应该不在分母中，这时这指标毫无意义，当然是我认为，你可以不认为，但我的观点是不能脱离环境和场景只谈指标的意义。而你的观点是不管啥行业啥情况，都是非常好的指标，这是我们的冲突点。

“指标”只能认为是当时制定的有效性，不能长期以历史指标有效性论断，指标是有有效期的。指标的意义是评价，观察，改进，量化。极端例子我觉得剔除指标计算公式更合理。

我们不是写标准，也不是实验室出来的指标，这些指标大都是众多实践总结出来的，可不必较真哈~在不同阶段能指导和考核我们大部分实行的工作即可。

从我们的实践来看，考核漏洞修复时效的意义在于，根据业界统计，漏洞的平均利用时长是7天左右，那么倒退回来，如果我们内部或外部发现的漏洞如果修复时间超过7天，就很有可能被外部利用进行渗透。但是从ROI角度分析，我们也会区分核心系统与非核心系统。所有这是我们从自身角度出发思考这个指标的价值。

利用时间那个我觉得7天太夸张，几分钟可能就有人打进来了，还是给自己定目标吧，一个脏牛修复时间xx，为了下次不要这么久，要做点事，fj同理，这次修复这么痛苦，下次要快一些，快到什么程度。有的时候，是情报慢了，朋友圈开始刷屏，你开始评估要不要行动，所以等你决定要发内部预警的时候，友商都宣布修完了……有的时候，是内部资产不清楚，你都不知道哪儿用到了fj，自以为修完了，结果外部报告说你还有没修完的，还有的时候，是业务高可用的能力，是否允许下线或者降级修漏洞，这些基本功打好了，一定会体现在指标上的，但是，非得单独追求指标，总有作弊的方法，综上，我理解，指标尽量丰富，多维度解读，按需，在不同的阶段，估计追求不同的指标，以推动主要矛盾的解决

指标的关键意义在于消除实质性风险，考核漏洞修复时效此类指标，需要结合网络攻击图等工具具体分析对企业自身的影响。业界成熟的完全指标体系可以参考、可以改造，形成和构建结合自身业务场景安全运营需求的指标体系，别人说再好吃的，你要能吃得下，吃的有营养才好

1、建立网络安全通报预警机制。主要包括：JY系统信息资产梳理，包括单位和信息系统情况等，这个量很大，从部里一直下沉到地方小学幼儿园等；建设监测预警平台，利用机构合作、采购安服、高校合作、部本级监测等形式，针对行业资产进行监测预警和漏洞通报；建设整改和通报机制，落实网络安全责任制，各单位要明确网络安全分管负责人、安全联络员，漏洞通报落实到人，三天整改，逾期函件通报，漏洞整改复测之后方能结束流程。

2、落实每年 GA 关于网络安全 ZF 检查、WX 关于网络安全检查的要求。这个其中一部分就是现场检查，每年选部分直属单位、重点高校和 10 左右个省厅（包括其直属单位如考试院），包括现场检查、整改落实、反馈座谈，座谈要求分管领导（厅级）必须参加。检查内容包括安全管理、策略核查、渗透测试（互联网+内网）。

面对监管，咱们针对网络安全自查每年开展两次：主要充分结合当前业务阶段和等保要求，自查上报绝不吹嘘，有一说一，积极拥抱自查发现隐患整改的态度，对漏洞修复敲得整改时间、对未达标的制定中长期规划…目的是防范单盲式突袭而通报；

KPI是管理工具，要配合其他管理工具的，纯KPI导向很容易引发 KPI hacking，KPI类似于演讲时的提纲，但演讲不能只有提纲，对重要且紧急的，用强KPI解决，对重要但不紧急的，就不要依赖kpi了，定完KPI了，还需要沟通完成的方法路径和资源，完成过程中还需要进一步沟通是否有偏差或者情况变化，制定过程中也要引入部分非定量指标，最终还要进行全面回顾分析。不能简单定一个指标然后让电脑自动计算的。但是KPI可以作为平日里每人心中的一尺子，但无法丈量特殊阶段的事物

是不是应该考虑为可被直接利用的漏洞和不可直接利用的漏洞？比如一些内网系统的ssh心脏滴血之类的就不要用作强制修复的考核？可能心脏滴血的例子不恰当。。公网有攻击面的，修复完毕，叫做止损时间，全量修复完毕，是另一个观察指标。

如果可以还是建议你了解清晰老板的期望和需求，方向是内部还是外部，资源如何，是否可落地，要达成什么目标，攻防或渗透，等等。不是别人做的方案就能直接套用的，省事了，到不一定适合自己

动态防御感觉不太好请外部的力量来操作，临时请的人员不太可能在短时间内很好了解网络架构，应用架构，部署架构，脆弱点、应急预案和应急设备等，这些因素都会影响到联动处置响应速度和效果，这些都是防御方的劣势。

攻防演练更多是检验动态防御和应急响应能力，如果内部枪少，对抗力量悬殊，感觉检验意义不大哈~

如前面几位大佬提到的，再进一步了解老板的需求，具体要达到什么效果。如果是想要快速知安全现状，可以来一波渗透测试或安全评估，快速集中推动做一波整改，借机推动上线安全流程、安全防御体系、合规体系。

外部的攻击可以参考众测的规则写写，内部主要就是协调处置分析工作，需要投入的人力很大，如果人力和分析设备不足，可以以应急响应流程优化为目的检测协调处置能力；如果人员安全设备完善，可以以分析为目的，寻找设备、人员和流程中的问题做运营的优化。

目前发现的问题都是隐性、莫名的问题，对部分办公软件或运维工具产生影响（慢、无法运行、报错等情况），业界多数产品都是这个问题，所以大多数只能叫做demo，不能叫做产品。在运营的框架下，这基本上也就相当于没能力了。

给厂商机会去迭代，以覆盖率为第一优先级，影响卡，慢的东西相当于技术不成熟打回，在广覆盖率的前提下，逐步迭代提升可感知的能力，做数据采集优先，基于数据采集之上的分析和精细化运营（按需开阻断）跟上。

1、基于后缀检查，在范围的后缀在基于其他行为。包括国外某产品全后缀检查卡的不行

2、大文件检查慢，占用文件导致app挂掉无响应

3、支持的app太少，国产浏览器大部分不在列表，比如国产聊天，浏览器

4、基于3的问题，导致很多软件去读取或者打开软件告警（误报），浏览器没法识别发送目的（如果接受文件包含敏感信息，直接从QQ打开也会告警，QQ占用了这个文件

很多小乙方厂商其实研发实力不强，带着一个idea看准一片市场就冲上去了。

所以他们的产品缺乏QA质量保障，缺乏大规模海量架构经验，或者实现上出现问题是非常符合逻辑的。

这是当前的业界比较客观的情况。

大厂质量虽然好一些，但是又不够灵活，支持不到位。

所以其实讲运营的时候，很多时候我们是在考察看菜下饭的本领：

本来做好一件事需要100个人，就给你2个，倒逼大家YY一些银弹来救世，或者很多的旁门左道来在最小资源的情况下提供最大的遮羞保障

一般来说，小团队的优势是在某个非常非常窄的细分领域会做的很深，也就是说某几个指标可以干过大厂或者成熟产品，但是从完整的角度看，就不行了

只审计 不 告警呢？那顶多做事后审计，对敏感事件阻断是过非常漫长的过程(适应过程），但是开启审计一定会对某些应用造成运行慢的的问题（用户无法接受），因此需要不断的调整策略。

#### 凌云分享（安全建设从1 到 10）

我相信群里大多都是甲方工作一段时间了，也就是过了 0 到 1  的过程。肯定渴望知道如何从 1 到 10。 学问之道,分为“体、用、术”。 体的方面，大家可以看群主@聂君-内部安全 的书，术的方面，大家平时在群里讨论了很多。 所以我会在这里简单介绍一下，一些“用”。希望给大家与启发。

我先说一下，新到一家首先做了什么。我首先对某公司的整个信息安全进行了摸底。这个我相信无论是从 0 到 1 还是  1 到 10.这个是必须经历的过程。否则很多东西没法下手。那怎么摸底。一般是先动嘴 ，再动手。我入职后，首先和所有的公司总监聊了一圈，这是一个体力活。了解目前他们眼里的信息安全情况。这个其实蛮重要，你可以从中获得很多信息，包括他们是否重视信息安全，他们目前觉得最大的安全问题是什么。

新来公司，和所有总监聊一圈，也去年来奇安信也是这么干的，后来还在合伙人会上被人表扬，说接地气，重视需求，不过这个效果好，能快速知道现状和问题。

然后呢，对办公网 、idc，网站 app等做一次摸底扫描，当然你也需要看看src、众测的结果，看看历史漏洞有哪些。这样可以对公司的薄弱环节 有个比较清楚的认识。有乌云的时候还可以看看乌云的记录，那现在没有了，可以看看各种众测记录，内部测试记录。

一方面知道怎么做，另外一方面可以知道平时要打接触的这些人的秉性是什么样子，能够看到很多边缘的应用，也能够看出不同的部门对安全的重视程度，或者说是开发能力的不同，一般按照经验的话，大厂出来的开发能力会强一点，中台的开发能力会比一些前线的业务部门会强一点

了解现状以后，我们就要对工作做分类，把职责做分类。把相同责任明确到一个组，当时携程大概有20多人的安全team吧。如果大家部门人少的话，可以责任到人。安全这个东西，其实很考验人的责任心，一旦明确了各个战线的责任人，我就可以比较明确的定义安全的kpi。带动团队积极性、奖罚分明。团队分组这块，其实又各家情况都很特殊。最初我是按照 运维安全、应用安全、安全合规、安全开发 这种方式进行分组。  试图将各类安全责任进行分解。  去年又开始按照 基础安全、安全运营、安全合规、数据安全、安全开发 这种方式进行分组。这块应该没什么对错。看最适合的是什么。

团队有了。再接着 ，我们就需要定目标了。那这个目标不能定的太高，否则好高骛远，也不能定的太低，低于了行业平均水准也不行。那这就需要负责人和同行交流。我那时候把几个大的互联网公司都跑了一次或者和他们的负责人微信沟通。包括北京的小米，美团，去哪儿等等。这时候 我就可以知道自己公司在什么位置，在同行里面是60分 还是70分 还是 80分水平。这个时候你就可以定一个 ，你跳一跳可以够到的目标了。

那规模差不多的公司做横向比较，如果是上市公司，你可以看市值,你可以看你最关心的是什么，嗯，举个例子，我那时候最关心的是SDL,我可能已经有了一些作sdl的想法。但是这是不是一个最佳实践，和其他互联网同行比是落后的，还是领先的？那这个要去沟通才知道

我当时在沟通的时候想了解大家怎么做被动式扫描的。被动扫描有两条路可以走，一个是流量方式，一个是浏览器代理，哪个是最合适的？有没有坑？这个如果不是一家家跑下来，和其他公司沟通，自己闭门造车，会有很多问题

前面群友也说了，我去年把胖胖派出去差不多，国内很多互联网公司也都兜了一圈。这目标是为了调研hids。那其实可能也有两种声音，那这边不方便透露，但大家走了一圈后，都表示对 hids 如何做产品，如何设计思考的更全面，更深入了

所以有时候你要做一件事情，或者你安排你的下属去做一件事情，发现他们的想法和你不一样的时候，你不一定要强迫他们安排安着你的想法去做，你可以帮他攒一些局，让他去和同行沟通。这样从下而上的效果可能会更好

目标有了，我们说就是 action。首先肯定是招人，那块缺人招那块。然后你要准备好你的短期工作目标和长期工作目标。短期的话，你要在几个点，半年左右的时间 做出业绩，让你的领导对你有信心。但很多项目不是半年就能出结果的。那这种 1 年以上的长期大项目，也要有伏笔。你不能都短期项目，也不能都长期项目。长短结合。全是短的项目的话，那就没大项目出来。如果全是长时间的项目的话，那就会很长时间出不了成绩。所以都要考虑到。

安全规划要做好：长期计划，中期埋点，短期多出业绩，

对于安全规划时长一般是3-5年规划，分阶段落地，前一阶段为下一阶段买下伏笔，不断进阶。在规划中，绕不开投入，1年、2年多少合适，说服boss有什么好的招数。

可以一两年这种长期规划的项目，但也需要几个月的短期见效的项目,当然，你可以把一个大项目拆成很多小项目来做，但要有一个整体的规划

如果是一个互联网公司，我理解 初期目标 很大一块应该会放在防止黑客攻击上。这块的内容可以做1-2年。包括 sdl、包括日志平台搭建、日志分析等等。在落地层面肯定各家不同，有的可以买，有的可以自研。这些都是术层面的东西。大家平时可以沟通，而且互联网和金融和 传统可能没有很强的参考性。因此具体落地我就不多说了。具体可见:

https://sec.ctrip.com/doc/陈莹-实时攻击检测的智能化之路.pdf

https://sec.ctrip.com/doc/凌霄-打造自适应攻击验证系统.pdf

https://sec.ctrip.com/doc/江榕-互联网运维安全建设与运营经验分享.pdf

到了中期 ，可以把一些合规内容拿起来看。无论是 iso27001，还是等保，还算目前比较火的数据安全，以及数据安全的相关标准 dsmm。将这些政策和一些内部管控流程结合。做dlp、做权限管控、ueba等等。都会起到不错的推动效果。我在携程通过推动dlp建设，发现不少安全隐患，引起管理层对安全的重视，还拿过公司项目奖。 具体可见:

https://sec.ctrip.com/doc/徐楷-企业数据防泄漏分享.pdf

https://sec.ctrip.com/doc/议题分享PPT.pdf

和同行沟通咨询，明确自己定位和目标，既能互相学习，也可以作为业内对标和领导汇报安全工作。后续是不是可以考虑部分线下沙龙的方式交流？

方面很多的原因有几个。一个是安全越来越被重视，二是因为有些法律规范，或者说是条例上面有要求，新项目上限需要做安全审核，第三是一些大厂其实已经做了很好的人员的一个培训，所以那边离职出来的人，它本身会有很强的安全意识

凌云总最开始的时候就说跟总监们进行沟通，认了认人，摸了摸品性，相信也是为了之后推动SDL建设做的准备吧。。

最快出效果和成绩，可能是做风险评估、渗透，合规检查，快速挖掘风险现状，然后整改哈,如果只是推整改，那就弱了，这个时候你就要借机上你的整个安全体系和安全流程

到了后期 ，伴随对公司业务的了解。安全部可以参与做一些贴近业务的工作。无论是风控、业务安全、反爬、ugc、验证码都是很好的切入点。这个需要安全人员有业务敏锐性。发现以后马上就切入进去。 具体可见:

https://sec.ctrip.com/doc/杨再三-黑产第一道防线--携程验证码架构变迁之路.pdf

https://sec.ctrip.com/doc/闵杰-Ctrip业务安全前生今世.pdf

怎么评价自己负责的安全工作干的好不好呀?

安全部门在公司里比较尴尬，很难体现出价值，请问凌总如何看待？

所以有些东西其实还是挺好推的，比如数据安全，大家可能刚开始觉得很难推。数据。分类分级啊，业务敏感信息啊，大家不一定会陪着你玩,但是你可以先做dlp。和管理层汇报，抓了多少泄密的。说清楚dlp只是暂时的。根本解决方案是数据安全。这时候，自上而下反而好做了

其实DLP推动，然后再抓典型是需要一个很长过程，因为相当于一段时间都是审计模式。

凌云总能否介绍下贵司基础安全包含哪些内容？差不多就是把应用安全和运维安全和在一起，把里面一些比较基础的内容在剥离到运营

当前我们推动的DLP已经有3个月了，还是停留在审计模式，因为涉及人员，场景太多钱，当然确实存在技术实现的问题，落地起来比较谨慎。所以还处于跟用户“交朋友”的阶段

主机的，大家都知道很麻烦。就可以先测网络的，而且大家的邮件服务器都有转发功能吧。你们可以看看有没有人把邮件设置成收到就转发的？

大家要学会向上管理，有些严重的安全问题要找机会告诉董事会，特别是dlp这种技术，技术层不重视的。只有业务层才会重视

董事会还有无数层级的飘过哈 直接上级和上上级都非安全出身，一级级游说哈，这种情况下，我个人的一点点建议，可以从业务（中层）骨干入手，有些时候，他们说话比我们管用。

有些敏感的。凌总。一些安全问题很严重，但是汇报也会引起大老板反过来的警觉，“这事你做安全的不应该知道啊，怎么你反倒知道了”，所以监控要先取得大老板的授权支持才可以，就是要先做东厂。

我们这边有些复杂，目前这些都不太好实现。我想找hr应该是更好推动人员安全管理，找业务聊，让他们更好支持业务安全、数据安全、合规安全等吧，这些都是好招

dlp你可以不说这么多细节嘛，你说只看到xx再发一个文件名，看名字有点敏感，请业务方评估下？

其实dlp只能逐步开展，先解决敏感度高的防泄漏场景或按照部门开展，比如：法务，财务等，做进行断的策略优化，直到可接受。

Dlp推时候还是需要比较谨慎的，一定要逐步推广，先在小范围内推。我们从推开始，陆陆续续客户端已经升级了10次了

我们这边安全投入，是IT部门长决定，业务那边不管哈，但在安全项目落地时需要他们支持都还是很到位的

dlp也好，ueba也好，本质上是采集数据，发现风险，进一步向上汇报申请资源。dlp属于一种相对成熟的工具，可以快速采集数据发现风险

目前东西部署了，策略下发了，审批流程也接入了，感觉就只干了管控的活 ，可怕的是领导们觉得依赖DLP可以万无一失了

后台每天能看到很多业务的敏感数据，本身是不是也是个高风险的岗位

所有IT管理和信息安全管理的职位都有此类风险，安全负责人需要考虑怎么防范和解决（如加强审计、权限控制）

目前想的就是看到这些各类不规范的操作行为，持续性做安全意识培训

其实能想到dlp的基本是数据或者文档已存在外泄情况，而此时往往是管理力度不够，技术存在盲点。dlp也是一个弥补的手段，不过期望值要降低。

我们现状也是封锁USB的，需要的时候，走特批开通，定期审计发报告。现在办公非常少使用USB进行数据共享，主要都是通过内部IM或网盘，我们这边主要有个别岗位如合规岗需要上报些资料，得插USB key

换个角度想一下，如果从管理手段来讲，策略传达到位，如果外发文件，以侵犯商业秘密罪起诉追究法律责任等，而后技术手段有更多安全管控，比如外传文件直接关闭网络传输，同时预警等，这样会不会杜绝外发文件呢？

我说一下我这边的做法吧，首先员工都有一台电脑，还都要上网查资料拷贝进来工作，这个都是正常需求，那么有的公司内外网隔离，有的公司就是办公网作为起点的，这个没关系，我们现在是在笔记本电脑里搞了个加密磁盘，业务系统下载下来的东西只能进这个加密盘，加密盘里的文件能拖出来到普通盘符但是是加密格式，发出去了也打不开，但是在公司内流转能打开，普通盘符的也能拖进加密盘但是出来就加密了，如果真的有外发的，首先保留申请解密的审批通道，其次我们尽量帮业务部门建系统帮他们自动化，毕竟绝大部分都是为了发送一些报表，最后对于确实涉密又确实要外发的建立了保密员的机制让第二人跟踪直至文件发出并删除，不留在普通盘内，我们用这种方法绕过各式各样的出口的那些坑，你在本地自己写的文件不管你，但是只要跟同事交流过，工作上用过，就让你只能进加密盘

关于外发邮件我提个问题，对于业务人员来说，外发邮件带一些文档是必然的工作需求，那么他们把文件加密了再发，到底是需要审计，还是不需要？不加密出去了更危险，加密了如果是有意为之反而抓不到

邮件发在如果有加密文档，可以提示自动解密并审计记录的，感觉震慑效果挺好。不过走审批流更好，不过不自动化了。

我觉得内鬼大致分为几种类型，破坏型、数据泄漏、流程获利、商业间谍、无意中泄露，涉及人员：合作伙伴、外包、待离职员工、已离职员工

事件驱动策略，或者正常的业务场景太多根本枚举不出来，出口管控。

谈了这么多dlp，我想请问现在识别敏感信息是不是还是靠关键字或者简单的正则？

也有编码算法、文档指纹学习、关键字，正则，签名，模型啥的、文件指纹，规则组合、主要还是关键字和正则。如果正则效率比较低，不能设置太多。

外包录单，有没有相关监管要求的？比如保险单，银行卡申请单，外包录入

印，封闭职场，禁止带入手机，一次只能查看切割保单信息，多人录入复检，等等，但是这个行业应该已经很成熟了，有没有监管要求的，主旨是防止流动率高的外包偷信息

自带设备必须装我全家桶就行，授信公司管理数据权限，除了硬件所有权是你的，上面东西你要都放弃，不同意别装，别拿来办公，就是不合规不让用的朴实无华的思想

VPN 解决了什么： 认证+加密+收到一个内网

达到这个目标必须要 VPN 么？不是的

代理+TLS+ 终端认证（证书+账号密码+可信设备ID+物理环境+补丁杀毒软件无告警+xxx），能起到一样的作用

下面这个朴实无华的思路叫做 BeyondCorp

做到了终端授信，终端补丁打了，杀毒装了，账号认证通过了才是有意义的

理解想实现的目标，再看怎么快速实现（不要管实现得是不是足够彻底优雅，就看性价比是不是最高，一步一步迭代到理想状态）

#### 张福分享（ATT&CK）

大家好，我是青藤云安全的CEO张福，和大家一样，我也是个安全技术爱好者。感谢聂总的邀请，今天有幸能在这里给大家分享一下我们这段时间对MITRE ATT&CK的研究，希望能和大家多沟通交流，如果有什么没说到的，也欢迎大家多多提问哈。

讲MITRE ATT&CK之前，首先我们来谈一下站在攻防角度，作为一个防守方会遇到的困难。

由于敌暗我明，防守方始终处于一个被动地位，因此，防御总是比进攻要难。这个情况在网络安全中尤其普遍。在网络安全领域，攻击方始终拥有取之不竭、用之不尽的网络弹药，可以对组织机构随意发起攻击，而防守方则必须每次都要成功地防止攻击者攻击成功。

由于这种天生的劣势，防守方始终会为以下问题而困扰：

1.我们的防御方案有效吗？2.我们能检测到APT攻击吗？3.我们收集的数据有用吗？4.我们的安全工具覆盖范围是否有重叠呢？5这款新产品对于我们组织机构的防御有用吗？......等等

因为缺乏一个明确的，可衡量，可落地的标准，所以防守方对于入侵检测通常会陷入不可知和不确定的状态中，从而无法有效的弥补自己的短板。

MITRE为了解决防御者面临的困境，基于现实中发生的真实APT攻击事件，创建了一个对抗战术和技术知识库，即MITRE ATT&CK框架。由于该框架内容丰富，实战性强，最近几年发展得炙手可热，得到了业内的广泛关注。

以上是背景介绍,下面我们开始今天的主要内容，分为三个部分：

一.MITRE与ATT&CK概念介绍

首先提一下MITRE是谁：MITRE是美国NIST标准化组织选择的专注于网络安全的组织，由美国联邦政府资助。很多安全标准都MITRE制定的，比如有名的漏洞CVE编号规则以及威胁情报格式STIX。所以ATT&CK非常有影响力，而且未来能成为一个公认的标准，今年RSA大会上MITRE也在大力推广这个框架。

ATT&CK是对抗战术、技术和常识的缩写。战术（Tactics）代表了实施ATT&CK技术的“原因”。战术是攻击者执行某项行动的战术目标。战术提供了各项技术的环境类别，并涵盖了攻击者在攻击时执行活动的标准、高级标记，例如持久化、信息发现、横向移动、文件执行和数据泄露。

技术（Techniques）代表攻击者通过执行动作来实现战术目标的“方式”。例如，攻击者可能会转储凭据，以便访问网络中的有用凭据，之后可能会使用这些凭据进行横向移动。技术也可以表示攻击者通过执行一个动作要获取“内容”。这与“发现”战术有明显的区别，因为技术侧重的是攻击者采取特定动作是为了获取什么类型的信息。

由于战术代表了攻击者的战术目标，因此随着时间的推移，这些战术将会保持相对不变，因为攻击者的目标不太可能改变。战术将攻击者试图完成的任务的各方面内容与他们运行的平台和领域结合了起来。通常，不管是在哪个平台上，这些目标都是相似的，这就是为什么Enterprise ATT&CK战术在Windows、MacOS和Linux系统中基本保持一致。

技术是ATT&CK的基础，代表攻击者进行某个动作或攻击者通过执行某项动作而了解到的信息。每一个技术都包括唯一的名称、分类、检测方式、缓解方式、详细信息等。

那么ATT&CK和KillChain是什么关系呢？在早期，ATT&CK模型是在洛克希德-马丁公司提出的Kill Chain模型的基础上，构建了一套更细粒度、更易共享的知识模型和框架。

现在经过几年的发展，整个矩阵内容变得丰富， 被拆分为PRE-ATT&CK和ATT&CK for Enterprise，其中PRE-ATT&CK覆盖了Kill Chain模型的前两个阶段，包含了与攻击者尝试利用特定目标网络或系统漏洞进行相关操作有关的战术和技术。ATT&CK for Enterprise覆盖了Kill Chain的后五个阶段。

但是，ATT&CK的战术跟洛克希德-马丁的网络杀伤链不一样，并没有遵循任何线性顺序。相反，攻击者可以随意切换战术来实现最终目标。没有一种战术比其它战术更重要。组织机构必须对当前覆盖范围进行分析，评估组织面临的风险，并采用适当措施来减小差距。

另外，除了在Kill Chain战术的基础上更加细化之外，ATT&CK还描述了可以在每个阶段使用的技术，而Kill Chain则没有这些内容。

二.ATT&CK背后的核心设计思想

ATT&CK背后的设计思想是十分明确的，主要有三个核心思想：

1.始终从攻击角度看待问题，保持攻击者的视角。

ATT&CK在其术语以及模型中介绍的战术和技术是从攻击者的视角出发的。相比之下，许多安全模型从防御者的视角自上而下地介绍安全目标（例如CIA模型），有的则侧重于漏洞评级（例如CVSS），有的则主要考虑风险计算（例如DREAD）。

ATT&CK使用攻击者的视角，比从纯粹的防御角度更容易理解攻击者的行动和潜在对策。对于检测，其它防御模型会向防御者显示警报，而不提供引起警报的事件的任何上下文，因此无法很好的理解攻击者的意图

2.不断进行实践证明，通过跟踪APT活动来更新技术。

由于对真实的APT攻击进行了追踪和分析，提炼出了技术点，因此，能够准确地描述正在发生或可能发生的在野攻击。

通过继续不断地积累ATT&CK知识库，使得该模型是基于可能遇到的实际威胁来完善进化的，有很大的实用价值而不是理论价值

3.进行抽象提炼，通过抽象提炼，将进攻行动与防御对策联系起来。

ATT&CK框架对相关的对抗战术和技术进行抽象提炼是ATT&CK与其它类型威胁模型之间的重要区别所在。各种针对攻击者生命周期的高级抽象模型，例如Cyber Kill Chain®、Microsoft STRIDE等，对于理解高级过程和攻击者目标很有用。但是，这些模型不能有效地传达攻击者要采取哪些动作、一个动作与另一个动作之间的关系、动作序列与攻击者战术目标的关系、以及这些动作与数据源、防御措施、配置和其它用于平台与域安全的应对措施之间的关系。

ATT&CK技术的抽象提炼的价值在于：

1.通过抽象提炼，形成一个通用分类法，让攻击者和防御者都可以理解单项对抗行为及其目标。

2.通过抽象提炼，完成了适当的分类，将攻击者的行为和具体的防御方式联系起来。

本质上是通过“适当”的抽象，既不很模糊，也不是太具体，而是很适度的抽象，给攻击和防御之间建立起了一个标准化的“语言”，能够让攻防双方站在同一语境下对话。

三.ATT&CK的四大使用场景

1.威胁情报：使用ATT&CK框架来识别攻击组织

网络威胁情报（CTI）的价值在于了解攻击者的行为，并用这些信息来改善决策。对于希望开始使用ATT&CK框架来收集威胁情报的小型组织机构，可以先从一个威胁组织着手，并按照框架中的结构检查其行为。

这样能通过攻击组织使用的技术和行为，来定位攻击组织。另外也可以随着时间的推移，来分析同一个攻击组织的技术变化

2.模拟攻击：基于ATT&CK进行红蓝攻防演练

模拟攻击：使用ATT&CK来组织红队计划开展一系列基于威胁的安全测试，模拟真实攻击者的技术，关注技术行为，即便没有红队，防御者可以先使用红队工具来尝试，并使用ATT&CK打造一支成熟的红队。

让企业的团队选择不同的ATT&CK技术，讨论如何使用不同步骤来执行攻击行为，邀请威胁情报分析人员谈谈攻击者是如何使用的，将ATT&CK作为通用语言与蓝队沟通，让红队主动模拟ATT&CK技术，制定自己的攻击者模拟计划。

这和一般的渗透测试有什么不同呢？主要在于可以模拟多个组织的攻击，而非单一组织的

3.检测分析：基于具体的”技术“，有效增强检测能力

检测分析：检测分析可以用CAR（Cyber Analytics Repository）安全分析库项目举例。主要是针对ATT&CK的威胁检测和追踪。这个项目主要基于四点考虑：根据ATT&CK模型确认攻击优先级；确认实际分析方法；根据攻击者行为确认要收集的数据；确认数据收集主体sensor的数据收集能力。后面三个方面与的Analytics、Data Model、Sensor相对应。这个分析库是由对每一项攻击技术的具体分析构成的。

4.评估改进：将解决方案映射到ATT&CK威胁模型，发现并弥补差距

评估改进：首先进行差距分析，弄清楚“我们现在在哪儿”，ATT&CK有助于企业确定自身在人员、流程和技术方面的差距，根据可见性来决定你要收集（和购买）哪些内容：你的差距在哪里？你还可以选择其它哪些工具？这些工具会帮助你建立更有效的防御措施吗？帮助企业拓宽安全视野，不仅仅是局限于检测；加强认识，了解可能需要承受哪些方面的风险；哪些内容是你无法检测或缓解，检查你的安全预算与计划，实现资源的优化利用。

之前企业做差距分析，是做自身安全状况的差距分析，分析后的内容主要用于指导安全体系的建设。但是并无法很明确的了解自身防御和检测能力的差距，ATT&CK可以在检测覆盖度上（明确分析出哪些攻击技术在目前的安全体系里无法覆盖），以及检测深度上（比如留后门一共有哪些姿势）提供一个清晰的差距分析，指导企业加强入侵检测能力

今天的分享就到这里，因为ATT&CK是一个非常庞大的框架，所以无法在这么短时间内说的足够透彻，时间也没控制好，在这里向大家致歉

1.ATT&CK 是不是很依赖威胁情报，感觉这种情报和传统的还不太一样，更需要对很多攻击手法apt研究，单一组织很难覆盖

2.如果要做到高准确率，那势必要匹配攻击者的战术目标，需要触发一些特殊行为如持久化 提权，到这个阶段也不算“尽早发现威胁”，那怎么对比优劣于现有的防御模型呢

ATT&CK带来的最大好处就是标准化、透明化了。让你比较清晰的知道自己哪里做的还行，哪里缺口很大。

ATT&CK都覆盖了并不能说明反入侵做的就一定好，还是要看场景的深度，能不能发现关键动作的攻击行为。因为ATT&CK里有很多动作是在APT里使用的（以前被使用）不一定适合企业场景

我尝试回答一下欠钱总之前问的关于怎么确定优先级的问题 我在前司曾经将已检测或者已处理的真实安全事件或者威胁与att&ck做映射和对照最后形成一个自己企业威胁最大的ttp集合 根据这个来优先设计和优化检测系统来针对此类ttps

我个人一直是把att&ck当做进攻手段的大盘的参考资料。

因为我们一直很难解释一个问题：我们的入侵检测做到了什么程度。

谈策略覆盖度的时候，我们其实是缺少一个黑客攻击手法的大盘的（没有分母，没办法谈分子）

这个东西是在试图贡献一个分母。

有了分母（虽然短期内某些精度和深度还不是很具体），至少我们有了共同参考的东西。

进攻和防守方，都可以拿它做一个比较。

当然我知道肯定有很多的进攻手段并不在这个表格里体现，但是未来可以往里面加（具体的use case）

也不是每一个格子都需要防守好（理论上一次完整的进攻，可能触及多个TTPs，任何1个环节的有效运营都可能阻断这次进攻）

拿它来作为大盘的指导，有助于统一管理语言。