1.1. 杀毒软件/安全软件

1.1.1. 杀毒软件可保护计算机免受网上病毒的侵扰

1.1.2. 每天都有新的病毒和其他恶意软件出现，因此重要的是要定期更新安全软件

1.2. HTTPS

1.2.1. 如果Web地址以https://开头，则表示网站配备了加密的安全层

1.2.2. 用户通常必须提供密码或其他身份验证手段才能访问该站点

1.2.3. 在线支付或访问机密信息都采用此加密保护

1.2.4. 在通过Internet或企业内部执行敏感操作时，培训用户在URL地址中查找它(https://)

1.2.5. 如果缺乏加密，同一网段上的用户就可以读取纯文本信息

1.3. 身份管理技术

1.3.1. 身份管理技术(Identity Management Technology)是存储分配的凭据，并根据请求（如当用户登录到系统时）与系统共享

1.3.2. 轻量级目录访问协议(LDAP)就是其中之一

1.3.3. 某些公司采用并提供企业许可的“密码安全”产品，该产品在每个用户的计算机上创建加密的密码文件

1.3.3.1. 用户只需学习一个长密码即可打开程序，并且可以安全地将所有密码存储在加密文件中

1.3.3.2. 单点登录系统也可以起到同样的作用

1.4. 入侵侦测和入侵防御软件

1.4.1. 入侵检测系统(IDS)将通知相关人员

1.4.2. IDS最好与入侵防御系统(IPS)进行连接，IPS系统可对已知攻击和不合逻辑的用户命令组合自动响应

1.4.3. 检测通常是通过分析组织内的模式来进行

1.4.4. 对预期模式的了解可检测出异常事件，当异常事件发生时系统会发送警报

1.5. 防火墙（防御）

1.5.1. 安全且复杂的防火墙应部署在企业网关上，它具有在允许高速数据传送的同时还能够执行详细的数据报分析的能力

1.6. 元数据跟踪

1.6.1. 跟踪元数据的工具有助于组织对敏感数据的移动进行跟踪

1.6.2. 外部代理可从与文档关联的元数据中检测出内部信息

1.6.3. 使用元数据标记敏感信息是确保数据得到防护的最佳方式

1.6.3.1. 由于大量数据丢失事件都是由于不知道数据的敏感性而缺少数据保护造成的

1.6.4. 如果元数据以某种方式从元数据库中暴露出来，则可能会发生这种风险，因为元数据文档完全掩盖了任何假设的风险

1.6.4.1. 由于经验丰富的黑客在网络上查找不受保护的敏感数据非常简单，因此这种风险可以忽略不计

1.6.5. 最有可能忽视保护敏感数据的人，往往是员工和管理人员

1.7. 数据脱敏/加密

1.7.1. 进行脱敏或加密的工具对于限制敏感数据的移动很有用

2.1. 应用CRUD矩阵

2.1.1. 创建和使用数据-流程矩阵和数据-角色关系（CRUD—创建、读取、更新、删除）矩阵有助于映射数据访问需求，并指导数据安全角色组、参数和权限的定义

2.1.2. 某些版本中添加E(Execute)执行，以创建CRUDE矩阵

2.2. 即时安全补丁部署

2.2.1. 应该有一个尽可能快地在所有计算机上安装安全补丁程序的流程

2.2.2. 恶意黑客只需获取一台计算机超级访问权限，就可以在网络上成功地开展攻击，因此不应该推迟这些更新

2.3. 元数据中的数据安全属性

2.3.1. 元数据存储库对于确保企业数据模型在跨业务流程使用中的完整性和一致性至关重要

2.3.2. 元数据应包括数据的安全性和监管分类

2.4. 项目需求中的安全要求

2.4.1. 对每个涉及数据的项目都必须解决系统和数据安全问题，在分析阶段详细确定数据和应用程序安全要求

2.4.2. 预先识别有助于指导设计，避免安全流程的改造

2.4.3. 如果实施团队一开始就了解数据保护要求，那么可将合规性构建到系统的基本架构中

2.5. 加密数据的高效搜索

2.5.1. 搜索加密数据显然包括需要解密数据

2.5.2. 减少需要解密数据量的方法之一是采用相同的加密方法来加密搜索条件（如字符串），然后用密文去查找匹配项

2.5.3. 匹配加密搜索条件的数据量要少得多，因此解密成本（和风险）会更低

2.5.4. 在结果集上使用明文搜索以获得完全匹配

2.6. 文件清理

2.6.1. 文件清理是在文件共享之前从中清理元数据（如历史变更记录跟踪）的过程

2.6.2. 文件清理降低了注释中的机密信息可能被共享的风险

2.6.3. 在合同中，获取这些信息可能会对谈判产生负面影响

3.1. 实施数据安全项目取决于企业文化、风险性质、公司管理数据的敏感性以及系统类型

3.2. 就绪评估/风险评估

3.2.1. 保持数据安全与企业文化息息相关

3.2.2. 组织往往会对危机作出反应，而不是主动管理问责并确保可审计性

3.2.3. 虽然完美的数据安全几乎不可能，但避免数据安全漏洞的最佳方法是建立安全需求、制度和操作规程的意识

3.2.4. 培训

3.2.4.1. 通过对组织各级安全措施的培训促进安全规范。通过在线测试等评估机制进行培训，以提高员工数据安全意识

3.2.4.2. 此类培训和测试应是强制性的，同时是员工绩效评估的前提条件

3.2.5. 制度的一致性

3.2.5.1. 为工作组和各部门制定数据安全制度和法规遵从制度，以健全企业制度为目标

3.2.5.2. 采取“因地制宜”的方式更有助于有效地吸引大家参与

3.2.6. 衡量安全性的收益

3.2.6.1. 将数据安全的收益同组织计划联系起来

3.2.6.2. 组织应在平衡记分卡度量和项目评估中包括数据安全活动的客观指标

3.2.7. 为供应商设置安全要求

3.2.7.1. 在服务水平协议(SLA)和外包合同义务中包括数据安全要求

3.2.7.2. SLA协议必须包括所有数据保护操作

3.2.8. 增强紧迫感

3.2.8.1. 强调法律、合同和监管要求，以增强数据安全管理的紧迫感

3.2.9. 持续沟通

3.2.9.1. 支持持续的员工安全培训计划，向员工通报安全计算实践和当前威胁

3.2.9.2. 通过持续性的规划传递一个信息，即安全计算十分重要，这需要管理层的支持

3.3. 组织与文化变革

3.3.1. 数据管理专员通常负责数据分类

3.3.2. 信息安全团队协助其遵从执行，并根据数据保护制度以及安全和监管分类建立操作规程

3.4. 用户数据授权的可见性

3.4.1. 必须在系统实施期间审查每个用户的数据授权（即单点授权提供的所有数据的总和），以确定是否包含任何受控信息

3.4.2. 了解谁可以访问哪些数据、需要包含密级和监管分类描述的元数据管理以及对权利和授权本身的管理

3.4.3. 监管敏感性分级应是数据定义过程的标准部分

3.5. 外包世界中的数据安全

3.5.1. 任何事情皆可外包，但责任除外

3.5.2. 外包IT运营会带来额外的数据安全挑战和责任

3.5.2.1. 外包增加了跨组织和地理边界共担数据责任的人数

3.5.2.2. 对以前非正式的角色和责任必须明确定义为合同义务，必须在外包合同中明确每个角色的职责和期望

3.5.3. 任何形式的外包都增加了组织风险，包括失去对技术环境、对组织数据使用方的控制

3.5.3.1. 数据安全措施和流程必须将外包供应商的风险既视为外部风险，又视为内部风险

3.5.4. IT外包的成熟使组织能够重新审视外包服务

3.5.4.1. 一个广泛的共识是，包括数据安全架构在内的IT架构和所有权应该是一项内部职责

3.5.4.1.1. 内部组织拥有并管理企业和安全架构

3.5.4.2. 外包合作伙伴可能负责实现体系架构

3.5.5. 转移控制，并非转移责任，而是需要更严格的风险管理和控制机制

3.5.5.1. 服务水平协议(SLA)

3.5.5.2. 外包合同中的有限责任条款

3.5.5.3. 合同中的审计权条款

3.5.5.4. 明确界定违反合同义务的后果

3.5.5.5. 来自服务提供商的定期数据安全报告

3.5.5.6. 对供应商系统活动进行独立监控

3.5.5.7. 定期且彻底的数据安全审核

3.5.5.8. 与服务提供商的持续沟通

3.5.5.9. 如果供应商位于另一国家/地区并发生争议时，应了解合同法中的法律差异

3.5.6. 外包组织从CRUD（创建、读取、更新和删除）矩阵的创建中受益匪浅

3.5.7. 负责、批注、咨询、通知(RACI)矩阵也有助于明确不同角色的角色、职责分离和职责，包括他们的数据安全义务

3.5.8. 在外包信息技术业务中，维护数据的责任仍在组织方

3.5.8.1. 建立适当的履约机制，并对签订外包协议的缔约方抱有现实期望至关重要

3.6. 云环境中的数据安全

3.6.1. “数据即服务(DaaS)”“软件即服务(SaaS)”“平台即服务(PaaS)”是当今常用术语

3.6.2. 云计算或通过互联网分发资源来处理数据和信息是对“XaaS”配置的补充

3.6.3. 数据安全制度需要考虑跨不同服务模型的数据分布

3.6.3.1. 需要利用外部数据安全标准

3.6.4. 在云计算中，共担责任、定义数据监管链以及定义所有权和托管权尤为重要

3.6.4.1. 基础设施方面的考虑对数据安全管理和数据制度有着直接的影响

3.6.5. 各种规模的组织都需要微调甚至创建面向云计算的新数据安全管理制度

3.6.5.1. 即使组织尚未在云中直接实施资源，业务合作伙伴也可能会实施

3.6.5.2. 在互联的数据世界中，允许业务合作伙伴使用云计算意味着组织的数据也被放在云中

3.6.5.3. 相同的数据扩散安全原则也适用于敏感/机密的生产数据

3.6.6. 私有云架构，包括虚拟机，即使可能更安全，也应遵循与企业其他部分相同的安全制度要求

4.1. 清晰有力的制度和规程是数据安全治理的基础

4.2. 数据安全和企业架构

4.2.1. 数据安全架构是企业架构的一部分，描述了在企业内如何实现数据安全以满足业务规则和外部法规

4.2.2. 安全架构

4.2.2.1. 用于管理数据安全的工具

4.2.2.2. 数据加密标准和机制

4.2.2.3. 外部供应商和承包商的数据访问指南

4.2.2.4. 通过互联网的数据传送协议

4.2.2.5. 文档要求

4.2.2.6. 远程访问标准

4.2.2.7. 安全漏洞事件报告规程

4.2.3. 数据的集成

4.2.3.1. 内部系统和业务部门

4.2.3.2. 组织及其外部业务合作伙伴

4.2.3.3. 组织和监管机构

4.2.4. 对于大型企业而言，以上各方之间的正式联络对于保护信息免遭误用、盗窃、泄露和丢失至关重要

4.2.4.1. 各方都必须了解与其他方有关的内容，以便能够以共同的语言沟通并朝着共同的目标努力

4.3. 度量指标

4.3.1. 必须对信息保护过程进行衡量并确保按要求运行

4.3.2. 指标还有助于流程改进，一些指标衡量流程的进度：开展的审计量、安装的安全系统、报告的事件数以及系统中未经检查的数据量

4.3.3. 更复杂的指标将侧重于审计结果或组织在成熟度模型上的变动

4.3.4. 安全实施指标

4.3.4.1. 安装了最新安全补丁程序的企业计算机百分比

4.3.4.2. 安装并运行最新反恶意软件的计算机百分比

4.3.4.3. 成功通过背景调查的新员工百分比

4.3.4.4. 在年度安全实践测验中得分超过80%的员工百分比

4.3.4.5. 已完成正式风险评估分析的业务单位的百分比

4.3.4.6. 在发生如火灾、地震、风暴、洪水、爆炸或其他灾难时，成功通过灾难恢复测试的业务流程百分比

4.3.4.7. 已成功解决审计发现的问题百分比

4.3.4.8. 跟踪趋势

4.3.4.8.1. 所有安全系统的性能指标

4.3.4.8.2. 背景调查和结果

4.3.4.8.3. 应急响应计划和业务连续性计划状态

4.3.4.8.4. 犯罪事件和调查

4.3.4.8.5. 合规的尽职调查以及需要解决的调查结果数量

4.3.4.8.6. 执行的信息风险管理分析以及导致可操作变更的分析数量

4.3.4.8.7. 制度审计的影响和结果，如清洁办公桌制度检查，由夜班安保人员在换班时执行

4.3.4.8.8. 安全操作、物理安全和场所保护统计信息

4.3.4.8.9. 记录在案的、可访问的安全标准（制度）

4.3.4.8.10. 相关方遵守安全制度的动机

4.3.4.8.11. 业务行为和声誉风险分析，包括员工培训

4.3.4.8.12. 基于特定类型数据（如财务、医疗、商业机密和内部信息）的业务保健因素和内部风险

4.3.4.8.13. 管理者和员工的信心和影响指标，作为数据信息安全工作和制度如何被感知的指示

4.3.5. 安全意识指标

4.3.5.1. 风险评估结果

4.3.5.1.1. 评估结果提供了定性数据，需要反馈给相关业务单位，以增强其责任意识

4.3.5.2. 风险事件和配置文件

4.3.5.2.1. 通过这些事件和文件确定需要纠正的未管理风险敞口

4.3.5.3. 正式的反馈调查和访谈

4.3.5.3.1. 通过这些调查和访谈确定安全意识水平

4.3.5.3.2. 还要衡量在目标人群中成功完成安全意识培训的员工数量

4.3.5.4. 事故复盘、经验教训和受害者访谈

4.3.5.4.1. 为安全意识方面的缺口提供了丰富的信息来源

4.3.5.4.2. 具体指标可包括已减小了多少漏洞

4.3.5.5. 补丁有效性审计

4.3.5.5.1. 涉及使用机密和受控信息的计算机，以评估安全补丁的有效性

4.3.6. 数据保护指标

4.3.6.1. 特定数据类型和信息系统的关键性排名

4.3.6.2. 与数据丢失、危害或损坏相关的事故、黑客攻击、盗窃或灾难的年损失预期

4.3.6.3. 特定数据丢失的风险与某些类别的受监管信息以及补救优先级排序相关

4.3.6.4. 数据与特定业务流程的风险映射，与销售点设备相关的风险将包含在金融支付系统的风险预测中

4.3.6.5. 对某些具有价值的数据资源及其传播媒介遭受攻击的可能性进行威胁评估

4.3.6.6. 对可能意外或有意泄露敏感信息的业务流程中的特定部分进行漏洞评估

4.3.6.7. 敏感数据的可审计列表的位置信息，要在整个组织中传播

4.3.7. 安全事件指标

4.3.7.1. 检测到并阻止了入侵尝试数量

4.3.7.2. 通过防止入侵节省的安全成本投资回报

4.3.8. 机密数据扩散

4.3.8.1. 应衡量机密数据的副本数量，以减少扩散

4.3.8.2. 机密数据存储的位置越多，泄露的风险就越大