安全管理

在四大的审计过程中，也提到了公司是否有安全委员会组织，在要推动管理体系建设和风险管控中需要建安全委员会，我们的安全委员会大概就是各个业务线的负责人组合而成，有开发运维测试，一般只开会，没有实际输出

### 安全治理

这五个方面是安全治理中比较关键的问题，也是考验管理能力、全局视野能力与掌控能力的关键成功要素，另外提到的安全战略规划，建议有需求的人员看看EA（企业架构）方法，前提是你需要有很强的安全能力背景。

1）战略一致性，信息安全的战略与重点应该与业务的战略、布局、拓展等能力需求保持一直，这个听起来简单，做起来并不容易，尤其在快速发展与变革的组织中，很考验安全Leader的业务理解、大型团队管理能力、资源投放能力。如果做不到，后果常见为安全团队变成救火队员、业务“裸奔“、领导们逐步对安全丧失信心等。

2）价值实现，信息安全是有价值的！这个做不做安全的人都不会反对，但如何体现出现来呢？也就是如何实现呢？企业信息安全绝不应该仅仅是安全产品与安全技术，酒香也怕巷子深，不能让业务认可并最终产生应用效果的安全技术都是信息安全部门在“耍流氓“式的自娱自乐。不管是前瞻性的研究还是实用性的落地技术与产品，信息安全部门的成本投入如何转化成生产力、产品技术壁垒、商业竞争优势、业务保障能力都是考验CSO们的能力。

3）风险优化，“影响目标实现的不确定性因素“（定义来自，尼古拉斯·西蒙·吴，极简化理解仅供参考）。在那些可能影响现在、未来业务生存与发展的地方，在可能导致公司归零的领域，优化风险管理能力、优化信息安全战场态势、变被动为主动能力，是信息安全风险的关键优化要求。以业务与风险为导向，以威胁为驱动手段，从管理、技术、人的纵深；从业务自身能力、安全风险管控能力、安全监督审计能力的纵深；从业务外延领域、虚拟边界领域、核心能力领域的纵深，进行全面安全风险整合优化，提升感知、管控、处置、迭代能力。

4）资源投放效率，安全治理中需要解决安全资源投放效率的问题，安全人员总数有限，招聘难度大，内部团队规模有限，资金支持也是在一定的预算范围内，能不能把资源合理使用，最大化发挥价值，不管是用ROI（投资回报）测算还是ALE（年预期损失）与管控成本差等方法，需要管理技巧对资源进行合理投放，但这方面安全团队的管理成熟度与对安全全面理解与把控能力上面临很大的挑战。

5）度量评价，安全的效果衡量，资源使用的度量评价，是安全治理中结果呈现环节的核心，无法衡量的价值可以作为一句漂亮的PR语句，但如果试图用这个说法找高层要资源、谈业绩，那么结果可能不一定漂亮。安全的指标体系、评价方法可以参考的内容不多，但金融行业风险管理与指标度量方法、ISO2700中的信息安全测量方法可以借鉴，但实践中能够落到实处的基本还是根据企业实际业务情况结合安全体系所构建的针对性测评指标更容易发挥作用，如建设类的具体能力点的覆盖率、准确率、召回率、稳定性等，运营类的平均事件响应时间、平均漏洞修复时间等。

### 重点保障

重保三宝，预案，检讨和辞呈，看情况摸一份甩出去，我让运维工程师准备了一份，平时跟他们讲的明白，定位叫临时工，工资比我高，出事好顶锅。多招两个互为 ab，开一个不至于业务瘫痪。想通了，被干塌了大不了离职，这背锅的日子。。。不过有一点做了快半年了，感觉有用

每周开一次运维会议，把所有运维厂商叫过来，把流量层，主机层，终端层的事件都过一遍，确定没有问题后一个一个签字，留存。以周为单位结掉，然后扫描报出给分管领导。这样，万一遇到外部通报，动辄是一两个月以前的事件，不用排查，直接把当周报告打印出来，该怎样怎样。好多外部通报基本不准，直接对打回去，万一准的，那就是能力不行，不是没做，你看报告就在这儿，我没责任。给人还是加设备领导定。留依据挺重要的

我们每天日会过昨天事件，坚持有几年了，以前是所有人一起，后面的确成本太高，现在改成 3 人加厂商模式，最怕的是麻木了，不优化，天天报警的事件，万一忽略了某事件，就得背锅了

### 安全治理

谭老师说的很有参考价值，目前在推行各类基础安全系统时，也会联合公司法务、内控、HR、职业道德等岗位，通过岗位不相容原则来设置不同的角色和权限，避免安全一方独大，就像警察上面还有督察一样。另外为了安全部门自身的考虑，也需要引入更多的角色一起来合作承担相关责任和义务

如果一个公司请来的安全人员想把公司建设成业内隐私标兵，而不考虑盈利需求，那么老板会怎么想，他是在代表谁

安全团队不能“器”用的太爽，否则凡事都需要自证清白，安全团队就告别野蛮成长阶段了

甲方和乙方的站位思考是不一样的，因为屁股不同，如果真的把什么GDPR之类的奉为圣经去企业内部搞整风运动，估计就呵呵了，除非借用来推动自己想做的一些事情还算务实

那些安全法律法规有一堆业内布道者天天在营销，但他们从来不说在企业里触及了人性怎么办，就跟售前一样只管挖坑，不管填坑

其实刚才还没说到极端情况哈 小的公司为求生存 故意违背法律法规 逃避监管 请问各位在职的安全人员 大家如何抉择？

一般都有通知整改期，不会一下子搞死的，对于这个过程绝大多数企业其实有悔改的操作空间的，（除了一些xxx问题直接引发关停的），知会风险，把选择权留给业务，说明后果，决策权和责任担当在同一方

市值领先，没有压力，可以自由的说不作恶，等有业绩压力，CEO都要面临董事会罢免的时候vs员工罢工，你是CEO你选哪个

GDPR老实说还是有点用（指非监管层面），借此作为由头推动内部平台业务侧数据鉴权授权审计，不然估计很难有业务方能去积极响应这事，野蛮生长的第X阶段

这个属于安全上层工作做得不好，在公司内没有影响力

安全治理的核心问题不是那些27001框架里的内容，第一要务是解决安全风险的决策权归属和责任担当框架的问题

因为企业不发展到一定阶段安全真没什么太大话语权呀 挂运维下头都很常见的组织架构 影响力是会有边界的 要考虑因素就很多了

但凡做安全管理直接切入流程制度的，可能都低了一个层次，Cobit之类的背的天花乱坠也不解决问题

安全不是说要主张做到这个样子，而是说，这个东西有这个风险，隐私泄漏，然后会导致什么后果，有案例在前，我们可以做一二三，分别要投入什么资源，给我安全哪些东西，如果做一出了事我们能抓人，如果做二我们能在关键处防止问题发生，如果做三我们能做全生命周期但是大家要改变使用方式，我有能力有方法，你来选择

### 等级保护

一般建议的初次做等保备案的顺序是

1、先和专家沟通好定几级，

2、找测评机构先按照定的级别做测评，

3、让测评机构出专家，做定级评审完成定级，

4、拿着定级备案和测评报告去做备案。（一般定级30工作日内要备案，所以先按照假定的级别做测评比较好，把定级和备案一起完成）

#### 云上应用

问问大家，所有的系统（生产）在云上，且云本身通过了等保且拿到高分，在测评过程中是否可以拿云安全的测评结果当做自身系统安全的标准，并且纳入测评合格项？

这个不行吧，云本身的测评可能有一些侧重点，比如云自身基础架构等平台方面的安全性，你的自身系统放入云平台，那自身系统的应用安全等云平台测评应该是不管的

在云上的话，一般物理安全层面不会测评，但是其它还是需要测评的

平台侧和租户侧分开测评，看你上云用的是啥，当前多为IaaS，OS以上还需要测评，还和你用的云架构有

云上肯定是需要测的，云自身的测评报告也需要作为附件，否则可能也需要测

### 隐私政策

有2个问题， 要求说提示用户阅读隐私政策前就开始收集用户信息。 紧通过通知平台发送短信是否算收集了，并未落地本地数据库，是否算收集？   收短信的目的是注册新账户，相关账户信息才会在数据库留存，而注册需同意协议，这个是否合规

稳妥考虑，最好是首次使用就弹出隐私协议，否则就容易违规

我的理解，隐私政策的主要用途就是告诉用户我收集你什么信息了，为什么，收集的信息会怎么使用和处理，所以从事务层面来说，一旦涉及收集用户信息，就应该先主动弹出隐私协议，君不见欧洲GPDR以后，访问国外网站，都是显著提示用户查看和接受隐私协议，而不是老早的，防止网站主页最下面，需要用户自己点击才能看到，给客户发短信，意味着你已经知道客户手机号了，不管是存在内存里，还是写到数据库里，从法理来说，应该让用户确认隐私协议先

现在app大都开启了定位信息获取，imei获取，app列表获取等能力，如果不在首次使用时签署协议，有违规的嫌疑。