每个公司的情况都不一样，信息安全工作也没有一定之规。理解“务实问题清单”的办法，有助于排除干扰，立足需求，围绕自己公司的特殊情况，摸索自己的解决之道。本篇承接前文，继续介绍执行清单的内容，产生和利用方法。
1. 执行清单的内容
执行清单用于记录安全管理工作中可以采取的行动及其预期。可以对执行清单的内容进行多个维度的分类，并反复整理和摆弄，以此优化自己的管理工作。
1.1 管理 vs 技术
前面的分析中我们已经知道，执行清单中的内容可以大致分为管理和技术两类。管理通常表现为制度、策略、权限等内容，技术通常表现为产品、功能、基础设施等。有些时候并不能分得很清楚，毕竟技术采用是管理意志的体现，是在既定管理思路下的主动选择。
1.2 建设、监控、评估和改进
建设、监控、评估和改进是信息安全工作另一个维度的分类：
- 建设是从0到1，或从1到2，或从A到B。建设目标可能是制定并颁行一条管理要求，上线一个产品，完善一个模块，修改一个策略。
- 监控是在预设好的反馈机制中的自动化执行。监控包括监视和控制两个部分。监视是观察和识别，控制是干涉或处理，中间的决策机制就是安全策略。监控会产生过程数据或者日志记录。
- 评估是为针对某个目的，对采集的数据或制定的方案进行分析并得出评判结论的过程。评估以管理目标为标准。评估应该在采取关键行动之前进行，或周期性的计划执行。
- 改进是评估、建设、再评估的组合。评估之后产生改进计划，建设中执行改进计划，再评估时检查改进结果。
通过建设、监控、评估和改进的划分，执行清单就具备了工作计划的功能。任何时刻查看执行清单，都知道下一步的工作内容是什么。
2. 执行清单的产生
执行清单的产生是一个自然、动态、反复修改、反复迭代的过程，本节以一个典型的研发环境终端数据防泄漏需求为背景来演示和说明。
2.1 回顾业务问题、安全问题和约束
回顾此前已经得到的业务问题、安全问题和约束三个清单，将它们视作需求项。做一个简单的分类，不同类别的需求找不同的供应商或咨询专家去谈，没有必要混在一起。
以终端数据防泄漏为例，简化之后的三个清单可能如下所示：
业务问题清单：研发代码和文档的防泄密
一些说明：
- 建设未完善前，上述清单表格中出现重复、分类不准确、表达不清晰之类的问题，都很正常。没有必要在表达和专业性上纠结，写出来比一切都重要。
- 业务问题、安全问题和约束，只是角度不同，但它们都是需求。写出来即可，放哪儿不重要。
- 这些清单的内容会急剧变化，如果有一个版本管理工具，可以帮助自己更轻松的看到思路发展的轨迹。
- 坚持使用清单来沟通、讨论和形成每个阶段的结论。
- 极重要的提醒：对技术路线隐含的规定性保持警惕。比如你可能认为“加密是防泄密的好办法”，由此你的安全问题可能表述为：研发代码、设计文档等没有被加密保护。这样的表述会驱使你去寻找一款加密软件，而忽略了其他潜在的选择（比如物理空间隔离）。
2.2 选择供应商或咨询专家
拿着需求清单去寻求相应领域的供应商或咨询专家的帮助。也可以通过一些好的综述或方案介绍文章来学习别人的成功经验。
不论是哪种方式，在做需求与方案沟通时，需要注意：
- 坚持使用自己的务实问题清单作为沟通的基础。可以要求服务方帮助修改清单上的内容，或者在别人的帮助下自己动手修改。
- 任何产品或解决方案都有它解决问题的基础逻辑（或隐喻），请服务方解释他是如何解决问题的。保持批判精神，宁愿相信符合逻辑的打比方和举例子，也不要信任纯粹的概念堆砌。
- 评估产品或解决方案的“安全性的可验证水平”，并加以验证。
- 不可避免的，技术路线或解决方案会显性或隐性地修改你的需求。保持警惕，尽量不要让技术性的描述进入自己的需求里。但也没有必要纠结于此。
举个例子。在与服务方沟通之后，你可能会发现前面的安全问题清单中没有“需要禁止USB接口以免代码通过U盘泄密”这样的描述，或者服务方可能会提示你忘记了“外设管控”这个重要的安全工作。这看起来是一个非常严重的错漏，你会修改安全问题清单，补上相关需求。但事实上呢，如果你在后面选择了“物理空间隔离”作为解决问题的方案，外设管控、甚至是加密都不是必须的。所以，紧守自己最初的安全需求，是需求与方案沟通中最关键的原则。
2.3 Aspace隔离办公系统简介
Aspace隔离办公系统可以用来解决研发代码和文档泄密问题，具有简单易用、效果直接的优点。本文后面以Aspace和物理空间隔离两个方案为例，来介绍执行清单产生过程中所需要的思考和沟通方法。
Aspace系统以存储隔离，应用隔离和网络隔离，为用户在一台电脑上建立起两个彼此隔离的计算环境。如下图所示，用户可以在安全桌面（S区）和开放桌面（O区）之间自由切换，随时选择在S区处理高密级的研发事务，或者在O区处理低密级的对外沟通和查询资料等事务。
在S区和O区之间，Aspace系统维护一个简单的安全策略：
- S区产生的所有数据均加密存储，且对O区不可见
进一步，Aspace连接多个S区，构成一个虚拟的安全协作网络，并维护如下基本安全策略：
- S区能且只能够连接安全协作内网
- 安全协作内网能且只能够被S区连接
2.4 管理和技术方案分析
本节提供一个经过简化的参考模型。这个模型列出在评估和部署一个安全产品时需要重点考虑的问题，可以帮助决策者：
- 理解技术和管理相互影响又相互配合的关系。
- 理解技术和管理的关系如何转化为执行清单中的执行项目。
虽说是个经过简化的参考模型，依然包括九个方面。在现实工作中，大部分公司只需要关注其中某几项重点，只是不同公司的关注重点不一样而已。这里一并列出，可以帮助读者快速筛选，避免遗漏。
- 分析信息合法流出和流入的方式。
- 明确残余的脆弱性，评估其影响和应对预案。
- 产品或方案特殊性所带来的管理问题。
- 正常工作如何继续开展，对正常工作的影响有哪些。
- 评估对员工工作效率的影响。
- 评估管理人员的工作量。
- 评估安全性，和安全性的可验证水平。
- 向员工宣布部署计划，并获得认可和支持。
- 向员工介绍安全软件的使用。
上述各项中，前三项是基础性的，后面各项却是容易被忽视的。后面两节分别对物理空间隔离和Aspace的应用进行分析，希望能够揭示这其中的一些方法和规律。
2.5 物理空间隔离的管理和技术分析
信息合法流出和流入的方式，或者说信息的流转方式在部署安全方案之后会发生变化。防泄密的目的是防止内部人员以不被察觉的方式有意或无意地将敏感信息泄露到外部。这并不表示防泄密要禁止信息的流转。相反，信息流转的效率要继续保持，这对正常展开工作至关重要。
物理空间隔离方案的隐喻是：既然所有研发工作都在一个隔离空间里进行，敏感的源代码和文档自然也就无法外泄了。这个方法看起来十分直接和有效，但在现实工作中，信息总是要流通才能保证效率和创造价值：
- 代码开发的最终目的是发版。如果是纯软件或Web应用，可以在服务器上完成自动编译和发布，发布之后的软件直接通过网络在外部访问。这个发布过程研发人员可以不参与，只要配置恰当，就不存在安全风险。但如果是固件程序，发布时需要烧录到下位机（或拷贝到U盘或SD卡）上，这些物理外设就需要严格管理，避免成为信息外泄的出口。
- 如果研发人员由于某个原因（比如写专利，与外部交流技术细节，或直接交付源代码等）需要导出代码、文档等，可以提交申请，并由相关主管审查内容后放行。这种事情发生频率很低，管理得当，风险可控。
- 研发人员在外部收集的资料或参考代码需要导入隔离空间内，数据量可能很大。可以提供一个文件导入的Web服务，在外部可以上传，在内部只允许下载。
- 不允许员工使用个人U盘向内拷贝数据。因为可以拷入，就潜在的可以拷出，除非在门禁处检查带出U盘的内容（增加了另外的工作量和风险）。
残余的脆弱性，也可以看做“潜在的脆弱性”，即在部署安全方案之后，依然存在的安全风险。残余的脆弱性有的来自于既有技术和管理方案无法解决的问题，也有很多是部署的安全方案本身所导入的。
一个研发环境在采用了“物理空间隔离”的安全方案之后，管理的焦点将不再是“空间隔离如何保证代码无法外泄”，因为这是显而易见的。而同时，隔离空间的出入口管理就成为重点，残余的脆弱性均隐藏在此。比如：
- 员工可能带手机进入隔离空间，而手机具备联网和存储功能，潜在的可以对外发送或拷贝信息。
- U盘、SD卡等移动存储设备容量大、体积小，不易发现。
- 攻击者可以借助合法外发的途径（比如经过审批的打印件、电子文档、调试外设等）以夹带的方式带出信息。
- 送修的电脑会脱离安全的隔离空间。
- 售前技术支持人员的笔记本电脑上会保存部分研发资料。甚至在懈怠的情况下，售前技术人员的笔记本电脑可以频繁的进出隔离空间而被人熟视无睹，原因是他是研发团队的自己人，他的工作是对外的，笔记本是个特例。
残余的脆弱性，产品或方案的特殊性都会带来不一样的管理问题。“物理空间隔离”在管理和技术的配合关系上就存在一些特殊的地方：
- 迁入隔离空间的业务要尽可能内敛，减少与外界沟通的需要。比如在汽车电子行业有很多厂商使用隔离空间来保护研发代码。但在对外技术支持或外场测试等工作中，总是需要使用U盘或SD卡拷贝一些临时发布的测试固件或补丁程序，这种发布具有临时性和突发性，是正常工作需要。然而，研发人员也可以借助这个合法渠道，将源代码或设计文档一起打包带出。从管理角度来看，第一，审批和审计价值不大，因为编译后的文件没有可读性；第二，频繁无意义的审批和审计工作，很快就会流于形式，无谓的浪费很多时间。
- 一旦采用了空间隔离方案，出入门禁就变得非常重要。而这时，不论是部署安检门还是手持式探测仪，都离不开保安人员的参与。很多企业里，保安人员与IT或信息安全不属于一个部门，这种情况下，就需要特别注意：不要让保安的懈怠和碍于情面成为整个安全方案的短板，导致其它的一切努力都失去价值。
- 法务、个人隐私和企业文化方面的考虑。比如研发人员在上班时间不能使用微信和手机，会不会觉得没法接受？
2.6 Aspace的管理和技术分析
相比于物理空间隔离的“纯硬”，Aspace隔离办公系统是纯软件的方案，不需要在空间布局和网络布线等基础设施上重复建设，能更灵活地适应规模和业务范围的调整。同时，二者虽然都使用了“空间隔离”的安全隐喻（解决问题的思路），但在管理思想上却有很大的不同。
具体来说，Aspace的隐喻是：内外有别，隔离办公。所有内部事务都在S区进行，所有对外事务或不涉密事务都在O区进行，如果员工觉得工作需要外发信息，可以主动发起解密导出的操作。Aspace将信息内外有别的判断交给了业务当事人，而在内外的边界上根据信任程度和安全需求做不同等级的管控。
相比较而言，Aspace让员工具有更大的自主权和责任感，员工的职业体面和专业判断也得到更大的尊重。
信息合法流出和流入的方式，Aspace的管理思路更加简单和清晰：
- Aspace在终端允许且只允许员工以解密外发的方式对外发送数据。而解密外发的操作受到权限许可、审批、审计等安全策略的管理。
- 在终端，用户从外部向内部导入数据十分容易，不受任何限制。
- U盘、SD卡等外设在默认情况下，不允许在S区使用。如果授权允许使用了，则数据被加密，在O区和其他外部环境将无法使用。
残余的脆弱性方面，在部署Aspace之后，主要体现在：
- 员工可能坚持在O区工作，而不进入S区工作。
- 员工可能利用自己的解密外发权限，以夹带的方式带出信息。
- 毕竟O区S区运行在同一台电脑上，员工具有管理员权限，且具备开发能力。所以他可能在S区直接针对存储隔离或应用隔离的机制实施攻击。
- 基于网络隔离的策略，代码服务器设定为只能S区访问，O区就不允许访问。这时并不能避免一台没有安装Aspace客户端的电脑依然可以访问代码服务器的情况。
产品或方案的特殊性带来的管理问题，对于Aspace而言，主要表现为：
- 与涉密业务相关的服务器（比如代码服务器，知识库管理系统）等都需要配置到安全协作网络内。即配置为O区不能访问，S区能访问。
- 部署S区专用的内部沟通与协作平台。或者把原有的迁入到S区。
- 由业务主管负责检查员工违规在O区处理信息的情况，并且及时批评纠正。比如前述脆弱性1中提到的情况，员工坚持在O区工作，代码服务器，协作与沟通工具都在S区，同事们都在S区，员工的这种坚持并不会威胁公司安全，而且他自己也并不舒服。这时，只要业务主管加以关心，问题很容易就得到纠正。
- 加强服务器的安全管理。比如部署服务器准入管理方案，严控服务器的管理员账号等。其实物理空间隔离的方案也存在服务器非法接入的问题（前述脆弱性4），但通常Aspace的语境下，客户更容易意识到这个问题。
- 因为只有解密外发一个途径，操作和原文都可以得到保留，所以可以视需要选用夹带检测的方法来加强。简单的办法比如审批人员手动做内容重建并比较文件大小，就能发现潜在的夹带（前述脆弱性2）。物理空间隔离的情况下，因为合法出口更多，物理带出和网络外发同时存在，夹带检测的要面对的情况就更加复杂。
- 内部人员直接采用研发手段进行攻击（前述脆弱性3），一方面，需要攻击者具备很强的心理素质和技术能力，他不仅要能做到，而且还要不留下蛛丝马迹，不引起注意。另一方面，文无第一，武无第二，攻击和防御谁更高明的问题永远都不会有确定的结论。作为管理者要做的是跳出这种无谓的争论，不能亲自下场卖弄技术。管理者可以从管理的角度解决问题。这里举例两个管理手段作为参考：a. 鼓励研发做攻击尝试，如果他们做不到，就意味着“相对于他们的水平，安全性是足够的”。b. 在O区和S区两侧监控和审计员工潜在的分析行为和内容外泄，不要试图严格阻断，而是要发现可疑的行为。这两个管理手段之所以有效，是利用了Aspace边界清晰，研发攻击行为容易暴露两个前提。
通过上述分析与比较，可以看到Aspace相比于物理空间隔离，更加灵活，尤其是具有“可管理性强”的优势。事实上，安全管理的核心目的之一就是要提高信息安全的可管理性，梳理清楚技术与管理的配合关系，才能获得有效的管理手段和变通余度。单纯一味地追逐技术安全性，而失去管理上的灵活性，所做的努力就会像马奇诺防线一样被消解在业务需求的细节之中。
3 执行清单
经过上述分析，下一步应该做什么基本上已经胸有成竹。下面给出两个经过简化的执行清单的示例。
3.1 基于空间隔离
3.2 基于Aspace
4. 执行清单的利用
现在我们已经有了执行清单，知道要做什么，为什么，也知道下一步应该重点关注什么。
此后，完成执行清单中的建设部分，公司的信息安全管理工作就进入日常状态。执行清单可以在下列方面继续发挥作用。
4.1 检查一致性，发现方案中的逻辑错漏
检查一致性，是确保安全性的诸多方法中性价比最高的一个。
方案的一致性比技术的安全性重要得多。技术的安全性没有止境，未知和不可控的挑战无处不在。现实中更常见的是为安全技术投入了巨大成本，却因为管理上一个不起眼的短板而失去价值。一致性检查可以发现安全方案中的短板，或者技术上的过分投入。
经过一段时间的管理经验积累，再去检视执行清单的内容，发现其中与现实不一致，或方案本身不一致的地方，就可以做出调整和改进。
比如：很多企业已经采用了物理空间隔离，但同时又要求隔离空间内要对源代码和文档进行加密。如果探究加密的必要，管理者就可能会列出各种硬盘、数据文件明文离开隔离空间的特例。
再比如：很多企业在部署数据防泄漏方案之前，会对数据做分类分级或密级标定，并在此后依据分类分级的结果来判断数据是否可以外发。但越是高价值的活跃的工作，在外发时就越可能产生各种“不得不外发”的理由来请求领导做裁决和审批。作为安全管理的一致性检查，就应该评估“事先的分类分级或密级标定，在事实上对事后的可否外发判定起到了多大的作用”。如果发现，只有那些对已经归档的、成为历史的项目文件的标定是有价值的，而新项目或活跃项目的文件大部分都依靠业务主管个人的判断，那就意味着分类分级和密级标定可能对归档更有意义，而对处在竞争前沿的活跃的机密信息的保护意义不大。
4.2 查漏补缺，发现未被覆盖的需求
可以使用如上的表格来查漏补缺，发现未被覆盖的需求，或未被处理的脆弱性。比如上表中揭示：
- 安检门和手持探测仪不能发现光盘。但如果隔离空间内确认没有光盘刻录机，也没有私自带入光盘刻录机的可能，这个问题就不用考虑。或者考虑再增加X光机，员工感受进一步降低。
- 审批并不能防止夹带，但审批时检查文件大小有助于发现在潜在的夹带行为，有助于缓解夹带的问题。
- 安全意识培训，违纪惩罚和案例宣传对任何脆弱性都有帮助，但都不可依靠。除去这两点，审批就是审批后外发行为的唯一安全保障。
4.3 检查落实，发现执行中的缺漏
基于执行清单，检查执行中产生的记录，并通过记录信息来评估安全管理方案的实施效果。
4.4 PDCA，在版本迭代中持续改进
使用一个文档版本管理软件，并有意识的对相关清单文件进行版本编号。这样通过前后版本的变化可以跟踪思路的演变过程，理解变化的原因，评估效果。
4.5 汇报和展示工作成果
直接使用清单表格、清单产生的数据、需求与措施的对照表等信息，轻松归纳和说明安全管理工作的成果。
通常会认为安全工作的成果汇报是个无解的困局，笑话说“没出事要你干什么？出了事又要你干什么？”。我们认为这是把安全片面的看做攻防、漏洞管理、应急响应等而导致的一种认识误区。如果一个安全管理者把工作目标设定为防止黑客攻击。而黑客是不可控的，理论上黑客在技术上无所不能，理论上漏洞总是存在。这样想的话，安全管理者的工作价值自然没法评价，没出事是运气好，出了事是能力差。
既然信息安全首先是管理工作，那成果汇报就应该从管理出发，采用管理的办法。使用务实问题清单的办法，以提高信息安全的可管理性为目标，安全问题产生于具体业务和经营目标，安全手段作用在业务和经营活动之上，最终体现信息安全为业务和经营保驾护航的价值。
4. 小结
本文结合一个简化和虚拟的研发信息防泄密的案例，介绍了执行清单的内容、产生和利用。并且通过物理空间隔离和Aspace软件隔离两个方案的分析和比较，试图帮助读者理解技术选择对管理工作的影响和约束。
