How To Manage Phishing Attacks and High-Risk Users
So I spent the past week at the COSAC Security Conference and I’ve recharged my engagement batteries once again. One thing that I heard over and over in speaking with my colleagues there, was that we still haven’t cracked the password issue. With the enormous rise in phishing and other account takeover methods, the problem is quickly getting out of control (1).
Fighting Phishing with Awareness and Two-Factor Authentication
We at Cycubix have built a brand new Phishing awareness training module for our clients, but even though heightened awareness among users has lead to reduced risk, there is still a window of opportunity for attackers to compromise staff with well-crafted phishing campaigns or targeted phishing (whaling / spear-phishing).
In thinking about what we can do to reduce this threat to near zero, I’ve thought that even with all of our increased knowledge (looking for https; looking at the URL, hovering over links, etc.), we still can’t 100% verify the server on the other end of the connection – we know who we are, but we can’t prove who they are. Similarly, the verification that the server needs to do on us, by its very nature, forces us to expose our authentication information (thereby leaving open a window of opportunity for attackers).
While Cycubix is vendor agnostic, I’m just going to mention here two of the champions of this cause – Google and Microsoft. In this article, I’m going to focus on at a very high level, what I’ve seen so far on the Google approach. I hope to cover the Microsoft approach next month. CAVEAT: I’m not endorsing either of these in any way. Similarly, I haven’t researched this in any great depth, it’s just a personal opinion on what I’ve seen, and the conclusions that I’ve drawn, from the marketing of Google’s Advanced Protection Program.
The data that Google has collected indicates that if an individual’s credential is phished, they are over 500 times more likely to be successfully compromised.
“No sh.., Sherlock” I hear you scream.
I fully agree, but what happens if that individual is a CEO, CFO, IT administrator, or someone that has access to sensitive personal information (e.g. Healthcare data). The threat is the same, but the impact on an organisation could be so much greater.
Enabling the Business in Phishing times
So should we go all “bells and whistles” and lock down users hard? At Cycubix, our main focus is to ENABLE the business. What I think we should do (and I’m warning you in advance, I’m going to use a fluffy word soon), is choose an “appropriate” (there it is) mechanism for different risk profiles of users.
The main methods that we’re currently using for two-factor authentication (and I applaud some organisations e.g. the Banks, for forcing 2FA on their customer base at last) fall into two main categories:
- A push challenge, where an SMS is sent to your phone with a unique one-time number (verification code). You type this code into the website that you’re transacting with in order to complete the transaction
- An authenticator app on your phone (e.g. Microsoft Authenticator, Google Authenticator, Okta Verify (I am forced to use all three)). These typically work on the basis of a new number being generated every 60 seconds. You type that number into your authentication page, along with your password, as an extra (off-device) verification step.
In general, I’d say that these methods are still “adequate” for many non-high-risk users. My security peers may disagree, but I’m applying the offset of convenience against risk.
Better 2FA for High-Risk users: FIDO Tokens
Where things have moved on, though, is the increased threat against the high net-worth individuals, the vulnerable (e.g. elderly), and the privileged (in terms of authority and power). In my opinion, these common methods of 2FA are no longer sufficient to protect them from the credential compromise threat. We need an uplift for them that is still “easy to use”.
Back to the “but we can’t prove who they are” statement – Google claims that using Fast Identity Online (FIDO) tokens, we can reduce the threat of phishing to almost zero. The FIDO key (over 30 different keys meet the standard) could be utilised as simply by having a Bluetooth fob on your keyring, inserting a USB key, or even interacting using NFC on an Android device.
Not only does the token specifically identify you to the server, but also validates the server as being genuine (2) (https://fidoalliance.org/fido2/). Google claims that it reduces the risk of compromise of device-based challenge (bulk phishing and/or targeted attack), and knowledge-based challenge (e.g. location, phone number, secondary email address) to zero.
Google states that since they have deployed FIDO security keys (3) internally, they have “not suffered a successful account phishing attack against a Google account”. Now I find that a fairly impressive public statement to make.
They recommend the use of FIDO tokens on Google accounts along side the roll-out of Account Takeover Protection settings (4) on enterprise accounts for:
- IT Administrator
- Employees based in high-risk industries (e.g. Government, Financial Services, Healthcare, etc.)
- Employees with access to sensitive information.
It’s also worth noting that FIDO tokens are also supported by the likes of Dropbox, GitHub, Salesforce, etc. where you may potentially need extra security over access to sensitive information.
Personally, I think that this is sound advice by Google. It’s a very minor inconvenience (and cost – FIDO keys retail from €15 up to about €90) to present or insert a security key when an individual is undertaking a high risk/high value task. It’s pretty non-intrusive and easy for non-technical users to do to reduce the risk of successful account compromise/takeover to zero. I think it’s something that security professionals should be actively promoting to clients.
Next month, I’ll outline Microsoft’s approach to “passwordless”, and you may/may not be surprised to see some similarities
This article was written by Richard Nealon a Senior Official (ISC)² Authorised Instructor.