如何共创POC 信息安全测试生态圈

冯斯恩

（上海汽车集团股份有限公司乘用车分公司， 上海 201804）

0 引言

POC[1]，即概念验证（Proof of Concept）。POC 测试是对目标对象按照业务需求进行验证性测试，特别是选型阶段。

企业及高层管理者都特别注重ROI，需严格控制重复投入或者是错误投入。尤其是网络安全、数据安全领域，专业性强，对规划引入某项技术、某个产品和某个解决方案时，均需要注重针对性、适度性和行业最佳实践。同时，各家企业又因所处行业不同、建设进度不同及安全理念不同，对于同一项技术、产品和解决方案关注的侧重点也不同。所以，依靠传统的口碑、企业实力和应用案例等维度作为决策依据的比重不断降低。而POC 信息安全测试能很好地解决上述问题，通过规划设计一系列小范围的典型应用场景，从真实应用的实践到战略意图的实现，来验证产品方案是否能满足业务需求，从而为规划业务合理性、产品方案可实施性，做出更客观、更准确的判断和决策。

1 POC 信息安全测试的难点和挑战

POC 信息安全测试（以下简称POC 安全测试或POC 测试）的关键要素包括以下方面：

1）准确且完整梳理业务需求，并转换为技术产品或技术方案信息安全需求。

2）合理确定POC 测试指标，设计构建POC 测试场景和用例。

3）客观公正地对POC 结果进行分析和评价。

要做好以上三点，需要足够的人员和时间投入，一般 “大厂” （特指企业规模大、信息安全建设完备及信息安全投入多的公司）是具备此类资源的，可惜他们均注重搞自研。而对于非大厂，特别是 “1 个人的安全部” 企业，面临安全团队人员和精力有限、应用场景少且单一以及企业安全需求的自驱动弱等局面，对POC 安全测试投入意愿性低，但又需要在短时间内选择引入契合度强、性价比高，且符合企业未来发展和潜在需求的安全产品。

2 POC 安全测试生态圈

所谓的POC 安全测试生态圈[2]，就是将业务安全需求及技术产品或技术方案安全需求、POC 安全测试指标、POC 安全测试场景和用例、POC 安全测试结果分析和评价等信息 “开源” 、开放。同时，允许基于同一类业务需求对已 “开源” 的POC 项目进行增补，给出完整的POC 过程信息和结果信息，完善POC 测试完备性、客观性和适用性。

对于构建这样一个生态，而且该生态又不是单纯的合并同类项，参与方不仅行业多样，业务需求发散。同时，在现实实践中，在甲方企业和乙方企业角度下，将安全产品业务需求、POC 结果等信息主动共享的意愿不强，对共享带来的不确定性存有忧虑。两个公司甚至公司间的部门都要考虑利益的交换，往往这些机构不会提供各自信息给其他公司，导致即使在同一个公司内，POC 测试信息也往往以孤岛形式出现。因此，需要一种共创共享模式，形成一条 “价值链” 。

3 POC 测试生态圈设计

3.1 “一种共创共享模式” ——联邦学习机制

联邦学习本质上是一种分布式机器学习技术，或机器学习框架。在保证数据隐私安全及合法合规的基础上，实现共同建模，提升AI 模型的效果。

将联邦学习机制应用至POC 测试，形成共创共享的POC 测试生态圈。把基于某个相对独立的业务需求，第一家企业称为开源方，其他每个参与该模式的企业称为参与方，根据开源方、各参与方之间所属地域以及行业分布的不同，将该模式分为三类：横向联邦模式、纵向联邦模式和联邦迁移模式，如图1 所示。

图1 联邦模式

3.1.1 横向联邦模式

横向联邦模式的本质是场景的联合，即扩展POC测试场景和POC 测试用例，使POC 测试能更充分、更客观地反映潜在安全产品的适合度。适用于参与方间业态相同但应用场景重合度少，即业务需求重叠多、应用场景重叠少时的场景。比如，不同性质的车企间，他们的业务相似（特征相似），但应用场景差别大。

步骤一：开源方在开源平台注册 “企业类型等基础特征信息” ，发布己方的业务需求以及已转换的技术产品或技术方案需求、POC 测试指标、POC 测试场景和用例、POC 测试产品信息和POC 结果分析和评价报告。

步骤二：每个参与方在开源平台注册 “企业类型等基础特征信息” ，利用本企业测试场景、测试用例对相同安全产品进行POC 测试，独立上传POC 结果分析和评价报告至开源平台，由开源方聚合各参与方的POC 结果信息，更新POC 测试指标、技术产品或技术方案需求（一般很少涉及）。

步骤三：开源方或开源平台，将更新后的需求、POC 指标、场景、用例和评价结果以及产品信息，共享给各参与方。

步骤四：各参与方按需更新各自的选型策略和POC 结果。

3.1.2 纵向联邦模式

纵向联邦模式的本质是需求的联合，交叉不同业态下的安全需求，使POC 指标考虑更周全、设置更合理，POC 测试结果更能体现企业未来的、潜在的需求，避免企业安全产品引入的短见性和片面性。适用于参与方间业态不同但应用场景重合度高（即业务需求重叠少、应用场景重叠多）的场景。比如，房地产企业与整车企业之间，他们的业务不同（特征不同），但都存在面向终端用户隐私（身份证号、家庭住址、消费习惯等）采集、应用和安全保护的相似场景。

步骤一：开源方在开源平台注册 “企业类型等基础特征信息” ，发布己方的业务需求以及已转换的技术产品或技术方案需求、POC 测试指标、POC 测试场景和用例、POC 测试产品信息、POC 结果分析和评价报告。

步骤二：每个参与方在开源平台注册 “企业类型等基础特征信息” ，提出基于本企业的业务需求、已转换的技术产品或技术方案需求和POC 测试指标。

步骤三：开源方以及其他参与方对于差异性的POC 测试指标进行POC 测试和分析、评价，并发布POC 测试用例和POC 结果评价。

步骤四：开源方或开源平台，将更新后的需求、POC 指标、用例和评价结果以及产品信息，共享给各参与方。

步骤五：各参与方按需更新各自的业务需求及POC 指标、更新产品引入对象。

3.1.3 联邦迁移模式

联邦迁移模式是指利用需求、POC 指标、应用场景之间的相似性，将在源企业的POC 结果，被目标企业直接采纳复用的过程。当参与者观察到己有需求、应用场景均已被包含且被POC 测试通过，引用该模式下的成果，即得即用，少走弯路，快速实现业务需求和价值。

步骤一：开源方在开源平台注册 “企业类型等基础特征信息” ，发布己方的业务需求以及已转换的技术产品或技术方案需求、POC 测试指标、POC 测试场景和用例、POC 测试产品信息和POC 结果评价报告。

步骤二：经过多轮的横向联邦模式和纵向联邦模式。

步骤三：参与方直接引用安全需求、POC 测试评价结果，引入目标安全产品。在实际应用后，发布该模式下对安全需求、POC 测试评价结果的正向反馈。

如图2 所示的POC 测试生态圈里，除了上述的 “开源方” 、 “参与方” ，还有游客方、开源平台方、安全产品方和白帽子方。其中，开源平台方即POC 测试生态圈的运营方，是独立的、公正可信的第三方机构。游客方的开源平台权限有限，是成为开源方、参与方的潜在企业。安全产品方，即安全产品厂商企业。白帽子方，即个人安全从业者，利用其专业知识和能力，对各方的共创产物进行double check。

图2 POC 测试生态圈

3.2 “一条价值链” ——生态圈值

如何运营该POC 测试生态，使各方均积极共创共献，又从中获得必要的帮助和相应的收益，在该生态处于良性循环中，需要 “一条价值链” ——生态圈值，由开源平台方按照生态贡献赋予圈值，后续进行兑付。

对于开源方，POC 测试开源、聚合发布和联邦迁移模式直接引用等按照生态圈规则，赋予不同的圈值。对于参与方，通过不同模式下的参与度、生态贡献等，赋予不同的圈值。对于游客方，需要通过消耗圈值共享生态成果。对于安全产品方，可通过生态圈发布圈值奖励计划，招募POC 测试的开源方，共享POC 测试结果、开源方和参与方需求。对于白帽子方，通过对生态圈共创产物进行复核确认，依据贡献值获取圈值。对于平台运营方，对平台运营、圈值运营，在不影响平台的客观、公正的前期下，采取公示的方式获取必要的收益资金和支持。

4 结语

设计和运营POC 信息安全生态圈较复杂，还有很多未尽事宜，例如，各方资质如何认定、平台如何建设、如何聚合各方共创产物、贡献值如何认定以及圈值如何运营和兑现等，还需进一步探索研究和实践。