大数据不会说谎,但录入数据的人可能会

F5生态系统 | 2018年7月16日

有一句大家耳熟能详的商业格言:客户永远是对的。

在数字经济时代,这句格言需要改成:客户的数据永远是对的。

我用一个小故事来说明。

最近,我决定买辆新车,并用旧车置换。那辆旧车我开了大约6年,每年行驶约3,000英里。我知道这听起来很不可思议,但确实如此。我只开它出过一次州,去俄亥俄州探亲。仅此一次。除此之外,它从未驶出过离家30英里的范围。我常开玩笑说,自己就像那种只在周日开车去教堂的老太太。

所以,当汽车经销商仅凭其查阅的车辆历史记录报告中的一条数据,就告诉我里程表读数不准确,误差超过3万英里时,可想而知我有多惊讶。这条数据还声称,我的车两年前曾在北达科他州接受过保养。

这一差异不容小觑。里程表读数会影响车辆的置换价值,而且篡改里程表属于违法行为(可能面临罚款和监禁)。由于里程表的实际读数远低于报告中的数字,不难想象,经销商对此有些不安。他不得不作出一个棘手的选择:是相信坚称自己从未把车开到北达科他州的我,还是相信声称我去过那里的数据?

问题很快归结为:“客户永远是对的”,还是“客户的数据永远是对的”?

事实证明,因车辆历史记录报告中的数据不准确而吃亏,并非第一次发生。大部分数据仍由人工录入,因此难免出错。但要更正这些错误,必须由当初录入数据的人承认自己犯了错。这意味着,他们必须记得自己在大约5年、10年甚至15年前犯过错,前提是当时录入数据的技术人员如今还在,能够承认这个错误。

最后,我开着新车离开了,修正报告的事则留给经销商处理。我相信,很多人都有过类似的经历。在数字经济环境下,这种情况实在太常见了。

人为(错误)因素

随着我们越来越依赖机器来解决问题、挖掘数据和做出决策,需要意识到手中的数据可能并不准确。在这些数据的保管链中,某个环节必然有人参与。而人难免会犯错,这是不言自明的事实。6年前,北达科他州的一名维修技术人员只需按错一个键,就可能让您突然置身强光之下,因以往每一次驾车出行而受到盘问。

对于用于决策的数据,我们需要谨慎判断其可信度。需要警惕的不仅是无意造成的错误,还有人为故意制造的错误。可以肯定的是,您的数据并不干净。

DNS的设计非常出色,它明确区分了权威数据源和非权威数据源。如果出现差异,可以前往唯一的权威数据源查明真相。但客户数据并不存在这样的权威来源。这可能是一个危险信号,因为我们目前使用以及不久后将使用的系统未必能判断哪些数据准确、哪些不准确。毕竟,没有任何地方可以验证其真实性。既没有证书颁发机构,也没有像DNS那样指定的权威数据源。而且在许多情况下,甚至无法对数据提出异议。

随着我们不断利用零散的数据构建客户的数字画像,需要充分认识到这些数据可能产生的重大影响。这不仅会影响作为业务决策者的我们,也会影响作为个体的客户,因为无论基于这些数据得出什么结论,客户都必须承受相应后果。

作为应用安全解决方案提供商,我们经常强调保护数据和身份信息,防止其被窃取或外泄。但我们很少换个角度,探讨数据损坏这一切实存在的可能性,无论是意外所致还是恶意为之。

我们应该重视这一问题,以免它成为Twitter上的热门话题。

我们已经看到,针对个人的报复性数字攻击日益增多,形式多种多样。由于911调度员无法从手机获取准确的位置和地址,受害者曾因虚假报警招致特警突袭而丧命。色情报复确实存在,社交媒体上冒充亲友的情况也屡见不鲜。3年多前,Kustodian首席执行官Chris Rock曾演示,由于大多数国家/地区的死亡登记流程存在漏洞,欺诈者可以为了牟利或恶作剧,人为地让某人在记录中“死亡”。该演示是在DEF CON上进行的(CS Monitor)。熟悉相关内容的人可能知道,这正是1995年电影《Hackers》中使用的一种黑客手段。片中还通过注销他人的信用卡和发布虚假征友广告,来报复某种冒犯,无论这种冒犯是真实存在还是主观臆想。

这种报复行为蔓延到其他领域并污染数据,只是时间问题。

如果您认为我是在杞人忧天,不妨回想一下2017年的RedLock CSI报告。该报告指出,31%的数据库存在向互联网开放的端口,任何人都能访问。再想想MongoDB事件,当时有超过27,000个数据库可供公众访问。一旦别有用心的人发现未设防的数据库,就可能严重破坏其中的数据。

问题就在于,我们已经到了这样一个转折点:数据往往被视为不容置疑、绝不会出错的事实。仅仅因为一个数据录入错误,这个所谓的“事实”就可能让我锒铛入狱。

数字数据尽职调查

随着企业运营乃至个人生活中越来越多的内容存储在数字世界,我们应当停下来想一想:数据仓库中的每一个比特和字节,都代表着真实个体的某个方面。我们以何种审慎态度对待这些数据,也反映了我们如何看待作为客户的真实个体。尤其是,我们无法预知今天录入的某条数据,日后是否会被解读为对客户不利的信息。毕竟,我的车辆历史记录中那条信息原本只是为了登记一次在北达科他州进行的换油保养。录入者并无恶意,但结果却可能给我带来灾难性的后果。

无论是制定安全策略以防止数据损坏、控制应用和数据库的访问权限,还是更加重视手动录入数据,我们都需要牢记:数据本身不会说谎,它准确反映了录入者输入的内容,但录入者可能没有如实填写。

分享
标签: 2018

关于作者

Lori Mac Vittie
Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师,在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构,还是探索可扩展系统的极限,她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前,她曾担任技术编辑,并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位,著述颇丰,出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏,并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章

相关博客文章

F5纪念2021年世界艾滋病日
F5生态系统 | 2021/12/01

F5纪念2021年世界艾滋病日

值此世界艾滋病日,F5郑重承诺,将与员工、客户、社区和合作伙伴共同努力,消除社会对HIV感染者仍然存在的污名与偏见。

Thingbot正转变为攻击平台
F5生态系统 | 2018/11/29

Thingbot正转变为攻击平台

Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究,并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用,还被转变为攻击平台,这意味着攻击者可以更充分地利用这个必然增长的市场。

借助F5全新Quick Start,在AWS上快速开展业务
F5生态系统 | 2018/11/20

借助F5全新Quick Start,在AWS上快速开展业务

在AWS re:Invent开幕前,我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。

为什么声明式模型对NetOps自动化至关重要?
F5生态系统 | 2018/04/30

为什么声明式模型对NetOps自动化至关重要?

为什么声明式模型对NetOps自动化至关重要?阅读F5博客,了解基础设施即代码如何简化网络扩展。

开源聚焦:F5基础设施即代码与多云可管理性
F5生态系统 | 2017/11/16

开源聚焦:F5基础设施即代码与多云可管理性

开源聚焦:基础设施即代码与多云。阅读博客,了解模板和Terraform如何简化F5应用服务的部署。

破解IT“无解困局”的答案:私有云
F5生态系统 | 2016/09/12

破解IT“无解困局”的答案:私有云

破解IT“无解困局”的答案:私有云。阅读F5博客,了解本地部署的敏捷性如何化解安全与速度难以兼顾的问题。