Technical Deep-Dive: Proofpoint

[Music]

[Music] so when we're thinking about um about identical uh identity deception this is uh this is a very uh well-known um and a very challenging uh problem to solve so identity deception is really when somebody is uh somebody is impersonating someone else now when i'm taking this to um when i'm taking this to the area of um of supply chain attack there are two um uh two points to focus on first point is i am a supplier that i'm being impersonated so as a supplier how do i protect my clients so they keep doing business with me maybe to stay compliant as a supplier how do i protect my clients from me being impersonated the second side of maybe the same coin

is if i'm a customer working with suppliers how do i make sure that first my suppliers do whatever they need to do to to protect themselves and protect me and also how do i tell apart legitimate suppliers from illegitimate suppliers for somebody who's um who is impersonating my supplies and i'll give a simple example i'll um i like use uh using proofpoint as an example let's say proofpoint is offering a uh a service that is essentially cloud-based service right say we uh we do email security it is a cloud-based email security therefore we have cloud services that we're using and we building our email inspection on top of this cloud services and then this email inspection this is a

product that we sell to our customers so in this scenario the cloud provider is our supplier we are the supplier of of our clients so being proof point we want to make sure that first we protect it against our supplier and i'll show you uh i'll show you why this is important just uh in a few minutes we want to make sure that our suppliers are not being impersonated and we're not getting fake invoices that we are expected to pay and being supplier by ourselves we want to make sure that we are not being impersonated and our customers are not being fake invoices so really how do we how do we do it and the way

the easiest way to do it or the easiest way to look at this is to start with um to start with authentication right it's all uh identity deception is really a problem of uh of authentication and problem of preventing uh identity section fraud when we're coming to um when we're coming to email how do we when we're receiving an email how do we actually know which email is legitimate versus versus not legitimate which email actually came from our supplier and something that came from uh from someone who's impersonating our supplier it all starts with uh dmarc authentication so uh and dmarc for those of you who don't know dmarc has uh really two parts first

part is spf um which really says who's allowed who is uh who's allowed to send on my behalf so just list of domains or ip addresses for every domain listed in our dns and it lists everyone who is um who's supposed to be sending on our behalf so maybe service now or my work day or microsoft or sharepoint online all of these are legitimate our legitimate uh suppliers so we would like to all partners and they sending on our behalf so we would like to list them in our spf record if servicenow is sending an email uh on proofpoint behalf for example we would like them to uh to be listed in our spf records so

the recipient part knows what to do with this emails when they arrive how to process these emails the other side is the the next step in this domain authentication journey is how do we sign our messages so to authenticate it's spf is not perfect if it wasn't perfect our life would be so much easier but the next step is simply using encryption to with what's called dkim i don't i don't really want to go um too deep into how dkim and how spf work but we just need to know that uh they both work together to indicate to the recipient part if the email sender is legitimate if he is authenticated and he if he is authorized

to send emails on behalf of a company now this is this is a very interesting part while doing this one other thing that we want to focus on is really to deliver our email to deliver our to to to conduct our business and to deliver our email so when we're thinking about email authentication it's kind of um it's it's a little tricky to work on email authentication and to complete email authentication in few easy steps as we all wanted to do because our senders have multiple ip addresses they can send from multiple domains and this is all before we even starting to talk about uh about the cloud so i want to show you what it would look

like if we use a system that we can we call it supplier risk explorer and um this system is learning the behavior of um based on email trunk email messages it learns the behavior of of your partners or it learns from the email traffic it learns to identify who your suppliers are and um and it looks something um it looks like something like what you see in um in a screenshot right now so this supplier service now has been identified as a supplier of proof of proof point and not just that the system looks at um at the risk that is associated with the supplier and

the risk means how many messages we can see how many messages we see here versus how many messages are malicious so you can see here um you can see here that malicious messages we have 378 000 messages and one of them was malicious so that's first data point how many malicious messages did we see out of uh messages all together the second data point is uh what this domain does let me uh let me pull up some [Music] uh demo here so you can see what would it look like so this is uh this is a supplier from a demo account i can see i can look at uh at the domain that's sending these emails and this is

just uh sample data i have zero threads there is one message that is coming to my domain and the sender is classified as high risk high risk means couple of things first because we are processing a large volume of emails high risk in this case means what is my demark policy am i asking so if i'm looking at microsoft for example microsoft is saying to everyone who receives an email from from microsoft to validate the signature of the email to validate spf to validate dkim and if it is not if it's failing dmarc validation to reject the message whatever the recipient gateway will do it is uh it is really up to the recipient gateway

but microsoft is instructing everyone who receives an email to reject the messages if they fail in dmarc this company doesn't even have a dmarc policy which means that recipient gateways will not uh will not be able to follow the instructions of the sender saying what should i do with this message if the message is if i can't authenticate the message if the message is failing authentication what should be my next step should i reject it should i quarantine it or maybe simply just ignore it and keep monitoring it so that is first thing second thing that we're looking at is how much threats we actually seeing from this uh threat actor or from this um from this domain

again this being a a demo system the number of threads is is obviously zero but for each one of them what we can do is to look how many phishing emails we have seen from this domain how many imposter or bec emails that we've received from this domain malware emails or spam emails not only that we can click on each one of them and go to the email itself to see the attributes of the email to see the indicators of compromise forensics that we have extracted everything is there and again i want to kind of pause here for a second and explain how this information is collected this information is collected because we processing a company's email

and inspecting every single email that gets in and gets out as a result we are aggregating this information we're collecting this information analyzing it and cross-referencing this information for every attack cross-referencing it with what we've seen um in other environments with other customers so phishing imposter malware as you can see in this uh in this particular case we've seen four phishing messages or four proof point customers being fished from this very domain we've seen two pro improvement customers receiving malware from this domain so therefore this domain is classified as as risky now there are two ways of mark the domain as a supplier we can manually up the domain as a supplier or our ai will

learn that the domain is a supplier or as we call it discover it based on analysis of incoming and outgoing emails to and that that are passing through gateways we can take a look at um at the domain itself that is uh sending emails and if there is more than one domain they will all appear here and what's more important is that we have actually a list of look-alike domains so imagine that and i've and i've seen it more than once with unfortunately with customers uh when they have the abc domain somebody if this domain is uh if the company is large enough and interesting enough for the attackers to to try and defraud then somebody will create

a domain abc dash customer service or abc suppliers or other domains that will suggest that this is um in our case is a wz uh these vzw um and you can see corp.com corporate cam news all of this is just a way to uh impersonate domains and make sure that when email is sent now when i have this domain registered my dmarc is completely useless because my dmarc is only going to look at vzw vzw.com and from the demons the dmacc standpoint vzw corp.com is a completely different domain it has nothing to do with vcw.com and i can tell you more that impersonating domains are often passing dmarc authentication because it's very easy to set up a domain to set

up dmarc authentication and start authenticating your emails saying yeah that's supposed to send on behalf of my domain now when users getting emails from look-alike domains they not necessarily they will not necessarily realize that this is a look-alike domain that it is just trying to impersonate the main domain and here we are um at the core looking at the core of a supplier impersonation that happens over email suppliers are being impersonated by using the same services the imposter uses the same services let's say an imposter uses office 365 um and sends an email using office 365 based on uh on the reconnaissance that has been performed so the imposter is using the same cloud services

that have been already um listed in maybe in the spf record right if i'm listing outlook.com everyone from outlook.com can send an email on my behalf so that's one second the imposter is setting up a completely new domain that will not get blocked that will not be even monitored for that part but will look almost identical or very similar to the domain attackers trying to impersonate the users on the other hand or customers of this domain will see it as a legitimate domain in this case is vzw.com and they will engage with the email this is if you're looking at a business email compromise this is how a vast majority of bc attacks are happening somebody is impersonating a

domain somebody with an impersonated domain impersonating a supplier and from from there there are actually a couple of actions attackers can take one of the actions being well let's just simply ask for an invoice or to pay our invoice or update our banking information this stuff is um is is happening you this is something that gets the news the higher the amount the more the more noise it makes but there is also other ways of doing it or other ways this could be harmful sharing a document or sharing an update with someone and when it looks when it impersonates the real domain is going to get users credentials compromised without them knowing it and without the security folks knowing it

because when a url comes we're all using uh cloud services today right when a url comes from sharepoint or from google drive or from excel online a lot of users will look at the domain well this domain has has a little padlock here well it's secure oh yes it does have a certificate it looks like domain i am working with again yes uh so a lot of users will not even think twice they will simply click for an update sales quote notes i mean whatever the attacker is uh whatever game the attacker is playing and once they're clicking on it they're giving up their credentials to login to get the document and you have another way

of you have another way of getting uh getting compromised by compromising your credentials so this is just one side of things so how do we protect ourselves from this scenario from our uh supplier being impersonated and actually getting to our business and and the way to protect it really there are a few steps to protect it not everything is not everything is something that we can necessarily do uh internally one thing that is very helpful is when we're looking at data like this when we're looking at something that says well there's no dmarc policy normally this is a conversation that we're having with um with security teams and this conversation goes to okay we need to stop talking to

technical people we need to start talking to our procurement or purchasing department because our technical people can implement technical controls our procurement however is responsible for managing or supplier supplier management is responsible for management managing suppliers with this information we can go to and we have done this this was um this was very interesting when we started uh having this conversation so procurement would reach out to uh to the suppliers and say you have to protect yourself and you have to protect us by not protecting yourself by not authenticating your email traffic you actually putting us at risk and you're putting yourself at risk and some of the companies we work with have started to work on amending the

purchasing contracts to make sure dmarc policy is implemented even if it's not rejecting right away at least implemented in quarantine mode or in non-mode there is a process around around email authentication so that's that's first obviously uh having an email gateway that is filtering traffic and inspecting um business email compromise traffic is is critical um [Music] because it will uh it will make sure that emails that are um that have the signs of impersonation of business email compromise will get stopped at the gateway and will not deliver to the users so that's uh that's the second part what we do what do we do with this this is a problem and this problem is completely outside of the email world

look-alike domains are when somebody is sending an email from a look-alike domain even if our organization has a email gateway it doesn't pass through the email giveaway it is a third party sending to a third party impersonating you as an organization so what we came up with to kind of deal with it for every domain that we're working on we are looking for look-alike domains so like here we can see a list of look-alike domains and then again it goes back to the conversation with the same supplier hey you are putting us at risk you have few look-alike domains that were spotted in the internet another thing that we do with this system and by

the way it's called email fraud defense this is all part of e-mail frog defense another thing we can do we can look who's impersonating us as a proof point corporation who's impersonating proof point and might be reaching out to our suppliers we do have a takedown virtual takedown service so if someone is um impersonating uh impersonating us or one of our clients our virtual takedowns uh take down process or take down system can take down a domain key and it can can blacklist an ip address or change the reputation of an ip address with browsers and with major reputation repositories so that is how we prevent inbound emails or inbound bec now let's let's talk a little bit about

um about the other side of things we we just talked about how do we prevent an incoming what do we do to make sure all our traffic is properly authenticating how do we and when i'm saying all our traffic i um i'm not necessarily i don't necessarily mean um standard emails or emails that are sent as as marketing because those emails are uh sent by third parties and they not necessarily um something that we even have uh control over right if we're sending something through uh sendgrid but what about emails that we send using cloud applications what about emails that we send using um using a software that we're on in in-house so for this purpose and again this is

all our emails this is legitimate emails that are just getting sent using uh using different methods um and this is all the senders that we can use again in in today's world when we're using cloud pretty much for um for everything starting from our email communications our crm communications um cloud-based communication still says that it is coming from our company so what do we do to make sure those emails the emails that are legitimate are getting to our customers because the other side of email delivery problem is actually deliverability we want the emails to get to our customers but we want to filter out bad emails emails that are that are impersonating us now the way

we are dealing with it um actually two ways sorry first way you remember i talked about um spf center policy framework and the first step in this journey is simply to hide your spf record we have this ability to host all your spf record for you that way attackers will not be able to see that oh he allows or they allow oracle and salesforce to send on their behalf the only record that is going to be here is proof point and we will manage like in a in a in a reverse proxy way we will manage all the records for you and we will show you and we will show only one record in your uh spf dns

record so that's first step second step is actually to create a system we call it a secure email relay and this is a cloud-based system that takes all the senders pushes them through one cloud sender which is secure email really makes the authentication when the authentication really happens it adds spf it is passing spf it will pass dmarc it will come from the company.com from your company and it will uh get to your closet clients partners and employees as authenticated message that means that if your partners are enforcing dmarc reject uh or inbound dmarc reject and your domain is um advertising or publishing the microreject policy this will help to make sure that imposters are kept out

and legitimate users are legitimate senders are delivering your email again if we're looking at um if we're looking at the um at a service now again as as an example um servicenow will send all emails to secure email relay this email will get authorized and it will get sent on behalf of your company same goes with internal applications so some internal application will leverage google cloud or send grid this all can be simply done by uh secure email relay and again the advantage is um [Music] the advantage is that these emails will get authenticated and you can start a dmarc reject policy and your customers can start enforcing uh inbound demarc uh reject i want to show you quickly how it works

graphically what actually happens but i maybe want to stop here and see and see if there are any questions

okay so all together uh we have a uh we have a way or applications or devices simply sending smtp traffic and passing through proofpoint system to get dkim signed to get dickham uh signing to evaluate for uh malware for spam and um at the end of the day they are uh being relayed back to the internet that's you know that that isn't an actual easiest way to look at this all of this um how they open ldap communicates with the sender and and uses email relay api this is um this is maybe important but this is not really uh critical the critical part is when email comes in we sign it uh we deconsign it evaluate it for not

being spam or malware and then we relay it uh to the world when it's completely authenticated and making sure that your um your dmarc reject policy is effective okay so one last thing i wanted to share with you is this link that points to proofpoint um dmarc spf creation wizard or validation tool so you can look at your domain you can see where your domain is with regards to the dmarc journey and actually let me show you

let me show you what it looks like so this will this tool that i've just shared will pull the dmarc record and we'll tell you from proofpoint.com so first we're using dmarc version one which is standard our policy is reject and here's where we are sending um aggregation reports and forensic reports this is really all your dmarc record needs to show where to send the reports and what to do with messages that are failing authentication if you want to learn more about different tags and different options with the dmarc you have them here [Music] percentage of the policy you have them you have all the explanations uh here with um with explicit tags and implicit tags you

can you can review it and again you can generate your own uh dmarc record create the using the wizard or you can check your spf

do you have to something to validate logos if they are legitimate that's actually a very interesting question um so yes the logo validation or bimi is is more or less uh built in in today's email infrastructure the only thing it requires um is for your dmarc policy to be either on reject or on quarantine once your dmarc policy is on reject or quarantine then your um your emails that are getting sent out will get sent out with the logo and obviously this will from the marketing and branding standpoint this is um uh this is a big deal but also from uh from the impersonation or identity deception standpoint this is also a big deal because if you

able to show your logo then users will learn that you know they will learn to tell your emails from the emails um that are impersonating your organization thank you for that question i want to thank everyone uh for attending the session and enjoy the rest of your day