Barracuda sentinel. One of the awesome solutions. I will talk real quick what
Graph is and what the opportunity is and what
Partner that are doing that we haven't seen before. For real quick those who don't
Know having seen and heard. I know i said it a lot, but a
Graph is ball you. We like to think about it it
Starts with slash me, your messages, mail, so on and so
Forth, right. That builds what we think
About for the gateway for the cloud. The gateway for the cloud for
Your data where we build
Whatever app experience you want microsoft 365, win 10 and
A breadth of data you can access and at the bottom
Of that microsoft identity and the work that we are doing to
Pull all of this across the country to allow yourself bold
Really interesting things. And this kind of surfaces as
The opportunity as we like to think about it in this case
Ere we have 59 of fortune 500 companies having data in the graph.
We have 700 million windows 10 devices contributing
At that to graph.
Using ems, so on and to forth. Every microsoft asset and property is generating information fed into the
Graph, and you can now take that as a developer sitting here today and going and
Building on top of that and experience.
I think it is interesting what barracuda sentinel did and say let's take all this
Opportunity that gateway, that data, and how do we infuse
That with ai and do things that we vice president seen
Before. I will let you talk more about
It. >> Thank you. You do hear me?
All right, hi, soil be talking a little bit about our
Integration with graph api to
Build our kind of core product called sentinel. What sentinel is
-- It's a first ai solution for catching spear fishing and other
Malicious e-mail s within our
Customer ten ants.
It connects with the graph. The core functionality around
Graph that we needed was how are we going to monitor every
Incoming e-mail that comes into our customers mailboxes.
To do that, we use the graph api and i will describe that
In more detail and show core examples in the next few
Slides, but what sentinel does is listen
S in on those incoming e-mails. It learns communication patterns.
Uses machine learning to find malicious e-mails.
And it quarantines those e-mails and permanently
Deletes those e-mails base and users' choices.
When we started this, we had a few options that we wanted to
Explore, and they are all based on a single term called
A web hook. For those of how haven't heard
That term, the web hook is a htp callback that you can
Subscribe to and will be notification.
And, for example, the e-mail comes in and we expect to
Receive that web hook notification telling us that
There has been a change in the user's mailbox, and that we
Can now go and retrieve that. So quickly going over the
Three options that we kind of had in front of us when we
Started this was -- so one was let's receive the web hook.
Once we receive the web hook, we need to go and fetch messages and we will maintain
A time stamp when was the last time we did that for that specific mailbox. That was actually the solution
We started with. We were maintaining a time
Stamp per mailbox to do that. The second solution that we
Were considering and that is a classic. I will give more details on
That later on was use that web hook and then use the delta
Query, which means basically kind of doing the same thing
As option one, just without managing anything.
Delta has a token. You do manage -- you save that
Token and up keep making those delta queries and out of every
Request will give you only the last changes that happen since
The last time that you use that.
You use that. Okay.
So i will explain why we didn't go with that solution.
The third option and also the winner is receiving that web
Hook which does contain the message id that was just
Received and go and retrieve that based on the id.
That was the fastest and most reliable method after some
Experimentations, we decided to go with that for our solution.
There is no need to keep any kind of state on that.
You have the message id and you go and retrieve that
Message and process is. The reason we didn't use the
Delta even though a really good candidate because it currently works on top of mail
Folders which moo wean you need to sync the mail folder
Structure and possibly even call delta the same amount of
Mail folders that the user has.
We decided too much of an overhead for us and doesn't
Allow us to achieve the latency that we want.
So a little bit about the architecture how sentinel
Actually does this. So there are three kind of
Main components here. One is the subscription
Management which makes -- which tells graph i want to
Receive web hooks for all of of the mailboxes.
There is the listener's side that receives web hook.
A light server that gets the web hooks and queues them and
The pipeline, which is the big chunk that downloads the
E-mail and processes it and decides what to do.
With a little bit more details and examples, so the
Subscription management part does need to have a mailbox.
There is no way to listen in on the entire tenant with a
Single subscription, what we do is list all the users, the
Git users, the git users call that you see here and we
Create a subscription per mailbox. The next part is listening in
On those web hooks. The web hook payload, you will
See a code example in the next few slides, but it is very --
Very light weight and says respond very quickly to graph
And tell them that knowledge receiving that web hook.
We get that web hook. We cue it on our end and we
Cue is 2 with 200. We have that.
And the pipeline is where all in terms of
Analyzing the e-mail. It downloads the e-mail with
The git message code and does the ai magic on top of that
And decides if this is a malicious e-mail, if this is
Fraud. It will quarantine or delete
It based on customer settings. So with that, let's -- let's
See the really interesting part which is the code.
The first component is subscription management.
Kind of the key thing here to notice is that in order to
Manage the subscriptions, we are going to need to save them
Because we are going to need to renew them periodically
Every -- almost three days. So we do need to be able to -- to keep track of them.
The second part why we need that is we need to be able to
Resolve a subscription into an
Axis token and user. So we are.
Our product used my multiple tenants, different customers
And find that right axis token and mailbox and use that to
Retrieve the message later on. We have the subscription part.
The call is a post to the subscription's end point.
And notification ur l.
This is where the web hooks will be delivered to.
Our web server and should be up and running and to be able
To receive those. The other interesting thing
That you see in the next slide is the client state which is
Kind of a shared secret between us and graph to make
Sure when we are receiving notification, we can safely assume that they are coming
From graph and that nobody else is spoofing them.
So we do save that. This is by code.
Doesn't matter how you save it, but we save those
Notification and there is a renew function as well that
Needs to run periodically before that expires and very
Important because if it expires, there is no way to
Renew it which means have to have some kind of a fall back
And re-create it from scratch. That is the subscription
Management part. You see in the web hooks here
It doesn't have any api calls doesn't work graph.
It receives the payload from graph.
We use no js to be -- nodejs to be.
>> He swivbing with io and get it done as soon as possible.
You can see we do verify that client state that we
Previously defined on the subscription.
We do add some -- some extra data so we can later track
That web hook for analytic purposes. But that's it.
We cue it to some magical service and process it later on.
All this that there is to actually receiving the web
Hooks. And in processing the web
Hooks, that is when we kind of -- we receive that web hook
Payload and we have a subscription id there.
That subscription id needs to be
Resolved into an access token and user id which is what happens because we
Already saved that on our subscription database already
Stores that information. Once we have the token and user and message id, we can
Very reliably retrieve that message from graph.
The graph call is -- you can see that git.
It is a very straightforward git.
We specify the fields. The best practice to specify the fields we are interested
In and in that case we are interested in a lot of the
Data and metadata and the body of the e-mail as well to
Analyze. So we retrieve that.
We do discharge graphs and we do discard e-mails that have
Received longer than an hour ago or so just because we do
Receive web hooks for e-mails that are moved or even drafts that are being saved.
Those are also change notify dhaition we receive, and in
Our case, we are not interested in actually
Processing those e-mails. All right, so that -- those
Are the kinds -- the three main components that i
Described earlier on, and some kind of best practices and
Learningings that we will have a chance to kind of discover
Along the way. So rate limiting is a big one.
We self rate limit to avoid being throttled by api.
It haven't always been on may box level but now it is. I think it allows quite a bit
Of requests per minute and per second
And we have that kind of window on our end and we avoid
-- We avoid the rate limit big graph itself by doing it ourselves.
And working with web hooks, the main kind of learning here is let's do things quickly and
Acknowledge receiving it and let's worry about processing
It later, and this is kind of the component that nodejs
Listener that you saw in the code example.
It just doesn't do any business logic.
Receives the payload and moves on.
Remove the subscription. I mentioned that.
A key point and as far as web hooks go.
Encourage to you check out the docs, web hooks for different
Kind of resources. We do use that for -- for
Syncing users as well because we need to
Sync not only mail but users. A new employee joins the
Company, we are expected to monitor that new mailbox that
Just popped up and that web hook and delta mechanism for
Syncing users and web hooks can be used for other things
On graphs and encourage to you check it out.
And as far as the web hooks in delta go, so we are not using
As i mentioned because of the mail folder limitation.
If you are looking to only sync a specific folder or
Items, that is a great, great thing to do with web hooks and delta.
It's probably the most efficient way to sync and as mentioned you can do that with
Other resources as well. And a few boards how we scaled
This and -- and how do we do it in real time.
The key is to create small components that can be scaled
Separately. Receiving web hooks and
Analyzing e-mails and quarantinequarantining e-mails.
All these pieces are scaled separately with microsoft
Surface architecture and we found that breaking it down is
Actually key if we want to scale it and some kind of --
To wrap it up, some future thoughts.
There is batch that we are not going to be using and
Exploring this opportunity where we maybe will make a single api call to graph and
Receive up to single e-mails at the same time.
For the same axis token or the same tenant and this could
Speed us up a great deal. The web hooks i mentioned for
Users was just announced i think yesterday or two days
Ago that was released version 1 on employee dunks and
Something that we are -- we are you using.
And -- and list subscriptions something that is now in gay
That can be used potentially to debug cases where you may
Not -- you may not be sure if all the different -- if all
The subscriptions are still valid because you do store them, and didn't refresh them
Or renew them on time. So that is something that can be used.
Currently in beta and sounds like an opportunity for future
Exploration and, yep.
That's it. >> Thanks, itay, and the key
Things to remember they started somewhere and they
Went on a journey, right. We on the products side are
Adding more graphs, way more data sets, way more
Capabilities. There is a booth in the back
And listening to a lot the feedback.
A couple teammates that work on it.
Dded subscriptions and.
It doesn't mean we are stopping there.
Some scenarios and we can help companies like. And actually build and grow
Their products and kind of take advantage of ms 365 and
The platform to make things more interesting.
We will have a couple of team members in the back and you
Can find us in the graph booth in the center.