从乙方到甲方 | 我所亲历的信息安全建设之变迁【1】

【关于我】

2000年初的学生时代，作为《黑客防线》论坛版主四处流窜，也是《黑客X档案》的特约编辑群、还是《黑客手册》创刊的首批团伙之一。

2004年工作开始，在三家安全厂商干了12年，做过产品、写过代码、扛过设备、撸过方案、参与过GB/T的撰写和推广落地，也有过不少行标的经验。个人感觉相对擅长应急和分析，也做过挺长时间的渗透。在17799到27000的那些年里也跟过咨询团队看过安全咨询及安全合规项目的样子，几乎所有PowerPoint和Word 的深层功法都是在那期间练成的。

2016年开始进入甲方，有幸一步进入当时最火热的威胁情报领域，从眼前的小小办公网做到了全球范围的对抗。后来趁着风走进了区块链安全，又开始了一段神奇的旅程。

【关于这个系列】

这个系列会分成多少篇，我并没有计划，只是今天堵在路上想起了自己的号已经停更很久，需要一些内容来填充。

我会从刚开始工作的那个年代我所看到的写起，有些回忆已经不那么清晰了，但还好我有保留文档和工作记录的习惯，我会一边翻出那些老文档、一边记录我的这个过程。

因为是随着时间的变化而进化，可能会有混乱、但我尽量将这些整理的更成体系一些，我也尽量客观但也不可能完全抛弃主观。

我并不期望能给人以指导，只希望能给自己以宽慰。

2020.8.17

（以下为正文）

【0】我们都是黑客 ？

04年，是我刚进入这个行业的时间。那是一个好的时代，也是一个糟糕的时代。到客户现场被问及最多的就是“你们公司都是黑客吧？” —— 但这里并没有什么褒奖之意。

那个年代大家对安全的普遍认识停留于防火墙，那时候提到的防火墙都是网络层防火墙，基于IP+端口。

曾经遇到一个防火墙调配失败的案例，无论前端Web配置界面上做什么都是无法生效，在好奇心驱使之下我使用了一些手段拿到了设备的shell，发现启动脚本出现了问题，导致iptables 服务没有启动，检查了 iptables的配置之后手动启动，前台立马看到红色的失败按钮变成了绿色。

没错，这就是那个年代，但这没什么值得嘲笑的，因为正是那时候的他们造就了现在的我们。

【1】那个年代的方案

[1.1] 办公网安全

那个时期的多数方案大概也是遵循了“云、管、端”三层的安全策略的：

• 端上：杀毒软件、补丁策略，WSUS直接入驻办公网

• 网络：VLAN+ACL

  同时阻断TCP 135/139/445/1433 / UDP 137/138/1434这样的端口阻断，可阻断当时的多数问题

• 边界：防火墙等传统硬件，先进一点还会有 NIDS

其中，尤其网络层这种粗暴的管理方式也会带来不小的体验伤害。

例如，在NTLM验证需要向下兼容的环境里，域内的各类认证传递就会偶尔出现问题，而更显而易见的问题就是在SAMBA共享盛行的年代里，139或445的封禁更会增加日常办公的复杂度。

为此，就需要更精细化的策略配置能力。

在域环境中，策略的迭代成本相对较低，所以这种场景中，很多精力是在不断的响应策略出现问题而导致的故障、然后优化策略、再去响应策略导致的故障，如此反复。

而对于没有域环境的网络来说，基本上就是灾难。这种情况下多数的策略只能向办公体验低头。所以这种环境里，反而更多的精力真的是扑在了安全问题上，但这也是颇具挑战的，就好像当年的冲击波、震荡波、SQL Slammer、烧鸡病毒、熊猫烧香 ……

[1.2] 线上安全

线上安全那时候真的是简单又简约 —— 防火墙+NIDS+扫描器。

日常为了解决问题偶尔还会动用sniffer，常常是拉根网线tcpdump跑半分钟拿pcap回来分析并如此反复 —— 那个年代在稍大的网络里抓下一两分钟的pcap对电脑来说是极大的挑战。

而在端上，能用得起 tripwire 这样的工具就算是个中高手了。

为了补充产品能力的不完善，初期还有很多定期人工巡检的工作。

所以也应运而生的出现了很多检查流程和程序，SANS的checklist和检查脚本充斥了客户的机房中的每台服务器。偶尔可以在检查的时候发现前人留下的信息采集脚本，打开后发现内容相似之后也会对着屏幕会心一笑。

后来随着SCAP及配套标准的推广，在国内也出现更加自动化且节省人力的检查方式。不过那也是后话了。

另外，微软收购的sysinternals、常用的chkrootkit、rkhunter也是线上检查的常备工具包，这部分可以参考之前整理过的一篇关于分析工具的文章。

应急体系是日常检查保障兜底必备的机制。

在我所经历的客户中，不但多具备完善的应急规范及制度，还有不少客户积累了大量应急过程中产生的案例库。有些意识先进、管理洁癖的用户，还会对各种案例库做详细的分类和关键词、关键工具及关键动作的抽取，方便在应急时能快速使用。

这大概就是那个产品不够先进、全靠人力补全的年代。

而这些人力和制度的保障能力，在早期的各类信息安全管理体系（ISMS）建设的指南、实践中都有非常完整的参考，这些框架至今也是信息安全体系建设的必要基石。

最后，还有一个重要的概念 —— SDL。

在我刚入行时，安全人员极少有甲方可选，所以建设SDL这件事几乎不可能。

我最早接触与其最为贴近的概念大概是在06年，因培训需要偶然接触了微软的STRIDE模型、进而了解到了微软SDLC的概念。然后就写了一篇我自己也不知道是什么的 “信息安全与软件开发全流程” 的培训胶片。仅此而已。

【2】堪称先烈级的SOC产品

我最早接触到 SOC 的概念是在2004年。

一个至今依然无法轻松驾驭的概念在那个年代里的情景可想而知。

产品的设计和运作思路很新奇，至少对那个年代的我来说，了解SOC的概念并不容易。最后我十分勉强的总结出了一套“由组织到资产到技术”的说词，用来说服我当时服务的几个客户。

毫无疑问，这个产品不会存活太久。

但至今我都觉得那是一个概念超前、实现理念超前的产品。

那时候我对SOC的概念认知大概会停留在几个浅薄的概念上，大概翻了一下当年的PPT简单还原一下：

• 组织

• 代表了我的客户

• 一方面是以 IT 部门为主的职责部门

• 一方面是以业务为代表的使用方

• 资产

• 所有软或硬的有价存在物（如：一个软件，或一台设备）

• 要给资产定出CIA（机密性/完整性/可用性）
  

• 组织与资产之间有强映射，产品会有一定的保障机制来保障两者之间的映射关系持续更新

• 找到了资产就找到了组织，找到了组织就找到了人，找到了人就找到了人

• 找到了人配合响应的安全流程就有了动作，有了动作就有了响应后续的一系列事情：发现、处置和持续改进

• 处置和持续改进的详情记录

• 技术

• 组织和资产之间的安全问题需要一个链接，这个链接就是技术

• 简单来说，将自家的各种能力集成并关联到一起，以求更快速和准确的发现问题

• 发现问题后即实现了定位资产，资产再倒推到组织那一套（参考上面资产的描述）

毕竟那是在2004年，还能怎样？

当然了，这个产品的无法延续几乎是必然的，其过程和原因，大概有那么几个显而易见的点：

• 在只能听懂防火墙是什么的年代里，这种理念并非是不能被理解，而是不能被接受

• 产品的方案成本和实施成本都非常高，单是为了梳理清楚资产并保持其持续、有效的更新，对我一个人来说就已经精疲力竭了，在我近两年的驻场支持里至少有大半年在做这个事情，更不用说后续的其他各种

• 产品的有效性低导致整体的有效性不高，大家都知道，那个年代里产品的准确度是个大问题，那么集成了一堆产品告警的平台就成了天大的问题，一个试图降低响应频度、提升响应效率的工具，却适得其反

【3】大集成时代的到来

在我之前的《国内安全行业人才的四个阶段》中曾经提及过这个阶段。

这个时代的形成一定不是一个两个原因导致的，但就这个时代形成的结果来看，对整个信息安全的发展确实起到了不小的影响。

我无法评价这个影响是正向还是负向的，只是，集成式的安全方案让早期的安全厂商似乎看到了市场的广阔（或许，反而是因为不够广阔才不得已而为之）。

而那个时候回头看看国内确实又没有几家能拿的出手的公司和产品，似乎每个安全公司都有机会 “一家独大”。但事实却是，尝试一家通吃的大集成时代加速了各个纵深领域厂商的出现 —— 因为传统安全产品组合、叠加的越多越快，给那些对这种组合后能发挥巨大威力以期待的人们所带来的失望也就来的越多越快。这种快速带来的失望加速了大家向更为专向的领域去尝试专注且深度的研究和发展。

那时候，最早出现的便是很多专注Web安全领域的公司出现，虽然那时候出现的很多公司后来也在慢慢的扩展其业务过程中开始步入传统的安全领域，但依然不乏坚定的拥护者至今依然专注在较窄的领域内深耕、并且也获得了其纵深领域内相当好的市场地位。

所以在那之后，大集成时代进入到了其第二阶段 —— 次集成时代。

（本篇完 / 后续正在缓慢整理中）

本文始发于微信公众号（Piz0n）：从乙方到甲方 | 我所亲历的信息安全建设之变迁【1】