每年都有安全漏洞、漏洞和黑客“恶作剧”.“当我们进入新的一年, 我们不可避免地会在主流媒体和商业媒体上看到报道其中最糟糕情况的文章.
这些名单如此普遍有两个原因. 首先是人性:恐惧会引起注意. 就像一个产品供应商使用FUD(恐惧), 不确定性, (怀疑)来促进销售, 恐惧也可以驱动新闻读者. 所以，贸易媒体自然会报道此事. 如果我们诚实地说，可能还有一点幸灾乐祸的成分. 像保证、治理、风险和安全这样的高风险角色是困难且有压力的. 当从业者读到发生在其他公司而不是我们公司的数据泄露时，会有一种“谢天谢地不是我们”的感觉.
当然，这一切都在意料之中, 但在某种程度上，当我看到不可避免的年终“违约重述”时,“我觉得我们错过了一个机会. 为什么? 因为只关注结果遗漏了讨论的重要部分——具体来说, 吸取的教训告诉我们如何改进.
我给你们举个例子来说明我的意思. 就说我告诉过你 14世纪死于黑死病的人数约为5000万. 可怕的,对吧? 但这能告诉你如何预防疾病吗? 治疗或诊断的措施? 有关携带者或传播媒介的信息? No. 当然，这样的统计数据很引人注目 ... 但是除了一小部分从业者(比如那些做病原体统计分析的人), 它不能促进未来的疾病预防. 如果你详细说明在这段时间内疾病快速传播的原因(当然简化了)与卫生/环境卫生有关, 人口密度, 以及海上贸易, 这开始告诉你一些可以预防的东西.
我的观点是, 在某种程度上，回顾一年中最糟糕/最可怕的事件是有用的，因为我们可以从中吸取教训，并为未来的努力提供信息. 记住这一点, 和你在其他地方看到的清单相反, 我们列出了今年发生的五个安全“事件”，我们认为其中包含了有用的经验教训. 这些都不是最大的违规行为，也不是最可怕的违规行为，也不是造成最大财务影响的违规行为. 相反，这些事件具有重要的经验教训，值得从业者学习.
#1 - Facebook帐户数据泄露
第一个是关于 发现5.4亿条用户记录 (约150GB的数据)通过几个第三方公司在互联网上曝光. 根本原因? 未正确保护S3桶. 这里有三个重要的教训. 第一个也是最明显的教训是关于保护和验证云存储桶上的权限(这是一个很大的教训)。. 但除此之外，还有其他教训. 首先，软件(“应用程序”)安全性的重要性. 我们所知道的应用程序威胁建模等工具可以发现并标记潜在的应用程序设计, 配置, 或者早期的实施问题. 因此，它仍然是我们安全武器库中的一个重要工具. 另一个教训? 第三方的角度，特别是责任. 在这种情况下, the collection was facilitated by third parties and not Facebook本身; but yet, 谁在标题中突出显示? Facebook本身. 永远不要忘记，如果你有主要的客户关系, 你最终要背黑锅.
#2 - Facebook明文密码
我选择强调的第二个例子也来自Facebook——在这种情况下，是 将Instagram密码存储在清晰的地方. Note that I’m not intentionally picking on Facebook by including them twice; in fact, 这实际上是他们的“成功故事”(至少从某种角度来看)。. 具体来说，在这种情况下，a 例行安全检查 找到以明文形式存储的密码. 在分析和补救的同时, 他们还发现，在日志文件中存储密码的情况更多. 那么，教训是什么呢? 我要强调的主要一点是技术保证工作的价值, 特别验证密码使用的值. 这些是经常被忽视的领域，但它们可能具有真正的、有形的安全价值. “Stuff happens” – and no company can ever do anything 100% perfectly all the time; but having a mechanism to find and fix those issues when they happen can mean the difference between minor egg on the face and major catastrophe.
#3 -源代码控制的诡计
接下来，攻击者 下载Git存储库，清除它们，然后拿着源代码勒索赎金. 从谍报技术的角度来看，这一事件本身并不那么有趣:这里的载体是普通的账户泄露(例如.g.、泄露或被盗的密码、API密钥等.有趣的是，它专门针对源代码控制. 在过去的日子里, 审查源代码控制平台(包括配置以及它们是否包含诸如加密密钥或密码之类的秘密)花费了大量时间，并且占用了相当多的从业者的注意力. 随着平台变得标准化，Git变得无处不在，从业者的注意力可能会动摇. 不要让这种情况发生. 对源代码控制保持警惕仍然很重要——即使在GitHub时代，一切都是集中和标准化的.
#4 -恶意软件完全加载
德国BSI (Bundesamt f
#5 -不满
最后，一名被运输服务公司解雇的IT员工是 因瞄准和破坏其前雇主的AWS系统而入狱. 长话短说, 在他2016年被解雇之后, he used an administrative account to begin systematically sabotaging and disabling AWS assets of his former employer; as a result, 公司失去了几个重要的客户合同. 这里有一些教训. 首先，再次注意前面关于保护云资产的教训. 除了再敲一遍, 虽然, 此事件还突出了内部威胁和特权帐户的使用. 我们都应该保持对内部威胁的意识. 随着技术变得越来越流行，业务越来越关键, 一个流氓或心怀不满的员工(甚至是前员工)都有可能造成重大损害. 同样的, cloud可以使特权帐户变得更加复杂，因为它可以添加我们以前没有的帐户类型(除了root和Administrator用户之外), 我们现在也有云管理员帐户来跟踪). 对这些账户的持续管理、监测和保护非常重要.
