近日，F5发布了《2018年网络钓鱼和欺诈报告：节假日期为攻击峰值》，并指出，2018年10月，11月和12月的欺诈事件相比往年攀升了超过50%;网络钓鱼仍然是首选渠道，钓鱼者通过盗取登录认证和信用卡号码等私密信息而实现犯罪。

该项研究采纳了多样化数据来源，针对从10月开始的节假日网络钓鱼和欺诈高峰现象，专门进行调研分析。其中包括：本年网络钓鱼欺诈趋势，遭冒充身份的顶级公司以及企业和消费者如何防范网络钓鱼以及其他欺诈行为。

在即将来临的节假日，不只是购物、聚餐的高峰季，更是网络钓鱼诈骗的高峰季。与此同时，钓鱼者的诈骗策略也在更新换代。曾经的骗局是一封要求上传银行凭据来获取遗产的电子邮件;现今的网络钓鱼者则变得更加狡猾精明，演绎出盗用身份来欺骗大众情感的手段，企图以此更轻易地骗取钱财。

网络钓鱼的技术和手段，从原理上说并不新鲜：通过一个心理诱饵，步步引导受害者，误以为该虚假网络程序和应用是真实可信的。网络钓鱼者通常会按照如下三个步骤，来设置网络钓鱼骗局：

1. 目标选择：即寻找合适的受害者，特别要透过电子邮件地址和背景信息，总结出一个具有吸引力的心理痛点。

2. 社交机制：布置恰当的诈骗诱饵，诱使受害者掉入陷阱，以窃取他们的账户并植入恶意软件。在鱼叉式网络的钓鱼案例中，这种诱饵是针对目标受害者而定制的。每当年终岁尾，网络钓鱼者会利用年终和节假日的各类活动包装出伪装外衣。

3. 技术工程：钓鱼者躲避开安全程序的扫描，以构建虚假网站，制作恶意软件等技术性方法开展诈骗。

消费者有必要认识到，URL欺骗正是网络钓鱼的常用方法，任何电子邮件地址都带有伪造性或欺骗性的可能性。

1. 减少URLS应用：尽量减少在如bit.ly这类服务网址上的浏览时间，因为他们都可以是恶性的。用户应该打开新的浏览器选项卡，并搜索涉及到的有关内容或网站。

2. 重视安全证书警告：警告会显示在用户浏览器，以提示当前登录网站的安全证书无效，或尚未由受信任的机构颁发证书。如果用户认为该网站合法，不该忽略警告，应另在单独的浏览器窗口中搜索该网站。

3. 认真检查网址：伪造的网络钓鱼网站往往精心制作，伪装出充分的合法性。因此，在提供登录认证或帐户等任何个人信息之前，用户应养成认真检查地址栏中网址的习惯。

随着网络钓鱼变得愈加复杂和精明，安全意识培训对于保护企业和员工免受依托技术的网络钓鱼诈骗变得至关重要。其中，包括电子邮件标签，防病毒(AV)软件，Web过滤和多因素身份验证等诸多方面的措施。

目前，尚没有针对网络钓鱼的一站式安全把控体系。现有降低公司业务风险的方法，就是构建出一个涵盖员工，流程，技术的综合可控安全架构。

如想了解更多信息，请阅读完整报告进一步发现当前的核心威胁，详细了解网络钓鱼的细节，并大量吸收建议，来保护企业免遭网络钓鱼的侵害。

12月21日，捷克国家安全委员会正式发表声明，对国家网络与信息安全办公室的声明进行了纠正。声明全文如下：

1、国家网络与信息安全办公室是独立于政府的机构，其结论不是基于技术评估。

2、总理对华为手机的禁令是草率的。

3、国家网络与信息安全办公室仅警告关键信息基础设施或重要信息系统中包含的系统，并且在任何情况下都不涉及普通用户和终端设备。

4、为了国家安全，始终有必要确保网络安全的安全。

5、国家网络与信息安全办公室无权评估其他国家的国际政治局势或法律和政治环境。

6、在没有与国家安全有关的严重理由的情况下，关键信息基础设施或主要信息系统中包含的信息系统的采购程序不应使投标者处于不利地位。

7、捷克共和国对所有合法外国投资保持开放，并将继续为其提供有利环境。

对于捷克政府的声明，华为欧洲总裁李健表示：“我们赞赏捷克政府的务实态度”。他表示：“捷克共和国安全委员会今天讨论了捷克国家网络和信息安全办公室早些时候发表的声明，并认识到办公室独立于政府发出的警告并非基于技术评估。华为很高兴听到捷克共和国希望对所有合法的外国投资保持开放，并且没有任何竞标者在没有充分理由的情况下，在信息通信技术领域的任何招标中都不应该为国家的关键基础设施而处于不利地位。华为认为，任何基于公司原产地的歧视都应在捷克共和国进行纠正。”

“根据捷克政府办公室今天的声明，我们坚信与捷克共和国现有和潜在客户，合作伙伴的任何业务合作都不会受到影响。我们的全球声誉，业务和投资不应再被这种毫无根据的指责所破坏。在过去的30年里，华为通过与全球170多个国家的客户合作，保持了良好的安全记录。在当今的数字环境中，网络安全比以往任何时候都更加重要，我们了解政府的网络安全挑战。作为全球领先的ICT公司，华为建立了可审计，可持续，可信赖的网络安全保障体系。我们愿意与捷克政府和行业合作，共同应对网络安全挑战。网络安全一直是我们的首要任务。“华为欧洲总裁李健总结道。

12月17日，捷克网络监管部门――国家网络与信息安全办公室主任杜桑纳夫拉蒂尔（Dusan Navratil）在一份声明中声称，“中国的法律要求中国的民营企业与情报部门配合，因此把他们的产品引入到关键的国家系统中，可能构成威胁。” 为此，总理安德烈巴比什呼吁国家安全委员会向国家网络与信息安全办公室主任杜桑纳瓦里蒂尔了解发布警告声明和补充公布信息的情况。

OWASP benchmark是OWASP组织下的一个开源项目，又叫作OWASP基准测试项目，它是免费且开放的测试套件。它可以用来评估那些自动化安全扫描工具的速度、覆盖范围和准确性，这样就可以得到这些软件的优点和缺点，还可以对它们进行相互比较。每个版本的OWASP benchmark都包含数千个完全可运行和利用的测试用例，每个测试用例都映射到该漏洞的相应CWE编号，所以该项目的漏洞数量和漏洞类型都是固定的，因此就可以查看扫描工具的测试报告进行对比得出该工具的误报和漏报率。

一般安全检查工具会检测出大量的漏洞，但是其中有很多都是误报的。为了得到所测试的应用程序的准确程度，benchmark设置了四种专门的测试结果：

1）工具正确识别了真实漏洞（True Positive-TP）；

2）工具没有识别真实漏洞（False Negative-FN）；

3）工具没有误报（Ture Negative-TN）；

4）工具误报（False Positive-FP）

考虑到如果一个工具将每一行代码都标记为漏洞，则检测结果将会是100%的误报并且是没有价值的。如果该工具没有标记一个漏洞，则误报率为0，但是它也没有报出任何一个真实的漏洞，这也是没有价值的。如果一个工具随机报告每个测试是否包含漏洞，则将具有50%的真实漏洞，和50%的误报。

此图上可以直观地显示工具检测报告的真实存在的漏洞和误报的表现，我们还可以计算出一个点的得分（0-100），将其称为Benchmark Accuracy Score（基准准确度得分），是一种Youden Index。基准准确度得分的计算方法为：

benchmark中总共有2740个漏洞：

$ git clone https://github.com/OWASP/benchmark $ cd benchmark$ mvn compile (This compiles it)$ runBenchmark.sh/.bat This compiles and runs it.

然后用浏览器打开 https://localhost:8443/benchmark/，就可访问benchmark。

benchmark自带了多种源代码静态扫描工具，下面说明这些工具如何使用。

使用PMD对benchmark进行扫描并得到检测报告（PMD中实际上是没有安全规则的）：

使用FindBugs产生测试报告：

使用带有FindSecBugs插件的FindBugs：

最终这些检测结果都被放置在/results目录下。检测的结果如下所示：

产生记分卡的应用程序BenchmarkScore是内置在Benchmark中的，它对扫描工具检测结果与预测结果进行对比，并生成一组网页，详细说明所涉及工具的准确性和速度。以下命令将为/results目录中的所有结果文件计算记分卡，并将生成的记分卡放入/scorecard目录中：

*本文作者：fengchenzxc，转载请注明来自CodeSec.Net

如果程序源代码使用Go语言编写，并且用到了单向或者双向TLS认证，那么就容易受到CPU拒绝服务（DoS）攻击。Go语言的 crypto/x509 标准库中的校验算法存在逻辑缺陷，攻击者可以精心构造输入数据，使校验算法在尝试验证客户端提供的TLS证书链时占用所有可用的CPU资源。

为了保护正常服务，大家应立即 升级 到G0 v1.10.6、v1.11.3或者更新版本。

42Crunch的API Security平台后端采用的是微服务架构，而微服务使用Go语言编写。微服务之间通过 gRPC 相互通信，并且部署了REST API网关用于外部调用。为了确保安全性，我们遵循了“TLS everywhere”（处处部署TLS）原则，广泛采用了TLS双向认证机制。

Go的标准库原生支持SSL/TLS认证，也支持大量与连接处理、验证、身份认证等方面有关的x509和TLS原语。这种原生支持可以避免外部依赖，使用标准化的、经过精心维护和审核的TLS库也能降低安全风险。

因此42Crunch很有可能受此TLS漏洞影响，需要理解漏洞原理，保证42Crunch平台的安全性。

42Crunch 安全团队针细致分析了该CVE，如下文所示。

这个DoS问题最早由Netflixx发现，Golang在issue跟踪日志中提到：

crypto/x509 包负责解析并验证X.509编码的密钥和证书，正常情况下会占用一定的资源来处理攻击者提供的证书链。

crypto/x509 包并没有限制验证每个证书链时所分配的工作量，攻击者有可能构造恶意输入，导致CPU拒绝服务。Go TLS服务器在接受客户端证书或者TLS客户端在验证证书时会受此漏洞影响。

该漏洞具体位于 crypto/x509 Certificate.Verify() 函数的调用路径中，该函数负责证书认证及验证。

为了便于漏洞分析，我们举个简单的例子：TLS客户端连接至TLS服务器，服务器验证客户端证书。

TLS服务器在 8080 端口监听TLS客户端请求，验证客户端证书是否由证书颁发机构（CA）颁发：

在标准的TLS验证场景中，TLS客户端会连接到TLS服务器的 8080 端口，然后向服务器提供证书的“trust chain”（信任链），其中包括客户端证书、root CA证书以及中间所有CA证书。TLS服务器处理TLS握手，验证客户端证书，检查客户端是否可信（即客户端证书是否由服务器信任的CA签名）。通常TLS握手过程如下图所示：

分析Go语言的 crypto/x509 库，最终我们会进入 x509/tls/handshake_server.go:doFullHandshake() 函数代码段：

根据代码，服务器会处理收到的客户端证书，然后调用 x509/tls/handshake_server.go:processCertsFromClient() 函数。如果需要验证客户端证书，服务器就会创建一个 VerifyOptions 结构，其中包含如下信息：

为了澄清问题机理，我们需要理解服务端如何管理证书池，以便通过高效的方式来验证证书。证书池实际上就是一个证书列表，可以根据实际需求通过3种不同的方式来访问。一种访问方式如下图所示：池中证书可以通过索引数组（这里为 Certs ）来访问，以 CN , IssuerName , SubjectKeyId 字段作为哈希字段。

然后 Verify() 会根据客户端提供的证书链来处理待验证的客户端证书，但首先需要使用 buildChains() 函数建立并检查整条验证链：

而 buildChains() 函数会依次调用占用CPU资源的一些函数，递归处理这条链上的每个元素。

buildChains() 函数依赖于 findVerifiedParents() 函数，而后者可以通过 IssuerName 或者 AuthorityKeyId 映射访问证书池，识别上级证书，,然后返回候选证书索引，以便后续根据客户端控制的证书池来验证该证书。

在正常情况下，程序会提取 IssuerName 及 AuthorityKeyId ，并且认为这些值为唯一值，只会返回一个待验证的证书：

buildChains() 函数会在客户端发给TLS服务器的整条证书链上执行如下操作：

攻击者可以构造一种非预期场景，其中所有的中间CA证书使用的都是同一个名称，并且 AuthKeyId 值为 nil ，这样当调用 buildChains() 和 findVerifiedParent() 函数时，就会造成CPU DoS攻击效果。 findVerifiedParent() 函数会返回与该名称匹配的所有证书（这里返回的是整个证书池），然后检查所有证书的签名。检查完毕后，会再次递归调用 buildchains() 函数处理找到的上一级证书，最后处理到root CA为止。每一次检查过程实际上都会处理整个中间CA池，因此单单一个TLS连接就会耗尽所有可用的CPU资源。

攻击者可以精心构造一条证书链，使客户端证书校验过程耗尽服务端所有CPU资源，降低目标主机响应速度。只需要1个连接就能导致这种攻击效果。根据Go的调度程序规则，只有两个CPU核心会受到影响，CPU使用率达到100%，攻击者可以创建新连接，强制调度程序分配更多资源来校验签名，最终导致目标服务或目标主机无响应。

Go语言社区已经通过 如下措施 修复该问题：

如果向修复该漏洞，请立即 升级 到G0 v1.10.6、v1.11.3或者更新版本。

以太坊去中心化网页钱包开发系列，将从零开始开发出一个可以实际使用的钱包，本系列文章是理论与实战相结合，这是第二篇，主要介绍钱包账号导出与导入，将对Keystore文件的生成的原理进行介绍。

，介绍了如何使用私钥及助记词来创建账号，如果是使用已有的私钥及助记词，这其实也是账号导入的过程。

有一些同学会问，我的账号是Geth生成的，如何导入到钱包呢？使用Geth的同学，应该知道Geth在创建账号时会生成一个对应keystore JSON文件，Keystore文件存储加密后的私钥信息，因此我们需要做的就是导入这个Keystore文件，这个文件通常在同步区块数据的目录下的keystore文件夹（如： ~/.ethereum/keystore）里。

尽管在ethers.js 中，简单的使用一个函数就可以完成keystore文件的导入，不过理解Keystore 文件的作用及原理还是非常有必要的，当然如果你是在没有兴趣，可以直接跳到本文最后一节：使用ethers.js 实现账号导出导入。

通过这篇文章理解开发HD 钱包涉及的 BIP32、BIP44、BIP39，私钥其实就代表了一个账号，最简单的保管账号的方式就是直接把私钥保存起来，如果私钥文件被人盗取，我们的数字资产将洗劫一空。

Keystore 文件就是一种以加密的方式存储密钥的文件，这样的发起交易的时候，先从Keystore 文件是使用密码解密出私钥，然后进行签名交易。这样做之后就会安全的多，因为只有黑客同时盗取 keystore 文件和密码才能盗取我们的数字资产。

以太坊是使用对称加密算法来加密私钥生成Keystore文件，因此对称加密秘钥(注意它其实也是发起交易时需要的解密秘钥)的选择就非常关键，这个秘钥是使用KDF算法推导派生而出。因此在完整介绍Keystore 文件如何生成前，有必要先介绍一下KDF。

密码学KDF（key derivation functions），其作用是通过一个密码派生出一个或多个秘钥，即从 password 生成加密用的 key。

其实在理解开发HD 钱包涉及的 BIP32、BIP44、BIP39中介绍助记词推导出种子的PBKDF2算法就是一种KDF函数，其原理是加盐以及增加哈希迭代次数。

而在Keystore中，是用的是Scrypt算法，用一个公式来表示的话，派生的Key生成方程为：

DK = Scrypt(salt, dk_len, n, r, p)

其中的 salt 是一段随机的盐，dk_len 是输出的哈希值的长度。n 是 CPU/Memory 开销值，越高的开销值，计算就越困难。r 表示块大小，p 表示并行度。

Litecoin 就使用 scrypt 作为它的 POW 算法

实际使用中，还会加上一个密码进行计算，用一张图来表示这个过程就是：

上面已经用KDF算法生成了一个秘钥，这个秘钥就是接着进行对称加密的秘钥，这里使用的对称加密算法是 aes-128-ctr，aes-128-ctr 加密算法还需要用到一个参数初始化向量 iv。

好了，我们现在结合具体 Keystore文件的内容，就很容易理解了Keystore 文件怎么产生的了。

来解读一下各个字段：

我们来完整梳理一下 Keystore 文件的产生：

当我们在使用Keystore文件来还原私钥时，依然是使用kdf生成一个秘钥，然后用秘钥对ciphertext进行解密，其过程如下：

此时细心的同学会发现，无论使用说明密码，来进行这个操作，都会生成一个私钥，但是最终计算的以太坊私钥到底是不是正确的，却不得而知。

这就是 keystore 文件中 mac 值的作用。mac 值是 kdf输出 和 ciphertext 密文进行SHA3-256运算的结果，显然密码不同，计算的mac 值也不同，因此可以用来检验密码的正确性。检验过程用图表示如下：

现在我们以解密的角度完整的梳理下流程，就可以得到以下图：

ethers.js 直接提供了加载keystore JSON来创建钱包对象以及加密生成keystore文件的方法，方法如下：

现在结合界面来完整的实现账号导出及导入，先看看导出，UI图如下：

HTML 代码如下：

上面主要定义了一个密码输入框和一个导出按钮，点击“导出”后，处理逻辑代码如下：

是可以用来在页面保存文件的一个库。

再来看看导入keystore 文件, UI图如下：

上面主要定义了一个文件输入框、一个密码输入框及一个“解密“按钮，因此处理逻辑包含两部分，一是读取文件，二是解析加载账号，关键代码如下：

参考文档

what-is-an-ethereum-keystore-file

深入浅出区块链- 系统学习区块链，打造最好的区块链技术博客。

最近，一股文件夹病毒之风在一中高一年级蔓延。其威力不小，给许多人造成了恐慌。

感染病毒后会U盘现象：

1.所有文件均变成了exe文件形式。

2.安全弹出时会提醒U盘正在被占用。

这确实令人头疼。

遇到这种别担心，其实，这种病毒本质上并没有吃掉你的文件，而是把你的文件隐藏，造成exe文件的假象。

建议不要使用一些奇奇怪怪的杀毒软件。

今天介绍一种文明方法，既不用以毒攻毒的360，也不需要依赖windows defender。

这种文明方式适合于把"查看隐藏文件及文件夹”打开后依然无法解决问题的人们，希望对您有帮助。

To be clear upfront: I think that our political system is amongst the best across the Globe. It is one of the purest systems to reflect a democratic process in a direct democracy. This is shown in special initiatives like the “Hornkuh Initiative”, where on farmer from the Swiss mountains found enough support for his idea to bring it in front of the Swiss citizens and the politics had to discuss it (it was about supporting farms who still work with cows with horns).

The downside however is speed: Our political processes are sound but slow, sometimes very slow and you can see that when it comes to Cybersecurity especially in the conflict between the shiny initiatives like e-voting and the hard work around security.

Our government tries to enable the digitalization and to provide a framework and an environment where companies can grow and they do a not too bad job there.

But then on the political pane they are driving initiatives like e-voting, which to me is mainly a political PR initiative with almost no real value-add but high risks. We are voting about very six weeks and it is a fundamental part of our society. Additionally, we can use different channels today already like early voting, voting by postal service or in person on the day of the vote. I highly doubt that it will increase the number of people going to vote nor do I think that the quality of the vote will increase if you can “swipe left or right” to vote yes or no. Voting requires upfront thinking and an upfront debate on the subject. I do not see a lot of upsides on e-voting except for a few politicians who can claim that they are the ones driving.

The “only” value add is for Swiss citizens living abroad (which is important, and I can understand this) but the risks connected to bring one of our most fundamental processes in our society to the internet are simply not acceptable. This was shown in a discovery by the Chaos Computer Club: Flaw reported in Switzerland’s biggest e-voting system . Not really a surprise. And this caused me to write this blog: On the one hand, our government and mainly our Federal Council wants to show their drive towards digital Switzerland with high-risk initiatives like e-voting but they miss the fundamental work on Cybersecurity: Schweiz: Regierung gibt grünes Licht für E-Voting die Gegner sind zahlreich . They key point which some people make is that we did a certain number of votes online already in some states in Switzerland and “nothing happened”. A laughable point if you are a security pro.

This is the shiny side, lets look at the basics, let’s have a look at security…

Since quite a time, the Swiss Federal Government is driving a National Cybersecurity Strategy and the people behind this strategy are very good and motivated but the responsible people on the political level do not take their accountability to drive this process. Instead the ministries are fighting each other on competencies and budgets. In July, the Federal Council took a no-decision on Mr./Mrs. Cyber, which caused an uproar within the security community. Different organizations published open letters, something which is not too common in Switzerland. It drove some press coverage as well:

The Federal Council did not take a position on this coverage (which is perfectly ok) but we all at least expect some action.

Well, the worst happened and the Federal Council once again did take a non-decision just before Christmas: Rückschlag für Cybersicherheit beim Bund Bundesrat vertagt Entscheid über Kompetenzzentrum

rather do your job and fix the basics and spend what is needed on security. This is the core job of the government and of you as a civil servant.

It would be nice if we get a smart and forward-looking decision beginning of next year! And then move fast!!

Today many people are using online payments more than ever before. The reason for this is that many businesses have integrated an online payment system as one of the way of receiving payments. The other reason as to why online payments have increased significantly is because is because it has been made safe and convenient that most people are able to use it without fearing that their information will be compromised. The other reason as to why online payment has increased in popularity is because it is easy and in most cases instantaneously. These are some of the tips you need to have at hand when looking to find the best way to accept payments online .

The basic way that businesses are using to receive online payment is by allowing their customers to use their credit and debit cards online. The commonly used cards which are used are Master Card, American Express, and Visa. This is where businesses are adding the feature where customers can input their credit card details which can then be verified and automatically billed when they make their purchases. This is a gateway which is added directly on a business website where customers are able to create their payment profile and returning customers do not have to keep keying in their financial information as it is stored on the website securely.

Another way that business are accepting online payments is by accepting eChecks which most of them are paid directly through the customer’s bank. The banking systems today are generating eChecks which do not require the filling of a physical paper. The good thing about eCheck is that what is mostly required is the filling of information in an online form which is processed electronically and also sends electronically.

You may like: 7 Reasons Why Your Ecommerce Website isn’t Selling Enough

There are businesses which prefer to accept online payment through merchant account which are dedicated for their business. This is another, very effective method given that it’s much easier and the merchant account takes care of all the security and maintenance issues. The common types of merchant account which most businesses are already using include: Authorize.Net and SecureNet which have proven to be safe and highly secure. The merchant service will act as a link between your customer and your business. This increases the transaction security and efficiency but one thing to note is that there are usually charges of this but in most cases, the charges are not high.

The increase of smartphone with internet access has allowed for more businesses to integrate this mode of payments. This is another very effective way of accepting online payments because now customers are able to key in the details of their credit number on their mobile platform. There has also been a rise in the mobile money payment system. This is where you can use your smartphone to make payments over the internet and also receive instant confirmation once the payment has been made.

链团财经.

马坤,区块链技术

21140浏览 0评论 0收藏

当传统网络安全遇上区块链安全将擦出什么样的火花？本期问鼎记大佬邀请到了四叶草信息技术有限公司董事长马坤先生，作为深耕于传统网络信息安全领域的资深专家，对于区块链安全有怎样独特的见解？

声明：BTC123登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。文章内容仅供参考，不构成投资建议。投资者据此操作，风险自担。

<html> <head> <script type="text/javascript"> var timer = null; function auto_reload() { window.location = 'https://en.vulnhost.com/mycenter/settings/account.html?4-2.IBehaviorListener.0-formContact-saveContact=&id48_hf_0=&gender=radio8&firstName=Account&lastName=Takeover&saveContact=1'; } </script> <body> <!-- Reload page every 5 seconds. --> <body onload="timer = setTimeout('auto_reload()',5000);"> </body> </html>

A British security researcher has discovered a serious flaw in Twitter that allows anyone with knowledge of the vulnerability to send tweets from other users’ accounts.

Richard De Vere, from ethical hacking firm The Antisocial Engineer , told Computer Weekly he worked out how to exploit the flaw in a matter of minutes.

“This is not a complicated hack, it’s a logic flaw in code.” he said.

The flaw exposes any account that has a mobile phone number associated with it. With knowledge of that number an attacker is able to post tweets, retweet, send direct messages, or post images and videos. According to De Vere, hackers can even switch off Twitter’s two-factor authentication functionality, which means that knowledge of a user’s login and password details would enable complete control over the account.

De Vere has reported details of the flaw to HackerOne, the security testing firm that runs Twitter’sbug bounty programme for notifying vulnerabilities. He said he isn’t seeking payment but it was the only way to report the issue.

He explained to Computer Weekly in a high-level summary how the hack was possible, but asked us not to disclose this information for fear of alerting malicious actors wishing to exploit the flaw. However, De Vere said he believes some hackers may already be aware of the bug, and have used it as part of scams on Twitter where high-profile accounts appear to have tweeted promotions for fake cryptocurrency schemes.

Ed Tucker , CEO at security consultancy Byte, and a former head of IT security at HM Revenue & Customs, described the flaw as a “serious vulnerability” .

“Imagine if, say, you used 10,000 phone numbers with this vulnerability, and then wrote a tweet about something, maybe a bitcoin scam, or maybe some fake news. Then every one of those phone numbers that was associated with a Twitter account would tweet the same message,” he said.

“Imagine what you could do with that, or what has been done with that previously. You would only notice some odd behaviour on your own account maybe, and not the thousands all doing the same.”

Tucker praised The Antisocial Engineer for exposing the problem, pointing out there is no way of providing details of the bug to Twitter without going through the HackerOne reporting process.

De Vere said he expected Twitter to struggle with the problem as it could mean switching off worldwide an important part of its functionality related to the bug. But he was also confident Twitter would fix the flaw.

“Do you know how frustrating it is to actually find the solution on their own website - but it’s not enforced as standard? It’s the classic case of policy being better than real-world implementation. IT security teams are obsessed with sophisticated attacks when often social engineering just works,” he said.

Hackers have previously taken thousands of dollars in cryptocurrency scams by posing as entrepreneur Elon Musk and hijacking high-profile Twitter accounts to impersonate Musk promoting fake crypto or Bitcoin schemes.

忙碌的2018年已经走到了尾声，回顾这一年，团队把重心放到了安全系统的研发上，几乎占用了我们3/4的资源和精力，目前看算是顺利完成了阶段性任务。在把资源集中到研发后，既有的安全保障工作还能有条不紊地进行下去，真的要感谢大家这一年来的辛苦付出，克服了很多困难与挑战。年底了，就以这篇文章作为YiSRC今年的收尾吧，致敬团队里的每一位小伙伴，也感谢每一位关注YiSRC的伙伴们。

这篇文章的内容主要翻译自2018年12月美国政府报告《The Equifax Data Breach》，对报告内容进行了精简和整理，旨在详细了解这起安全事件的始末，以一个比较全面的视角去审视安全工作。如果你觉得公司还不够重视安全，你可以把这当成一个安全案例用于培训；如果你对公司的安全水平很有自信，也可以拿它来对标review一下自己的安全工作是否到位。当然，企业面临的安全威胁多种多样，黑客外部入侵、内鬼泄露、针对员工的钓鱼攻击等等，这个事件并不能覆盖所有的攻击向量，但仍能从中发现和总结有用的内容。

Equifax过分自信、过分自满的网络安全文化导致了这一切。Equifax未能修补已知的严重漏洞，使其系统面临145天的安全风险。公司未能实现基本的安全协议，包括文件完整性监控、网络分隔，使得攻击者访问和获取了大量数据。在攻击者获取数据的过程中，安全设备的证书过期19个月，又使得可以提前发现的攻击行为被掩盖。

CEO、CIO、CSO提前退休，VP被解雇，支付安全费用，公司股价暴跌，声誉受损。虽然这是一起很不幸的事故，但它却再一次提醒我们，每一家公司都要时刻保持警惕――因为攻击者和敌人是如此老练并且资金充足，我们需要不断保持安全工作的推进并且持续做得更好，才能尽量避免这样的灾难发生在自己身上。

图：Equifax提供的图表概述了2017年数据泄露事件中被影响的数据分类

一.Equifax的商业模式

二.数据泄露事件的始末

三.失败点和反思

四.后续

在美国有三大征信机构（The consumer reporting agency，简称CRA）分别是Equifax、Experian、TransUnion，征信机构收集消费者的信息，对其进行分析以创建信用评分和详细报告，然后将报告出售给第三方，并以此盈利。企业使用CRA提供的用户信用数据来识别和管理交融交易风险，例如，金融机构在决定是否授予贷款和调整相应的利率时参考信用报告和信用分；保险公司使用这些信息来设置保单的保费；而企业雇主则可以使用这些信息来甄别雇员的欺诈风险；电信服务提供商则利用这些报告核实客户的身份，并确定新客户的付款要求和话费额度。

然而这一数据收集的过程，并不是用户主动或是自愿提供给CRA的，相反，CRA积极地从其他商家那里收集消费者的个人信息，收集的信息包含了大量敏感的个人数据，包括有关信贷记录、房租记录、就业信息、保险理赔信息、犯罪记录、破产信息等等历史数据，这一过程是CRA合法的商业模式。

图： Equifax如何接收你的数据

Equifax成立于1899年，在1965年成为一家上市公司。目前在全球拥有10300名员工，并在北美、南美、欧洲以及亚太的24个国家开展业务。在2017年数据泄露时，Equifax拥有8.2亿消费者和9100万家企业的信用信息。

Equifax也是标准普尔500指数的一员，它的普通股在纽约证券交易所交易，股票代码是EFX。2018年10月26日，Equifax的市值为117.2亿美元，相比之下，Equifax在2017年9月7日公开宣布数据泄露事件的前一天，市值为170.2亿美元。在2018年9月发布第三季度盈利报告之前，Equifax的股价几乎回到了其宣布数据泄露前的价格$138.06美元，但是在10月份季报公布以后，报告显示，由于与数据泄露相关的成本持续增加，Equifax没有实现预期的预期，股价下跌了17%以上，目前收于$97.19美元。

图：Equifax的股价（2017年5月至2018年12月）

2005年12月，Richard Smith被聘为Equifax的首席执行官（已于2017年数据泄露事件发生后退休），他上任后迅速启动了雄心勃勃的增长战略。2007年，Equifax以14亿美元收购了拥有1.4亿雇员记录的美国人力资源和薪酬服务公司TALX；2014年，以3.27亿美元收购了英国债务管理公司TDX集团；2016年，以19亿美元收购了澳大利亚领先的信贷公司Veda Group。Equifax总共收购了18家公司，这些收购使Equifax成为世界上最大的私人信用跟踪公司之一，积极的增长策略使Equifax的市值从2005年12月的大约38美元增加到2017年9月初的138美元。

然而大量的敏感信息使得Equifax成为黑客攻击的主要目标，姓名、出生日期、地址、社会保障号码、驾驶执照等，这些个人识别信息Personally Identifiable Information（简称PII）由于其潜在的高价值，在电信诈骗、金融欺诈、恐怖行动等其他犯罪中的有着重要用途，已成为网络犯罪世界中最有价值的商品之一。

CRA受各种旨在保护消费者信息的联邦法律的约束，监管部门可以根据法律对CRA进行管理。

联邦贸易委员会（FTC）可以依据“联邦贸易委员会法”第5条规定的权力追究CRA数据安全违规行为，包括要求企业实施全面的数据安全改进工作或向用户提供金钱补偿。

消费者金融保护局（CFPB）侧重于检查CRA对用户信用报告的准确性、公平性以及合法使用，与保护数据安全并没有太多联系。

格拉姆-利希法案（GLBA）要求CRA开发、实施和维护一个全面的信息安全程序，以确保客户信息的安全和保密，每个CRA都必须做到：

1.指定一名或多名员工协调其信息安全工作

2.识别和评估客户信息在公司运营的每个领域的风险，并评估目前控制这些风险的保障措施的有效性

3.设计和实施安全保障方案，并定期进行监控和测试

4.选择有安全保障措施的服务提供商或供应商，确保合同里要求他们维护安全措施，并监督他们对客户信息的处理

5.根据公司业务运营的变化，或安全测试和安全监测的结果等相关情况及时评估和调整整个安全工作

公平信用报告法（FCRA），于1970年颁布，用以提高CRA保存的用户信息的准确性和隐私性。根据FCRA的规定，CRA必须维护一套程序，通过这些程序用户可以对其信用报告中不准确或不完整的信息进行纠正和申诉。为了遵守这一要求，Equifax为消费者提供三种途径来对信用报告中的信息进行申诉：电话、书面文件邮寄、在线服务（通过Equifax提供的一个门户网站）。Equifax在1970年建立了这套自动信用调查系统Automated Credit Investigation System （ACIS） 来处理用户的申诉。用户可以提交与其信用有关的文件副本，当Equifax收到申诉时，它会创建一个ACIS案件来跟踪信用调查过程。而整个数据泄露事件的导火索正是源自这个ACIS的门户网站。

另一方面，当发生数据泄露事件时，虽然没有全面的联邦数据泄露通知法，但所有50个州都颁布了立法，要求将影响到个人的泄露事件进行通报或通知。通常州的泄露通知法里都包括这几个部分：

1.哪些实体比如企业必须遵守法律

2.哪些个人信息受到保护，以及如何定义数据泄露

3.什么水平的损害程度才可以触发通知

4.通知必须以何种方式和何时送达

5.是否有例外的情况或安全港协议

6.其他州法律的优先权，以及与其他联邦法律的关联关系

7.执法当局和对受伤害者的补救措施

由于不同州之间的法律有冲突，比如对通知的时间要求不同、对个人信息的定义不同，可能会出现在一次泄露事件中，企业需要对一个州的用户通知，但并不需要对另外一个州的用户进行通知。

除了向政府部门提供泄露通知外，企业还可能被要求向投资者披露网络安全风险和网络事件。在2011年10月，美国证监会SEC发布了一项指南：如果网络安全风险或安全事件对投资者“有足够的重要性”，企业可能被要求在注册、财务声明、8-K forms中披露这些信息。

这部分会以时间线的方式详细描述整个数据泄露事件的始末，从最开始漏洞被公布、攻击者如何实施入侵并获取数据的细节、攻击持续76天后被发现、Equifax的调查取证工作、以及泄露之后的补救工作等。Equifax在整个事件泄露的过程中的表现并非一无是处，有些做法甚至仍然值得借鉴。

2017.2.14

Apache软件基金会收到了关于Struts（一个非常流行的Java Web应用程序框架）多个版本中发现的漏洞的第一份报告。一名安全研究员发现了该漏洞，并通过其安全邮件列表向Apache报告了该漏洞。

2017.3.7

Apache Struts项目管理委员会（PMC）公开披露了Struts漏洞：攻击者可以利用文件上载功能向服务器发送恶意代码或命令。国家漏洞库NVD的影响分析表明，利用该漏洞进行攻击的复杂性很低，并且，在受损害的系统中，完全丧失机密性、完整性、可用性的可能性很大。根据评分标准，给出了10分的最高得分。Struts漏洞被广泛报道后，安全人员几乎立即观察到大量的攻击企图。一家公司观察到黑客试图使用简单的命令（whoami）以及更复杂的命令。在公布漏洞的同时，Apache Struts项目管理委员会也发布了修复该漏洞CVE-2017-5638 Apache Struts 2 S2-045的补丁。

图：NVD CVE-2017-5638 影响分析

2017.3.8

国土安全部的计算机安全应急小组（U.S.-CERT）向Equifax发出了一份关于需要修补Apache Struts漏洞的通知。Equifax的多个人收到了US-CERT的邮件，其中包括全球威胁和漏洞管理（GTVM）小组和首席安全官Susan Mauldin（已于2017年数据泄露事件发生后退休）。

2017.3.9

Equifax的GTVM小组对漏洞进行了通告，大约430个人和各种邮件组收到了邮件，邮件里指示公司负责Struts安装的人员需要将其升级到指定的Struts 2版本，并且强调“这个漏洞可以被利用，并且已证实目前正在被利用，因此该漏洞被列为严重风险，根据公司的安全策略需要在48小时内进行修补”。

Equifax的安全团队同时执行了一次组件扫描，在服务器文件系统上进行扫描，用以识别运行了漏洞版本Struts的系统，但是扫描结果表明并没有发现有受影响的系统。

2017.3.10

仅仅过去一天，就有攻击者利用这个漏洞并执行了“whoami”命令去发现Equifax其他潜在受影响的服务器。不过，并没有发现直接证据表明3月10日的行动与5月13日开始的正式的入侵活动有关。

2017.3.14

Equifax的应急威胁小组发布了一个Snort特征规则，用来检测针对这次Struts漏洞利用的攻击，对抗小组则在入侵检测与防御系统（IDPS）上安装了这个规则。

2017.3.15

Equifax从安全厂商McAfee收到了一个新的特征规则，用于识别出带漏洞版本的Struts服务。Equifax使用McAfee漏洞管理器工具应用这个识别特征，对其外部面向互联网的系统进行了两次扫描。扫描器检查了958个Equifax的外网IP地址，没有发现存在该漏洞的任何实例。

简而言之，Equifax在修补过程中使用的两种扫描工具都未能发现识别出公司正在使用的带漏洞的Struts版本。

2017.3.16

在GTVM团队主持的月例会上，它们讨论了Apache Struts漏洞，会议的幻灯片指出，该漏洞目前正在被利用，并提醒负责Struts安装维护的人员将其升级到2.3.32或2.5.10.1版本。会议结束后，GTVM把这些幻灯片例行邮件发送给了430个在邮件列表里的人。

2017.5.13-7.30

将近过了两个月，入侵者利用Struts漏洞成功进入了Equifax的内部网络，攻击的入口正是上面提到过的ACIS系统（Equifax为消费者提供用来对信用报告中的不准确信息进行申诉的一个门户网站）。在入侵ACIS系统后，攻击者上传了第一个Webshell后门程序，用于远程控制。（Webshell是一种后门程序，攻击者通过它可以随时重新进入这台服务器，可以使用文件系统、进行数据库操作，方便执行系统命令，并提供文件上载/下载功能；在后续的攻击过程中中，攻击者大约上传了30个不同种类的Webshell）

随后，攻击者通过挂载NFS（网络文件系统）共享，由于Equifax未对存储中的文件进行访问控制，攻击者获取到了敏感的配置文件，包括未加密的应用程序使用的连接数据库的用户名和密码。攻击者成功使用这些凭证访问了与ACIS系统功能无关的48个数据库。

攻击者在这些数据库上运行了大约9000个查询，这些查询包括对数据库元数据的查询，以发现表中包含的信息类型；以及一旦找到了一个带有PII信息的表，需要执行额外的查询，用以从表中获取出想要的敏感数据。总共，9000次查询里的256次查询，返回了包含PII的数据集，并且所有这些PII信息都没有在数据库中被加密。

攻击者将265次成功查询的PII数据输出存储在文件中，压缩并放置在一个可访问的WEB目录中。在远程通过Wget工具下载了这些文件，成功将数据从Equifax窃取。整个攻击过程，攻击者使用了大约35个不同的IP地址。

攻击持续了76天，然后才被Equifax的员工发现。原因是Equifax有安全设备可以监控到网络里的异常流量，包括它们之前更新了规则的入侵检测与防御系统。但是这些安全设备的前面还有一个SSL解密设备SSL Visibility （SSLV），用于将加密的流量解密后发给检测和防护系统进行分析识别。但是，在事件发生时，SSL解密设备上的证书已经过期了，根据设备的配置，证书过期不会影响流量的正常传输，但是却会影响入侵检测与防御系统，因为它们无法分析加密的流量。其中ACIS的域名ai.equifax.com的证书在2016年1月31号就过期了，也就是说在19个月之前，入侵检测与防御系统就已经无法检查ACIS的流量了。

图：外部访问、SSLV设备、IDS设备、以及内部服务器示意图

2017.7.29

晚上9:00点，Equifax的对抗小组将67个新的SSL证书上传到数据中心的 SSL Visibility （SSLV） 设备上，恢复了入侵检测与防御系统对流量的分析和识别。几乎就在同时，对抗小组马上就检测到来自其他国家的IP地址的可疑请求，通过分析，发现这些请求返回的流量大都超过10M，可能还包含了与信用调查有关的图像文件。对抗小组讨论后对这些IP进行了拦截。

2017.7.30

Equifax的调查分析人员很快就发现外流的流量里可能包含PII数据。意识到事件的严重性之后，Equifax决定于7月30日下午12点41分关闭ACIS门户网站以便紧急维护。当网站离线时，这次网络攻击也就结束了。

2017.7.31

Equifax启动了代号Sierra的项目，负责跟进事件的分析和影响调查。调查分析小组发现了一些本不属于ACIS项目的JSP代码文件，并立即对环境进行了镜像，以便后续分析和取证。此时，Equifax还不能完全确定攻击者是如何进入ACIS环境的，但是根据ACIS的WAR包分析发现里面包含了带漏洞版本的Struts，所以它们怀疑很可能攻击者是通过Struts漏洞实施的入侵。

2017.8.2

Equifax联系了外部律师，并聘请网络安全公司Mandiant完成对数据泄露的全面调查分析并确定入侵的范围，同时向联邦调查局通报了这一事件。

2017.8.3

Mandiant安全公司于8月3日至10月2日进行了调查分析，模拟执行攻击者在当时访问数据库时使用过的查询语句，然后确定攻击者能够获取的信息范围。

2017.8.11

Mandiant安全公司首先确认了攻击者对用户PII数据的访问。

2017.8.15

Equifax的雇员告知CEO Smith，用户的PII很可能被盗。

2017.8.17

此时此刻，Equifax已经确定有大量的用户数据被侵害，包括首席执行官、首席信息官、首席法务官、首席财务官、被入侵系统ACIS的业务负责人、Mandiant安全公司代表、外部律师一起讨论了调查结果。

Equifax同时发起了一项专门的响应措施，项目代号Sparta：创建一个面向消费者的网站，用户可以查询自己是否在这次泄漏事件中被影响，如果是的话，还可以免费注册信用监控服务以及身份盗用保护服务。CIO和CEO亲自负责，有50名IT人员参与到这个紧急的项目。同时，为了防止忙中出错，再引发新的安全问题，Equifax在设计和准备这个外部网站时做了大量工作，对这个网站的设计和安全措施进行仔细的检查。

Equifax也开始为建立呼叫中心的能力做准备，以应对用户咨询涌入的电话，作为一个B2B公司，之前并没有如此大量的面向用户的客服需求，只配置了500名客服人员，预计需要增加1500个坐席，这也是一项有挑战的工作，所以不得不临时借助外部第三方的客服。

2017.8.24-8.27

Mandiant安全公司证实了有大量PII被攻击者访问，并与Equifax数据库所有者协调，以确定攻击者访问了哪些数据和受影响的个人，并且由于Equifax没有数据库所有者的列表，数据库中的某些数据也没有清晰的定义，使得这一过程非常具有挑战。与此同时，CEO Smith向Equifax董事会报告了这一泄露事件。

2017.9.1

Equifax召开了董事会会议，讨论调查、受侵害的PII范围、以及对外通知的计划。

2017.9.4

Equifax在Mandiant安全公司的支持下，完成了大约1.43亿受影响的消费者的名单（最终这个数字增长到1.48亿）。

2017.9.7

Equifax宣布公司发生了一起“网络安全事件”，影响到大约1.43亿美国消费者，包括姓名、社会安全号码、出生日期、地址和驾驶执照、209000个信用卡号码和182000份用户信用报告申诉文件。Equifax公司向各州的官员发送信件披露了数据泄露情况，解释了泄露情况和Equifax公司为保护消费者所采取的措施，以及该州可能受到影响的居民的大约人数。

就在宣布的同时，公众反应就带来了一系列问题。之前建立的提供用户查询是否受到泄露影响的网站equifaxsecurity2017.com，由于 Equifax官方Twitter在拼写时不小心颠倒了单词顺序，将用户引导到了一个“钓鱼网站”（所幸，这个网站是由一个安全研究人员创建，目的并不是欺骗获取用户的信息）。同时，在一开始网站存在一些Bug和性能问题，导致用户每次查询的结果不同、或是网站处理速度很慢，以及注册免费的被盗保护服务时出现错误。虽然编码错误后来被解决了，但这进一步带来了用户公共关系的损害。临时搭建的客服坐席，由于训练和培训不足，虽然夜以继日的工作，还是没有达到应用的水平，导致客服被淹没在大量的用户咨询里。

图：官方推特指向了错误的网站

图：在securityequifax2017.com钓鱼网站上弹出的提示

2017.9.15

Equifax宣布其CIO（David Webb，在Equifax工作7年）和CSO（Susan Mauldin，在Equifax工作4年）退休。

2017,9.26

Equifax宣布CEO（Richard Smith，在Equifax工作12年）退休。

2017.10.2

Equifax公司终止了高级副总裁、Equifax全球平台首席信息官（CIO for Global Corporate Platforms），Graeme Payne的职务。佩恩在数据泄露之前工作了近7年，且是一名评级很高的高管。公司解雇他的原因是，黑客攻击的ACIS系统在佩恩的管辖范围内，而他“未能转发2017年3月9日GTVM内部发布的修补Apache Struts漏洞的邮件” 。然而Payne认为这并不是自己的职责，他只是收到漏洞邮件430人中的一个，并且从来没有接到任何人的指示去转发这样的漏洞修复邮件，他也不是ACIS的系统所有者或者应用程序所有者。

直到数据泄露发生时，公司的CSO不是向CIO或CEO进行汇报，而是置于首席法务官CLO之下，CLO则是名义上的安全负责人。例如在高管会议中，通常安全部分的幻灯片会包含在法律部分的review。

在这种结构及汇报关系下，IT和安全之间存在着很大的不协调的鸿沟，公司没有促进CIO和CSO之间建立很强的合作伙伴关系，CIO将自己以及IT团队完全和安全撇清关系。IT和安全部门被隔离，双方缺乏信息的共享、流动以及沟通，双方的协作大多发生在处理问题时，例如当安全需要IT授权对网络进行更改时。这种不一致和缺乏协调，还表现在：双方都维护了各自的软硬件资产列表，然而更佳的做法，在一个充分协作的环境下，应该两个团队一起完成清单，并合并成一个单一的主列表。

Equifax的CEO没有把网络安全放到很重要的位置，CSO也不被认为是高级领导层成员，在每次的高管会议上，CSO并不会定期参加会议，会议上讨论的各种议题，安全只占很小一部分。在这个会议上，CEO不能及时收到关于Equifax安全态势的信息，因为他所收到的信息是由没有任何IT或者安全背景的法律部门负责人CLO提供的，而不是CSO――公司真正的IT安全专家提供。普华永道（PricewaterhouseCoopers）在2018年发表的一项研究得出结论：由于当前信息安全对公司的重要性，CSO更趋向于直接向CEO或董事会报告，而不是向CIO报告，这样的情况越来越普遍，这项研究发现，调查对象中，24%的CSO向CIO报告，40%的CSO直接向CEO报告。

在泄露事件发生后，Equifax将CSO变更为首席信息安全官CISO，在2018年2月2日任命Jamil Farshchi为CISO，同时将CIO变更为首席技术官CTO，在2018年6月15日任命 Bryson Koehler为CTO，CISO和CTO都向CEO汇报。这些管理行动表明，公司现在认识到网络安全是一项核心的业务属性，让CISO和CTO加入到公司的高级管理团队，才可以用更有成效的协作方式开展安全工作。

图： Equifax的IT组织结构

Equifax的补丁管理策略，表现出来的策略开发和执行之间的脱节尤为明显。此策略定义了不同的角色和责任，并为修补过程制定了指导方针，根据该策略，业务所有者将被告知修补的必要性，并负责批准停机时间用于修补。系统所有者负责安装补丁，然后应用程序所有者负责确保正确安装了补丁。然而，除了指定角色，并没有指定具体负责的人。策略还要求系统所有者和应用程序所有者订阅外部来源的漏洞公告，但是缺乏对系统所有者和应用程序所有者的正式指定也意味着没有任何一种机制可以确保每个人都遵循这一订阅要求。

图：2016年版的补丁管理策略下的关键漏洞修补流程

同时，公司缺乏一个全面的、准确的资产清单，缺乏对IT资产的管理，也造成了修补过程中的遗漏，如果一个组织不知道它的网络上有什么，它就不知道哪里需要修补。其实在2015年的审计过程中，Equifax就已经了解到了在管理策略中的差距，但是在2017年发生泄漏事件前仍没有进行有效的改进。

审计发现的不足

改进措施

未及时修复漏洞

实现自动修补工具，并尽快淘汰遗留系统

Equifax缺乏适当的资产管理程序，缺少全面的IT资产清单、准确的网络文档、IT基础设施的全局视图

改进IT资产管理控制以确保所有IT资产的准确收集和统计

没有及时对系统进行修补，大多数修补程序都在GTVM发出修复警告后

实施积极主动的修补过程

部署新系统或变更已有系统时，未要求进行安全扫描

修改变更管理流程，以要求在部署前对资产进行漏洞扫描

补丁程序在部署之前没有得到充分的测试

安装补丁前进行测试

在确定应用补丁的时间窗口标准时，未参考IT资产的重要程度

对IT资产进行风险分类，改善管理策略，加入对高风险系统提出更严格的修补要求

另一个在策略开发和执行之间存在差距的例子就是Equifax的证书管理，公司清楚地意识到缺乏更新SSL证书的流程。过期的证书限制了入侵检测和防御系统的作用，如果将能够在更早的时间内看到来往于ACIS平台的可疑流量，也许就可以减轻甚至防止这次数据泄露。

遗留技术既是安全问题，也是创新的障碍，遗留系统通常很难修补、监控或升级，所以带来了更高的安全风险。另一个遗留技术的风险是懂得操作和维护的雇员人数会不断减少，ACIS就运行在老旧的系统上，在数据发生泄漏时，公司能维护它的人只剩下几个了。ACIS运行在曾经的IT厂商Sun Microsystems公司的 “Sun servers”上，上面运行着Solaris操作系统。在一个更现代的系统中，有很多agent和扫描器可以方便地收集软硬件的信息，但是在这些老系统中，却缺乏这些工具的支持，使得扫描的效率变得很低、识别率也很差。

在数据泄露之前，Equifax公司正在德州建立一个现代化的、软件定义（software-defined）、高度自动化和编排的数据中心，项目代号Bluebird。消除历史遗留的技术债务，不仅是成本问题，还涉及到很多重构问题，并且需要很多技术专家才能保证迁移过程可控。公司正是认识到遗留系统的诸多问题，才决定朝着这一方向改进，然而他们行动的还不够快，没有赶在泄露之前完成转型。

ACIS应用服务器与Equifax网络的其余部分之间没有隔离，从INTERNET获取应用程序服务器控制权的攻击者可以转到Equifax全球任意的网络中的设备、数据库或服务器。适当的网络分割、或更细粒度的访问控制可以防止恶意软件和攻击者在网络里的横向移动，防止潜在的攻击传染或扩大。

在应用程序和Web服务器上都没有文件完整性监控（FIM）。大多数外部网络攻击都会对系统进行修改或配置。FIM能够检测并对发生的未经授权更改进行告警，安全公司Mandiant表示，FIM可以检测到在Equifax环境中创建的30个Webshell后门程序。

跨系统共享文件是一种非常容易受到攻击的做法，特别是在没有适当设置访问权限的情况下。并且，系统管理员应该遵循“最小知悉”原则设置文件访问权限，特别是包含敏感信息的配置文件。攻击者正是通过NFS文件共享获取到其他业务系统的数据库访问凭证。

服务器的日志只保留了14天，因此很难、甚至不可能追溯任何恶意活动。日志记录了系统和网络中发生的事件，对调查取证以及还原攻击过程有着至关重要的作用。日志只有在保留的时候，日志才是有用的。研究表明，针对金融机构的有针对性的APT攻击平均需要98天才能被发现。NIST建议将高影响的系统的日志保存3至12个月，尽管这会带来存储的成本。支付卡行业（PCI）数据安全标准（DSS）则建议归档日志保留至少一年，最近三个月的日志则要保证在需要时立即可供分析（比如保存在诸如ELK里）。

安全公司的报告包含有11项关于Equifax的改进建议，包括加强扫描和漏洞管理、增强数据库的访问控制、改进网络分隔、部署Web应用防火墙WAF、加快实施文件完整性监控、加强各种系统和设备的日志管理、加速实施特权账号的管理等。截止2018年8月，Mandiant和Equifax官员确认Equifax执行了所有11项改进建议。

同样，国家、州的各个监管机构、政府问责办公室等都对Equifax提出了改进建议以及签署了协议书。

Equifax提交给SEC的10-K文件中显示，公司已经采取了各种补救措施以解决在泄露调查中发现的缺陷，并将继续加强，防止这类事件再次发生，重新赢得消费者、客户和监管机构的信任。

在2018年给投资者的年度报告中，Equifax报告了其董事会是如何加强监督以提升Equifax的网络安全保障的内容，包括：强化董事会的全面参与、拓宽技术管理委员会的职责、成立安全相关的专委会、加强网络安全防护等。

Equifax在泄露事件之后增加了IT和网络安全支出，2017年11月，公司临时首席执行官Paulino do Rego Barros表示，Equifax公司自发现泄露事件以来增加了四倍的安全支出。Equifax报告称2018年前9个月与这起安全事故有关的费用为2.215亿美元，包括技术和数据安全、法律和调查费用、产品赔偿等。

写在最后，这两天在群里（基于量子透明计算的可信自主可控区块链式拟态安全态势感知的威胁情报联盟微信交流群）里看到各位大佬讨论安全工作的本质：

看完感触很多，也解除了我的一些迷茫，这几年大家在跟进业务安全、追求安全产品研发，想着对外能力输出甚至盈利，却慢慢忽略了安全最重要的那部分。如果问我2019年最想做什么，我想应该是把那些最基本、最基础的事情重新梳理做坚实、做牢固，去追求最开始作为一名安全工程师时设定的那些安全目标，用个俗气的词――“不忘初心”。

声明：本文来自宜人安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如需转载，请联系原作者获取授权。

The recent Magellan vulnerability in SQLite allows attackers to exploit affected applications and run malicious code on your machine. One such application is the Chrome browser, which uses SQLite as the backend for several of its components, including WebSQL. WebSQL allows any javascript-enabled webpage to run arbitrary SQL queries on your machine so if SQLite has a vulnerability, then malicious webpages can exploit it.

Though the Tencent Blade Team haven’t yet disclosed full details of the vulnerability, Zhuowei Zhang has already been able to reverse-engineer the fix to produce a Proof of Concept. With just a few lines of JavaScript, the demo webpage can crash the browser tab in affected versions of Chrome.

A quick look at a bit of the vulnerable SQLite code in the stack frame above the memcpy() crash:

Note the integer comparison on the first line. This contains a classic integer overflow vulnerability, and that’s used by the proof of concept code. In a debugger:

Notice the region of memory in blue, which is the same as the string in the PoC code:

Also note the 0xFFFFFFFF (underlined in red); this is INT_MAX, so when the value of nSuffix (which is 2) is added to it, it results in an overflow, producing a negative result, so the comparison results in an erroneous skip of the early return.

A little more work would be required to exploit this, and even so, thanks to Chrome’s architecture, the attacker would have achieved Remote Code Execution only within the sandbox. If the attacker were able to additionally exploit some other vulnerability in the Chrome sandbox or the windows kernel, then they may be able to do more nefarious things such as install ransomware. There have been dozens of Chrome sandbox escapes over the years, and plenty more Windows kernel exploits that may be used.

The nastiest aspect of browser exploits is clearly that user interaction is not required. Bromium has been tracking an increase in Exploit Kit activity throughout 2018, and has noted a particular use of CVE-2018-8174 (IE Remote Code Execution) and Flash CVE-2018-4878 to deliver ransomware without user interaction. Even in the past few days, CVE-2018-8653 has reportedly been exploited to perform RCE in Internet Explorer.

One such infection vector that we see often, is when a user receives an email or tweet with a link to an infected website. This message can easily pass through all the layers of email security within the organization, as the destination is generally not known as malicious. Attackers frequently use websites of a small company or organization that has been compromised and is being used to host the attack, as this is less likely to arise suspicion of the security tools than if they had been using a newly registered domain.

Upon clicking the link, the website is immediately able to run the exploit, without any user interaction.

Bromium users are inherently protected against browser exploits like these, since we run each browser task in its own lightweight, hardware-isolated container . With Bromium, malware is separated from the host machine and other browser tabs, which allows us to continue execution of the malicious code with no risk to the user. In the Magellan demo it simply crashes the tab, and this is immediately fed back to our customer’s security team. For example, in the classic Proof of Concept with a calc.exe launching from IE the security team would see this:

And with all malware, all process and network activity, filesystem and registry modifications, etc. will be captured and made available for analysis.

The fact that the Magellan bug was found in such a thoroughly-tested, widely-used library demonstrates that vulnerabilities are inevitable, and will continue to exist.

Bromium users remain protected because the attack unfolds inside the micro-VM container where it doesn’t actually matter what the malware does. With Bromium, the malicious code is completely isolated from the host operating system and is destroyed as soon as the user closes the browser tab. There’s nothing to steal, no way to move laterally, and no ability to persist.

If you want to learn more about Bromium Secure Platform ,contact us to request a demo.

Bromium bloggerMatthew Rowen also contributed to this post.

This post looks at two-factor authentication adoption in the wild, highlights the disparity of support between the various categories of websites, and illuminates how fragmented the two factor ecosystem is in terms of standard adoption.

Performing a longitudinal analysis highlights that the adoption rate of 2FA (two-factor authentication) has been mostly stagnant over the last five years, despite the ever increasing number of accounts hijacked due to the reuse of passwords found in data breaches and phishing attacks . Even more troublesome, looking at the type of 2FA offered reveals that some verticals, including some that have widely adopted 2FA, solely rely on custom two-factor solutions, instead of using two-factor standards, such as U2F/FIDO and TOTP .

Arguably, this behavior should be considered harmful to Internet ecosystem security, as it tends to create an unhealthy competition between sites to entice users to use different systems and install many apps. For example, as you can see in the screenshot above, HSBC and Blizzard Entertainment rolled their own proprietary two-factor software that requires you to install their app. They also use their own lingo and workflow e.g HSBC ask for a PIN to generate the TOTP code and call their software authenticator a secure key which is confusing to say the least. These practices certainly does not make it easy for users who have to learn the quirks of each system they enroll to.

In contrast, if every site were to use standardized two factors and a common language, once the users have installed a single app or bought U2F hardware dongles, they would be able to use them everywhere with a consistent user experience. In that ideal world, every site supporting 2FA would benefit from a virtuous snowball effect and user life would be a lot easier.

The remainder of this blog post is organized as follows:

Before diving into the results, let me briefly describe how the data was collected and analyzed.

To establish how many sites offers 2FA (two-factor authentication) and what kind of second factors are offered in the wild, I pulled the list of sites offering 2FA from dongleauth.info . To have historical perspective, I relied on the fact that the dongleauth.info git repo has been active since 2014 and pulled the list of sites as it was after the last git commit of each year from 2014 until 2017. Finally, I wrote a few python scripts to aggregate their yaml files and compute the statistics needed to create the charts that are used in this post ( raw results available here ).

Among the main limitations of this approach, it is obvious that it is not systematic - ideally, we would go through all of the top 1,000 sites and manually verify if 2FA is available and, if so, in which format and what language is used. Similarly, the examples used through this post are anecdotal: I didn’t do a formal analysis of the language used to describe 2FA across all sites. Finally, while there are a lot of studies that show consumers are picky on what app they install, there is no user research that directly shows that users are unwilling to install all the security app that are needed.

That being said, this blog post is meant to be a conversation starter and raise awareness, rather than a full-blown research paper. In that context, I would argue that the data presented in this blog, which is used to support its claims, are good enough as the issues are so widespread that they are obvious whichever way you look at them. In particular, looking at the database coverage for the 2015 old version of Alexa top 1000 sites (the recent one can’t be downloaded since Amazon bought it) shows that the database covers 40% of the top 100 domains and 23% of the top 500 - this is not perfect, but it is more than enough to spot trends.

Moving forward, I agree that the community would benefit from a more rigorous study with clear recommendations that can be used as a reference by CISOs, CTOs, policy makers, and other key opinion formers. It is something that I hope we can do in 2019 - so, if you are interested in contributing, drop me a note!

With this out of the way, let’s delve into the study results.

Overall, as of late 2018, 52.5% of the 1149 sites listed in the dongleauth database support 2FA. As we will see throughout this post, while having one site in two-supporting 2FA is good news, there is a lot of nuance behind this number that paints a somewhat grimmer picture.

To evaluate if the adoption rate of 2FA is increasing, I plotted the number of sites in the database at the end of every year since its inception (2014) and how many of those sites were marked as supporting 2FA. The resulting chart, visible above, shows that the trends don’t look great, while the number of sites supporting 2FA grew from 205 in 2014 to 603 in 2018 during the same period, the total number of sites in the database growing from 382 to 1149. This means that the ratio of sites supporting 2FA barely changed over the last four years: the adoption rate was 53.66% back in 2014, 48% in 2016, and back above 50% in 2017 (50.38%)

Now, one might argue that the main driver behind this stagnation is the fact that the dongleauth database grew by 300% over the last five years (~1200 up from 400) and that the newcomers are smaller/newer sites with less resources, which are, therefore, less likely to have 2FA. To test (and refute) this hypothesis,I looked at how much of the 2FA adoption growth was due to existing sites turning on 2FA. As visible in the chart above, turn out that very few sites that didn’t have 2FA from the get-go did adopt it after being added to the database. This leave us with the conclusion that:

Understanding why sites don’t adopt 2FA and what can be done to incentivize them to do so are key questions that need to be answered, so that we can devise an effective global strategy that will ensure a steady adoption.

Looking at the adoption of 2FA by site categories reveals that FINTECH- (financial technologies) and IT (information technology)-related services, such as cryptocurrency and cloud services, are leading the 2FA adoption charge. The sites related to services that predated the Internet, such as utilities, food, and transports, unsurprisingly, have the lowest amount of adoption. The most concerning part of this breakdown is that a few categories of sites that handle very sensitive user data, such as education (40.9%) and health (21%), have a very low adoption rate. This highlights the need, as a community, to help those sites jump on the 2FA bandwagon to better protect their user data.

Looking at the type of 2FA supported across the board reveals that software based 2FA is by far the most widely supported second factor, with 82.1% of the sites supporting 2FA offering it. SMS, with 45.6%, is a distant second and hardware token is third, with only a 36.2% adoption rate. This breakdown is probably best explained by the fact that software-token systems are easier to implement and have no operational cost, whereas sending SMS/offering a hardware token does.

Obviously, the price argument is quickly becoming obsolete with the rise of the U2F hardware standard, as it allows any site to rely on security keys to do 2FA with a few lines of javascript . With webauthn and FIDO2 becoming mainstream in 2018, it will become easier than ever to offer a hardware 2FA. This is great news for user security, as U2F keys are the only type of second factor that can’t be phished, because the proof of ownership of the second factor is directly exchanged between the user key and the website.

However, all of this will only happen if sites indeed leverage standards and don’t invent their own version of second factors. This brings us to the last and probably most important part of the post, as it comes down to the future of 2FA: do websites follow standards?

As I alluded to in the introduction, the key to getting more users to use 2FA is to have all sites offering two-factor options to be standardized. This would allow users to reuse their existing app and hardware tokens, instead of having sites competing to get users to install proprietary apps or buying single-site tokens (which is also bad for the planet).

The willingness of the industry to adopt standards is becoming even more crucial, as the next generation of hardware tokens FIDO2, which offer browser native UI, will hit the mainstream in 2019.

Before delving into adoption rate, let me briefly recap what standards exist and when they appeared, so that everyone is on the same page:

Those standards, specially webauthn, offer the promise of a consistent user 2FA experience across the Internet, which, in the long run, is critical to having unphishiable accounts become the norm.

Having reusable two-factors tokens/apps and an Internet-wide consistent experience is only possible if sites adopt standards - this is why measuring adoption prevalence and tracking is so important. As you can see in the figure above, the current plot adoption rate of standards across the industry is pretty bleak - only 11% of the hardware tokens follow the U2F/FIDO standard and 26.8% of the TOTP one.

While the lack of U2F support can be explained by the fact that it is relatively new and was not supported by all major browsers, the lack of support for TOTP is more concerning. The protocol has been around for close to a decade, there are countless apps on Android and OSX that support it, yet barely one in four sites support it. This shows the resistance of the industry to adopt standards, and, thus, calls for a large community effort to get sites to adopt the standard.

As pointed out by my friend Brad on top of not using standards, many websites use their own made-up language, which further increases user confusion about what to do for security. For example, as visible above, Paypal talk about registering the phone as security keys when it is in reality a SMS system. Twitter call 2FA login verification and Bank of America branded it SafePass and copyrighted the word… For more examples checkout the EFF article on the subject.

Breaking down the HOTP/TOTP support by industry-type reveals that industries that predate the internet era are the ones that are the least likely to adopt the standards. This raises the question of how the security community can engage with those industries and encourage them to participate in 2FA standardization. The chart below shows that problems with the adoption rate for the U2F standard is as pervasive and suffer the same lack of support that HOTP/TOTP.

To conclude, we are finally reaching the point where we have the technologies to offer users unphishable accounts with minimal friction and a consistent native UI across the Internet. It is up to us, as a community, to make sure that this doesn’t take 15 years to do, just like the deployment of HTTPS did. We need to engage the industry as a whole and get as many sites as possible, as quickly as possible, on the bandwagon to create a virtuous self-reinforcing circle, instead of a fragmented ecosystem.

A big thanks to Alexei , Aude, Brad and Christiaan for their feedback and insights -- this post wouldn’t be half as good without them.

Thank you for reading this blog post till the end! Don’t forget to share it, so your friends and colleagues can also learn about two factor authentication adoption in the wild. To get notified when my next post is online, follow me on Twitter , Facebook or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .

A bientt!

一提到杀毒软件，想必不少人第一时间都会联想到360这样一个软件吧，当年，在国内有着众多的杀毒软件，什么金山毒霸、卡巴斯基以及百度杀毒等等，在当年的杀毒软件满天飞的年代里面，360凭借免费一举成了杀毒软件的龙头老大，可现如今的360却慢慢走向了没落。

360当年的风光可以说是无人能及的，不知道大家还记得当年著名的3Q大战没有？在10年的时候，360发布了一款隐私保护器专门收集QQ软件的数据，从而引发了腾讯的不满，QQ当即又指出360浏览器涉嫌用黄色网站做推广，双方的战火正式打响了。

双方一度打得十分火热， 到了后来甚至出现用户装QQ的话，就不能用360，装了360就不能登录QQ的局面，尤其是后来，腾讯把QQ医生改成了QQ电脑管家，这摆明了是和360抢生意的，最要命的是腾讯还把QQ电脑管家和QQ绑定在了一起。

双方的战火也愈演愈烈起来，就在这时，工信部以及互联网协会等部门的介入下，双方在政府的调和下，慢慢放下了恩怨，但是，腾讯要求360必须下架隐私保护期并且停止对QQ的拦截，而且还要求360向腾讯道歉并且赔偿损失，所以，这场战争最终是腾讯取得了最终的胜利，但是，这场3Q大战也看得出来360绝对是一个不好惹的主。

虽然表现上双方的战役已经结束了，但是，双方的口水仗还一直没有结束，在法院打官司一直打到了14年的时候，从中级人民法院一直打到了最高人民法院，最终，法院以认定腾讯旗下的QQ并不具备市场支配地位，驳回奇虎360的上诉，维持一审法院判决，正式宣告结束。

当然，现如今的360日子可不好过啊，由于近些年来电脑的安全系数越来越高了，用户对于360的需求性越来越低了，360也慢慢走向了没落了，前段时间公开的资料显示，现在的360市值已经缩水到了1682亿，比起巅峰时期的4600多亿来说，缩水了足足3000多亿。

之所以360会变成现在这样一个模样，我个人觉得老板周鸿yN绝对脱不了干系，我们从360整个体系就可以看出来，周鸿yN绝对不是一个创新者，反倒回来像极了一个投机主义，近些年来，他都是跟在别人后面做东西，几乎没有任何能够称得上创新的，唯一有点印象的可能就是360手机助手了。

反观曾经跟他打过3Q大战的腾讯，虽然腾讯在游戏上饱受玩家诟病，但是，不可否认的是腾讯在创新方面是十足的，在QQ取得巨大成功后，又马不停蹄推出了自己的全新产品微信，后来又开始着实巩固自己的游戏平台，打造了一个又一个生态链。 返回搜狐，查看更多

责任编辑：

中新网12月21日电 据“外交部发言人办公室”公众号消息，外交部发言人华春莹今日指出，针对美方在网络安全问题上的错误言行，中方已经第一时间表明了严正立场。我想告诉他们，谎言重复一万遍还是谎言。在这个世界上，最终邪压不了正。正义也许会迟到，但永远不会缺席。

在今日的外交部例行记者会上，有记者问：据报道，美国司法部宣布将以阴谋入侵计算机、电信诈骗及盗窃身份罪名起诉中国公民，指责中方长期破坏美国网络安全。请问中方对此有何评论?

华春莹指出，针对美方在网络安全问题上的错误言行，中方已经第一时间表明了严正立场。我想再特别补充强调两点：

美方援引各种不具名消息源或貌似“真的数字”对中方进行种种指责，但后来都被证明是假的，这已不是一次两次了。大家应该记得，不久前，针对《彭博商业周刊》所谓中国在苹果、亚马逊和其他美国公司等产品中植入芯片，从后台窃取并传输信息的报道，苹果、亚马逊、超微等公司都第一时间予以否认。苹果公司要求媒体撤回报道。亚马逊公司表示相关报道失实之处数不胜数，从未发现被修改过的硬件或恶意芯片引起的任何问题。超微公司公布第三方调查公司对芯片进行全面检查结果，显示没有任何可疑芯片或恶意软件。听说超微公司还将保留追究法律责任的权利或者考虑采取法律行动。就连美国国土安全部都公开表态没有证据证实中国做过这样的事。这次，美方又以所谓“网络窃密”为由对两名中方人员进行“起诉”，指责中国攻破惠普公司和IBM公司网络。但我看到今天有报道说IBM已经澄清，表示没有证据显示该公司或客户敏感数据被中方盗用。

美方作为当今世界第一强国，不仅妄自尊大、自私自利，而且出于维护自身霸权的狭隘零和思维，对打压别国正当发展权利无所不用其极，甚至不惜捏造事实、无中生有。这与它大国的地位不相符。这样的一个美国对世界的和平与发展不是好事，从长远看也不利于美国自身利益。

华春莹指出，无论是网络安全问题，还是以前的所谓航行自由问题，美方有些人总是习惯于不断对中方进行无端指责，扣各种帽子。他们也许认为“谎言说上一千遍就会变成事实”，但我想告诉他们，谎言重复一万遍还是谎言。在这个世界上，最终邪压不了正。正义也许会迟到，但永远不会缺席

新华网上海12月22日电(记者兰天鸣)《2018全球网络安全产业投融资研究报告》在19日举办的2018网络安全产业创新(上海)论坛上发布。报告显示，据不完全统计，2013年到2017年间全球网络安全企业数量以每年近14%的速度增长，2017年达到8982家。

报告由上海赛博网络安全产业创新研究院发布，收集了2015年至2018年11月的1992起全球网络安全产业投融资数据和事件：从网络安全投融资情况来看，全球投融资事件数量和规模逐年增长，主要集中在美国、英国、中国和以色列的网络安全企业。

报告指出，从2017年以网络安全为主营业务的上市企业的财务数据来看,营业收入持续稳步增长。10家典型企业平均营收60亿元,营收平均增长30.55%。

融资渠道主要是风险投资和并购，其他如无偿资助、IPO、ICO、众筹等较少。从获投企业所处的细分领域来看，身份管理与访问控制类是最热门的领域。

此前，中国信息通信研究院发布的报告显示,2017年全球网络安全产业规模达到989亿美元，较 2016 年增长7.9%，预计2018年增长至1060亿美元。2017年我国网络安全产业规模达到439亿元，较2016年增长27.6%。

中国信息通信研究院安全研究所副所长覃庆玲表示，当前世界主要国家都在强化网络安全、技术、产业方面的投入。从区域分布来看北美、西欧、亚太呈现三足鼎立的态势，三个地区市场份额加起来达到90%。

杭州安恒信息技术公司总裁范渊认为，网络安全产业之所以发展迅猛，原因在于网络安全、性能、业务曾是“较难兼顾的三角”，随着技术的进步、模式的变化，三者已经能有机地融合在一起，正为数字经济发展赋能。

“网络安全产业在这几年到了飞跃发展的转折点，随着有关政策的出台，预计未来几年我国网络安全产业整体规模和各方重视程度将日益加大。”覃庆玲说。

In the eyes of the cyberattacker, just about anything and everything out there is a target. But whether for the theft of personal and confidential information (such as passwords and PIN numbers) or having enough data about somebody to launch a covert identity theft attack down the road, their ultimate goal is one thing: to get money, and lots of it.

In this regard, one of the most vulnerable industries here in the United States is the financial industry. Despite being mandated by various federal legislations forcing financial institutions to improve their system of controls and audits, many of them are still are victims of cyberattacks.

In this article, we look at some of the major security topics that should be included in any checklist as a CIO or CISO make sure their financial institution is complying with federal legislation and mandates.

Note that for the purposes of this article, the term “financial institution” can mean any organization that handles money and related transactions for a customer. This includes banks, lending centers, brokerage institutions, stock and commodities trading firms and so forth.

It’s obvious that many financial institutions, at least here in the United States, create and possess many documents. These can range from simple bank statements to confidential financial modeling data that the banks have to send over to the federal government for review and approval.

In order to electronically transmit these sensitive documents from one place to another, employees have to use file-sharing programs. Most financial institutions already provide this tool, which is supposed to have built-in security features. But employees, being creatures of habit, often like to use the software tools that they are accustomed to. Many of these tools send information as clear text across a network, which would make it very easy for the cyberattacker to intercept and hijack mission-critical information and data.

Although many financial institutions have relatively good spam filter technology in place, there are still quite a number of attacks that get through, especially the phishing emails. The cyberattacker of today knows how to make these phishing emails look very convincing, enough so that a financial institution’s employee will fall for it, submit their private/confidential information and leave a door of opportunity open for the cyberattacker.

Social engineering attacks can also happen to any organization, but they are very prevalent at financial institutions, especially targeting the lower-ranking employees such as administrative assistants. The cyberattacker can sweet-talk one of these employees into divulging contact information that will later be used in a business email compromise (BEC) attack, which normally involves transferring a large amount of money to a fictitious bank account overseas.

In an effort to save money, financial institutions often hire contractors from third-party vendors in order to carry out day-to-day tasks, especially when a deadline is looming. One of the best examples of this is the Comprehensive Capital Analysis and Review (CCAR), which takes place on a yearly basis at the top 30 banks in the United States.

These banks must provide documentation to the federal government that they will be solvent should another Great Recession (like the 2008 one) occur. This huge project involves the work of many people these banks are often understaffed for this project. They often wait until the last minute to hire third-party vendors to help out. The result of this is that these third-party vendors are not properly screened and vetted out, increasing the chances that there could be a rogue contractor among them.

As mentioned before, information is vital for any financial organization, whether it’s customer data or just internal data. But in either case, it must be protected so that it does not fall into the hands of a cyberattacker. Examples of bad practices include the following:

If it’s in your budget, it is highly recommended that you seek the help of an accounting firm or another cybersecurity firm in order to help you establish your set of data loss prevention controls and get regular audits.

Other common safeguards include securely deleting all data from discarded hard drives and shredding documents before disposing of them.

It should be part of your organization’s security policy that employees must use company-issued devices (such as laptops and smartphones) for their work-related activities. They should be constantly reminded of this and the consequences if they do not follow through with this.

Under no circumstances should the employees be allowed to use their own smartphones to conduct work-related matters. This will greatly reduce the risks of what is known as “BYOD,” or Bring-Your-Own-Device. The primary reason for this is that company-issued devices will already have all security measures implemented into them to make sure that no confidential information and data is accessible to a cyberattacker.

It’s also important to conduct routine audits of these company-issued devices to make sure that the employees have not disabled or deleted any security-related applications that were installed onto them. This also includes all forms of communications. As mentioned previously, under no circumstances should personal email or social media accounts should be used to communicate messages that are sensitive in nature. Only authorized means of communications should be used, such as using only company email or an approved instant messaging application.

Given that many employees like to work remotely, it is very important that your financial organization maintains the highest levels of security standards for remote login and network access. In this regard, you should implement the use of Virtual Private Networks (VPNs) between the employee’s laptop and the corporate servers. Also implement the use of two-factor authentication (2FA).

Apart from using the normal password, you could also consider using the RSA Security Token and biometric technology in order to fully authenticate a remote employee.

This simply means that your entire IT staff has been trained and is keeping up with installing the latest firmware/software patches and any other relevant updates on all of the servers, workstations and mobile devices. It is important to keep a regular schedule of this and to be sure that the duties are distributed among various employees, not just one.

Passwords are still the prime source of interest for the cyberattacker, especially at a financial organization. Therefore, it’s critical that you have a very strong password policy in place. This will of course mean that employees will have to create long and complex passwords, so in this regard, you should consider making use of a password manager application.