← All talks

Guardians of the Logs: Monitoring SaaS with the Event Maturity Matrix

BSides KC · 202343:3956 viewsPublished 2023-10Watch on YouTube ↗
Speakers
Tags
Mentioned in this talk
About this talk
SaaS applications have become critical infrastructure for enterprises, yet security monitoring lacks standardized guidance on audit logging capabilities across vendors. This talk introduces the Event Maturity Matrix, an open-source knowledge base mapping SaaS audit log event types, sources, and field-level data availability. Through three attack scenarios, the speakers demonstrate how to use the matrix for incident response, threat detection, and compliance validation across platforms like Salesforce and GitHub.
Show original YouTube description
SaaS has been described as the operating system of business. Therefore it’s essential to protect the sensitive data that is stored and processed in SaaS systems by monitoring for any anomalous or malicious activity. Traditional security monitoring focuses heavily on endpoint, network, and infrastructure audit logs, with a vast amount of resources available to guide network defense priorities. However, network defenders must now shift their focus to also include monitoring for tens to hundreds of SaaS applications, each with its own unique challenges and nuances involving collection, schema, and visibility, without established standards or resources to guide the way. This problem led to the creation of the Event Maturity Matrix: a comprehensive knowledge base dedicated to SaaS application audit logging. Its purpose is to serve as a fundamental resource for security professionals to gain a clear understanding of the capabilities and nuances surrounding SaaS audit logging. By leveraging this knowledge base, security practitioners can obtain visibility into the types of user activity actions that are logged, see real-world examples of how SaaS applications log user activity, and use these insights to inform their security operations and compliance objectives. When threat hunting, researching a detection hypothesis, or responding to a security incident for a specific SaaS application, have you ever asked yourself any of these questions as a Security Operations practitioner? What applications do we suspect that a compromised user accessed? Are we collecting events from these applications? If not, what are the requirements for event collection? - What log sources should I prioritize? What activities do these applications log? How much context or metadata is available within the audit logs? Are there other log sources from that application that we should be analyzing? These questions led to the conception of the Event Maturity Matrix, and wanting to build a knowledge base to help security teams quickly understand the monitoring and visibility capabilities of SaaS products and services. During this talk we will showcase Event Maturity Matrix, the different components as well as how to utilize it within your environment. To do so, we will discuss 3 different attack use cases targeting SaaS, reviewing the TTPs utilized and audit logs generated from each SaaS platform. By discussing the adversary’s objective, techniques utilized, and how each action is manifested in SaaS audit logging, we’ll highlight the challenges and opportunities that exist with modern SaaS audit logging and how the Event Maturity Matrix can be utilized to support security operations. Finally, we will spend the remaining time highlighting the newly released Event Maturity Matrix knowledge base website, quickly demoing the layout which includes: Per SaaS vendor documentation for audit logs, including links to API and schema documentation A thorough overview regarding the accessibility of vendor audit logs, including cost/licensing, latency, and vendor hosted retention considerations A description of observations of vendor audit logs, including complexities or nuances that exist with analysis or audit log collection A heat map matrix of how SaaS audit log event sources align with basic audit log event types that are often required by Security Operation teams, including providing real world examples of sample events. For example: Successful and failed authentication events Successful and failed MFA verification events Modifying a user account or security role Modifying a user’s MFA enrollment settings Modifying a global security configuration, such as a Password Policy Downloading a Resource such as a File or Report Lastly, the concluding remarks will lay out the next steps for the Event Maturity Matrix, including the addition of more SaaS applications and encouraging community feedback via Github.
Show transcript [en]

all right um we're going to talk today about our well thank you for coming I really appreciate it um yeah I've been here I think every year or at least the last several years here presenting about random stuff but today we're going to talk about Guardians of the logs uh we're going to be introducing a new product uh new open source tool called the event maturity Matrix we'll tell you what that means here in more detail am I going to do all right just making sure it's working uh my name is Josh Rickard I go by Ms administrator on Twitter GitHub you know all that stuff uh I am a senior software engineer currently at app Omni where I work on

their threat detection Pipeline and product um where we process like billions and billions of in a day um okay I'm Paul I'm not David uh I do threat detection what threat detection add up Omni um but actually we do owe a lot to to David he did a lot of these slides and uh he was supposed to be here but he had a scheduling conflict so I'm Paul not David all right so do you use SAS applications there's only one of you come on all right I thought I was going to have to like skip past this slide but maybe I just need to like stand there now all of you are liars I know that every

single one of you uses this s app in in your life you have a smartphone unless you're like weird and you have like one of those you can only call phones whatever the hell that's called um what's it yeah yeah well kind yeah there's like a anyways there that's probably probably a sess um but yeah some stats uh so pretty much everyone's using stats um maybe we have have the few outliers in this room but uh most Enterprises are using 130 or more on average um which is 85% of their overall software usage so most apps are SAS not even sure I'm not even sure what's still on Prem but there must be something um and it's a $200 billion

Market uh by the end of the year so lots of sass lots of money um some pros and cons we sort of have this laid out so it's like what are the benefits of SAS why are people using it and then what does that mean from a security perspective so like how has this sort of changed the landscape of uh what you have to monitor and why so um the first is rapid deployment uh you can sign up for uh sasap you know Salesforce Microsoft Etc just by filling out a form I'm sure you know this um and of course that means people in your organization are doing the same thing so you Pro like

unless you're using some sort of like SAS Discovery and even still maybe then uh there's SAS apps that you don't know about there's data in places that you don't know about um and then related to that is sort of accessibility so once it's up and running it's easy to get to it's easy for you to get to it's easy for anyone else to get to um so obviously that's that's a benefit and it's a drawback so it it sort of it moves the traditional sort of monitoring boundary out to all those devices your phones your browsers uh whatever your Western Union um and with that it's sort of um it's difficult sort of to keep track of

who has access so you know if if you're integrated with an identity provider maybe it's a little bit easier but if you're not then you're sort of provisioning users you're responsible for de-provisioning and it's just sort of hard to keep track of all that uh and then integration so this is like you know if you think of on Prem if you wanted to sort of move data between applications you were responsible for export in it from one place importing it to the next or build pipelines and all that fun stuff um now there's pretty powerful Integrations between a lot of applications so it's as easy as just sort of point and click Connect app X to

X to Y and the data just sort of moves around and uh the drawbacks there are kind of obvious but but also you know um there's the permission perspective like you have to know what are the permissions that an application should have um you know to to sort of understand what your scope should and shouldn't look like and that's not always so easy also origin sort of like do you trust where your apps are coming from how do you validate that um how do you make sure that those like Supply chains are are are safe couple more um customization is an obvious one if you've used any of these platforms like you can you can build

powerful business logic applications you can also build totally crazy things um I'm sure we've all seen like security platforms built on top of SAS I've worked on teams that used uh a CRM for incident response and things like that so there's all sorts of crazy things you can build which means that it's really hard to know like what does a safe build look like what is a safe configuration and then how do I know when I've deviated from that uh and it's sort of a a continuous sort of evolving picture of like how should things work and how are they actually working and then related to that is just the the data picture of you know with with all

these things uh comes the the data that you're using for your business processes so really easy to get data in really easy to get data out and then what we're highlighting and what we're going to talk more about is like where can you monitor those processes how do you actually know when someone's putting data in what does it look like when someone downloads all the data um what does it look like when people modify data and things like that yeah so and does this look familiar to anybody has anyone ever seen this this is a shared responsibility model has anyone heard heard of that okay so the shared responsibility model if you're not familiar is

that on premise type uh infrastructure you know you had to worry about you had to worry about the physical you know data center uh actually purchasing Hardware networking all the different layers of um you know software and how it works so you have all the on premise and from a user perspective you're always kind of responsible for a the data but then also the underlying infrastructure as we've kind of moved away from a data center to more uh I or infrastructure as a service um you know you take away some of that with the physical security and the host and the infrastructure but uh you still are responsible for the operating system still having gold image Imes um so

making sure that they're patched so on and so forth It's all still your responsibility the opposite is now Amazon or Azure or wherever then you move into the SAS world right and this is pretty self-explanatory but you don't have to we've kind of extracted away the operating system and the patching and and all the other components but there's still ones that we're trying to make aware that that if you're not doing you must be doing is still protecting your data in those SAS applic um anyone here uh monitor all their SAS applications and all activity all right well this is a kind of called to action let's just say you need to go and start doing that now uh

it's not going away you know obvious obviously Paul you mentioned um what is it 130 plus different apps I don't know how many um you all have in your environment but I know that there's uh quite a bit and they continue to grow so with that shared responsibility model you know we weren't really um we didn't really care too much uh we cared about the data but it wasn't like a huge concern and a lot of people I think now just don't worry about that when it comes to SAS apps like authorizations taking care of by OCTA wherever your IDP is um and that's pretty much the extent of it but there's a lot of data in there

and it's being used in a lot of unique ways and we need to keep track of it and protect it so a long time ago again we didn't we didn't really care when you had on premise apps uh we had some logging maybe you know IIs or whatever kind of web server logging you might have a proxy logging you know things like that but in SAS world you don't really have that so um really we just nothing's really changed uh that much and you can kind of see that and got to love memes right oh like they're literally laughing at you uh so no for real though like with SAS applications and and monitoring we need to actually start detecting

threats in those environments because that's where everything is living from now on so challenges right from a security perspective who anyone here do detection engineering or that's part of their role thread hunting or anything like that all right well um woohoo the standards right there's lack of Standards when it comes to to security monitoring especially in SAS uh all those products are completely different and one of the biggest concerns from like a detection engineering or just security operations perspective is the lack of that schema or that standardization across it so on top of that we have the collection the difficulties um not all these products are the exact same they all have different methods and some have many

different methods we'll share some horror stories here in a minute but uh overall um it's it's a huge concern when it comes to collection and how do you collect when do you collect what is that duration um all the other kind of intricacies around that then visibility again a lot of these SAS audit log providers or service providers don't really offer up those logs or don't advertise them and we're going to show you how you can um well you can use this new framework to kind of build up your detection and response especially when it comes to SAS applications and just cloud in general okay cool yes so we have some uh some horror stories or some examples we

didn't put any names on these um maybe you've seen some of them maybe not um the first one is an application um generates audit logs it generates login logs but the the MFA events are sort of stored on like a web report um that you can only access from the application I've actually seen this in a couple places where like the applications were built for the purposes of like generating an audit Trail and then like the security stuff is just like it's available uh as a web report but there's no easy way to get to it um another fun fact about this one is that all the events are logged in CST and that's that's specifically CST it

doesn't change for daylight savings has anyone seen that okay interesting that's kind of an obscure one but future in the future yeah we talk a little bit about about timing too on the next slide um app this is kind of common too like so they they have a standard audit log but there's no authentication events in it I already sort of talked about that but it's a it's a common sort of pattern where the apps are built as sort of like an a user audit Trail without a focus on security security stuff is bolted on afterwards but like maybe not so easy to get to um this is a really common uh app you've probably seen this one there's

there's good logging but for some reason they don't include IP addresses you have to sort of log in and turn that on um uh yeah so these are sort of patterns that we've seen across a few different ones um sure you've seen it too different licensing tiers so there's like a there's a standard audit log that maybe has like logins or or something and then if you want more you have to pay extra um which is like maybe part of the like SSO Security tax or maybe not maybe like a different service um there's there's plenty of apps that sort of don't provide IP addresses across the different event types that they log so you'll have a a

login event and that will have an IP address but then later on the user is doing some things they're updating objects they're downloading Etc and there's no IP address on those logs and there's no session ID so the only really way to Corel relate that data is to look at like time stamps and usernames and that that type of thing um and then yeah the timing one so this is again pretty common you know there's significant latency sometimes in how logs are delivered by Design you know they'll they'll document that to say like don't expect these logs for for up to 12 hours um and then there's other services that make no guarantee regarding you know

like no sort of SLA so the logs are eventually consistent we'll eventually send them to you but every time you pull you're going to have to dup to figure out what you may have missed um so this is just a picture of some some notable sort of breaches from the past couple years it's definitely not all of them I think um you know the points worth calling out are just going back to that 85% number so if you realize that 85% of the software used within Enterprises which I think is pretty accurate or roughly accurate you know you you'd have a hard time finding a breach that at this point that doesn't include a SAS app especially if you're

including like identity providers um so there's been a lot recently I think the the other thing worth calling out too is that like sometimes it's not so obvious like the the big platforms get called out a lot Microsoft Google there's been a lot even in the past couple months but sometimes you'll be reading a a report and it'll just say like you know customer contact information was was lost and where's that coming from it's probably either like a support titing system or CRM or something like that yep some headlines I'm sure you've seen them okay so sort of recapping the the history um and the sort of high level problem basically just you know SAS is

everywhere um it's over overall good for business but brings a lot of different sort of security challenges that that maybe teams have to adapt to um governance is is very different um or maybe not different but more important right since we talked about how accessible rapid deployment that type of thing it's it's more important to sort of monitor these things um you know audit logging is sort of a mixed bag you don't know what to expect you don't know when an app is going to generate a log and you don't know what that log is going to look like and and how to get it so um and then the last piece is is sort

of obvious comes with the comes with a big picture which is just that you know SAS breaches are only going to be more common um that's it really I mean there's so much data in there and everyone's using them and so you can expect to see more and more I love this meme why shouldn't we have another security Matrix right well um I'd like to introduce the you know because of these problems that that Paul is talking about right with with again the the prevalence uh of SAS just growing in environment we're trying to a raise kind of awareness of hey you need to be monitoring this stuff because there's a lot of uh a lot of data that uh

organizations are moving around and there's a lot of Integrations there a lot of third party and you don't know what's happening to that data and if you're not monitoring this uh environment um well yeah you should so that that's kind of the the big point but let's introduce SAS a vent security or sorry event maturity Matrix jeez messed that up so this is really a a website when we'll show you and we'll kind of go through and break down all the different components and and all the data points that we we'll show you but SAS event security Matrix or the event maturity Matrix is basically a knowledge base of a centralized documentation as well as the

nuances and it kind of explains the nuances of uh different audit logs from different products into a normalized and standard way um we provide examples and we also again that visibility mapping and we'll we'll kind of walk through and show you what those mean but but really it's a uh service or or um a framework that we can kind of expand and kind of normalize these events across different products in SAS environments within uh that that are applicable to security operations so let's talk about it centralized documentation so we'll I'll have the Links at the end but if you actually wanted to you could now it's event maturity matrix.com and it is a web app that has this data driven uh

definition framework so but it but really it's all about having current up-to-date information about these different uh audit events in a centralized place as well as explaining the nuances of how the API Works um maybe there's some uh problems with the collection and we've kind of noted that from our experience and other people's experience um we also have licensing right again some of these horror stories that Paul is talking about they they uh these vendors charge for certain audit logging features and uh so how do you protect you know against a product that you they don't you have to pay for more logging to get basic logging um and then you have latency and retention right it

all matters for for live detection uh if their latency is a day uh doesn't really help you much but um so it it kind of gives it in the centralized place where it's all organized and Visually well visually appealing and easy to to digest we also again that visibility mapping um one of the coolest things I think is that we've taken a lot of these events and normalized them to uh Central core um event types and categories so category is going to be and we'll show you examples and go through demos but let's say authorization or authentication all those are different kind of buckets of events and then we also have the normalized event types

that we have mapped uh different products to there's also the supported and unsupported uh this both is this is both the activity but it's also even down to the field level meaning um you know you receive uh let's say a log event that's in Json we go down to the actual field level in that response uh and map and show what data is available in that log and what is not available in that log um for instance if an IP address is in that log or not and then again we provide also these real world examples every single event uh mapped to event maturity Matrix it has provided examples at least one possibly multiple just depends on the

service U so the one of uh the great examples is let's say Authentication and you have um you know when you create a user creating a guest user versus creating an admin user completely different logs and completely different views of how you could respond to that event all right so we've talked about you know the kind of the history and we've talked about the basics of event maturity Matrix but we wanted to kind of showcase some of the scenarios or or different situations that this would be beneficial right incident response when you're in an incident do you want to be reading documentation probably not you don't want to be digging around going behind pay walls all this other stuff so we

wanted to provide a centralized place again that that you can view this in a very easily consumable and digestible way to speed up that that process we've also you know with uh the threat detection in general how are you monitoring how can you collect this data where do you collect it what is the format uh and then all the other kind of details around that event and uh We've also have you know compliance right now you can visually see um if you're providing the data that that is needed for some compliance um that I'm I'm not a compliance guy so um you know requirements that that are that need to be met and then obviously the SAS

evaluations um one of the goals we don't have this currently but uh you'll be able to visually compare um or contrast different products against each other so for instance if one product doesn't um log uh basic authentication events um but another one does maybe that's advantageous for your business or for you to go with one product over the other vice versa um and also the unsupported fields and values and all the other kind of intricacies that are that go into the decisions yeah I think that the last example is a really interesting one because like if if you've ever worked in or or just seen the work that like a risk team does in a large Enterprise

like they're constantly being asked to evaluate new applications every business team wants a new app every week and they want like 10 different at least project management tools and so looking to the future I think it could be interesting to sort of look at you know how these applications Implement security and use that as a maybe it's a tie to comp clients to but like you know assessing risk um so uh jumping into sort of the terms that we use and then we'll we'll show you some screenshots after this and then go into the demo but um just wanted to talk talk terms first sasap is a product obviously um an event source is um it's just a log Source right like so

sometimes there's multiple ways to get logs out of an app and we Define those as um as event sources maybe that'll make more sense when you see examples um a category is a contextual grouping of of the the next few objects so like event types live in a category think of a category as like authentication and then event types are like a normalized set of events that we expect to be logged like a user login or MFA verification and then event attributes are the fields that we expect to be present in those logs so these are the screenshots hopefully you can see them but we'll do the demo too um these are the products that are on the site now so if you open

the site this is what you'll see on the left in the red box is all the currently supported products if you click on one of them you'll get the event sources sorry that's kind of hard to read it says GitHub and then the two event sources for GitHub are audit logs and web hook events um next thing we're highlighting here is just the categories so authentication authorization and then the two um system and activity auditing and then the event types underneath that so it's pretty straightforward at this point there's um 34 different event types that we've started with uh you can see like account log in account log out um we'll get into some examples of these as we sort of

walk through and towards the end a quick note on um on event types so the verbs that we're using today at least in the initial 34 set are um so there's two sets there's crud plus download and then ACR um if that doesn't make sense the example sort of highlights why that's important it's imagine you're updating the you have a group of users imagine you're updating the name of it so you're changing it from you know admin users to whatever not admin users um you could call that an update group event now imagine that you're adding a adding a user to that group you could also call that an update group but it doesn't really doesn't

really make sense there's not enough context there so we use crud and then we use ACR the ACR verbs are for updating membership of a group so you're adding to a group or you're changing the membership of a group or a me uh removing from a group uh and then finally if on each box for the event types you see a little uh little box Inside the Box called show attributes and if you click on that you get two things um screenshot on the left shows supported and unsupported Fields um this is cool because you kind of you don't have to remember the schema so you're looking at an event type and all the fields are here and you could see if

they're supported or not if they're present or not so you can you know look at the create user event and see that it has these fields but it doesn't have these ones um and then the other tab there you click over and you can see the example logs um in this case we've got uh two examples so there's a log for when you create a a member account and one for when you create a guest account um it's significant only like when there's slight differences in the formats of the logs we'll try to call that out as two different examples all right so that brings us to our demo all right so I'm gonna have to exit

out of H just I'm going to have to like navigate because my or whatever but like like you said if you go to event maturity matrix.com uh there's a mobile site now but um we'll continually to add more products we have several already in the the uh let's say pipeline whatever um you know but the majority of it is around these and we're not trying to like call out certain products or you know anything like that we don't care about the products it's more of how do we actually log and protect against attacks in these environments and we'll show you some examples here soon but um for the most part we have all these kind

of different products and and event types or event sources so if you're if you're looking here um let's just take a look at like box right um so we'll just look at box and we can click on that of V Source sorry I'm trying to speak into this and navigate but you can actually view the details when you and this is why I wanted to kind of show this demo is you can go in and click on the little informational box and it'll show you details about box and like what the company does and you know if you didn't know but uh we also have like links and references to the documentation types schemas and other uh related information

that are holistic to box um some products if we looked at like Salesforce they have like 50 plus different uh event sources um where box or one drive or whatever has one right or or two um so those nuances matter when it comes because uh it's going to be a little bit more complex in a in a Salesforce environment than it is others so we we have these kind of stream types and if you look like it's all the links I'm not going to go I don't think my internet's on but um additionally with that Event Source you can VI again the individual details we will include any references to like schemas or or data uh formats

and then we also have things like retention detail how long do they keep those logs for and that matters when you're doing when you're sourcing but also the latency uh this one is luckily near real time but some of them are delayed by 12 hours right or by hours just kind of depends on the product um but we kind of call that out as well as other notes and details in the the schema and definitions but we won't go into that that part of it so if we look at you know these authorization and sorry this is kind of zoomed in here but we can see like different authorization points let's say like create rooll obviously this service

doesn't really have that event or event type but these are the normalized event types that we were discussing earlier now when you we look at one that that actually exists wherever that's at let's go to GitHub so um it it's kind of hard to tell on the screen actually but I want to call out that they are different shaded uh you see this is kind of a dark darker blue than the the white doesn't really show up on this monitor but uh they are different colors I promise and so it kind of visually you can quickly see all the different uh events that are supported by that product but you know the differences of okay this one has IP

address and IP geolocation user agent that's great but uh what is the result did a failure happen does it does it tell you any of that information like yeah okay uh someone logged in but was it successful we don't know it's not really logged there so those details kind of matter in in the this event um obviously there's other you know components that you can use but but those differences where we're trying to actually show um and highlight why something like this is definitely needed from an example log um they're they're pretty basic um for for this of course but some of them are massive Json if you're not familiar with Json it doesn't really matter it's a key

and then a value that's all you have to really know all right let's take a look at so we looked at gooda but let's look at like Salesforce right I'm just going to keep scrolling here because there there's like tons of them of these different event sources and each one of them are very specific um so for example this one is I don't even know which one it is but um let's say account login right so account login luckily you know but each uh Event Source is a different API is a different service that you're going to have to collect data from and so each one of those goes into your detection and response uh

processes again we can uh scan scan through and we can actually see you know slack and I'm going to show you another detail where this this one has like a few more links and references but um so default you know retention study or retention for slack is 90 days as well as near real time but it can be um customized so those data points are all kind of in this Central visual um well visibility map that U we call you know event maturity Matrix additionally if you wanted to learn more about like the intricacies of like how it works behind the hood it's actually all uh yaml like definition files uh that's all on the the

repository and we have extensive documentation explaining like how that works under the hood if you wanted to know maybe uh details about a very specific event type uh the description of what it actually means um we have that kind of all documented in in the repository itself oh yeah thank you uh so you can also filter by uh these events s I'm going to go to another one here you can actually just filter all the the entire list by let's say only ones that are supported man yeah so you can actually just filter them out and just get rid of all the ones that you don't care about uh and only f Fus on the ones that you want and

vice versa but it it's a really easy way to kind of visually again compare I think the next step well we'll go into that in in one of the slides all right that's kind of a a brief demo right it's event maturity Matrix we'll share the link at the end but it's event maturity matrix.com um yeah let's take a look at some how do how would you use this you know when would would this come in come in handy so this is anyone does does this look familiar to anybody like these this slide I know I know it might be a little hard to to read but uh this is a typical like chain an attack path whatever kill

chain I don't care what you call it but basically this is bad and so it's bad okay we have Tim over here uh Tim likes to click on things just like most people in the world that's a shame comment the so we you know you have the fishing site they went to the fishing site and they had an adversary in the middle and they have these secrets hacker took over and then persistence and all that we'll go through these and show you um how you can actually detect and it just depends on the product but but that's why we have event maturity Matrix uh here so initial access right uh you have Tim clicked on a link uh went to a

fishing site uh adversary in the middle captured some some credentials or convinced them to share some Secrets whatever the situation is and they now have a valid account in that uh environment okay so credentials MFA code not all products support this uh which is surprisingly shocking especially from someone who is used to like Windows authentication logs and and all the endpoint data that we have uh SAS applications and monitoring that activity is extremely difficult um it's getting better but um you know because of the normalization and and the different event types we have account login as well as MFA verification where you have a chance to actually detect this um threat an an example uh again we have

account login over here where and this is actually from the same product we remove the product name just to kind of compare but um you have an account login okay they have a lot of cool information but all right they have an IP address great but they don't include any of the geolocation information so we now have to enrich that data to make sure that we know what that data is um we we also have uh user agent name great but credential context failure user type all of that critical other information is just missing from from that product so MFA verification they don't support anything at all so if someone changed their MFA token or added a new one

you're not going to detect it at all um so that's the huge contrast and and where we're trying to a bring awareness of this uh but also trying to normalize it in a digestible way again that that makes sense for everybody okay cool yeah so I'll I'll go through the next few slides which is just sort of some things that could happen and some examples of what it would look like uh in the in the Matrix uh sounds weird to call it that actually um so we're in uh we logged in we have an active session to some application um but all we have are username and password so we need some way to to satisfy MFA without constantly

fishing it so maybe we add a new Factor we have the and on the right is just obviously sort of the the different event types that we Define for each step so add enrollment remove enrollment um maybe I just add my own identity provider so I don't have to worry about that um those would be security configuration uh audit activity events so those are crud events um or you know update user at the Top If I'm just changing like an email or password so maybe I go in I just re register my own MFA I've got the username and password and now I can continue to log in um I don't know how readable these are but

these are again just they are examples from from a from one of the the services we just took the name off um update user on the left this is one I don't remember what service it is from now CU I took the name off but like this is what I was talking about earlier where there's no IP address in these logs so like the the login event I'm sure has an IP address but then as you're going down and sort of like now you're updating a user account and now there's no IP address on those there's no session ID so you know in this case where you have like a session hijacking attack uh it's you

know that's kind of unfortunate and then on the right the right screenshot is just an MFA enrollment um these these sometimes look a little bit different depending on um obviously what the service is and what type of enrollment um or what type of factor you're adding I've seen a I've seen a lot of different um examples of logs that we'll try to get in there um OCTA has some really good some really good MFA logs obviously um so the next step is uh I've got persistence I've got my own Factor um configured maybe I want to do some things to uh you know evade defenses try not to get caught um a common one is

just disable auditing logging so we've got a an event there for delete security configuration just be the a crud event or um you know maybe I just register my own integration so I could authenticate as a a service account or something like that um again more example logs over on the the left uh create integration and then over on the right is an update security

configuration and then the final step um you know collect collection and exfiltration so there's a lot that could happen here um a common pattern is just sort of like there there's a lot of ways to get data out of a SAT application um so in this case let's say they just sort of download a report of all your contact information or something um so in in these two events we would have like a read resource and then a download resource um it's kind of generic and it's going to vary across platform so this is where it's kind of important to look at to look at example logs for services and then these are these are

two examples you can you can click around I think it's sort of more more interesting when you're looking at services that you work with uh and you can sort of understand you know where where the important events are so these are kind of just two generic examples of a read resource and a download resource event they're going to they're going to vary widely from service to service sweet so this is the event maturity Matrix right now it's SAS based um we do have plans they're going to maybe look at expanding it or or kind of normalizing even further out but uh the framework is there and you know there's a lot of kind of next steps that we but we wanted to

kind of do this presentation get feedback so on and so forth but the core kind of features or or big pieces that we're going to focus on is you know adding more services of course um we have several already in in line I don't even know how many but several um and we're doing this you again it's all open source all the data is open source uh it's all in a standard um format that that's pretty easy to read I think but um yeah so we're also looking for feedback from but that may be a little difficult for some to get started with but if you're interested let me know and we can become best friends expand on the

intricacies right U add additional details that that matter uh yes we have latency and we have duration but um observations that we've seen issues downtime all those other components are probably and more are going to be added is just kind of to add more more data around it um and we also want to add attack path so one of the visual visualization pieces of it is if you could compare um different attack types uh to different product and service um application SAS applications and U it might take a little little work but um I think we can do it and lots and lots more you know a lot of UI updates and a lot of more uh data components but those

are kind of the core pieces but one of the biggest things we need the feedback we need to make sure that it's you know useful helpful um and one of the big points I guess I wanted to make is that with this um we from a security perspective we we need to defend and we need to monitor this stuff most people are putting it into place and letting it go you know they have too many other worries too many other logs too many other services just on Prem and I get it but from a operational perspective we've seen it everywhere is moving to sass and we don't think that that's going to stop at any point um and is going to continue

to grow so we need to figure out a way how can we detect malicious threats or just anomalous activity in these environments when these services do not provide or do not give a way to actually defend against those type of attacks so it's kind of a call out but but it's also you know we want to help and support you all who are doing this on the dayto day yeah I don't know um sorry Josh I don't know how well we highlighted it but one of the goals one of the big goals is really to to provide like an upto-date reference uh I think there there is some information out there a lot of it's outdated if you ask

like chat GPT about like logs it might give you information like maybe it'll make something up or maybe you'll get information that was accurate a couple years ago so there is a lot of you know there's a lot of rot out there I think in terms of like documentation about this so we do we definitely do appreciate any input I'm sure there's things we got wrong um or that you know is is out of date by the time we committed it up so that's really important important to us I just wanted to point out that chat gbt is always right so this total joke don't if you didn't get the joke I'm not uh serious so event

maturity matrix.com uh please go check it out again they have a mobile we have a mobile site and all the data is there it's freely accessible but if you wanted to you can view the documentation from there but uh if not you just go to our uh GitHub appomni Labs uh and event maturity Matrix is the repository please go check out um let us know the feedback and we hope that you enjoy the event maturity

Matrix