-
任何产品都用于至少一个用户 —— 管理员。当你的创业项目还只有 4 个人左右的时候，你需要做的只有，用一个复杂密码替换掉默认的管理员密码，并通过支持密码分享的密码管理软件共享。
-
共享密码是为了避免出现当他人需要权限进入系统的时候，密码却只有一个人知道的尴尬状况。
-
最好每个人每个服务都对应一个不同的用户。其次是分别创建一个管理员用户（用于特殊情况），开发者用户（用于日常工作）和服务用户（用于检查代码）。主要思想是，当一位开发者离开时，你无需更换服务密码。
-
向你的雇员们解释清楚，最终他们只需要记住两个密码：电脑的密码以及密码管理器的密码。
-
向你的雇员们解释清楚，不要使用他们的“家庭”或者“个人”密码。因为那些密码很有可能已经被曝光了，或者即将被曝光。更多信息详见https://haveibeenpwned.com
-
解释清楚如何选择密码管理器的密码。这里一则短视频介绍了该怎么做。
-
雇员们很有可能会讲工作时候用的电脑用于个人事务。那无可厚非。尽管如此，从第一天开始，跟你的雇员解释清楚不要把工作用电脑用于下载种子文件、色情内容或者访问其他不健康网站。让他们另外购买电脑用于这类事情。
-
如果你被入侵了的话，很有可能是因为有一名员工打开钓鱼邮件中的一个链接。作为公司娱乐活动中的一项，来玩玩防钓鱼测试吧。
-
停止使用邮箱附件。那些习惯打开邮件附件的员工最容易装上恶意软件了。使用 Google Drive 来共享文件，如果你处于受监管的网络中，使用 Box 作为替代（尽管它更加昂贵）。
-
使用 Slack 来进行内部沟通。使用邮件来联系客户和供应商。
-
使用密码管理软件来分享密码、许可证和秘密信息。
-
停止使用 U 盘。在公司文化中明令禁止使用这种设备！它们是黑客控制你电脑的最快的方法。教导你的员工把它们视作严重威胁！
-
更多背景信息，请阅读 DBIR(数据泄漏调查报告) 。
如果你的电脑因故丢失或者被偷走，你不会希望危及到其中的数据。
- Mac 用户仅需点击几下即可加密硬盘。
- Windows 用户需要专业版支持并且选择支持 TPM（可信平台模块) 的硬件。
- Linux 用户需要将硬盘重新格式化。
有一点在选购电脑的时候需要注意。如果在将来，为了迎合规定（比如 MDM — 移动设备管理），你需要集中管理你的电脑的时候，你得知道，大多数的供应商是不支持 Linux 的。它们一般都支持 Mac、Windows Pro、Android 以及 iPhone，但是仅部分支持 Linux 或者完全不支持。
与 Android 相比，没有越狱的 iPhone 更难被攻击。它们还默认打开锁屏和机密功能。确保你的经理和管理员打开了他们手机上的锁屏和加密功能。
大多数的操作系统（电脑或者云端）都有自动安全升级的选项。通常这只需要一行配置，但却可以降低近 10 倍受攻击的风险。
你将会至少需要一个域名用于网站，一个用于 API，一个内部使用。
-
第一个域名通常是公司的官方名称或品牌名，用于市场营销（网站）和员工邮箱。这两个大多由外部服务供应商提供。使用 SPF 和 DKIM 保护邮件域名。那并不是很复杂，但却可以降低黑客的钓鱼攻击威胁。大量的安全事故都源于某个员工打开了一个钓鱼邮件，因此这很重要。
-
第二个域名用于服务本身（比如 REST API）。这个域名需要额外的注意，与企业域名不同，这个域名很有可能是托管在 AWS 上的，并且由工程师来维护。这个域名的存在有两个主要原因。第一，企业域名是由 SPF 保护的，这使得从 AWS SES 自动发出的邮件很有可能被识别为垃圾邮件。另一个原因是自动发出的邮件很有可能会被收信端识别为垃圾邮件。仅仅是影响了部分员工正常接收邮件（被识别为垃圾邮件），这个问题就已经足够严重。
-
第三个域名用于内部使用和后勤工作。这个域名最好是匿名注册的，这样就不会那么容易被找到了。
如果可能，尽量使用 SSL，包括你的网站、API、后勤工作服务器以及内部服务器（如果可行的话）。
查看 AWS ACM 或者 Let's Encrypt 来获得更简单的方案。
监控你的公共证书的过期时间从而避免证书过期。
记住，SSL 会加密网络流量，但是并不提供认证。SSL 也不能替代 2FA（两步验证）。
-
一旦选好了一个基础设施供应商，要想更换就很难了。在将来你会需要保护那些供应商可以接触到得到的数据。因此，对于云服务提供商，选择这些巨头（Amazon、Google、Microsoft）中的一个，或者至少是拥有 SOC2 Type2 认证的供应商（对于基础设施服务），对于支付服务商，至少要拥有 PCI 认证，或者拥有其它相关的业内认可的证书。
-
这并不意味他们的服务就很好。这仅意味着日后你无需更换供应商。
-
AWS 用户默认会选择 Oregen (us-west-2)数据中心。如果你清楚你的目标市场在哪里，你应该选择靠近目标市场的数据中心。
-
对于那些严格规定数据所在地的国家，可能会有些监管方面的问题。对于欧洲的顾客，这可能会导致交易失败，而后期迁移数据中心代价可能是相当高昂的。
如果你的公司对外开放 API 服务，确保每一个用户都有一个唯一的 API key。否则的话，当某个客户的测试脚本出现 bug 的时候，你的整个服务都有可能下线。
使用 git 和 pull-request 是进行版本控制的最基本的方法。合适的版本控制和测试是创业公司的一项基本要求。最好从现在开始就做起来。
使用 git 还可以让你得以在有限时间内聘用外包／兼职的开发者，只需要给他们提交的权限并在日后取消就行了。
-
为你使用的所有服务都打开两步验证。这对你的开发团队尤其重要，因为一旦这些服务被入侵的话，很可能你的整个产品都得下线。 Google、Dropbox、GitHub、Microsoft 等等，所有账户！
-
那些目标用户是企业客户，或者在受监管的环境中的工作的，通常从第一天开始就开启了两步验证。
-
一个简单易用的使用两步验证的方法是使用 TOTP(Time-based One-time Password) 两步验证。雇员们可以在手机安装 Google Authenticator，它会生成一个一次性的 6 位数字，登陆的时候除了密码还需输入这 6 位数字才行。
-
一个更加可行的方案是推送通知。很多 SaaS 服务商支持通过推送通知来验证。这要比每次登陆的时候都得输入 6 位数字来得方便。缺点是你可能需要为每个不同的服务准备不同的 App，并且在没有网络连接或者推送服务宕机的时候失效。
-
使用手机进行两步验证的问题在于，当某位雇员丢失／忘记／替换手机或者手机没电的时候，他就无法进入系统。一些员工不喜欢加固他们的手机（使用加密和锁屏来保护两步验证软件），并且认为公司应该为其购买运行两步验证软件的手机。这就是一些机构选择使用 Yubikey（一种小型的可以感应指纹触摸的 USB 设备） 的原因。和手机 App 推送通知一样，Yubikey 可以防止恶意软件和黑客利用键盘记录密码。缺点是，与手机不同，雇员很可能会和电脑一起丢失 Yubikey。所以，如果被偷走的笔记本落入可以把密码从电脑中提取出来的人手中，这样他们就可以使用这枚 Yubikey 登陆任何服务。另一个问题是，Yubikey 是一个 USB 设备，所以你得区分开 USB 存储设备（不被允许）和 Yubikey（允许）。
-
使用短信来完成两步验证是不被鼓励的并且应该被禁用。一个有经验的黑客可以说服你的手机网络客服将你的线路转到他的名下。另外，最近发现近 8亿 Android 设备感染有能够读取短信内容的恶意软件。
-
使用语音呼叫来进行两步验证也应该被禁用。黑客只需在你手机离线的时候尝试登陆，然后黑进你的语音信箱，而这只需要猜对你那可能从来没换过的四位密码即可。
-
如果某位雇员要求远程修改密码，可能的话让他亲自来到办公室修改。如果这不可行（或者时间上来不及），验证他的他们的身份：不要认为你可以听出他们的声音。永远不要使用邮件发送密码。
-
为离职人员准备一个列表。列出所有需要停用的服务（记得包括聊天群等，注意不要在群里发送密码）。
-
检查 Google 文档日志（或者类似服务）确保离职人员没有下载敏感信息。
-
多数终端安全产品都可以设置避免外部设备（USB、蓝牙、手机等）拷贝电脑数据。
-
以防离职人员仍然拥有管理员密码，建议更换敏感性系统的密码。
-
当你在招聘新员工的时候，询问他们的前同事该人的性格类型以及离开前任公司的方式。请注意，至少在以色列，要求雇员提交犯罪记录是违法的。
-
你可以很方便找家服务商为你安装办公室 VPN（不要自己安装）。
-
一个办公室 VPN 加上一个办公室网络的固定 IP 地址可以让你限制服务器的访问控制。举个例子，你只需要允许办公室网络或者在家通过办公室 VPN 连接的接入权限，而不用将 22 （ssh）端口开放给整个因特网了。
-
另外，建立在云端的 VPN（比如安装在 AWS EC2上的）要有一些额外的优点。首先，办公室与云端的所有通信都是加密的（当你在访问数据存储，比如不使用 SSL 的 Elasticsearch 时，这一点尤其重要）。对于那些离办公室很远的远程工作者来说，网络环境也要更好些。另外，既然办公室里没有网络设备，这也缓解了物理层面的安全压力。这时候，办公室就像一家咖啡馆。缺点是每次断开办公室网络连接时，你都得重新连接 VPN。
-
VPN 连接也应该开启两步验证。
-
安装一款终端安全产品是很容易的。确保这款产品支持你们所有电脑的系统。配置好自动更新，发送邮件警报（可能会比较吵），并且屏蔽所有外部连接。最后一项对本地运行服务器的开发者很重要。
-
最好在雇员到达前就装好反病毒软件，因为很多开发者都对安装反病毒软件不感冒。
-
大多数产品都有导出／导入功能，这使得配置更加容易。
-
除了反病毒软件之外，还有其他的额外保护产品称为 EDR（Cyberreason, BlackCobalt），但是他们通常来说非常昂贵。
如果资金允许的话，使用第三方认证服务来存储密码、管理密码、恢复密码、两步验证以及其他。一些服务商会提供按每月活跃用户计费。
然而，如果你决定开发自己认证系统的话，请遵守OWASP 用户认证指南。
- 如果你的数据库泄露并被公布出来，当你的用户密码包含在其中而且容易被破解的时候，事情会变得更加棘手。（人们喜欢重复使用密码。这是真的。）因此，记住使用哈希算法 专为存储密码设计 来保存用户的密码到数据库中。bcrypt、PBKDF2 或者 scrypt 等通常需要一秒钟左右来哈希化密码。不要使用 MD5、SHA1 或者其他 不是专为存储密码设计 的哈希算法，用这种算法存储的密码通常只需要几秒钟来破解。
-
设置你的电脑在你离开（最多）5 分钟后进入睡眠，并且需要密码来重新打开。要求雇员们离开桌子时手动锁定桌面，比如使用 macOS 的触发角， 或者在 Windows 上按徽标键 + L。
-
永远不要让陌生人靠近电脑（尤其是有 USB 接口的）。物理接触是威胁到你的系统、产品与用户的最快的方式。
-
提醒雇员在离开时关好门窗，并启用警报器。
-
工作时间内在前门放置警示牌来震慑内部偷窃。要求员工接近陌生人如果他们没有员工陪同的话。
-
锁好机房（或者其他放置网络设备的房间）。
-
检查云端防火墙配置，确保没有低级错误。
-
建立一个邮件群组并命名为[email protected]，在你的网站放置一个页面来发送安全问题到这个邮箱。
-
为了能够及时了解严重问题隐患，开设一个 Zapier 账号，简单点击几下，将风险项的 RSS 订阅源连接到 Pagerduty 上。这里是一个个 RSS 订阅源和一个 Zapier 过滤器配置范例。
-
后期再来把生产网络和开发网络分隔开来是件很难的事情。在 AWS 上，安全可以通过账号层面来轻松地管理，因此开发用私人虚拟云（VPC）应该归属于机构内的一个单独的账号。通常会有三个账号。一个用来统一计费，一个用于产品，另一个用于其他所有事务（开发和后勤，通过访问控制来只允许来自办公室的连接）。
-
最近 Amazon 发布了 AWS 机构，更进一步地简化了为不同账号分配不同规则以及支付账单的过程。
-
把生产与开发环境分开来也会有缺点。有时候你会想要把数据从生产环境拷贝到开发环境（或者反过来），这时候就需要 VPC 之间的通信和自定义访问控制规则了。虽然这不是啥高精尖科技但是却需要细心。
-
一旦你开始向大客户做销售，他们可能会要求关于安全的认证和规章方面的报告。而你要做的第一件事就是 —— 不要紧张。接下来，找一个技术实力过硬的员工来处理会议和文案。
-
试着弄清楚哪些部分是可以放弃的，从而界定好需要考量的内容。下面是一些例子：
-
即使你得开设另一个 Amazon 账号并且不得不移动部分只有两个员工能接入的服务，那也是值得的。这可以将资格认证限定到那个账号以及那两个员工。
-
考虑把产品服务（用于服务客户）和工作服务（用于服务雇员）分开到不同的账户中去。通常情况下，产品账号的管理要更加严格。
-
另外，你许需要进行渗透测试。测试期间，你得允许外部渗透测试服务商来尝试绕开你的安全措施并且利用危险项以及错误的配置。
-
某些情况下，你需要提供给渗透测试方 API key 来模拟客户账号被黑并被黑客利用来黑进你的组织的情况。这就是灰度测试。
-
其他情况下，你可能得允许渗透测试方来检查你的代码库。价格取决于服务的复杂度、黑客的经验以及代码数量。
-
-
这里还有一个重要概念——补偿性控制。这是你可以（谨慎）使用的另一张王牌require further translation。举个例子，当某项规则被违背的时候，Slack 机器人就会向经理发送一条信息，这就是此项规则没有强制执行时的补偿性控制。对于小企业而言，通常来说，在罕见情况下发出警报要比强制执行更加合理。
-
资格认证中的一大部分是关于过程和处理公司内的各种文档的。对于小型创业公司而言，新建一个 Google 文档详细说明什么时候使用 git，什么时候使用在线文档，以及当你是最后一个离开办公室的时候你得锁上哪些门之类。把它作为新员工第一天必读材料并且保持更新。这对许多资格认证都是有效的。你可能会需要为某些句子标上注释以注明来源，使其变得易于查询。
-
留意资格认证其本身的花费，以及总开销（包括渗透测试、人力资源，你可能会需要雇佣自由职业者来确保这项工作可以按时完成，从而使你的销售正常运转）。
-
当你移除他们的权限的时候，开发者往往认为这是针对个人的（甚至可能会感到愤怒）。与其他拥有管理权限的相比，他们会觉得自己不再被信任。他们可能会觉得不管是谁在促进资格认证，都是在以他们为代价来表现自己。另外一些人会觉得他们被戴上了镣铐束缚住了手脚，像是在为官僚集团工作。
-
你不可能让所有人参与决策，但是你可以努力使持有不同意见并敢于发声的代表人物参与进来。开发者通常不善于抱怨，他们只是不理解为什么需要抱怨。因此，你必须指出哪些部分是对认证很重要的，哪些是顺便加进去的以往积累的技术债。具体说明顾客提出的具体安全需求。
-
把自动化需要的时间也考虑进去。自动化必须被用于需要高优先级的常规型任务。举个例子，添加一个新客户，又或者是升级一个新版本。没有自动化处理的话，任何人都得需要管理员权限；而有了合适的自动化工具的帮助，任何雇员都可以自行执行那些操作。显然，流程的改变也需要经过同伴审查。
-
提醒团队领头人和管理员也不要使用管理员权限，而是与其他人一样使用自动化工具完成日常任务。管理员权限的使用不能让他人产生嫉妒感，而应该用于自动化工具无法解决的长期精准的任务。这关乎以身作则，以礼待人的领导智慧。
-
为在特定情况下给特定员工提供有限时间的管理权限制定规程。有些时候，某个开发者可能需要管理员权限来加速新组件的开发进度或者自动化某个重复性任务。记得流程中要有可以提交给审查员的日志记录。这是很有必要，因为这样开发者就不用每天找 10 次管理员了，也免得使双方都不愉快。
-
一些小公司会把所有开发者都定为管理员。审查员可能会接受这种做法并在报告里面提到这点。
现在你应该已经拥有了自动化测试，（半）自动化升级／降级产品版本。下一步要做的就是确保生产系统是不可更改的。这意味着，一旦某个服务上线了，就永远不能再更改，只能通过新更新的实例覆盖。
-
缺点是，如果自动化服务器宕机，或者只是某些测试偶然没有通过，整个组织就得面临服务下线。有了 Murphy 的帮助，那仅会在你为产品做紧急快速修复时发生。
-
接下来，你需要一个优先于自动化的方法。但那不必是管理员权限。那可能仅仅是一个意味着推送未经测试组件到产品的标签。作为补偿性控制，你可以在某个开发者使用这个标签的时候给负责人／管理员发送条通知。
-
任何更改数据库键值，影响产品的行为都必须通过变更管理。
-
一定程度上，SaaS 服务商的数量乘上雇员的数量使得密码管理器难以维护，尤其是在有员工入职或离职的时候。密码应该只被管理员使用，其他的 SaaS 应用应当都使用相同的（支持单点登录）身份管理服务。
-
融入这些平台需要花费些时间。对于初创公司而言，Google G-Suite 可以为所有支持 OAuth 或者 SAML 的站点提供单点登录。作为服务供应者，也应当支持基于浏览器的认证和智能两步验证来降低雇员之间的摩擦，并且通过 ldap 或者 radius 连接 VPN／SSH。
-
一些服务供应商并不提供管理员权限管理服务。所以管理员仍然需要使用密码管理器。
-
办公大楼的安保部门和保险公司很可能要求在非办公时间段内启用警报。建议每天 23:00 自动启用，这样就不用担心雇员忘记手动启用它了。
-
如果办公室的入口没有安保摄像头监控的话，你可以购置一个简单的网络摄像头，并把它连接到移动 App 上。这样你就可以知道是谁最后离开办公室并且忘记关门／激活警报了。而且如果真的是窃贼的话，你可以看清他们的脸。
-
此时，你可能会想要把前门由基于密码的门禁系统更换为基于芯片的。
-
这样，每次有员工离职的时候你就无需更换密码了。注意尽量不要给清洁服务人员芯片卡，因为他们过一段时间就会换人。你应该安排某个人为清洁人员开关门。磁性门禁卡（有磁条的）通常来说要更加昂贵并且对新员工和面试者而言显得很机构化。然而，相较于芯片式门禁系统，磁性门禁卡更难以复制或者被黑。
大量的服务提供商都提供有登录与密码管理服务。如果某个服务商拥有 SOC2 认证，他们很可能要比你们更擅长用数据库管理顾客的密码。
他们还提供自由服务和接口来建立和取消用户，强制使用密码策略以及恢复密码。尽管如此，大型客户也许会想要接入他们自己的身份管理方案。
数据泄露带来的财政上的影响（失去商业合作，补偿）甚至可能会导致初创公司破产。
-
作为安全训练的一部分，告知你的雇员们哪些是私人信心，以及这些信息我们是怎么处理的。 这份可视化表单应该可以帮助到你。
-
告诉你的员工们，你不会因为谁犯了个错误就解雇谁。请求他们发生事故以后务必立马告知你，这样你就可以及时修复问题并把损失降低到最小。坚守这份承诺。解释清楚内部故意泄露数据和不幸的人为失误的区别。这一点很重要，因为不同的员工可能来自不同的文化和工作背景，如果不解释清楚的话，有可能他们会错误地处理这种问题。
-
通过修改或者识别数据来把潜在损失降低到最小。这通常需要管理者在没有“必要的”数据的情况也能做出正确的决定来帮助企业渡过难关。主要的观点是延迟对“机构味”的安全软件的需求，通过移除敏感信息，最起码是禁止大部分员工对那份数据的接入权限。
-
恰当地使用正确的工具来避免数据泄漏：
-
从本地电脑移除数据，使用远程桌面工作而不是在本地桌面电脑。
-
使用浏览器隔离技术保证桌面电脑远离恶意软件。它会让你觉得是在使用常规浏览器在本地浏览，然而实际上，你看到的只是从远程电脑正在浏览的页面的图案。
-
在手机和移动电脑上使用数据管家(Data Leak Prevention agents)来监控并预防数据泄漏。这需要在机构内所有设备上都安装上并且正确配置，以此来监控指定类型的数据。
-
使用移动设备管理措施来监控并管理电脑与手机的应用权限和系统设置（锁屏／加密／VPN设置等）。Google G-Suite 自带了基础移动设备管理能力。
-
使用用户认证和权限管理来保护所有数据仓库。监控相关的数据处理和检查系统。
-
使用应用层来加密数据读取／写入操作，使用存储层和网络层加密来保护数据。
-
-
参考 OWASP 最佳实践 来进行安全代码工作。
-
使用 WAF 和 DDoS 分流服务。
-
（在外部网络）运行外部危险项扫描。这可以保护你免受恶意脚本的侵犯。
-
运行内部危险项扫描（在防火墙内）。这可以防止黑客接触到你的某个服务器的时候危害你的核心系统。这通常需要代理或者 ssh 连接，以及避开防火墙进行防火墙的能力。
-
使用渗透测试和 BUG 奖励政策。你会付钱给那些试图找出你服务危险项的真实黑客。测试阶段你需要允许外部渗透测试服务商来尝试避开你的安全措施并利用那些危险项和错误配置。
-
某些情况下，你需要为渗透测试方提供 API key 来模拟客户账号被入侵的情形。黑客会利用他们的密钥来侵入你的系统。这就是灰度测试。
-
还有些情况下，你需要允许渗透测试方来审查你的代码库。价格依服务的复杂度、黑客的经验以及代码量而定。
-
奖励政策可以让你接触到那些有特别能力的黑客。
-
-
经常升级你的依赖库。或者更进一步，使用机器人来自动化请求升级依赖库版本。
-
扫描源码漏洞。一些服务商汇使用静态和动态分析来检查你的代码。另外一些则扫描经常使用的开源软件（如 SourceClear，BlackDuck，CheckMarx）。
确保企业的重要数据被备份了（即使它意味着需要花些时间来恢复备份）：
-
确保备份是自动化的，连续的，囊括了要求的数据集，从而避免丢失数据。
-
确保备份位于另一个不同的云账户，从而避免人为误操作，甚至恶意删除数据。
-
确保数据位于不同区域的不同数据中心，从而避免自然灾害造成的数据损失。
-
你甚至可以选用不同云服务商来备份数据。比如，Google Cloud 就提供了连续备份 Amazon S3 上数据的服务。
-
不是所有数据都是同等程度上关乎企业存亡的。如果数据量太大或者花费太高，那就从最重要的数据开始。
-
确保所有的数据恢复操作都详细写出并经过测试。你不愿意看到在你需要恢复数据的时候原本认为可用的数据结果是无效的。
-
几乎所有的资格鉴定或者大客户都会要求你提供一份年度数据备份／恢复报告。
-
为所有云服务打开日志记录功能，即使它额外收费。集中管理所有应用和服务器的日志。存留至少一年内的日志。
-
与你的法律顾问（律师事务所）和会记事务所协作，制定一份事故响应计划。这里列出了需要做的事情，包括事故调查、处理和损失控制。还包括了与顾客、终端用户和专家们的磋商等。大型的法律和会计公司有一连串的关系网和经验来帮助制定出这样的计划。
当你有了明确的商业计划（巨大的商业成功）和可观的安全预算后，开始寻找一个适合你企业的首席安全官。这可能会花费你数月的时间。原因在于首先得考虑技术能力，还得承担 CEO／CTO 身上的部分责任。理所当然地，安全官必须认同你的企业文化。这段视频里面有个很好的例子。
威胁模型是你用来决定某项安全方面对策是否合理的首要原则。一个基本的模型就是区分攻击者。
如果你被 FBI 等攻击，那么放弃吧。
如果不是，你可以在投入一定资金的情况进行有效的防御。区分这两者攻击的一个方法在于考虑一种可行的，难以阻止的，非法的攻击，比如贿赂某位雇员。换句话说，如果贿赂雇员的成本要比暴力破解密码的成本要低，那么再花费资源在保护数据上就没什么意义了。
-
记住，随着你企业的发展，你的受攻击面以及攻击动机也会同步增长。你的安全预算也需要随之改变。通过预算告知你的投资者们你对待安全问题的严肃态度。
-
考察完整的风险评估，尝试首先堵上大的安全漏洞。那些通常是最容易被攻击，或者危害最大的（或者两者之和）。把你所有的注意力都集中于一个问题上，相当于请求你的攻击者使用下一个漏洞。
-
一些源于顾客和受众的安全要求不一定非要放在风控首位上。举个例子，担心 Amazon 拷贝他们商业数据的顾客可能会要求 AWS 内部使用点对点加密传输数据。尽管 Amazon 内部人员有可能会窃取你的数据，或者一个精密的恶意软件突破了虚拟机的隔离，但是这不必放在你的安全清单的首位——尽管这位于客户需求的顶端。
新任安全主管首先要做的一件事就是评估所有不同的风险以及其可能的表现形式。
为了追求一个高的起点，你可以查看由 DBIR 报告提供的一份数据：
查看 CIS CONTROLS FOR EFFECTIVE CYBER DEFENSE 附录 B、C 来获取基于 DBIR 报告的更多信息。
接下来，让我们估测一下潜在的商业危害。这里有个例子：
| 攻击类型 | 攻击者 | 年内预计攻击次数 | 攻击危害性 | 年内总损害 |
| 欺骗 | 信用卡欺诈、市场欺诈、Friendly Fraud | 高 | 低 | 高 |
| 宕机 | 天气 DDoS | 中 | 中 | 中 |
| 现实偷窃 | 办公室偷窃 车辆偷窃 家庭偷窃 内部误用 | 中 | 低 | 低 |
| IP 泄漏 | 恶意软件 服务器危险项 服务商被黑 | 低 | 高 | 中 |
| （用户）数据泄漏 | 恶意软件 服务器危险项 服务商被黑 数据库泄露 | 中 | 高 | 高 |
| 商业／HR／内部文件遭窃／泄漏 | 恶意软件 服务商被黑 | 中 | 中 | 中 |
| 数据被毁／要求赎回 | 服务器危险项 证书被盗 恶意软件 | 中 | 中 | 中 |
| 资金损失（比特币，服务器实例） | 证书被盗 服务器危险项 | 中 | 中 | 中 |
| 用户服务被黑 | 服务器危险项 证书被盗 | 中 | 高 | 高 |
接下来详细介绍如何应对各种威胁。这个表格是工作计划的基础：
| 预防 | 对策 | 攻击者 |
| 自动预防欺诈 | 培养意识 + 手动检查 | 市场欺诈 Friendly Fraud 信用卡 |
| 多区域服务 | 转移服务 | 天气 |
| DDoS 保护 | Talk with AWS account manager 404/403 Alerts | DDoS |
| 警报门芯片 两步验证 锁定 | 将所有服务器和VPN转移到云服务上 加密磁盘 永远不要把电脑忘在车里 Pin 密码 远程抹除被盗手机数据 | 办公室盗窃、 汽车盗窃、 家庭盗窃 |
| 接入权限管理、 数据泄漏防护 | 友善对待员工、 记录日志、 MDM（移动设备管理）、 离职清单、 隐私培训、 新入职培训、 NDAs | 雇员误操作、 兼职误操作、 服务商操作 |
| 把 IP 移到企业数据保险库、 终端保护、 数据泄漏防护 | 最小特权原则、 记录日志、 培训、 加密数据 | 恶意软件 |
| OS/Docker 自动升级、 依赖升级、 外部危险项扫描、 渗透测试、 安全漏洞奖励措施 | 危险项 RSS 订阅、 失败登录警告、 使用另一个地区／账号备份、 网路隔离（安全部门、子网络、VPN 云服务账号） 、 内部危险项扫描 | 服务器危险项 |
| 两步验证、 加密电脑证书、 加密服务器证书 | 每年替换管理员密码 | 盗取证书 |
| 使用用户名／密码来加密 SQL／NoSQL、 需要 VPN 两步验证来连接、 应用层面=加密 | 检查无用数据、 不要在创建本地拷贝、 培训、 记录日志 | 数据库泄露 |
我们欢迎来自在创业公司工作的工程师们的各种建议，他们也是这篇文章的目标读者。请尽量保持精简并切中要害。在保障实际可行的同时，尽量不倾向任何服务商。欢迎各种建议。
感谢原作者 Shahar Keidar、Avishai Ish-Shalom、Yogev Levi Shaked、Elad Shulman、Eliran Ben-Zikri 的工作。
This work is licensed under a Creative Commons Attribution 4.0 International License.
