高瓴技术峰会札记

上周六经前同事Fairy邀请，参加了高瓴技术峰会。本想去蹭顿饭，结果感触良多，收货远超预期。为了答谢Fairy的盛情邀请，也是为自己做了这个笔记。记录一下，并针对自己的安全专业作出自己的诠释。鉴于个人经历和视野的局限，可能会对张磊和陆奇先生的原始理念造成曲解。所以本文只代表我，基于两位大佬的激发产生的对安全技术和事业发展的一点儿愚见。

张磊演讲摘要

• 初心：中立的机构才能做好事
• 投资技术驱动、科技赋能的机构：什么是技术驱动？是实用了人工智能，启用了大数据分析吗？还是像特斯拉一样搞了别人不能搞的电动车和自动驾驶？我想这分两部分：
  • 一个本身业务就很具有技术含量，有技术壁垒，实际上我们看到，信息安全领域的技术壁垒还是很高，个人视角，国内安全圈比较浮躁、包含很多专业的安全公司，核心安全理念，安全技术依然存在很多差距，因此踏踏实实把技术做精，做专，还是很容易建立起壁垒的；
  • 另外从更为广义的角度，技术的提升、迭代效率，也就是我们说的创新能力是另一个重要指标，就是公司的软件研发能力，技术架构体系能否支持整个公司快速学习成长。这里大数据，人工智能肯定能起到这个作用，我要提的是更通用的部分：软件开发能力，DevOPS。
• 保持中立，是信任的重要基础，而信任是安全合作的基础。如果客户都不信任你，你很难获得很深入的合作，顶多做一些外围的防护。安全公司保持中立的办法很多，从技术纬度，我认为从产品架构设计到服务交付方式都可以做，首先要保持诚意，开放源代码是获取信任的手段之一；此外服务、数据分离，算法、密钥分离，以及公开算法，第三方审计以及第三方托管等都是保持中立获取信任的方式。
• 技术驱动对安全领域尤其重要，技术是安全的核心竞争力，不仅表现在技术对抗，密码学，权限模型等专业领域，也包含安全与新兴技术的融合，包含对新兴业务模式的支持。这个我在后面的安全的驱动力里面回详细说。因此作为安全人，不仅要保持技术的同步、领先，还要保持不断学习，快速拉大优势的能力。
• 一起把蛋糕做大而不是对立：这里将的是生态、合作共赢，在安全领域我有不同解释，主要是与研发的博弈，红蓝对抗等角度，我想通过同理心empathy来详细诠释。主要观点是学习、分享，服务才能共赢。
• 聚焦，墒减，学会做减法：信息安全涉及的领域太广了，会包含几乎所有的技术领域的知识和技能。大而全不如小而美。如何保持特定领域的专业性，我希望通过安全的“专家系统”来诠释。保持专业性和权威性，也是获取信任的重要手段。在这个凡事论结果、看绩效的，讲求快速变现、弯道超车的浮躁互联网环境。保持耐心和专注尤其重要。
• TECH的理解
• Trends 对技术趋势的理解和把握，这一点我做得远远不够，是需要加强的，对于技术人来说，往往容易自以为是，陷入自嗨无法自拔，我看到最多的是，技术圈分安全技术和其他技术。我想最好的办法是保持开放的心态，保持学习和分享，不怕出丑，这个在后面陆奇的总结会详细讲。 多出来看看，多看看Youtube，多参加安全的和非安全的技术峰会。
• Empathy 同理心，张磊讲了他8岁儿子讲的跳井理论。当你看到一个人掉井里了，你看了心疼，那叫sympathy, 只有你也跟着跳进去了，那才叫empathy。这在我们行业里叫入坑。Empathy对技术人来说，重要的是不鄙视，不居高临下，开放、平等，服务意识。
  • 对研发人员的同理心：研发人员是构建者，对他们的系统挑刺儿很容易，因为你占了专业技术优势，不对等。而且研发人员的KPI和你的不一样，快速上线产品，保证产品的效能和稳定就是他们的生命。安全人员制定策略，提供安全特性和服务时，不仅仅从安全本身考虑，而且要考虑到研发本身的技术背景，拥有的资源，因此尽量简化流程，尽量把安全功能用工具、代码封装起来，让研发在不需要太多efforts，就能实现安全能力，即展现了安全人员的技术能力，又表现了尊重，同理，更能获得认同和支持。“人人都是安全工程师” 这句话充满了自嗨，连Sympathy都谈不上。
  • 对产品人员的同理心：用户体验，可用性对产品来讲，可能比看不到的安全来得更重要，产品上了你的加密功能后，系统慢如牛，把用户都吓跑了，我们就都失业了。
  • 对用户和客户的同理心：客户的水平参差不齐，往往从技术水平到安全意识都比较弱，或者安全意识强，但不知从何下手。这时你可以通过技术和知识优势，获得一定的信任，但最终能否为用户提供能用的安全保障，

 

• Curious 好奇心，这点对做安全技术成长的尤为重要。通常，搞安全的偏向保守，对于新生事物往往默认拒绝，看到的都是不成熟和风险，不敢冒险。我们都曾经年轻过，对技术狂热，充满激情。在某个领域成为呆久了，会产生惰性，加上随着年龄的增长，经历和体力的下降，无法照顾过多领域。这就需要做减法，精挑细选你关注的技术和业务，然而求真求实的初心，可以让你对要保护的业务系统，使用的技术有更深的理解，知其然还知其所以然。
• Holistic 通才，这个与上面的聚焦似乎有点儿矛盾，这个可能是说CEO的，对安全技术专家来说，我想是需要一专多能吧？通过不断的学习，交流以及合作，拓展自己的边界，从安全防御的构建者我的理解是除了聚焦的领域，需要有以下三个知识领域，我称之为3know：
  • 了解你的敌人：对手使用的技术、技巧以及思路，乃至包含攻击对象和动机都在不断迭代。如不与时俱进，你的防护是不靠谱的。除了每个特定领域的专业网站和论坛外，Blackhat，DevCon等大会，以及各个技术厂商的安全公告订阅和详细解读，CVE等都是非常好的来源。包括一些威胁情报，新的病毒木马等。对于大的漏洞的发布，安全事件的详细解读和复盘，可以衍生出更新奇的攻击套路，也刷新自己的认知。
  • 了解你的盟友：几大安全防护机制必须随时跟进，包括NIST，CIS的安全基线，参加RSA，OWASP等顶级安全峰会，除了解核心防护机制和技术外，也可以对接顶级安全厂商的安全白皮书和解决方案，也是很好的参考，当然，每个领域的专家都会有自己领域的防御矩阵。此外Google，AWS以及微软等核心技术提供者本身的安全防护框架，也给我们很好的参考。
  • 了解你自己：实际上包括了解你自己的业务，业务模式，核心资产，实际业务模式，使用的底层技术栈。这些最好的方法就是安全评审。安全运维的一些方法，从另外一个角度，对核心技术的完整、深入的学习，也是了解自己的重要途径，包括陆奇讲的，我也非常认可的，LAB全闭环学习模式。

 

 

陆奇演讲札记

陆奇演讲给我第一印象就是这个人的高效，PPT完全白板，我想这个PPT他可能准备没超过1小时？但却满满个人智慧的总结。

 

• 一个系统如果你不能真正构建起来，你很难去真正理解它，这是盖茨对陆奇讲的。我觉得是每个技术人的圣经。是一个学习方法和态度。从另外一个角度，构建系统，构建软件的能力也是安全人必备。所以我招人的时候，不会刻意要求他的安全经验，而特别注重他的构建能力，编写代码，端到端的搭建一个微服务甚至应用。如果你一个没有从头设计一套https web服务器，跟你讲TLS，那你可能要小心了，这人很可能就是传说中的架构师。这里引用Linus的金句，“Talk is cheap. Show me the code” 。没有实际搭建过，实际踩过坑。就没有办法设身处地和帮业务解决问题，结果就是不接地气，不会获得业务的信任，也无法给出真正匹配的方案。要么无法落地，要么安全性大打折扣。获取理解系统的几个办法，我从做有效到最容易做了排序
  • 全闭环构建整个业务架构和使用场景（LAB）：比如你研究容器安全，你就用docker和k8s搭一套真是的环境，从初始化，策略配置到实际编码，部署，然后把你的安全特性和方案集成进去。 这个涉及的学习曲线比较长，但效果最好；
  • 合作模式（只读）：充分阅读产品文档，和业务复盘产品架构，阅读产品白皮书，源代码，并在业务的支持下，进行安全方案设计，集成测试并进行推广，解决问题。这个相对来说比较快上手，因此可以实现更广的覆盖。但对某些复杂系统可能会比较难，而且这个非常依赖你的业务合作伙伴。
  • 自助/自动模式（DevOPS）通过制定基线、规则，并提供一定的安全服务，有业务和产品自助接入、合规。

那么具体如何把握？ 我觉得对于聚焦的专业领域，核心技术业务，需要LAB，因为技术都是相通的，这样你的路会越走越宽。一切都在掌握的感觉也很棒。只读模式对于建立数据，积累经验，快速横向扩展是有必要的。对于金字塔底座的绝大多数业务，需要通过服务交付，采用DevOPS模式，这是安全能力扩大化、规模化的目标。

 

• 技术驱动力：我从来没有仔细考虑过这个问题，这次也是开了脑洞了，安全技术的驱动力是什么？传统的攻防对抗，只是表象，我考虑安全技术也具备技术的共性，核心驱动力也是钱。钱在哪儿，人才就在哪儿，这是驱动技术演进的共性动力。当然带动这些的本源可能不一定这么俗，可能是对于自由的向往，对未知领域的好奇心。但结果却是，这些都带动了新兴的技术和业务的发展。而安全技术的驱动力，实际上是这些蓬勃发展的新技术领域引发的新的产业。安全不值钱，本身不创造直接价值，安全是寄生在新业务才能产生价值。所以以业务为中心，对新兴业务模式，新的数据交互模式安全必须跟随。业务有多大，安全价值就多大。安全是为业务服务的，应该使能新业务，而不是作为blocker。赋予业务放心跑的能力。反过来，技术的进步也反哺安全，为安全提供了新的技术属性。
  • 移动互联网：移动支付，IM，Facebook，IOS的革命，让手持设备成为人的另外一个属性，数字化了人民的生活，隐私，精准识别人，设备和应用都为安全提出了新的课题。而手机app，微信，支付宝小程序，将信任的边界推向了移动端。你不能阻止这个趋势，你还得保证业务的可用、易用，还得保证安全；
  • 云：打破了传统数据中心的物理防护模式，租户隔离机制，把IAM上升了新的高度，同时在IAAS，Paas，SAAS等租户和资源共享业务模式下，让用户，租户和CSP的产生了新型的信任模式。
  • 虚拟化和容器技术：让操作系统内核态、用户态又提升到新的高度。
  • 移动办公：原来的NAC已经不适用，所谓的BeyondCorp等机制，实实在在为IAM提出了更高层次的要求。
  • 大数据：你必须保证数据充分交换、使用，促进业务蓬勃发展，你还得保护隐私，保证用户的遗忘权。
  • AI IOT 无人驾驶，刷脸：软件扩展，延伸到你生活的方方面面，包括涉及生命的交通，医疗生产，核设施，军用系统。软件爆发式的扩张，对安全有多大的驱动力？

我只是举了部分例子，这个本身还会无限的扩张下去。安全的机遇和挑战也会不断的扩张下去。传统的方法，已经跟不上了，唯有靠近业务，靠近技术，通过技术驱动安全才有希望。而驱动一起的是基础研发技术的变革，DevOPS、微服务架构和平台化。

安全防护的核心与趋势

专家的价值就是在专业领域能做到墒减。实际上无边界的背后，万变不离其宗，安全还是要回归安全的本质——信任。新的业务模式，技术迭代，打破了原有的信任边界和信任模型，但同时建立起新的交互渠道和心的边界。安全技术主要就是识别这种新的信任边界，并利用技术，保护信任关系。合法的人（或系统）能更顺畅的交互，使用数据；非法的人（或系统）更容易被隔离，限制。这里简单介绍一下安全防护技术的演进。

 

• 身份认证：由于物理边界被打破，认证成为更为重要的攻防前沿。这里除了传统的3因素（请搜索三因素或者多因素认证MFA， 2FA），逐步衍生了基于设备，运行环境以及行为数据衍生出来的用户画像，账户风控等第N因素正逐步发挥作用。
• 安全架构设计：信任边界从传统的物理、网络边界延伸到业务逻辑、租户等边界。同时也延伸到单个系统、主机乃至应用的内部的隔离。安全架构设计需要识别并控制好更为灵活、隐蔽的边界入口。比如移动设备中不同App之间，小程序之间以及老的浏览器跨域的访问。
• 加密：加密要能抵抗更高算力，更廉价的存储以及大数据集群，人工智能的攻击。同时要保证加密数据兼容大数据和AI的计算要求。目前这部分还没有技术上的突破，同态加密等技术还没有成为量产，token化是一种非技术的探索，能兼顾保密和数据共享，运算的需求。
• 攻击行为监测，威胁情报：大数据和算力存储的增长，也可以承载全球的黑色信息。一旦关联起来，恶意无处遁形。
• DEVOPS： 快速膨胀同时，也可以把安全能力DevOPS化，通过自动化，自助的工具对产品，业务和人赋能。

 

安全与生意

安全的生意随业务水涨船高，是没有界限的。这种无限并不来自传统安全领域。基于主要安全需求内核披上新技术和新业务的马甲的新的生意可以给我们无限的遐想。作为安全创业者需要处理好一些关系。我的观点是广结善缘，充分赋能

 

• 安全与业务的关系：
  • 安全必须为业务服务，是业务加速的垫脚石而不是减速器；
  • 安全要追随业务，追热点，追用户，追数据（势利眼）但也要保持一定的中立性和灵活性
  • 安全也要具有前瞻性：对业务趋势和技术趋势进行总结，抽象。为新的研究方向提供指引。
  • 安全要保障合法，限制非法：要保持权威性和同理心，核心坚持原则，架构和实现要灵活，敏捷
• 安全与技术的关系：
  • 安全要向技术学习，保持先进性和成长性
  • 安全要反哺技术，对技术提供新的
  • 安全还是一门实用科学，一定要和业务，技术相匹配，不要孤芳自赏，不要闭门造车

补：如何评价一家安全公司？

 

安全公司要想赚钱，具有长远的发展，还要回归本源，为用户创造价值，安全公司的价值就是为用户，或者业务赋能，赋予安全防护的能力。而建立起信任是第一步。安全公司的评价我的愚见：

 

• 安全公司首先是一家技术公司，技术的核心体现我的说法就是具备
  • 专家系统：在细分领域，必须具备权威的科学家，这个科学家的专业性上面已经说过了，不再啰嗦，另外内部专业人才要形成梯队，各种层次的人才梯队外部形成影响力；
  • 人工智能：安全赋能最终要落到软件等工程化的东西上，好的软件是把专家的专业性变现，规模化，创造更大价值。好的软件一定体现在，兼容性，稳定性，安全性和多种形态。还是那句话，最简单粗暴的就是实打实的安全防护能力，而最直接的防护就是产品。
  • 形成生态： 有平台，或者和平台合作，通过开源，技术论坛等方式先服务，共享，再收益的模式比较好
  • 工程化能力：速度决定成败，交付软件的速度，低成本拭错。敏捷、DevOPS，可复用的微服务架构。能保证在多变的业务环境下，保持实验和创新的能力，抓住风口和机遇。你只要看他产品迭代速度。和产品由0到用的交付时间就可以了。
  • 架构师：产品力和架构能力，能保证产品的顶层设计