一个人的攻防演练：聊聊企业安全策略

写在前面

首先交代下背景，本次演练防守方的客户是一个金融企业，基础安全做了近3年，基本上就要迎接高大上的深度探索阶段，然后本次演练客户不是主要目标，属于大型目标下的小目标，也就是说供应链的一块，演练的时间本来想说是一个月的，后续又是省护，大家都明白了，总之敏感时期，不是在演练，就是在演练的路上；之所以介绍这些就是想说，防守方属于基础安全扎实，整体安全成熟度属于成长阶段，同时并不是主要攻击方，所以相应的我的压力就会小很多，虽然期间出现了很多0day，也有很多扫描，尝试攻击，甚至有异常通信，但基本上都处理完了，可能有一些没有发现的，这里也没办法说明，检测能力并不能说100%发现问题，以上就是本次攻防演练的背景。

接下来可能要说的都是和安全策略相关，攻防演练期间我们采取了一个怎么样的策略去进行防护，同时不影响业务，涉及策略的上层设计，策略的产生，策略的执行，策略的运营相关内容，因个人精力有限，就此抛砖引玉，共享盛世。

0×01 什么是策略？

策略宏观上指的时根据形势发展而制定的行动方针和斗争方法；

在服务器中，安全策略（Policy）的概念：安全策略既一种整体的安全控制策略，如依据某些服务的设计基本的存取控制策略，也是一堆具体规则（rule）的组合，指定具体服务针对具体资源的存取权限；

安全策略就是指在某个安全区域内（一个安全区域，通常是指属于某个组织的一系列处理和通信资源），用于所有与安全相关活动的一套规则。这些规则是由此安全区域中所设立的一个安全权力机构建立的，并由安全控制机构来描述、实施或实现的。

通俗一点就是针对资产（网络，数据，权限，账号等）限制访问，使用，授权等安全规则。

所以安全策略也可以叫做安全规则，由于策略的使用面和使用层级不同，策略有很多种表现，我这里参考威胁情报，我把策略分成战略层，战术层，作战（运营）层，为什么这么分层？便于对策略有不同级别的深入考虑，就个人分析发现分层不宜过多，此外要系统；

那么参考情报分层，我们可以得出：

战略策略：用于引导整个信息安全，网络安全的总体安全策略，主要用于我们用策略解决什么问题这一逻辑；

战术策略：策略如何去解决安全问题，主要考虑策略如何进一步的解决问题，问题的难易程度，策略的深度，如何去实现战略策略等等

作战（运营）策略：策略在针对安全问题进行解决的真实情况，有没有解决？解决了多少？存在什么隐患。如何优化策略？

所以我们要从三个点去考虑安全策略的生命周期，至少目前是如此。安全策略解决什么问题？安全策略如何解决问题？安全策略解决问题的效果如何？

1.1战略策略

大多数时候我们遇到某个策略时，脑海中总会有一种似曾相识的感觉。随着策略的展开，策略运营者会发现这难道不就是之前做过的类似的策略。曾几何时，同样的场景，不一样的人或工具，结果需要不断的调整策略，直到策略看起来完成全面的防护；我们不禁会想，为何没有在最开始就制定了完整的策略，一个全面覆盖的策略。尽管在策略的调整过程中可能做了一些小的优化，但对企业的安全没有持续，稳定的影响，可能有新的紧急问题得优先处理，导致策略一直没有很好的覆盖或闭环。人们对战略有一个误解，导致它往往被忽视。这个误解是没有时间实施战略。在日常的事件响应世界里发生了很多事情，有时候是每小时一次，许多人为了保持战术水平而感到不知所措。战略往往被视为“有更好”而不是“有需要”，只有在时间允许的情况下才会制定战略，但时间很少允许。

战略策略的名称不仅来自其涵盖的范围，通常是对信息具有长期影响的高层次分析，而且也来自其受众。 战略策略面向具有行动能力和决策权的决策者，因为这种情报应该形成向前推进的政策和策略 。但是，这并不意味着领导是唯一可以从这些见解中获益的群体。战略对各级人员都极为有用，因为它可以帮助他们了解在处理各级问题时的周围情况。理想的情况下，战略 可以帮助个人理解为什么要制定某些策略，或者为什么将重点放在某个特定的领域将有助于更有效地发挥个人角色的作用。 John Heidenrich说道：“ 战略并不是一个真正的计划，而是一个推动计划的逻辑 。”

在许多情况下，战略、战术或作战（运营）之间最重要的差异之一是建模过程。在战术和作战（运营）策略中，分析人员使用他们可用的模型来解决手头的问题，无论该模型是专家策略还是人工智能策略。在战略分析中，那些模型往往是第一次更新或开发。

记住，战略策略并不是策略的具体计划和细节，战略策略只是一个推动计划的策略逻辑；战略级的策略我们需要关注目的性和逻辑性；

1.1.1目的性

演练的战略策略我们一开始有2个的目的：

 1.尽量不被攻破
 2.不给上级供应链造成破坏，并且不垫底

后来我们的战略策略改成了：

不垫底

那么我们的战略就决定了我们在接下来的战术层面和作战（运营）层面不会过于严苛，比如禁止变更，不允许开放站点等行为，在某一程度上我们会容忍一定的策略放过和调整；此时的策略对业务会较为放松，这也是演练期间业务运行的策略，其实和平时的是一样的；

1.1.2逻辑性

与其说是逻辑性，倒不如说是合理性，逻辑严谨让人无法反驳，从某种角度而言，策略的出发点是符合逻辑的，比如我们要做一个针对上网使用远程工具的策略，禁止使用远程工具，这就是一个简单的战略策略，有着具体的目标和目的；关于策略实施会在战术和作战层面详细说明；

总而言之就是：

战略策略一定要存在目标和目的，要在战术策略，作战策略层面可以实施，符合一定的目的性和逻辑性；

1.2战术策略

战术策略主要关注受众，策略方法；

战术策略主要是面向你的用户，也就是策略的受众，以及如何制定策略，注意，此时的策略并没有实施，可以理解为一个解决方案；拿前面提到的针对远程工具访问内网的行为，我们制定了以下的策略：

针对业务人员禁止使用任何的远程访问工具

针对一些非业务，非管理员的用户我们禁止使用远程访问工具

针对网络，服务器等基础设施管理员我们允许在短时间内容提单申请下有限使用

针对远程访问工具，我们收集了anydesk，teamviewer，向日葵，RDP等

不同的受众有着不同的需求，就拿限制远程访问的受众来说，高层，业务人员，销售，办公基本上是不需要或者不允许可以远程访问，管理员在远程处理应急事件是可能会使用到远程访问工具，但大多数是VPN，供应链基本上都是远程访问工具；

上面就是一个具体的战术策略制定，但是实际上执行情况可能会和战术策略不太一致，但是不能违背禁止使用远程访问工具的战略策略；

1.3作战（运营）策略

策略分层只是为了让战略级别的策略能够更好的落地，大多数的策略其实只分两层：战略和战术策略，大概就是专注制定什么策略，策略怎么执行？但实际上策略制定完战术策略后，需要考虑策略的真实落地情况，需要对一些用户反馈意见较大的策略结合安全要求和业务适当调整，这里的调整不是让步，而是理解；

针对使用远程访问工具，我们进行了调整：

收集了更多的国内外的远程访问工具

允许了部分供应链授权情况下进行远程排查

增加了新的可控的远程访问手段

以上就是一个针对远程访问控制的大致策略设计；

1.4虎攻防演练案例

既然是演练，这里提一下我们在演练期间做的策略情况，可能有的总结点没写，但大致差不多，和大家演练的思路基本上是一致的。

1.4.1演练战略策略

减少所有的外部风险

关注内部潜在风险

1.4.2演练战术策略

回收测试区域的应用；

回收不符合安全要求的应用；

关闭不必要的端口；

排查外部弱口令情况；

组织演练沟通小组；

关注内部流量；

关注内部邮件

关注终端，服务器安全告警

1.4.3演练作战（运营）策略

（1）盘点所有外部开放资源，确定所有可以进入内网的途径，包括应用服务，端口，登录页面，确定资源的开放情况，关闭情况

（2）确定安全防护能力：确定所有安全设备的运行情况，安全设备规则库，病毒库，情报库，甚至系统库；

（3）监控外部威胁情报：0day，1day，Nday为主的攻击情报

（4）联合行业进行防护：同步相关攻击情报，对攻击IP进行封禁

（5）记录所有的攻击防护措施，避免过度防护导致业务运行异常

简而言之就是：

（1）暴露面最小化

最小的暴露面，确定的攻击路径

（2）安全能力持续更新

保持最新的防护策略和规则，通常包括检测规则和阻断规则，这里有IPS，IDS，FW，天眼

（3）及时响应和相应的响应组织

及时响应演练期间发现的漏洞和情报，同时有相关的管理员配合，实现快速响应，同时提前制定好相应的响应流程

（4）备注和登记

一般而言，很难在演练结束的一瞬间完成整个安全能力的升级，当一些无法进行实时整改的，需要进行登记备注，然后关联立项，同时部分策略实施后可能对业务会造成一定的影响，记录便于恢复

这里还得提下规则库，也属于战术策略的一部分，但由于可以进行优化的属性，也可以看成作战运营策略

0×02 策略设计

2.1需求产生策略

策略产生有很多，但最常见的就是两种，甚至可以说就是一种，那就是需求驱动策略，安全需求驱动安全策略的产生；还有一种时约定俗成的基线，你需要这么做；

我们的安全策略的目的是解决一些安全风险和安全问题，那么安全风险和安全问题经常会产生一些相应的安全需求，我们需要怎样的安全解决办法？比如我们担心账号会被爆破，我们就用限制失败次数和验证码的策略去限制爆破。我们担心用户会获取过多的权限，我们默认是最基础的权限策略，再要使用我们就通过申请审批来授权。我们担心扫描器的结果不好，所以我们要求用2-3种扫描器进行漏洞评估，同时我们要求扫描时使用最新的策略。等等，我们需要什么样的安全风险解决办法，我们就在此基础产生一定的安全需求，安全需求导向安全策略，安全策略总是有效的？不见得，后续我们在来聊一聊。

需求又从哪里获取？

需求一般有三个来源：

1.上司：一般是技术负责人对于安全有一定要求产生的安全需求，这一类是实现波动性较大的，有的需求可以实现，有的不一定，但大部分你都会尽力去满足，同时对上级的策略需要从多访问理解，比如业务，安全，基础设施等，一般都是战略级别的策略。

2.用户需求：此类需求又具体分内部用户和外部用户，比如你的内部用户要求你临时开放teamviewer权限，但你的安全策略限制了他的访问，此时你会临时在上网管理上开放，又或者你的内部用户觉得在上班时间宽带限速了，但下班时间以后也限速不合理，此时你就通过流控开放了18点之后的流量限制。外部用户的需求一般和产品相关，比如登陆需要验证码，客户觉得每次登陆都要验证码，体验很不好，然后就进行了反馈，然后应用觉得可以关闭，但又担心被爆破，此时你引入登陆设备，地址，时间段等风控手段，然后密码错误的前三次关闭了验证码，这一整套策略的调整都是来源于每次登陆都要验证码的反馈，用户此时满意的提交下一个反馈。

3.事件驱动：其实有一些安全策略的产生是被迫的，也是应该要具备的，比如外网开放3389，有一天服务器因为外网开放3389被cve-2019-0708等类似漏洞拿下了，甚至弱口令爆破，我们的策略就变成了：禁止开放3389端口，事件驱动安全需求，安全策略是很痛苦的，或许我们需要一个默认安全策略。

此时，在这里不得不提一个产品解决安全问题思路，那就是默认策略。

我们常听说Elasticsearch，mongodb数据泄露，通常是因为默认密码没有修改，倘若我们创建应用后强制修改成不同于默认密码的强口令，此类事件会少很多，同样一些防病毒默认是开始更新和同步，一些ips,waf,ti，ids产品配置好代理默认更新策略，默认关闭共享，默认关闭高危端口，等等，默认策略能够避免人力所不能及的那部分策略的失效或者未生效。

其实标准和合规可以极大的驱动出策略的产生，关于标准和合规此处不做赘述。

2.2策略设计原则

一个好的策略应该是在所有的受众下都可以接受并且是符合安全需求，业务需求的安全策略，能够促进生产和安全能力提升；

最小化原则

一个好的策略应该是至少符合最小化，有效，可优化的，为什么这么说？

好的策略不应该过于庞大，应该是精简而且恰到好处的，比如你担心Web收到攻击，所以你把WAF防护级别调到了最高，结果业务无法运行，实际上中级的防护级别加上定制化的策略修改就能够满足Web防护的功能，辅以web渗透和漏洞评估，网站监测就可以完成Web的基本防护

有效原则

策略最重要的其实是有效，任何的策略设计完之后如果无法起到预计的效果，都不是一个好的策略，比如在白名单防护策略中，由于白名单不详细，导致白名单之外的正常业务无法运行，此时应该取消白名单，先用黑名单过滤，然后再完善白名单后进行策略实施；

自适应原则

好的策略应该是可持续，并符合自适应安全自身和业务安全要求不断完善的，就拿限制远程访问工具的使用，很有可能出现新的远程访问工具，此时就应该将它添加的禁用名单，不然策略的本身就在失效中；

2.3如何设计一个好的策略

策略的好坏最终是看策略的实现，其目的和作用，如果你设计了一个策略，结果对业务造成了影响，那么这个策略从某种程度而言，虽然防护住了业务系统，但是影响了业务的运行水平，甚至影响业务连续性，这就得不偿失，一个较好的策略可以从以下几个方面考虑：

1.思考设计的策略是否可行？

好的策略是可以用于实现其策略的目的，并且落于实地；也就是说，首先策略能够定位到人或者资产，能够通过策略控制来实现策略的执行；其次策略是可以执行并不会影响业务和系统，策略的可行性从其他角度就是切合策略的受众的可用性；既能够实现策略最初的目的，又能够保护业务运行不受较大影响，安全策略最终的服务对象大多是业务和内部需求下的用户，此时要考虑业务运行和用户体验；同时要确定策略的受众，策略所执行的层面到底时在哪些用户或者设备资产，如果一个策略执行后无法在资产中进行定位，那么这个策略基本时无法运行的，管理策略也是如此；

2.策略是否可维护？是否可闭环？

策略实施之后可调整，可运营，可闭环，具备持续性，可维护性，如果策略在基础设施，技术发展的冲击下不复存在，此时策略应该取消，替换成针对新技术，新架构下的新战略策略下战术策略，作战策略

可闭环，相比可维护，闭环更难以实现，毕竟一个好的策略应该满足不但优化，并且能够符合业务驱动下的安全需求和受众，做到千人千面，反馈显得极为重要，好的反馈流程反馈渠道可以让策略落地的更加有效，这里建议将反馈渠道放在责任人和安全人员之间，最好有相应的讨论渠道，不断的快速获取反馈和优化；

3.受众是否乐意遵守策略并参与优化？

好的策略应尽可能的满足受众的心理期望并实现安全控制；

如果一个策略本身被大多数人抵触，并且短期无法看到策略执行后的效果，此时应该思考策略是否需要调整，或者策略是否应该设计并执行，真正充满人文关怀的策略是随风潜入夜，润物细无声的，所以策略设计尤为重要，并且在流程上需要足够的支持和适配；当然如果遇到适当的抵触，但是总体效果不错的策略可以适当的调整，以满足几乎所有受众的体验要求；

这里提一下漏洞修复策略：我对于安全是主战派，就是强调安全是需要测试并且充满主动的，所以我初期执行的漏洞修复策略是每月定期更新，并且强制推送，但是现在办公网络很多用户都不会进行日常的办公电脑维护，补丁安装过程充满了各种的问题和反馈，后续我将策略调整为高危漏洞或在野利用的漏洞强制推送，非高危且无在野利用的漏洞直接延期一月推送，并且对推送的时间做了调整，业务终端，也是反馈最多的终端在一个月基础再延期一周进行推送，前期基础设施，营销体系先推送，整个策略调整后反对的声音减少了一些，但漏洞管理依然会有一些抵触；

2.4策略生命周期

整个策略从产生到终止分成4个阶段：策略产生，策略使用，策略运营，策略终止

策略产生：策略经过战略策略设计，战术策略设计后产生的具体策略清单

策略使用：策略落地，开始对相应的受众进行约束的过程

策略运营：策略开始作战（运营）的阶段，主要目的在于调整和优化策略，查缺补漏

策略终止：策略随着技术架构变化调整后不再适用，经过评审后进行终止

基于策略简单的设计了一个策略钻石模型（参考事件钻石模型）：

该原子为“策略”，策略是最小单位，一个完整的策略应该有至少四个要素：目的，受众，技术和管理；策略的基本元素比较简单，主要有时间戳和执行结果，时间戳包括启用时间，调整时间，终止时间。

目的

目的就是策略产生的基本目的，也就是策略的产生是用于解决什么问题的？为什么要制定这个策略，目的是决定策略的归属和方向，只有明确目的的策略才能具备效力，目的最好体现的层是战略层策略；所以换句话而言，战略层的策略应该是专注解决特定类型的问题，一般是业务和安全自身需求；

受众

受众即策略最终落地去实施和使用的人群，也就是最终评价策略好坏的一环，受众的反馈有助于策略生命周期的延续，良好的策略反馈可以促进策略的优化和调整，不断的促进安全和业务需求下的策略的落地和改善

技术

主要是设计策略过程中使用的各类技术，涉及开发，网络，存储，数据库，桌面运维，邮服，中间件，安全技术等，相当于等保2.0中的技术部分；

管理

管理即通过流程，制度进行限定受众执行，达到弥补技术措施无法实现的手段，比如人员管理，外包管理，策略修订管理，业务上线下线管理，网络安全管理，权限管理，供应链管理等等；管理策略多来源ISO27000，监管单位要求，等保2.0等

0×03 策略的使用

策略的使用其实没有什么诀窍，大多说都是采取触发式的办法去使用策略，比如上线要安全评估，漏洞，基线，渗透，防护，甚至代码审计，只有有载体出现，策略才能生效，而难度主要在于策略的赋能，所以有几个建议：

建立策略库->插入流程->收集意见->定期更新和维护

 1.建立策略库：把策略当重要资产一样进行收集和统计，然后保持更新
 2.插入流程/引用策略：包括安全流程，处置安全问题，安全事件的流程，包括应用开发流程，业务上线流程，员工入职离职流程，资源申请归还，等等，在你的ITSM里面尽情，合理的展现
 3.收集意见、反馈：开放策略收集和反馈渠道，很大一部分的策略没有变化或者没有优化大多是因为听不到外界声音，策略的创建和维护者在自娱自乐
 4.定期更新和评估：没有永远不变的策略，只有相对完善的策略，不断的评估策略有效性，完整性，可用性，严谨性。

总结下就是2种方式使用策略：

（1）变更，流程触发策略使用：当有变更或者有措施将要执行的时候，插入策略评估，进行策略的评估，判断受众的行为是否满足已生效要求的策略，同时关注潜在目的，需求，风险下的策略，尤其是那些还没有实施的策略，这部分内容是策略运营的主要目的和核心；

（2）基线库定制规范策略：对于策略进行封装，让“出场”的设置资产，业务流程就符合基本安全，满足安全基线，从而达到策略规范，这里要注意的就是定期对策略进行检测和更新，基线是需要定制并不断的优化的；其深度，其广度应该覆盖所有的资产范围，业务流程范围；

0×04 策略运营

策略运营，现在大多数的安全都喜欢带上运营二字，策略也是，运营就是对策略整个产生，使用，结束的生命周期下进行优化的过程，同时参考三同步，并让策略持续拥有动能！

策略运营我把它分成 策略检测，策略更新，策略备份与维护，策略评估 四大块，简单的理解就是策略的后续生命活动特征。

4.1策略检测

策略下发或者受众执行后不一定百分百的生效，甚至有的策略可能会进行规避，临时的也好，长期的也罢，我们都需要一系列措施进行策略的检验和修复，常见的策略检测手段有定期策略检查，策略更新，策略备份与维护，策略评估，基线检查，代码审计等；

4.1.1策略检查

策略巡检即对业务流程，基础设施资产等资源下发的策略进行人工巡检，常见的策略巡检方式有风险评估和等保检查，安全设备评估，基线评估，代码审计等；通过风险评估，等保检查对资源进行排查，确认是否符合安全策略红线要求；

（1）风险评估：对 信息资产 （即某事件或事物所具有的信息集）所面临的威胁、存在的弱点、造成的影响，以及三者综合作用所带来风险的可能性的评估。作为 风险管理 的基础，风险评估是组织确定信息安全需求的一个重要途径，属于组织信息安全管理体系策划的过程。关于策略风险评估主要关注着策略对于风险控制的有效性，对资产面临的威胁，存在的弱点进行规避的措施是否有效，如果策略无效应该采取什么措施去规避是重中之重；

（2）等保检查：又叫等级保护，即对信息和信息载体按照重要性等级分级别进行保护的一种工作；那么就很容易理解策略对于资源的风险控制和保护要求，不同级别的系统所采取的的策略应该是不一样的；

（3）安全设备评估：这里指的是安全防护能力的评估，当你部署了各种安全设备的时候，并对设备进行了启用和防护，应该考虑安全防护，检测，阻拦，响应相关设备的能力是否存在缺失并进行及时的发现和更新，这里就需要对于各种设备有一定的理解和掌握，并能够自定义的优化相关设备，从而实现策略巡检，优化调整

（4）基线评估：基线评估其实就是对各种资源的基线情况进行检查和确认，这里主要准备的资源就是资产清单和资产对应的基线脚本和结果报表等

（5）代码审计：检查源代码源代码/3969)中的安全缺陷，检查程序源代码是否存在安全隐患，或者有编码不规范的地方，通过自动化工具或者人工审查的方式，对程序源代码逐条进行检查和分析，发现这些源代码缺陷引发的安全漏洞，并提供代码修订措施和建议。

（6）其他：其他可以对于策略进行检测的任何方式，包括但不仅限于风险评估，等保检查，安全设备评估，基线评估，代码审计，比如访谈确认业务流程和相关策略执行情况，手段并不是唯一的，专注检测出策略状态的目的。

4.2策略更新

策略更新部分是仅次于策略产生的重要部分，该环节的策略运营决定了策略的生存周期和使用效果。

策略更新包括策略变更和策略调整

策略变更：策略变更涉及策略的调整的流程，就是如何对策略调整进行规范化，不能肆意的调整策略从而导致策略影响业务

策略调整：指的是具体的策略调整的动作，可以是缩小范围，扩大范围，增加力度，减轻力度等涉及策略具体操作的行为。

4.3策略备份与维护

一般策略的修复就是为了解决策略下发不彻底，下发后执行不彻底，策略执行存在Bug等情况；

常见的策略备份是通过设备已有的备份功能直接进行备份，然后将备份包进行定期的维护，存储充足的情况基本上不考虑清理历史策略；

维护：当策略因为实施过程中产生较大影响和事件时，需要对策略进行停用维护，或者策略不生效，出现了异常（不满足策略当初设定的状态），需要对策略进行分析和纠正的过程。也可以是将某一节点某一时刻的策略恢复到上一个正常的节点；

4.4策略评估

策略维护主要考虑策略的备份和高可用性，不会由于设备绑定策略等原因，从而由于设备宕机甚至设备淘汰之后部分优化策略无法使用，策略维护主要考虑策略的备份和还原，策略评估主要考虑策略的优劣，通常通过以下几个问题来评估策略：

 1.策略用来干什么？策略达成了目标么？
 2.策略是否过于严格或者过于疏松？
 3.策略是否可以跳过？
 4.策略实施数据是否有存储和记录？

总而言之，一个好的策略就是有一个/多个明确的目标，追求简约，同时又不可绕过，最后能够定期的回顾和复盘。

0×05策略库系统

经过上面对策略的探讨，现在对策略进行一个基本的设计，此处只是一个Demo，仅供参考：

现在对上面的的模块进行更进一步的分析:

对于一些不怎么出现的模块，功能做一些自己的说明，通用的就不做说明了，比如账号认证模块

策略库管理：对于策略的记录，调整进行管理，主要是增加，删除，修改策略，策略库涉及基线策略，代码安全策略，其他业务，应用，流程，管理策略要求；

策略检测：主要是对于策略检测的操作进行管理和记录，和策略库分开管理；主要检测方式有基线检测，代码扫描，业务逻辑检测等

策略下发：这里主要考虑策略库系统可以实现的任务发布和无法实现下发的任务，可以调用的任务直接通过策略库系统进行下发，无法下发的通过调用接口或者手动策略调整的方式实现，所以策略下发由自动下发，手动下发，手动排查策略3中方式；

资产管理：策略库的资产主要由策略检查中的资产，CMDB API导入的资产，其他手动导入资产进行管理，资产的纬度就是策略和策略检查结果，检查结果为不符合/总检查项这样展示；可以通过nmap，masscan来进行资产发现；

工单系统：用于管理从ITIL中提交的策略检测的服务单和变更单，涉及策略的检测，调整为主，同时对工单的创建，执行，结束进行同步和监控

任务系统：定时检测任务和手动检测任务，主要是对于工单系统记录的内容进行操作记录，运行的检测脚本，执行情况进行跟进，对任务进行取消等

通知系统：对于一些策略评估项进行及时通知，对于一些结果进行手动通知

日志：策略库管理日志，策略检测日志，任务管理日志，工单系统日志，通知日志，资产更新日志等；

以上仅为demo，仅供参考；

总结

聊了那么多，你咋不放一些策略出来？

仔细想想，是没有安全策略还是安全策略没法实施。配置基线，病毒库，补丁更新，规则库，安全编码和SDL，上线，下线，大部分的企业都有涉及，但效果都一般，要么太厚重没办法落地，要么太浅显没有效果，很大一部分的安全策略需求都是来自于基础的安全需求和业务成长需要关注的安全能力，这一块会成为基础安全建设成熟度的一部分，并不是没有策略，而是没有用好策略。

最后说说演练，其实刚开始演练的时候我是不打算封IP的，因为这并没有什么价值和安全能力提升，就和当初政企等保一样，走个过场，然后应用和基础设施依旧千疮百孔，所以我对于恶意IP都是永久封禁和持续关注，后续再次高频率出现就开展溯源分析。以致于后面演练的频率从每小时一次分析告警到每天2次分析，演练期间是5*8值守，效果还行；

但从某种结果而言，HW给长期以等保为基线的企业带来了新的安全思维，新的安全理念，不再是单纯的报告和评分，而是攻防对抗下的博弈，也促进了很多甲乙方和安全从业人员对红蓝对抗的关注，所以我们都笑着说这是演习，对于企业来说，开放的端口和应用更清晰了，权限和内网架构，流量也更加的可见，风险管理也变得更加有效，这也是一件好事，就这次演练而言，做了很多，也深有感受，细细思量，最终得出一个结论：演练常态化是安全能力的持续正常迭代，这不能牺牲大量的用户体验来实现，有的直接关闭了外部邮箱访问，有的边缘业务全部关闭，意义不大，除非业务直接整体下线，那么新的业务如何开展？当然，像不做防护的邮箱，同时不遵循安全合规下的整改的边缘业务关闭和回收也不是不可以；

总的来说，只有具有防护，检测，阻拦，响应基本安全能力的企业才具有演练常态化的趋势，但不能忽略策略和流程的力量。安全其实应该是一种能力和属性，就像武器附魔一样，给业务增加杀伤力，但如果因为过度附魔而导致业务奔溃，业务使用的限制大幅度提高，原来平民武器到后来需要神一样的体质才能使用，那就得不偿失了，合适的才是最好的；

接下来个人会重点关注安全建设框架和模型，“一次性”的安全建设不能保证业务的持续安全，为了让安全更好的赋能，安全策略，安全建设应该更多的关注目的，业务需求驱动安全目的，战略目的驱动策略和建设；

策略就是为了控制风险，这里对于其他部分的内容，如风险控制，业务安全，风险库等内容不做过多的描述，会在后续的文章中聊聊自己的看法，也欢迎大家一起交流和分享；

*本文原创作者：LinuxSelf，本文属于FreeBuf原创奖励计划，未经许可禁止转载