这篇文章挺不错的，拿来和大家分享一下。
摘自：http://www.secpulse.com/archives/34805.html
安全行业的第三流派-CSOs
目前在大多数行业后加入者的眼中“二进制”和“脚本”流派广为人知，虽然他们是安全行业的主力军，但除了微观对抗之外安全是一个很大的工程，比如企业安全管理，我把他们归入安全行里的第三流派-CSOs，加了s跟scriptkids一样表示他们是一个群体，这个群体从生态链的顶端链接着绝大多数从业者和安全厂商。
企业安全是不是发现漏洞然后修漏洞，再设置一下防火墙之类的？假如你的公司只有一个产品，只有2台服务器，只有3个程序员写代码，我认为这个说法不能算错。不过在绝大多数情况下，企业安全远不止于此。渗透性测试和对抗能不能算企业安全？在一个过于纸上谈兵的企业我觉得这是不错的切入点，不过局部对抗发生于企业安全的各个场景中，他只能算是缩影，不是全貌。企业安全是什么对传统乙方安全公司，对新兴的业务安全公司移动安全公司，对甲方的互联网公司，对甲方的传统公司，对咨询顾问，对漏洞研究者，对活跃于各大SRC上的白帽子们的诠释肯定都不一样。
先说一下我自己的经历，以便了解我是从什么角度来看待这一问题的，学生时代跟现在的很多白帽子一样玩玩渗透，玩玩二进制，在过去那个叫幻影（Ph4nt0m）的组织里，大学毕业后即进了绿盟做安全服务和咨询，这是乙方中离甲方安全最近的职能，接受了绿盟对传统安全体系和方法论教育，有些10年前的东西放到今天都还会觉得很高大上，现在的安全行业里除了显得有些空洞的安全标准的传承，要么就是很浅的木桶理论之类的外延的理解，尤其在遇到互联网崛起时，攻防受追捧，有些东西因为没有收到金钱的认可很多人就直接把这一部分东西给扔了或自我否定了，其实有些思想跟技术表现形式一点关系都没有，放到今天仍然是很实用的技能。在绿盟最大的便利并不是下班路上随便都能找到能聊exploit技术的大牛，而是视野：从金字塔视角看到安全的整体解决方案，囊括组织、管理和技术3方面的东西，覆盖全行业全价值链过程的技术方案，算上第三方的话几乎涵盖市面上所有的安全产品和解决方案。有人看到这些会问这不是传统安全那一套吗？我说且不急，听我慢慢讲，而且我可以剧透的说之后几十篇都是围绕互联网企业安全的，并不打算在传统安全上花很多篇幅，只是需要区分一下企业安全实际的状况和某些厂商为了兜售自己的产品而宣扬的概念是有所不同的，大多数厂商都会避开自己的弱项而在市场活动及软文上专注的强调自己擅长的概念。离开绿盟后我去了甲方，一家大型网游公司，08年那时将近万台的物理服务器分布于30多个IDC的规模似乎比当时搜狐全站的IDC规模还要大一些，跟现在一样那时候也是社会上的公司普遍缺少安全负责人的时代，我也有幸组建了一支属于自己的安全团队，成为当时少数的安全总监之一，团队的这些人现在遍布互联网行业的半壁江山，且都是安全部门独当一面的骨干。在这段时间我身体力行了从乙方到甲方视角的过渡，从零开始建立安全体系，真正把乙方玩的东西在一家甲方公司落地了，我的方法思路过程跟某些互联网公司不太一样，因为那时候BAT的安全人员大多是毕业后直接去的甲方，一开始就做甲方安全，而我是从乙方到甲方，所以实践上更多了参考了乙方的方法论，除了攻防之外多线并行，直接建立较完整的安全体系，在遇到上海的网游业被腾讯包抄整体沉沦的时候，我也失去了继续深挖甲方安全建设的兴趣。之后我去做了一家webgame公司的技术负责人，社会俗名CTO，由安全转向全线技术管理，说实话在这段时间里我并不是特别重视安全，一方面跟自己是安全出身有关，另一方面这确实是屁股决定脑袋的事情，不是安全不重要，而是有很多事情比安全更重要。安全这个事情说白了就是当你有100w的时候拿出2w买个保险箱装它们你觉得值，但你只有2w的时候要拿出8k买保险箱大多数人都会囊中羞涩。这也是我在知乎上回答的那个问题，为什么做安全一定要去大公司的原因之一。我窃以为很多公司的CEO、CTO的对安全重视，翻译过来应该是：被黑是一件很负面的事情，所以想找个人筹建团队打包了，只要不出事他们就不会太想起这事，但不是心理真的认为安全非常重要，也不会当成是一种竞争力，这句话并不是在映射过去，而是当下国内那么多对企业安全负责人的招聘在我看来也就是那么回事。之后我去数字公司经历了短暂的时光，再次以乙方的身份拜访了企业级客户，很偶然的发现大多数乙方的顾问或工程师其实都没有真正做过企业安全管理的经验，虽不能把这些直接等价于纸上谈兵，不过确实是乙方的软肋，在竞争性的销售活动中，三下五除二就“把别人说没了”。在甲方企业高层的眼中，攻防这档子事可以等价于我花点钱让安全公司派几个工程师给我做渗透测试然后修漏洞，不像大型互联网公司那样上升为系统化和工程化的日常性活动。离开数字公司后我到了全球化的公司-菊花长从事产品线安全，第一个项目是云计算，产品线安全属于甲方安全又跟很多甲方安全不太一样，他比传统意义上的甲方安全介入的更深，覆盖率更高的SDLC，直接导向产品设计的源头，对绝大多数甲方而言你也许在用OS的Dep&ASLR，也许在用各种容器，但你很少会自己去发明轮子，你也许会自己造一个WAF这样的工具，但你可能很少会像微软那样要自己去搞一个EMET这种涉及安全机制层面的东西，但在产品线安全里，这一切都会更进一步，不只是像互联网公司那样关注入侵检测、漏洞扫描等而是从设计和威胁建模的角度去看整体和细节的安全。这又拓展了我从R&D的视角看待以及分析安全问题的眼界。至此，我既不属于脚本二进制，我也不属于乙方咨询顾问派，也不单纯属于甲方CSO，而是站在一个较全面客观中立的立场，我不会说某些方式属于纸上谈兵，也不会把攻防捧的至高无上，我认为这些都属于偏激的话。
好了，切入第一篇的正题，企业安全是什么？我认为它可以概括为：从广义的信息安全或狭义的网络安全出发，根据企业自身所处的产业地位、IT总投入能力、商业模式和业务需求为目标，而建立的安全解决方案以及为保证方案实践的有效性而进行的一系列系统化，工程化的日常安全活动的集合。怎么感觉有点咬文嚼字？好吧，这里面的每一个项都会决定你的安全整体方案式什么，哪怕同是中国互联网TOP10中的公司其安全需求也完全不一样。
有人也许会觉得CSO干的活有点虚，但凡偏管理都是纸上谈兵。我不直接回答这个问题，我只举一个例子。大多数身在这个行业的人都知道社工库遍地都是，入侵者甚至站在了大数据的维度，国内的数据库绝大多数除了password字段加盐值存储，其余信息都是明文保存。而在欧美等地隐私保护是有明确的法律规定的，映射到数据持久化这个细节，就是需要满足一定强度以上的加密算法加密存储，CSO就是需要制定这些策略的人，你难道说这些都是形而上学无用的安全措施么？在互联网公司，安全负责人是会较多的介入到日常的技术性活动中的，但随着组织规模的扩大和官僚程度的加深，CSO不再可能表现的像白帽子一样专注于攻防对抗的细节也是一个无法回避的现实问题。是不是一定要说出诸如CSRF时IE和其他浏览器的区别这样的问题才算是合格的CSO，我觉得这个看具体场景，对于国内排名TOP5以后的互联网公司我觉得这个需求算合理范畴，但对于规模非常庞大的公司而言，这个需求显然太苛刻了，比如我所在公司，CSO属于法务类职位而不是技术类职位。
不想当将军的士兵不是好士兵，虽然有技术路线，不过我估计这个行业里至少有一半以上人想过要当CSO，但是CSO这个职业又跟某些大牛们表达的不完全一致，所以下面的篇幅会继续写，至少在技术层面，CSO不会只停留在微观对抗，而是会关注系统性建设更多一点。（http://www.ayazero.com/?p=8）
企业安全涵盖哪些事情
从我在绿盟所受的安全教育来看大致分为以下几方面：
1. 网络安全：基础、狭义但核心的部分，以计算机（PC、服务器、小型机、BYOD……）和网络为主体的网络安全，主要聚焦在纯技术层面
2. 平台和业务安全：跟所在行业和主营业务相关的安全管理，例如反欺诈，不是纯技术层面的内容，是对基础安全的拓展，目的性比较强，属于特定领域的安全，不算广义安全。
3. 广义的信息安全：以IT两个字为核心，包括广义上的“Information”载体：计算机数据库意外还有包括纸质文档、机要，市场战略规划等经营管理信息、客户隐私、内部邮件、会议内容、运营数据、第三方的权益信息等但凡你想得到的都在其中，加上泛“Technology”的大安全体系
4. IT风险管理、IT审计&内控：对于中大规模的海外上市公司而言，有诸如SOX-404这样的合规性需求，财务之外就是IT，其中所要求的在流程和技术方面的约束性条款跟信息安全管理重叠，属于外围和相关领域，而信息安全管理本身从属于IT风险管理，是CIO视角下的一个子领域
5. 业务持续性管理：BCM（Business Continuity Management）不属于以上任何范畴、但又跟每一块都有交集，如果你觉得3和4有点虚，那么BCM绝对是面向实操的领域。最近前有网易、中有支付宝、后又携程，因为各种各样的原因业务中断，损失巨大都属于BCM的范畴。有人会问这跟安全有什么关系？安全是影响业务中断的很大一部分可能因素，例如DDOS，入侵导致必须关闭服务自检，数据丢失隐私泄露等。又会有人问这些归入安全管理即可，为什么要跟BCM扯上关系，做安全的人可以不管这些吗？答案自然是可以不管，就好像说“我是个java程序员，JVM、dalvik（ART）运行原理不知道又有什么关系，完全不影响我写代码！” 事实上BCM提供了另一种更高维度，更完整的视角来看待业务中断的问题，对于安全事件，他的方法论也比单纯的ISMS更具有可操作性，对业务团队更有亲和力，因为你知道任何以安全团队自我为中心的安全建设都难以落地，最终都不会做的很好
6. 安全品牌营销、渠道维护：CSO有时候要做一些务虚的事情，例如为品牌的安全形象出席一些市场宣介，presentation。笼统一点讲现在SRC的活动基本也属于这一类。
7. CXO们的其他需求：俗称打杂。这里你不要理解为让安全团队去攻击一下竞争对手的企业这样负面向的事情，而是有很多公司需要做，但运维开发都不干，干不了或者不适合干的事情，安全团队能力强大时可以承包下来的部分，事实上我的职业生涯里就做了不少这样的事情。
基础的网络安全是绝大多数在甲方的安全团队能cover的事情，不管你的安全团队能力如何，在公司里有无影响力，这个是必须要做的因为这是把你招过来的初衷。再往后的发展，是否止于此则看各人的想法，对于沉醉攻防技术的人其实不需要往后发展了这些足够了，但如果你的安全团队富有活力和想法，即便你想止于此他们也不干，把部门做大做强是这些人的愿望，只有这样才能给安全团队更大的空间，因为这点跟乙方是不一样的：对于乙方而言你可以在某个单点领域上无限深挖，而不会遇到天花板，因为你始终是在满足主营业务的需求，即使你成为骨灰级的专家公司也会对你在某方面创新有所期待而给你持续发展的可能性，但是在甲方，安全不是主营业务，归根结底是一个保值型的后台职能，不是一个能创造收益的前台职能，他是一个成本中心而非盈利中心，他的成本的大小跟业务规模以及公司盈利能力相关，公司发展时他的budget和headcount会发展，业务停滞时安全做的再好也不会追加投入，因为无此必要。反面的例子也有：做的不好反而追加投入的，那是一种政治技巧而非现实需要。如果你在乙方的研究部，无论你的漏洞挖掘技能多牛逼，公司都不会跳出来说“你已经超出我们需求了，你还是去更NB的公司吧”（通常情况）。但是在甲方，假设是在一个国内排名大约TOP5-TOP10的互联网公司，养一个漏洞挖掘的大牛也会觉得很奇怪，他是在给公司创造价值还是在自娱自乐是会受到质疑的，CSO也会被质疑是否花了大价钱挖来的人不是出于业务需要而是用于扩大自己团队在业内影响力这种务虚的事。假如公司到了google这种级别，有一大堆产品，储备大牛则是顺利成章的，业务上显然是有这种需求的，不过还是要看产出是否对主营业务有帮助，工作成果不能转化为主营业务竞争力的尝试性活动在公司有钱的时候无所谓，在公司收紧腰带时则其存在价值会受到质疑。
以狭义的安全垂直拓展去发展甲方安全团队的思路本质上是个不可控的想法，筹码不在CSO手中，甚至不在CTO手中，而是看主营业务的晴雨表，也就是我以前微博上说的，甲方安全是要看“脸”的，这个脸还不是指跨部门沟通合作，而是在最原始的需求出发点上受限于他们。因此有想法的安全团队在（1）做的比较成熟时会转向（2），（2）是一个很大的领域，发展的好安全团队的规模会x2，x3，并且在企业价值链中的地位会逐渐前移，成为运营性质的职能，结合BCM真正成为一个和运维、开发并驾齐驱的大职能。
BCM在很多人眼里就是DR（灾难恢复），DR其实只是BCM中的一个点，属于下层分支。不过这对技术领域的人而言是最直观的部分，DR在互联网公司里由基础架构部门或运维主导，不过对于强势的甲方安全团队其实也是能参与其中一部分的，我之前也主导过这些，当然也是受到了绿盟的教育以及我的“前辈们”的启发。有兴趣的可以看一下BS25999
广义的信息安全，比较直观的映射就是ISO2700x系列，行业里的绝大多数人都知道ISO27001和BS7799.不展开了，对真正有安全基础的人而言都是很简单的东西。在企业里能否做到广义的安全，主要看安全负责人和安全团队在公司里影响力，对上没有影响力，没有诠释利害关系和游水的能力自然也就做不到这些，另一方面，狭义安全主要对接运维开发等技术面公司同僚，但是广义安全会对接整个公司的各个部门，对于沟通面的挑战来说又上了一个新的台阶，似乎在我看来这主要取决于安全的领队人物自己拥有什么样的知识结构以及他的推动能力如何。
对于（4），如果你所在的组织有这方面的需求，安全职能自然也会参与其中，是否刻意去发展他则看自己需求，对我朋友中某些做过IT治理和风险咨询的人相信是有能力一并吃下的，如果是技术派我就不建议你去搞了。
（6）属于水到渠成的事情，到了那一步你自然需要考虑，就算你不想公司也会让你去，就像我现在明明做技术活，却也不知道为啥会跟这一类事情挂上钩。
（7）有人看时自动过滤了，不过安全负责人自身是否有瓶颈，能否在企业里发展起来跟这条有很大关系，甚至有很多从（1）发展到（2）（3）的人都需要借助（7）这个渠道，点到为止不多说了。。。
对于互联网公司，我建议做1、2、5；对于传统行业，我建议做：1、3、4、5。
在互联网行业安全包括哪些内容，我觉得可以概括为：
信息安全管理（设计流程、整体策略等），这部分工作约占总量的10%，比较整体，跨度大，但工作量不多。
基础架构与网络安全：IDC、生产网络的各种链路和设备、服务器、大量的服务端程序和中间件，数据库等，偏运维侧，跟漏洞扫描，打补丁，ACL，安全配置，网络和主机入侵检测等这些事情相关性比较大，约占不到30%的工作量。
应用与交付安全：对各BG，事业部，业务线自研的产品进行应用层面的安全评估，代码审计，渗透测试，代码框架的安全功能，应用层的防火墙，应用层的入侵检测等，属于有点“繁琐”的工程，“撇不掉、理还乱”，大部分甲方团队都没有足够的人力去应付产品线交付的数量庞大的代码，没有能力去实践完整的SDL，这部分是当下比较有挑战的安全业务，整体比重30%+，还在持续增长中。
业务安全：上面提到的（2），包括账号安全、交易风控、征信、反价格爬虫，反作弊反bot程序、反欺诈、反钓鱼、反垃圾信息、舆情监控（内容信息安全）、防游戏外挂、打击黑色产业链、安全情报等，是在“吃饱饭”之后“思淫欲”的进阶需求，在基础安全问题解决之后，越来越受到重视的领域。整体约占30%左右的工作量，有的甚至大过50%。这里也已经纷纷出现乙方的创业型公司试图解决这些痛点。
对整体介绍的部分在前面的篇幅讲的比较多，主要目的是希望“视野”部分不缩水，这些概念在后面篇幅都不打算再展开了，如果你迟迟没看到技术篇，很正常，这只是一个开头而已。下一篇谈谈互联网企业安全管理和传统行业安全管理的区别。（http://www.ayazero.com/?p=19）
互联网企业安全管理和传统行业的区别
总体来看，传统安全偏重管理，“三分技术，七分管理”，互联网行业偏重技术，我认为应该倒过来。其实这种说法也是不准确的，到底什么算技术，什么算管理，这些都没有明确的定义，安全领域大部分所谓管理不过是组织技术性的活动而已，充其量叫技术管理，如果你较真这些理论那你就掉坑里了。
先说一下传统安全和互联网安全的建设需求上的差异：
传统安全：
- IT资产相对固定
- 业务变更不频繁
- 网络边界比较固定
- IDC规模不会很大甚至没有
- 使用基于传统的资产威胁脆弱性的风险管理方法论加上购买和部署商业安全产品（解决方案）通常可以搞定。
互联网安全生态，对于大型互联网而言，需要应对：
- 海量IDC和海量数据
- 完全的分布式架构
- 应对业务的频繁发布和变更
同时架构层面关注：
- 高性能
- 高可用性
- 扩展性
- TCO（ROI）
在规模不大的互联网公司，传统的风险管理方法论是可以沿用的，但在大型互联网公司传统的方法论可能会失效，因为你可能连基础架构上跑什么业务都搞不清，你想理清所有的系统接口间的调用关系以及数据流去检视设计风险以及设置细粒度的访问控制就是件不现实的事情，产品线极多时业内没有任何一个团队敢说自己有能力支持全产品线，对于高速发展的业务，当你理清了你想要的说不定架构又发生变化了，只有对占公司整体营收比较主要的以及培育性质的战略级的核心业务才有必要去深入调研并随之update，其他的还是要依靠自动化手段。
从安全建设上来看，传统安全建设：
在边界部署硬件防火墙、IPS/IDS、WAF、商业扫描器，堡垒机、在服务器上安装防病毒软件，集成各种设备、终端的安全日志建设SOC，当然购买的安全硬件设备可能远不止这些。在管理手段上比较重视ISMS（信息安全管理体系）的建设，重视制度流程、重视审计、有些行业也必须“等保合规”。
其实这里还有一个很大的区别就是，互联网有生产网络和办公网络的概念，即便最近Google声称取消内网也是针对办公网络而非生产网络，互联网行业的大部分安全建设都围绕生产网络，而办公网络的安全通常只占整体的较小比重。但是对于某些传统公司，他可能完全没有生产网络而只有办公网络，他的网络安全也就变成了办公网络的网络安全。但我推测随着社会互联网+进程的加速，很多传统的公司也会有自己的生产网络，最终都变成和互联网公司一样的形态。所以对于那些在给传统企业客户提供咨询和解决方案的乙方的同学，如果你们不学习互联网安全，也会被淘汰。
互联网的生产网络的解决方案基本上都是以攻防为驱动的，怕被黑、怕拖库、怕被劫持就是安全建设的最直接的驱动力，互联网公司基本不太会考虑等保、合规这种形而上的需求，只从最实际的角度出发，这一点是比传统行业更务实的地方。最近也遇到一个例子，说要在服务器上装防病毒软件，一看就知道是传统行业来的思路，不是没有真正做过互联网企业安全就是没被业务线挑战过，在大型互联网，光是性能损耗、运维成本和软件成本这几条就能分分钟把这种需求干掉，更不用进入对于服务器防护这种更实际的话题了。很多标准说到底都是各厂商参与编写，博弈并达成妥协，有利于自己产品销售的代言白皮书，并不是完全站在建设性的角度的，作为乙方卖卖无脑客户赚点钱自然无可厚非，但在真正的甲方做企业安全生搬硬套是会受到质疑并逐渐失去影响力的。
对于超过一定规模的大型互联网公司，其IT建设开始进入自己发明轮子的时代，安全解决方案开始局部或进入全部自研的时代，例如不会购买硬件防火墙，而是用服务器+Netfilter的方式自建，不会部署硬件IDS/IPS，而是用其他方式来解决这个问题。其实不难理解，规模小的时候买台硬件防火墙放在最前面，省事。但是规模大了我去买1000台硬防放在IDC机房？光￥就受不了啊。其次，基于CAP理论和Map-reduce衍生的一系列互联网架构，本质上都具有“无限”水平扩展能力，而传统的硬件盒子式的解决方案其设计大多源于对过去体系架构的理解，基本不具备扩展能力，完全不能适应大规模的互联网架构，总体上属于相对封闭的单点式防护。在这种情况下甲方安全团队自己动手去打造完全围绕自身业务的解决方案也就成了必然趋势。
自研或对开源软件进行二次开发+无限水平扩展的软件架构+构建于普通中低端硬件之上（PC服务器甚至是白牌）+大数据机器学习的方式是目前大型互联网公司用来应对业务的持续性增长的主流安全解决方案。是否真的到了机器学习阶段这个有点难说，但是安全进入大数据时代则是很稀松平常的事了。
对办公网络和雇员信息安全管理而言，互联网公司的文化比较open，一般不太会维持激进的安全政策，这点也是跟传统行业差别比较大的地方（http://www.ayazero.com/?p=25）
针对中小企业的安全解决方案
为了快速成文的无脑版本，基本没去思考，赶工迹象严重，将就吧。。
大规模生产网络的纵深防御架构
纵深防御这个在安全行业被用的很烂的词，乙方的顾问写方案时信手捏来，我想大家的理解可能并不一致。其实我比较赞同lake2用的“河防”以及数字公司用的“塔防”的概念，这些都是比较贴近实际的。下面的篇幅仅从自己的理解来展开，并且主题限定在大规模生产（服务）网络而不是办公网络。当下各安全公司都偏爱APT和大数据威胁情报之类的概念，在办公网络我想这些是他们圈地运动的战场，不过生产网络似乎仍然遥远。自动化运维的交互模型跟大幅度人机操作的办公网络完全不同，而且现在号称机器学习的方法在实操中表现的很一般，效果不如对攻防模型抽象后定义规则的方式。这里并不是在否定机器学习的方法，只是表达离成熟还尚有距离（我不是在说QVM，请不要对号入座）
先说一下互联网安全的一些理念性的东西，首先没有漏洞是不可能的，互联网追求快速交付，把安全做的太厚重是“不满足业务需求的”，为追求极致的低缺陷率而大幅增加发布成本是不切实际的，但是互联网安全有几个比较核心的需求：快速检测、有限影响、快速溯源，快速恢复。通俗解释一遍就是：允许带着一些问题上线，但是有bug或入侵我能快速检测到而不是无知无觉的状态，就算发生了攻击或入侵，我能做到入侵者所获取的权限和造成的影响尽可能的小，并且我有途径或快照还原入侵过程做根因分析，安全事件能在基本不响应不中断业务的情况下恢复到健康状态。当然这个话题也太大，这次只讨论其中关于“有限影响”的部分，在谈及防御之前先看一下攻击路径：
Plan-A：通常路径，从目标系统正面找漏洞，远程直接rootshell在现代基本没有了，大多数是从应用为入口，先获取上层应用的权限，然后通过上传webshell等方式间接获得系统shell，最后提权获得rootshell，后面继续扩大战果的事情就不提了，安全建设的思路自然是要反过来，阻止你扩大战果。
Plan-B：如果正面没有明显可利用的漏洞的话就需要曲折迂回，从周围信任域开始下手，这个信任域是广义上的，包括可arp重定向的，可嗅探的，可会话中间人的，可链路劫持的，相同内网的，口令满足同一规律的，互联互通信任关系的，灾备或镜像站点等，获取一个点后再折返，之后的路径与A类似。
Plan-C：直接针对生产网络不行的话，就需要考虑社会工程学了，针对管理员和办公网络的APT，水坑攻击，针对应用后台管理员的社会工程学技巧，搞定SA自然也就搞定了所有服务器。
安全建设是反入侵视角，针对攻击活动中的每一步“埋点”，埋点的寓意在于我假设攻击者到了这一步，我要阻止他进入下一步或者不能带着完全的火力进入下一步还能全身而退。当然这里只针对有限影响，入侵检测之类的部分这里先不展开，后续会有专门的话题。
第一层安全域划分，这个安全域是对业务的抽象，并不是对物理服务器的划分，在大规模分布式架构中，同一个安全域的机器可能并不一定位于同一个物理机房，但是他们对应相同的安全等级，共享一组相同的访问控制策略，只对其他安全域或Internet暴露有限的协议和接口，即使攻击者渗透了其他相邻的服务器，也只能扫描和访问这个安全域内有限的几个端口，没办法自由渗透，这个问题主要解决Plan-B曲线救国时被入侵者“误伤”，以及获得单点root后进一步渗透的扩散，希望能把安全事件爆发的最大范围抑制在一个安全域中，而不是直接扩散到全网。
第二层是基于数据链路层的隔离，只有2层隔离了才能算真正隔离，否则只在3层以上做ACL也是不行的，仍然会被ARP。2层使用VPC，vxlan，vlan等方法相当于在安全域的基础上对一组服务器以更细的粒度再画一道圈，进一步抑制单点沦陷后受害源扩大的问题。在不是特别大的网络中可以直接跳过安全域到这一步。当然安全域的概念在任何时候都是存在的，仅仅是在做划分的事情但不去套这个名词。
二层之上就是协议端口状态过滤，这是绝大多数“防火墙”的场景。解决的还是对黑客暴露的攻击面的问题，即使我的加固做的不到位，不必要的服务没有清理干净，开放了有问题的端口，甚至有些端口上跑着的服务还有漏洞，但是因为被防火墙过滤了，路由不可达，所以攻击者利用不了，他只能在对外或对信任域暴露的端口上去想办法。本质一点就是给攻击者提供“窄带”，有限的访问通道。不过在有复杂嵌套引用关系的大规模生产网络中，出于运维成本的考虑，有时候访问控制策略不会做的很细粒度，因为那样的话如果有台机器挂了换个ip都麻烦。这也是安全的妥协，我之后会有单独篇幅讲做安全是否需要妥协，应该如何妥协，底线是什么。
再往上一层是现在讨论的最多的一层，其实从图中也可以看出你平日的工作都是聚焦于哪层。这一层单独拆开都可以再建一个纵深防御的子体系。应用层通常是暴露在Internet上的攻击面，这一层主要是解决认证鉴权、注入跨站上传之类的应用层漏洞，尽可能把入侵者堵在第一人口之外。如果你在开发WAF，那你对应的也是这一层的工作。
应用层上方是容器、运行时环境。这里的目标是假设我的服务器上的应用程序有漏洞，且攻击者找到了漏洞，我不希望这个漏洞能被成功利用直接跳转到系统权限，而是希望能在这一步阻止他，办法就是通过容器加固，比如阻止一些危险函数的运行，比如上传了webshell但是不被解析执行，比如你想执行eval（）并用种种方法变形编码字符窜拼接逃过了应用层的检测，但是到了运行时其实是相同的底层指令，那么无论你在上层多么努力的变形我都会希望在更底层把你揪出来，哪怕不直接阻断我也至少报个警。在绝大多数入侵活动中，上传或生成webshell是从应用权限向系统权限转化的关键一步，所以这一层的防御也是比较重要的。以后如果有时间单独篇幅讲如何对抗webshell。
如果不幸之前的都没阻止攻击者，对方已经得到了普通用户的shell”$”，那么我肯定不希望你继续得到rootshell，对抗的办法就是大家常见的那些系统加固项，那些文章洋洋洒洒写了一大堆主要就是用在这个场景的，不过最主要的还是对抗本地提权以及内核提权，攻击免疫或称攻击缓解机制例如SMEP、SMAP、DEP、各种ASLR，stack-canay，read-only .PLT .GOT等都是在这里“埋点”，其他的诸如umask=022等也是在这里埋点，似乎看上去这些不太需要安全team的介入，好像都是OS默认的机制？其实不然，安全做到偏执的程度还是有自己出手的地方，Android出手比标准的Linux更快一点，也许以后就真的没太多需要自己出手的地方了。不过当下各种基于LXC的容器，越来越多的multi tenant的云环境，隔离的机制完全依赖于kernel的健壮性，这些场景下对抗这一层的攻击都显得尤为重要。
如果被拿走了root自然是很令人不爽的事，但还不是最令人不爽的。如果有一天当你的1万台服务器中有500台被人搞了，而且还不能推断是不是装了kernel rootkit的情况下，这种感觉是最要命的，你生了个肿瘤手术摘掉也就算了，那种情况就像你手术完都不确定摘了没，即便500台服务器备份数据重装系统都不彻底，而且近似于你某个子业务要处于离线状态这种极其影响可用性的事情业务部门会把你逼疯掉。所以不是特别需求要干掉LKM，/dev/kmem，限制/dev/mem的全地址空间读写，另外kernel MAC内核强制访问控制也能限制root只能做有限的事情，尽管理论上内核提权还是能控制一切，不过要在没有开发环境的服务器上实现完整的kernel rootkit功能并保证不在用户态留下蛛丝马迹的概率还是比较低。这样做还有一个好处，把入侵检测聚焦于用户态，不要动不动就去装一堆内核级别的重量级玩意儿，大规模高并发的生产环境伤不起。
在云计算环境中，上面那步可能还不算是单点渗透的终结，更底层还有hypervisor，如果攻击者逃逸出VM那就比较狼狈了，每个厂商都需要考虑一下VMM的保护方案，现在hypervisor这一层很薄不会做的很重，似乎还没有特别成熟和通用的办法，不过肯定会发展起来，会有更多类似于XSM这样的方案。
在一个真正建立纵深防御的系统中，入侵者一般到不了root这一步就会被揪出来，只不过完整的纵深防御要以后的篇幅慢慢写了，这里只是选取了其中一个维度来试图解读这个概念。另一方面，完整的纵深防御体系只有大型互联网公司才可能全覆盖，因为跟安全建设成本有关，所以又涉及另外两个话题：不同规模企业的安全需求和同一公司在不同安全建设阶段的需求，以后再展开。(http://www.ayazero.com/?p=33)
不同规模企业下的安全管理
创业型公司
对于创业型公司而言，安全不是第一位的，我在唱反调么？应该只是大实话而已。安全建设的需求应该是：保障最基本的部分，追求最高性价比，不求大而全，映射到技术实现应该是：
- 基本的补丁管理要做
- 漏洞管理要做
- L3-L7的基本的访问控制
- 没有弱口令，管好密码
- 账号认证鉴权不求各种高大上的基于条件的实时风控，但求基本功能到位
- 办公网络做到统一集中管理（100人以上规模）和企业防病毒，几个人的话就完全不用考虑了，APT什么的就听一听拉倒了
- 流程什么的就比没要去搞了，有什么需求口头约束一下
- 找两篇用到的开发语言的安全编程规范扔给你们的程序员看看，安全专家们说的SDL就不要去追求了，那个东西没有一堆安全“准”专家玩不起来
- 系统加固什么的，网上找两篇文章对一下，确保没有root直接跑进程，chmod 777，管理后台弱口令对外这种低级错误，当然有进一步需求也可以参考后面的技术篇中的措施
- 实惠一点的，找个靠谱的白帽子兼职做一下测试，或者众测也行
是不是觉得简陋了一点？我估计很多乙方提供的服务除了卖产品之外也不会比这个效果更好了。不过呢现在不少创业公司是拿了不小的风投的，也没那么寒酸，另外一个很重要的特征，创业公司基本都上公有云了，不会自己再去折腾IDC那点事了，所以相对而言以上措施中的一部分可以等价于：
- 使用云平台提供的安全能力，包括各种抗Ddos，WAF，HIDS等
- 使用marketplace中第三方安全厂商提供的安全能力
具体怎么选怎么用就不展开了，不过不要因为迷信云平台关于安全能力的广告而自己不再去设防，毕竟针对租户级的通用型的安全方案其覆盖面和防御的维度是有限的。
大中型企业
这个层次对应市场上大多数公司的安全需求，他的典型特征是，业务的营收的持续性需要安全来保障。公司愿意在IT安全上投入固定的成本，通常小于IT总投入的10%，不过这已经不错啦，这时候开始有专职的安全人员或安全团队，建设上重视效果和ROI，会具备初步的纵深防御能力。对应技术上的需求为：
- L2-L7每一层拥有完整安全设计
- 对所有的服务器、PC终端、移动设备具有统一集中的状态感知、安全检测及防护能力
- 应用层面细粒度控制
- 全流量入侵检测能力
- 无死角1day漏洞发现能力
- 在安全等级较高的区域建立纵深防御和一定的0day发现的能力
- 初具规模的安全专职团队
- 对应用交付有自主的评估和修补能力
- 从IT服务层面建立必要的流程，业务持续性以及风控应急措施
- 对业务安全形成自己风控及安全管理方法论
- 将难以自己实现的部分外包
好像跟前面的描述比一下子抽象了？是的，这个层级的安全需求没办法很具体的量化。不同的业务模式对应的安全实现还是有很大的不同，加上这个区间里的公司营收规模可以差很大，对应的安全投入也可以差很多。那什么样的公司归入这个区间呢？比如四大行，国内TOP10甚至TOP5以后的互联网公司，大量的电信、金融、政府、能源等企业都属于这个区间，但我为什么不把BAT归入这个区间，这样的分类岂不是不科学，我之所以这样分类完全是从安全建设的复杂度上去考量的，而不是从安全建设的资金投入上去归类的。很多比如金融行业的安全投入很大，但这些解决方案大都是靠花钱就能买来的，而BAT的方案花钱不一定能买得到，很多都需要自己动手去创建，对安全团队的定位、能力和需求完全不一样。那BAT以外较大的互联网公司呢，我觉得他们会玩些各自特点的小花样，但是不会进入大范围的复杂的安全建设，这是由公司的整体面和业务决定的，不需要过分保障和超前业务的安全建设。
在往上一层大型互联网企业，这个留到后面的话题。(http://www.ayazero.com/?p=38)
安全建设需求：生态级公司vs平台级公司
事实上并不存在我说的这种分类，即生态级公司和平台级公司之间没有必然需要这么做，必然需要那么做的条条框框，但是两者的安全建设需求之间确实不仅仅是量的差别而是质的差别。
主要差别表现在是否大量的进入自己发明轮子的时代，即安全建设需要依托于自研，而非采用商业解决方案或依赖于开源工具的实现。上一篇提到金融行业的高成本安全整体方案几乎全都依赖于商业方案，这是跟大型互联网安全建设有很大的区别，假设金融行业的CSO去互联网公司可能会比较吃力，反之在适应金融行业的BCM后则能轻松驾驭，这个观点因为有明显的倾向性，所以肯定是会受到挑战的，不过我写这些的本意也并不是为了讨好所有人，时代的浪潮总归是有所指，不会所有的人都是受益者。
那么平台级公司和生态级公司的区别又在哪里，从表象上看，生态级公司的大型基础架构如果用传统的安全方案几乎都无法满足，所以会大量的进入自研，而平台级公司则会依赖开源工具更多一些，不会全线安全工具进人自研。如果有预算的话也会优先投在“业务安全”侧，比如反欺诈平台等等，而不会自己去搞入侵检测，当然这有可能是个伪命题，有可能当我的企业安全系列全篇写完时，乙方公司也开始提供具有可扩展性，能应对分布式架构的方案，或者当时间尺度拉的长一点，平台级公司每年在自研上投入一点点，多年之后也具备了BAT级别的安全能力也并非完全不可能，不过这些都是理想状况，现实总是受到多方面因素制约的。
首先影响的第一因素是技术驱动的层次，在底层还是在应用层驱动业务。表象上平台级公司和生态级公司都是以pc端web服务为入口的平台应用和以移动端APP入口的移动应用，有的依赖于一些PC客户端或移动端偏底层的APP，但在技术实现方式上，平台级公司更多的直接使用或少量修改开源软件，而生态级公司的IT基础设施则会类似于Google的三篇论文一样，不仅仅停留在使用和少量修改，而是会进入自己造轮子的阶段，其中所造的轮子是否对业界有意义这种问题暂时不去评价，但对应的安全建设则反映出平台级公司的安全主要围绕应用层面，而生态级公司的安全会覆盖基础架构和应用层面两块。直接使用开源工具的部分交给社区去处理，自己跟进打补丁就行了，但如果是自己开发的，那么就需要自己去解决一揽子的安全问题，比如Google造了Android这个轮子，那Android一系列的安全问题Google需要自己解决，比如阿里自己去搞了一个ODPS，那阿里的牛人也需要解决这个，再比如我所在公司在物联网领域造了LiteOS这个轮子，自然也要去处理对应的问题，而这些偏底层的问题显然早已超出应用安全的范畴，也不是一般的甲方安全团队有能力应对的。其实有些平台级公司也是发明了一些轮子的，比如自动化运维工具，比如一些NOSQL，不过IDC规模两者之间仍然差的比较远，上层的业务复杂度也有差距，支持的研发团队的规模也有差距，对安全工具的自动化能力和数据处理规模仍然存在阶梯级的差别，这一点也决定了为什么要自研。安全其实只是IT整体技术建设的一个子集，当整体技术架构和实现方式进入自产自销阶段时，安全建设也必然进入这个范畴。对于很多实际上依靠业务和线下资源驱动而非技术驱动的互联网公司而言，安全建设去做太多高大上的事情显然是没有必要的。
第二因素是钱，钱也分为两个方面（1）成本（2）ROI。假设安全投入按IT总投入的固定10%算，又假设生态级公司的安全建设成本是平台级公司的5-10倍，这个成本除了带宽、IDC服务器软硬件，还有技术团队，加起来才是总拥有成本TCO。10个人的安全团队和100个人的安全团队能做的事情相差太大，具体可以参考我在知乎上的帖子《为什么从事信息安全行业一定要去大公司？》http://www.zhihu.com/question/27356955。还有一方面则类似于“去IOE”，上面提到目前对于大型互联网没有合适的安全解决方案，即使有，这个成本可能也会无法接受，所以假如乙方公司能推出既能支撑业务规模，又具有性价比的方案的话，我认为甲方安全团队真的没有必要再去造轮子了。
第三个因素是人，安全团队的人员数量也只是一个很表面的数字，安全团队的构成才是真实反映，能囤到大牛的安全团队和由初级工程师组成的安全团队显然是不一样的，一方面前者的成本不是所有的公司都能接受，其次，平台不够大即使大牛来了也未必有用武之地。大多数平台级公司的安全团队其知识和经验集中在web/app，应用层协议，web容器，中间件和数据库，生态级公司则扩展至系统底层，二进制，运行时环境和kernel级别，能力积累也存在差别。这里并无褒贬之意，仅在说明业务对技术的需求不一样。
那平台级公司是不是就没有乐趣呢，其实他们也玩一些小花样，比如修改sshd、LVS，加入一些安全特性。可能也会自己定制一个WAF，或者搞搞日志的大数据分析。但比如涉及DPI，全流量入侵检测，SDN，kernel level的安全机制基本上都不会介入。这些对一个规模不是特别大的平台级公司的甲方安全团队而言门槛还是有点高。
自己发明轮子是不是全领域进军呢？也不是，主要还是在入侵检测、WAF、扫描器、anti-DDOS、日志分析等领域。在SDL环节上可能也会自己研发些工具，但未必有直接使用商业工具来的短平快。阿里钱盾、腾讯管家、百度杀毒这些都跟360客户端一样跟生产网络没什么关系，就不去讲了。另外自研有一个原则：都限定在民用领域，不会自己去发明一个RSA算法这样的东西。
国内的平台级公司里也有一个例外–数字公司，因为其主营业务是安全，所以就不会受到安全投资固定占比理论的影响。(http://www.ayazero.com/?p=42)
创业型公司一定需要CSO吗？
转一个我在知乎上的帖子：http://www.zhihu.com/question/27560328
其中的abc轮并不代表企业发展的某种阶段，只是一个象征性描述，写于2015/1/13
最近听说不少创业型公司都在找CSO，也有找到我的，就分享一下我对这个问题的思考。首先这个问题即便是对同一个人而言可能答案也会因时而变（例如我），其次CSO只是一个代表性的称呼，大家不要过于纠结一定要做什么事才算CSO，CSO和CISO又有什么区别之类的，在这个语境下用来指代招聘方想找一个拥有全局安全管理经验的，经验丰富的甚至最好是资深的从业者并且能带一支哪怕是几个人的安全团队，事无巨细能把安全相关的事全部揽过去这样的人。
对于尚在天使融资阶段，找个CSO大多就是去忽悠投资人的，通俗一点理解就是凑一支履历光鲜的队伍去“骗钱”，能不能做事情这个很难说，也不能说人家一定做不了事情，这种只能事后诸葛亮盖棺定论，随便说人不靠谱也是不负责任的，不过我想对于大多数有不错岗岗位的人而言应该是不会去的。
第二种，拿到A轮，业务方向已被证明，业务量不大但进入快速成长期，问题层出不穷，CEO和CTO觉得头疼并且想把这部分压力转嫁出去，理论上是应该找一个懂安全的人的，但是现在这个时间点也就是2015年真的不是一个好时间，在当下很多公司100-200w也经常找不到合适的CSO，创业型公司要在这个层面上争夺安全人才真的是很累的一件事，取而代之应该找2-3个靠谱的安全工程师，然后CTO（技术总监），运维Leader，开发的架构师这几个角色自己遇事应急性补一点安全的知识和方法论，哪怕是充当救火队长赶鸭子上架的方式大家配合一下，累一点应该也能把安全撑起来，不一定非要找一个大牛级的CSO，因为有时候业务量没那么大规模，不一定需要很高level的人，且创业型公司为了保持自己的鲜活也不需要套用大公司的流程和方法，做好基础的运维安全，代码安全，加强一些安全意识，不出问题的时候腾出时间来研究一下下一步怎么做，跟时间和业务增长速度赛跑，跑着跑着，应该就会越来越轻松。当然了，作为创业者，如果你有一个安全领域的朋友愿意帮你出谋划策，偶尔回答一下安全建设如何做这类问题，其实那CSO的需求也就解决了，代价只是请吃几顿饭？呵呵
第三种拿到B轮，业务初具规模，开始朝更高的地方冲刺，同时能给人画更多的“饼”，如果之前已经招到靠谱的安全工程师，那这个时候应该已经成长起来，承担起leader的角色，通常也不需要从外部招CSO了，这个时候想从外部招CSO的都是之前主观的或被迫的不太重视安全，被捅菊花了才想要头痛医头脚痛医脚，这个时候的业务形态跟大公司比应该是“麻雀虽小五脏俱全”，安全管理上应该是有很多相似的地方了，对于出具规模的业务而言安全管理的经验很重要，可以直接从大公司挖人，当然了level较高的估计还是挖不动的，主要就是骨干那一层的人吧，通常你需要容忍他们业务上有深度但不一定面面俱到，很可能情商和管理能力也差强人意，不过能解决你的问题就行，面面俱到的毕竟还是太贵了，呵呵
第四种拿到C轮冲IPO，这个时候想必不会囊中羞涩，如果看官你是这个区间公司的CXO，还为找不到人感慨万千，我想也许是心态还不够开放，亦或许是给人的“诚意”还不够，到这里我也给不了太多建议了，毕竟市场上只有那么一小撮人，来不来去不去也就是那一小撮人的意愿而已，被打动了自然来，没被打动的自然不去~
创业公司的那些事对选择转会的CSO是否有挑战？有，也没有。首先做的事情往往还是从头建团队，把过去建设安全体系的过程从零开始再做一遍从这个角度讲重复过去做的事情尽管业务有所不同但过程和结果上未必有挑战，有“挑战”的反而是如何在创业公司的条件下招募成员，维系团队和在很多流程及界限不分明的情况下推动事情落地，仅此而已，对CSO本人而言得到的实践机会未必有大公司多而广，因为安全是一个随规模而复杂化的工作。但是，如果你是CSO的跟班小弟，那你可能是成长最快得到锻炼最多的人，因为你经历了安全建设飞速发展从无到有，从简单到自动化的过程，这个过程不是人人都能体验，所谓的全局视野并不是你进入BAT在一个很细的分支上耕耘几年就能积累到的，相反是在这种环境下才能快速积累。所以除非公司IPO，CSO都不是团队里收益最大的人，但跟班小弟却是最大的赢家，哈哈
甲方的同学看了是不是觉得有很多场景很相似，是不是该珍惜当下，因为有些令你痛苦的事情，恰恰就是你成长的机会，区别只在于你选择了什么方法解决这类问题，你的解决问题的方法拿到业界算得上是最佳实践么(http://www.ayazero.com/?p=44)