Targeted phishing has become the single most effective attack type in the world today, and attackers’ emphasis on social engineering tactics make the protection of cloud communication platforms a critical component of any cybersecurity strategy.
In this 20-minute webinar replay, GreatHorn CEO and co-founder Kevin O’Brien discusses the critical role of automation in staying ahead of cybercriminals.
The session covers:
- The findings of GreatHorn’s research into the modern email threat landscape (for example: the average enterprise can expect to spend more than 305 per week on email threat review and remediation)
- How automation reduces the workload on IT and Security teams by programmatically identifying and addressing threats
- How to incorporate automation into your cybersecurity strategies to keep critical data safe
Video Transcript:
CATHERINE: Hello, everyone. Welcome, thanks for joining our webinar today. We’ll get started in just a few minutes, we still have a few people joining. In the meantime, let’s give a little background on what we’re going to be talking about today. We’re going to take some time today to walk through statistics and data from GreatHorn’s independent research into the modern phishing threat landscape, and explain how our inbound email security platform reduces time to detection and response for targeted phishing attacks through the use of automation. I’ll save about 10 minutes for questions at the end of the session, so, please feel free to type any you might have into the GoToWebinar interface, at any time throughout the presentation, and we’ll answer as many as possible at the end. Of course, if you don’t get a chance to ask a question that you’re looking to have answered, feel free to just drop us a note at the very end of the presentation, we’ll have an email address, we’d be happy to get in touch and discuss anything further.
Now that everyone’s had a moment to settle in, let’s get started. Our presenter today is Kevin O’Brien, GreatHorn’s CEO and Co-Founder, and the Cybersecurity Expert with over 20 years of experience in the industry. I’ll let Kevin take it from here.
KEVIN O’BRIEN: Thanks, Catherine. Hello, everyone, thank you for joining, it’s nice to be with you today. Looking forward to the conversation, I’m looking forward to your questions towards the end, as Catherine mentioned. By way of background, I’m a cybersecurity guy. I come out of the space with about 20 years of experience, and we’ll be talking today about cloud email security, and some of the issues around why phishing continues to be the master problem that it is. We will also briefly touch base on some of the industry trends what we see from the GreatHorn platform to illustrate the macrotrends that we are observing, as an email security company. If at any point, you’re interested in learning more about GreatHorn, please feel free to reach out to us, either via the questions panel, or you can go to www.greathorn.com, and much of the same information we’ll be covering here is available [03:00] for your review and download there.
What’s happening in the space today? Well, if you think about the overall set of data breaches that have hit the market, we are at a categorically different point in the cybersecurity landscape than we were even 12 months ago. Social engineering attacks, data breaches, the loss of personally-identifiable information, even a cursory glance at mainstream media will give you the sense that we are losing the battle against targeted, sophisticated hackers. Things like the Experian data breach, some of the information that’s happened through the loss of personal information from large healthcare companies, the ongoing question of foreign governments gaining access to US companies and European companies’ internal data sets, and their sale of that information on the black market, has made cybersecurity a board-level issue for many companies. One of the things that we track, and we’re continuing to see grow as we move into 2018, is the prevalence of the social engineering attack, or a targeting phishing attack, as the first point of contact. Or, 90% of all social engineering attacks begin with a phishing email. And the reality today, is that email is the front door for most organizations. Yes, there are attacks that utilize highly-targeted, advance persistent threat, or custom-built malware, but for most organizations, it is a standard to have an employee base that is accessible around the clock, looking at their phones or their tablets or their laptops, and paying attention to email. And, if you are an attacker trying to get someone to wire money, or engage in some kind of fraudulent financial transaction, or give away credentials, you can very quickly, and very easily, reach the entire employee population of a target company in seconds through an email environment. Unsurprisingly, 30%, or a third, of all phishing breaches were targeted.
I want to take a minute to differentiate the fact that there are targeted phishing attacks, what we think of today as business email compromise, and those that generally are more broad-based and go after consumers. When we’re discussing and describing social engineering attempts on organizations, what we’re getting at are the kinds of attacks where a CFO is impersonated, or a CEO is impersonated, and the actual attack is leveraging sophisticated and often multilateral attempts to get someone to do something. Think of an attacker who goes on LinkedIn and determines who the CFO of an organization is, and then sends an email to a sales team using the response from whatever person in sales replies to them, copies the signature block, rewrites the email to look as though it comes from the CFO, and then through that same research on something like LinkedIn, targets a lower-level employee in the finance department, and appears to be asking for W-2s as part of a wage study. This is in fact the exact form of an attack that hit a large manufacturing company that we were tracking a year ago, and lead to the loss of every W-2 for every employee. This is an organization that represents this kind of attack, that today, hits almost every business at some point or another.
And yet, despite the fact that we can, in 30 seconds, run down the exact description of how that kind of an attack is leveraged, companies are still getting breached by them. Why? Well, first and foremost, we have undergone a transformational infrastructure and architectural change over the course of the last three years. Email is an old system. If you look at the ways that we were interacting, using Outlook clients or Lotus Notes clients, in 2000, and you were to compare it to how we interact with one another over email in 2017, aside from differences in web browsers and some upgrades to our desktop clients, it’s functionally the same system. What’s changed about email is not the underlying system, not the fundamental protections of what email can or can’t do, but rather its prevalence. Twenty years ago, email was something that only ran inside of a corporate firewall. There was an exchange, or a Notes or Dominos server sitting in a server room or a data center, protected by a firewall, but today, most companies are running their email infrastructure in the cloud. Using technologies like G Suite or O365, businesses have created an always-on, highly-available email infrastructure, [but have seeded?] the perimeter to Microsoft and to Google. And to be clear, Microsoft and Google do a very good job at protecting against the kinds of things that we were concerned about 20 years ago. You don’t hear about people “hacking in” to Office 365, or Google’s data centers, and exporting data or gaining access to inboxes, but rather, the risk transmits itself now across the user base. That is, social engineering attacks pay off, because if I, as an attacker, can convince that mid-level finance professional that they should send me the W-2s, because, hey, it’s the CFO, well, that kind of an attack is not something that will be stopped by the data provider, by Microsoft or by Google. Rather, there’s a shared responsibility model here, and the person who must protect against that kind of an attack is ultimately the recipient of the email.
We have looked for a while at solving this problem through training. We thought, if the landscape has shifted, and we now need to protect the end user from cyber attack that uses social engineering, the solution must obviously be for our information security teams to train those people, or our technology, to help them identify and learn to protect themselves from a fraudulent message. But we’re simultaneously putting more and more people on the front lines of the attack surface, that is, giving them access to cloud-hosted email systems, and all of the infrastructure that’s connected to it, while we are reducing our information and security staff, because we cannot find a sufficient number of trained infosec professionals. The rise of the data breach, the significance of the kinds of massive cyber attacks we have seen over the past two years, have lead to a dramatic shortfall, over two million unfilled jobs by the end of next year, according to some reports, in the information security professional role.
That cloud infrastructure migration is not limited to email, either. Most organizations have now adopted cloud communication technology, pulling from a big blast report published in 2016. Over half of all organizations had adopted either Office or G Suite. This trend will continue, as the on-premise exchange licensure expires, as we see Exchange 2012, or 2016, begin to be replaced by O365, whether that’s in a hybrid mode for companies that are still moving to the cloud, or a full swap for a cloud-first, cloud-only technology landscape. But, email is also now increasingly being coupled with other forms of technology. Things like Slack are providing organizations with additional technological resources for communicating internally, for distributing access to sensitive files and information, and often for sharing data between both internal employees and external employees, more rapidly than ever before. The reason that we mention Slack in the context of a cloud email infrastructure, is that once an organization has adopted something like O365 or Google, and the users of that infrastructure are expecting to be able to communicate in real-time, from any device, at any hour of the day, technologies like Slack, or teams from Microsoft, or other real-times communications, augment that email landscape, and often integrate directly with the user credentials that are provided from their O365 or Google account. And so, we have reached a point in which literally ever user of every business in the world is a publicly-available target for a cyber attack.
But, we have relied on Legacy technology that is 20 plus years old in some circumstances, to try to address these threats. Enter the Secure Email Gateway. SEGs first came into the market in the late 1990s. Some of them have gone public over a decade ago, and have continued to grow because the cloud adoption for core technologies, like email, has lagged behind the adoption of cloud platform as a service, or infrastructure as a service technology. But that’s changing. And so, where email becomes a cloud-hosted, cloud-native technology, and secondary communication platforms connect to it. The idea that you can prohibit someone from breaching your organization by putting what is effectively a perimeter security control, built for infrastructure you no longer have, designed to solve a problem that the core platforms address natively, simply doesn’t hold.
Secure email gateways are tremendously effective, if what you are concerned about is your exchange server going offline. Deliverability, mail spooling, backups, archiving, these are the considerations that mattered in 2002 or 2004. But Google and Microsoft typically don’t have large public outages. They don’t lose vast quantities of mail due to hard drive failures. So, all of these technical solutions are from a bygone era, and what they have not done is kept up with the modern threat landscape of the hacker who utilizes social networking to identify executives whom he or she can impersonate, and couple that with a sense of social engineering pressure that deceives someone into doing something that they shouldn’t.
And what about that training model? Well, training is an absolute must. You should, as the chief information security officer, or the chief compliance officer of any organization, have a robust security awareness training program. If for no other reason than because doing so ensures that you are able to remain compliant with various audit and external analysis obligations, whether that’s SOC, or a FERPA or FISMA. But also, because if you are so unfortunate as to have a data breach, demonstrating that employees had undergone security awareness training is the barrier to entry for a gross negligence charge against the security organization. However, we must not conflate compliance with security. Forester ran a piece of research in 2015, looking at companies that have undergone a publicly-reported data breach. Fifty-two percent of them received no training whatsoever. Forty-eight percent had undergone security awareness training. The margin of error was roughly 3%. That is, statistically, there is almost no difference in the outcome, from a data breach perspective, between investing in security awareness training, and not doing so.
And the reason for that is that sensitive attacks that people are going to identify and flag, are far out stripped by the shortfall in information security, and the volume of highly-targeted attacks and anomalous messages that the typical organization receives. When we think about what it takes to staff a security organization, and deal with literally every message that is flagged by an end user as potentially suspicious, the typical organization said there’s absolutely no way we can do it. In fact, over half of all security holes in the typical organizational structure go unfilled for months, or even permanently.
So, this is not a problem that you can kick to the end user, and ask them to click a button and report to someone, and have it then be manually remediated. Automation, as with much of the cybersecurity landscape, is the only way to keep up with the vast quantity of phishing and suspicious messages that organizations receive. We are at an interesting moment. If you walk the floor of the RSA Conference, or Black Hat, or Defcon, literally every vendor has some component of their pitch that involves machine learning. In part, this is because it’s an attractive marketing term, but it’s also representative of the fact that we are at a moment in time when compute power is effectively free, or cheap, and we have vast, almost infinite quantities of data storage at our disposal. So, a security organization can tap into those resources to do what a manual process cannot, to look at every message, every security incident, every social connection point between employees, external vendors, customers and trusted contacts, and utilize that data with a learning model that can identify a phishing attack in real-time. This is what GreatHorn has done for the past three years. In fact, in the study that we pulled, over half a billion uniquely-analyzed emails in 2017, and looking back at all of the threat that we had detected and remediated in the year prior, we found that for the typical organization, almost a fifth of all mail had some component to it that was initially suspicious, and following a remediation plan of cleaning up mail authentication records, and working through configuration-level issues, nearly two tenths of a percent of all of that mail continued to be malicious or a risk to the business.
Those numbers may seem small, but if you project out what that looks like for a typical organization, in terms of manual remediation time, the average organization would need to staff over 12 man-hours’ worth of information security professional time every month, just to look at for two to three minutes, each of those messages. And of course, nobody sits in front of their sock and looks at mail eight hours a day, nonstop. So, the typical deployment of 305 hours of information security time requires two to three times as many man-hours available from a staff. At typical market rates, what that would mean is spending multiple millions of dollars simply looking at suspicious email. Nobody does this. And so it’s unsurprising that the core problem from a phishing perspective is the unmitigated threat surface, and why this is then the root cause of over 90% of all data breaches.
Automation, the ability to take action on 70 to 80% of all of that mail, and either remove it from mailboxes or provide contextual analysis to an end user that alerts them to a potential phishing attack is the only scalable way to address this threat. We typically will find that a Fortune 500 company that has between 15 and 30,000 employees will use a variety of different techniques once an automation platform is in place, to drive down time-to-detection response [20:00] by 80% plus, ensuring that, when they do need to spend those expenses, security analyst resources, they’re doing so for the 10 to 20% of all attacks that represent highly-targeted, highly-sophisticated encouragement attempts, and not drowning in the noise of alerts that the typical secure email gateway or training-only approach yields.
And to look at what that does for an organization, if we pull the camera lens back, six months after beginning a GreatHorn deployment, this is a risk analysis score, slightly anonymized, from a Fortune 500 company that has done exactly that. And what they have found is that by turning on these automation technologies, their team of a dozen security professionals was able to focus their time in much more efficient ways, and of the nearly 1,500 suspicious messages that we detect on the average month for them, over 900 are automatically remediated, changing their total exposure risk from when they didn’t know where these messages were, who had received them, what their payloads were, or what social deception techniques were being used to try to trick people, in ways that got around the email gateways they’d put in place, were the core functional aspects of the platform, to only a third of them being unmitigated and requiring security time. Today, this same customer has their risk score at under 5%, because they have turned on automation to either quarantine, delete, move, or mark up those emails for every user in every platform, without having to rely on the delivery modification or a network change, or something that slows down or makes the cloud email system they’ve invested in less efficient.
That concludes the overall presentation on the phishing problem. I do believe we’ve got a number of questions, so I will turn things back over to Catherine, and we’ll answer as many as we can in the time we have left.
C: Thanks, Kevin. We have, indeed, received a number of questions from folks, so let’s dive right in. First question is, how is GreatHorn different from a SEG, from a Secure Email Gateway?
KO: Good question. Secure Email Gateways, if you’re not familiar with the technology, work by changing your DNS-level mail routing, that is, the rules that define how someone sending an email to your organization actually get that email to land in front of a user or recipient at your company. So, if you use a traditional Secure Email Gateway, they will become the first port of call for every email which you receive. They will take that message, look at it, make a decision about whether it might have a virus in an attachment, like a Word file, or something that looks like it could be malicious in some fashion, and then either quarantine that message or delay its delivery, [23:00] and pass on the good messages to the intended recipient.
There are a couple of problems with this. The first is that false positives are a first-order issue for a SEG, because if they get it wrong, your user literally never sees it. The second is that this is a very coarse instrument. The ability to block something from being delivered means that you can drive down things like spam by an order of magnitude, but it’s very, very difficult to pass a message to someone with any more nuance to the action or remediation.
GreatHorn does not take this technical approach, rather, we recognize that in a cloud ecosystem, the cloud infrastructure you’re running, like G Suite or O365, is best protected by a cloud security product. So, we utilize the APIs that are made available from Microsoft and Google, and analyze them in real-time, at the moment of receipt in the mailbox. [24:00] That gives us the ability to modify that message, or move it, or take action without delaying delivery, or potentially slowing the receipt of a critical message by an end user. But it also gives us a very different ability to modify a message, post [fact it?].
Classic example of this, we had a customer who received a message a few months ago, it was actually a campaign [above 40?], impersonating Docusign, a common business document signing technology. That message reached a group of executives, and at the time that it was delivered, the Docusign impersonation went to Docusign, it went to a redirect. And so anyone clicking on the links in that would have gone to Docusign, it would have looked fine. But two hours later, the attackers weaponized the page they had put up that had the redirect, and instead of redirecting to Docusign, it delivered malware, a piece of ransomeware called [Lucky?]. No SEG in the world could do anything about that. They already analyzed and delivered the message. But because we’re post-delivery, GreatHorn still had access to that mail, and could modify it or remove it after the fact.
C: Great, thank you. In fact, we have a follow-up question to that. Can you expand a little bit on that post-delivery aspect of things? How are you able to do that?
KO: So again, a lot of the technical infrastructure and groundwork here comes down to utilizing cloud-native approaches, versus utilizing mail redirection approaches. By having API access into a mailbox that is the actual data set of all of the folders that you see, and the email you receive when you look at your iPhone or your Outlook client, GreatHorn can retroactively modify anything within the mailbox, or it can remove things or modify them at the moment of delivery, after conducting the analysis that we do, and we’re not stuck doing it only in a perimeter security model. So, the answer there is really, it’s API-driven, and there are technical standards like oAuth that allow third-party services like GreatHorn to operate in that fashion across your domain.
C: Thank you. Next question, does GreatHorn solve for other threat types? So, beyond spear phishing, for example, malicious links, attachments.
KO: Good question. There are really a trifecta of issues that lead to most phishing and email-related threats today. Business email compromise is the most insidious. Organizations that fall victim to a business email compromise attack typically see it happen based on someone sending a message that impersonates a CEO or a CFO, and that was the first thing GreatHorn was designed to protect, in fact, much of our patented infrastructure and the things that we did first in market were around stopping those impersonation schemes. But, the other two halves of that problem are the file-based attachment, [27:00] where somebody will send a piece of malware like we discussed a moment ago, or a malicious URL that impersonates a well-known site or service, and trick someone into logging into a fake Dropbox or Google account, for example, and really stealing credentials. We protect against both of these attacks in addition to a targeted spear phishing attack or a business email compromise attack. Our technology has the ability to do link sandboxing, where we can rewrite URLs, and ensure that you have the time-of-click, as well as retroactive protection, from a malicious URL or known phishing site, and we can also quarantine, analyze, and hang off of indicators of compromise that have all been real-time, for any file-based attacks.
C: A little bit of a different direction here, you touched on email authentication earlier in the presentation. Where do [OP?] frameworks like SPF, DKIM and DMARC fit into all this? Do they help solve the problem?
KO: They do. So, email authentication is largely about preventing the impersonation of your brand. An organization that implements SPF, DKIM and DMARC will ensure that someone cannot literally say that they are sending from your company. This is most important for large organizations that have a public presence. Classic example here is your mortgage company. Imagine that your mortgage was held by Bank of America. Bank of America uses technology like DMARC to ensure that you don’t receive a message that comes from [email protected] that’s really an attacker. That attacker would have to do a more sophisticated form of impersonation to trick you. However, the typical attack that an organization receives as a phishing attempt is an impersonation that uses some other technique, like a lookalike domain where it’s Bank of America with an “L” instead of an “I”, or it’s a Gmail account that claims to be from the name of the CEO, [29:00] that is not obvious to the end user. So, SPF, DKIM and DMARC mail authentication, although a vital component of email architecture and security, do not protect against the kinds of phishing attempts that result in large data breaches.
C: Great, thank you. Unfortunately, we’re right at the end of our time for today, so we’re going to have to wrap up. Thank you to everyone who joined us for this session. We’ll send out a recording of the webinar later on today, and if you have any questions that weren’t answered, please don’t hesitate to send us an email, we’d be happy to discuss further, and in addition, we invite everyone on the line to try out GreatHorn in your own email environment, because of the cloud-native component, which Kevin spent some time talking about, we can deploy in just a few minutes, so it’s really easy to [spin up a trial?]. If you’re interested, please drop us a note, and we’ll work out next steps.
KO: Great. Thanks so much, everyone.
C: Thank you.
–END OF AUDIO FILE–
