 So, we're talking about security logs, they're not good enough. So, I think you're logging everything important. You've turned on logging in all your critical systems. You've set up a logs management tool. You've created rules to alert you when something's not right. You're totally covered if a customer accuses your employees of looking at user data. Right? Right? Nope. If you're relying solely on security logs to protect your user's data, you almost certainly won't be able to tell what's happened in the event of employee access to employee abuse of user data. Security logs aren't enough to protect your user's or you from malicious activity targeting user data. So, first off, who am I? Why do I think I can talk about user data access logs? My name is Alicia Clark. I'm a privacy TPM at Lyft. Before Lyft, I was a security engineer in privacy at Google. And before that, I worked for Boeing building security systems for government customers. My entire career has been about protecting data. So, now that you know who I am, what's all this about security logs not being good enough to protect your user's data? So let's start with the basics. Why do we log anything at all? Anybody? 6 o'clock PM, I'm totally making this an interactive presentation. You ought to talk to me here. So why do we log stuff? I don't know if it's something untoward. Untoward, something untoward happens? Audit. Audit? Regulations, yep. Developers left it in. Developers left it in. So, accountability. Yeah, generally speaking, what I'm hearing from a lot of you is we want to provide a record of an event. And specifically to aid in future investigations. Broadly speaking, we need to be able, if an investigation is needed, we need to be able to tell what happened. All right. But when I say an event, what does that mean? So I'm assuming y'all being here at DEF CON that you're familiar with security events. But just in case, here's a real quick review. A security event can be broadly defined as an unauthorized access to one or more systems. There's a lot of possible motives for this. Money, by stealing data that can be sold to third parties or just stealing money. Political or ideological motivations that results in vandalization or destruction, fame and fortune by stamping over a customer's company's website with I hacked this. Or even just laying the groundwork for future attacks. So when you're faced with a security event, you need to know three key things. When it happened, where, or on what system it happened, and what exactly happened. Let's say you get an alert that someone tried to log in as root on your system. When you go to investigate, you need to find out these three things. What, when, and where. You have to forgive me for having the awkward speaker's notes here and computer here because Windows 10 does not agree with multiple displays. So a typical security log, like these sample SSH logs, provides all of the information. The when, the where, the beginning, you've got your timestamp, you've got your host name. And the what at the end. So you can look at a set of logs like this and see that somebody tried to log in as root, or two people tried to log in as root, or possibly the same person from two different IPs, one failed and then one succeeded. With this information, you can determine whether the attack was successful, whether any information was accessed, about how long the attack lasted, and then you can use that information to increase your security. Maybe change the root password or implement stronger SSH policies or even just banning those IPs. All right, so that's a security event, security investigation. What's the big deal about user data access events? How are they any different? Let's take a look at what constitutes a user data access event. For starters, the definition is different. It's an access to user data without business justification. The key point here is business justification. In most companies, employees do have reasons to access user data, like fixing bugs or providing customer support, things like that. A user data access event is when an employee doesn't have a legitimate reason to access user data. So there's a lot of reasons why someone might look at user data. They might be maliciously stalking someone. They might have spotted a family members or a celebrity's account, got curious, decided to poke around, see what they could see. They might be trying to commit fraud. Maybe they're going to access a family members account, provide a few extra services that aren't being paid for, erase a balance, something like that. They may even be simply trying to help someone but aren't going through the proper channels. When you're investigating a user data access event, you need to know the same thing as a security event, where it happened, when it happened, and what was done. But you also need three more pieces of information in order to successfully investigate. You need to know the who and the whom, and that's not just a grammar thing, there's two specific separate things there. Who made the access and whose data was accessed? You also need to know why the access was made, the business justification for it if one exists. Typically, business justifications are represented by things like bug IDs, customer support tickets, or a specific job role or project. These three things work together to determine whether an access was business justified or not. For example, if employee John Smith accesses his wife Jane Smith's account and doesn't provide a business justification, that's kind of sketchy. But if John Smith accesses Jane Doe's account and provides a customer support ticket where Jane Doe called in for help with her account, probably fine. Typical business activity, not really anything to worry about, but John Smith accesses his wife Jane Smith's account and provides that customer support ticket for Jane Doe, that's sketchy. All three of these pieces of information work together to indicate whether an access was appropriate. So of course, in order to know these three things during an investigation, you need to have them in your logs. This means that in addition to the when, where, and what of a security event, you also need to log the who, the whom, and the why. So right about now, you're probably thinking, hold up a sec, that sounds like a lot of work. Why should I even care? So yes, protecting user data is hard. Yes, implementing a new type of log is time consuming and difficult. I'm not gonna stand up here and tell you that it's easy, that it's gonna be a quick job, plug and play, you're done. But this is DEF CON, we know security is hard work, we know that we're used to putting in an effort to defend ourselves from malicious attackers. Shouldn't we want at least as much protection from insider access to our user data? All it takes is one bad egg, one person who can compromise your privacy. These are all real headlines written about real employees who abuse their access to user data. Some of the organizations that I've blacked out are household names. Others are less well known to the general public. But either way, you can bet that the abuses had a really big effect on the organizations in question and an even bigger effect on the victims. And if bad publicity and customers being afraid to use your product isn't enough to motivate you, how about some cold hard law? You like law, right? That's a good thing. Most companies, countries have some form of privacy law that dictates a requirement for companies to reasonably protect their user's data. Depending on the exact country, the exact law, the exact situation and question, you or your company or both could be subject to civil fines, criminal fines, even jail time if you don't adequately protect your user data. And if all of that isn't enough to convince you, it's just the right thing to do. If fosters trust in your users because they know you're trying to protect them and if something bad does happen, they're gonna be a lot more willing to forgive an honest mistake than willful recklessness. Now it is, companies even sell products based on privacy. Look at all the apps where their user model is basically, we don't store your data, we don't store your messages. Or you can think about it from a selfish standpoint. You want your data protected, right? You got all these companies that have your data, you wanna make sure they're protecting it. And when it comes down to the wire, we're human. We like to think we're doing the right thing. Protecting user's data is part of that. Okay, so protecting user data is good for business, good for users, good for me, LRA, we like this. But you might be thinking, all right, I don't have any user data. I'm a simple coupon company or maybe a news website or a security vendor. Totally don't have anything. It's all good. Are you sure? Absolutely sure. You probably have user data. It's nearly impossible to conduct business in the modern world without involving user data in some way. Even buying groceries involves user data if you have a store loyalty card. And things that might seem innocuous at first glance, such as, for example, someone's contact list, might turn out to be a treasure trove of information to a malicious user. An abusive husband, for example, spying on his wife might look at her contacts list and see a women's shelter or a divorce layer. That's gonna be really bad for her. A curious employee might look at a celebrity's calendar and see multiple appointments with a doctor who specializes in a particularly sensitive medical condition. That employee could sell that information to the tabloids. That's bad for the celebrity. Even a grocery store loyalty card can reveal a frightening amount of information about a person. You may remember there's a famous article from 2012 about a very popular grocery store chain that sent pregnancy-related coupons to a teenage girl before her father knew she was pregnant. He was not happy about that. So take a close look at your business. If you collect any data at all from your users, that's user data, and you need to protect it. All right, so you got user data. You wanna protect it. How do you go about actually doing that? I'm scaring everybody away. So before we even get to the logging part of user data protection, we need to start with the people side of things. Logs only tell you what happened after the fact. It's much better to invest effort in preventing abuse before it happens at all. So you wanna make sure employees' job roles are clear. Knowing exactly what any given employee is supposed to be doing at any given time lets you define what accesses they need. And conversely, what access they do not need. Then enforce those job roles. Use strong ACLs, keep them up to date as employees join and leave and change positions. You can't abuse data access if you don't have any data access. You also need to make sure that you're storing your data in a way that allows you to create and enforce good ACLs. For example, instead of dumping everything into one gigantic MySQL database, break out your data into multiple individual tables or even multiple individual databases with separate ACLs. This way, you can allow, for example, customer service to access a customer's billing account without seeing their message data. Or vice versa, you can allow an engineer who needs to debug the messaging system, view the broken messages, but not any of the billing data. Another part of proper data storage is ensuring that everyone who accesses the data store has their own unique ID. Just like you wouldn't give all your employees the root passwords for all your servers, don't give them the admin password for all your user data stores. It's more common than you think. It's kind of scary. I've heard stories. So once your hardware and software are set up to protect user data, you also need to set up your employees as well. You wanna create clear policies and rules about when and for what purpose employees are allowed to access user data. And make sure your employees know and understand those policies. Finally, you need to enforce the policies. Yeah, it sucks if you have to fire someone for accessing user data, but would you rather do that or be the subject of one of those headlines I showed earlier? All right, so now once you've implemented the basic data protection mechanisms, you can focus on your logging. Because while good data protection practices will stop them merely curious, they might not be enough to stop a malicious actor. How you implement data access logging depends on where you get your software. If you write all of your own data access software, then great, you build in your logging system, logging function records everything that you want it to and tailor it to your specific company, your specific environment, your specific data set. It's easier said than done and we'll go into details in a minute. But generally, if you write your own software, you're in a pretty good position. On the other hand, if you use a caught software, commercial off the shelf software, your job is a little trickier. If you have the resources for it, you could write a custom interface for your data store. For example, an admin tool that sits between your database and your employees and handles all the direct interactions with the data. This option is ideal because, again, aside from allowing you to implement proper data access logging, it also gives you greater control over what your employees can access, what data they see and how they do it. It also allows you to track metrics, implement custom tools, do a lot of useful things that you can't with a database alone. But if building and maintaining a custom data access tool is too costly for you and let's face it, sometimes it is, that's a lot of work. You can work with your Cots software vendors, existing logging tools to couple together something that more or less covers what you need. You may not be able to capture everything that we're gonna talk about to make up a complete data access log, but you can probably get pretty close. And close is a lot better than nothing. You can also encourage the company that makes your software to implement better logging, to implement data access logging. It's unlikely to solve your problem in the short term, but over time, if enough people speak out and say, hey, we wanna protect our users' data, companies will start building this in from the get-go. All right, so you're ready to implement data access logging. Do you need to figure out what your data access log your DAO is gonna look like? So reminder, you need to log six things. Who, whom, what, where, when, and why? Let's cover some of the terminology of DAO's start. First off, we have actors and targets, the who and the whom. The actor is the human performing the data access, the person doing the thing, being logged. Each actor gets their own DAO, just like in regular logs. Notably, you shouldn't log when a machine accesses user data. For one, machines are going to be providing all of the services and you're gonna make a bunch of noise to clutter up your logs. For two, machines can't abuse user data. By definition, they only access what you tell them to access so they're not gonna be able to go off and do unauthorized things. You also shouldn't log a user's access to their own data for much the same reasons. Targets, on the other hand, are the subject of the data access. They're the human whose data was looked up. A DAO can have zero or more targets which makes a little more sense than it sounds. Let's say an actor searches for John Jacob Jingleheimer Smith, but there is no user in your database with that name. The actor is still attempting to look up a user. He still issued a query and the fact that no results were returned doesn't mean that the action isn't log worthy. For example, they may have misspelled Jingleheimer so they try again, spell it right and this time they get a result. These kinds of actions together like that, depending on their business justification could potentially indicate something suspicious. So what do I mean when I say the actor issued a query? In a DAO, the query is the input from the actor that determines what user data is displayed. This might be a username entered into a search box, might be a SQL query, it might be a link in a tool that they click on. And yes, you need both the target and the query fields because what an actor searched for may not necessarily be the thing that they end up accessing. For example, let's say an actor needs to look up the account of one William Gates insurance salesman from Wyoming. Searches, gets back results that include Bill Gates, the Microsoft billionaire. If he then clicks on Bill Gates, the Microsoft billionaire, but inputs the justification of William Gates from Wyoming, that's pretty sketchy. On the other hand, if he searches for Bill Gates because hey, even billionaires aren't immune to bugs, then that's probably okay. Which leads me into what exactly is a business justification? That is the why of an access attempt. Before looking up a particular user, an actor should be able to provide a concrete reason why they need to look at that user data. In other words, why they can't use anonymous statistics or maybe a test account or something else that isn't user data. So like I said earlier, typical justifications include bugs, support tickets, a specific project or task and specific job roles. Justification by job role is an ideal since it makes it much harder to spot when someone in that job role actively abuses their access. But depending on your company and your data situation, it might be the only option that doesn't drive employees in that job role absolutely insane. Business justifications do not include any of these other things over here. And yes, these are all reasons that people have provided for accessing user data. No, because isn't a reason unless you're the parent of a toddler. Neither is I wanted to. Yes, we do in fact look at these and no helping a friend actually isn't a good enough reason. There it goes. So wait a minute, why isn't I was helping my friend a good enough reason? If they're helping someone isn't that a valid thing? Not exactly. So first off, if they're legitimately helping someone, there should be a bug or a customer support ticket and they should have put that instead of I was helping. Second, as a matter of policy, you generally shouldn't allow people to work on a relatives or a friend's account. Not only is there the potential for abuse, so hey, while I'm in my girlfriend's account, I'm gonna look at who she's been talking to, maybe what messages she's been sending. But it also completely negates the point of having a customer support or a bug system. Friends and family of your employees should go through the exact same help process as everyone else, both to make sure that any fixes get applied to everyone. You'll cowboy engineering often over there and to avoid even the perception of abuse. So what do I mean by the perception of abuse? That's when a reasonable observer might believe that abuse is happening, even if it's not. And it's almost as bad as actual abuse because it causes many of the same consequences. You lose user trust, you might get legal liabilities depending on, again, the specific laws of the country and the company. So don't even allow the perception. Story time. I said it was gonna be interactive. If you were investigating this access, what would you determine from these facts? Sketchy? Why? Okay, no bug ID. Use the rule of third party over voice. I think it sounds like Smith. Mm-hmm. So those two are the main points. We've got somebody, they're using multiple search terms, they're trying to find a specific person with an unusual spelling. When returning the name didn't work, they looked by email which returned a user account. And then they then provided an invalid bug ID as a business justification. You know, that could be benign. They might have typoed the bug ID. They typoed Jane Smith the first time. But it could indicate that they knew that they shouldn't be searching for her and all. And they provided a fake justification. So this means that you're logging both success and failure? Yes. Yes. And I'll talk about that a little more in a minute. So consider the pieces of information I just gave you here. This is the who, the whom, the what and the why. Typical security logs would only give you the where, the when and the what. That wouldn't be enough for you to figure out what was going on here. Now that we've established what all the pieces of a dial are and why they're important, let's look at a very basic dial written in plain English. There's multiple ways you can format your dials. Protobuffs are good for it. So is XML. You can use a syslog style if you want, just a text string. That's harder to parse for logging systems. But if that's what works for you, then go for it. Here's the same dial written in human readable protobuff over there and XML format. Pretty simple, easy to read. Now let's get complicated. Just like any log, there are endless varieties of user data access logs. So these are some of the more common complications that you'll come across when you're trying to implement user data access logging. First off, front end versus back end. Where should you capture your logs? At the data access front end used by employees or on a central authentication or authorizations back end server. While a back end such as an authentication system has the advantage of being centralized so that you don't have to implement logging in as many places, it's unlikely to have enough information to make a complete dial. Back ends typically don't know anything about queries, about justifications, about any of that. They're just there to respond to requests. A good rule of thumb about logging in general is to log as close to the source of the action as possible and in the case of user data access events, the source of the event is the actor. So you wanna log close to the actor, which means logging in the front end. Multiple targets. Depending on the exact interface used to access user data, you might see any or all of these situations. Incidentally, none of them are wrong or bad. They're all perfectly legitimate ways to access user data. Again, depending on the situation, on the system, on what they're trying to do. You just need to make sure you log all the targets accessed by a given query, which is pretty simple. You just use repeated fields, pretty straightforward. Even in string syslog comma separated, again it's a lot harder to parse, but it's doable. So what about multiple tools? That should be the same thing, right? Repeated fields? Probably not. You should log a new record for each actor tool query combination, rather than stuffing multiple tools in a single dial. Why? Because different tools have different purposes. They store data differently, there's different reasons for accessing them, they're gonna show data differently, and therefore each actor is going to have a different motivation for using each different tool. For example, an actor looking up someone in an administrative front end that everyone in their job role uses, probably not too suspicious. An actor who normally looks up users in a front end, but then turns around and goes and looks someone up in the database, that's pretty sketchy. Breaking out your dials by tool makes these discrepancies a lot easier to spot. And since each access to user data should have a business justification, you wanna make sure to capture the business justification for using that specific tool. If you allow users to provide a blanket justification for multiple accesses using multiple tools, it becomes much easier for them to hide a single malicious access in a sea of benign ones. So how about no query? You might find situations where in your system where an actor is able to access user data without issuing a specific query. So without manually typing something into a search box. You still need to find a way to capture what exactly the actor was trying to look for. Remember, knowing what an actor was trying to see as well as what they actually looked at can tell you much more than either piece alone. For mouse-based interactions, the link an actor clicked on is usually enough. It's good stand-in, it's not gonna be perfect, but a lot of the times if you look at it, it'll have data, you know, click on John Doe. Pretty close. In cases where a tool automatically supplies user data without a specific query by a user, you should probably first look at why your tool does that. Can you modify it to only display user data when a actor specifically requests it? If that doesn't make sense for your tool, then investigate ways to have the tool itself supply the query to the DAO along with the data. So if it's a bug report, you can log the bug ID as the query or perhaps the ID of the user who filed the bug. Sometimes, you'll find that a tool displays user data even though it's not needed for the thing that they're doing. It's just there. For example, your customer support system might show a user's purchase history and billing information even if they're just calling in for a password reset. Or your database is structured so that it is faster and easier to pull all of the user's data instead of the one little subset that the actor needs. In those cases, rather than trying to log around the problem, you should look at why your systems behave that way and try and restructure them so that they're only supplying data when it is specifically requested. No business justification. The business justification is very often the hardest part of a DAO to capture. You can get the other five parts by just recording what is going on in the system, the bits and bytes flowing across the wire. But the business justification comes from the actor. The moment you put a human in the equation, you're dealing with a whole new set of problems then when you're just yanking data off the wire. The most obvious problem is that your tool might not have anywhere to enter a business justification. If you haven't been logging DAOs yet and you don't have it set up yet. If you build your own tool, you can easily remedy this by adding in a little text box that a user has to fill out with a business justification before they can click search. However, this leads to the second potential problem which is that the employees aren't going to like this. It's time consuming. It's frustrating. They have to go look up a bug number. They have to type in a bug number. What are my notes doing? All right, sorry. This isn't an easy problem to solve. Yes, you're are giving up a little bit of employee convenience in order to make a lot of gains in user data protection. You can solve this with user education. Work with your employees to teach them why it's worth it. Or if your systems allow it, just remove the manual aspect altogether. And again, program the tool to automatically enter the justification for them so they don't ever have to do it. What happens if there is no easily available clear justification? For example, frontline customer support reps might take dozens of calls from users an hour. They don't have time to open a new support ticket for each one. You could require them to do it anyway. It would suck. It would slow down your customer support by a lot. You could allow them to all use a single blanket justification like customer call. You could just allow them to use no justification. In those cases, it's really kind of up to you to look at your system, look at the accesses, look at the risk and weigh what's the best thing to do there. So now the fun part. Get examples. So first, quick disclaimer. These are all fictional. So with that out of the way, take a look at this doll. Is there anything that jumps out at you immediately? Family? So yeah, that's not a great justification. And you can then look and see the actor and the target have the same last name. What about the tool you used? Customer support billing? It's kind of sensitive data there. Employee Rose, we see, is looking at her relative Roxy's billing data. Maybe it's benign. Maybe Roxy's having a problem with her account and Rose being the good relative that she is offered to help her out. Still not good, because Rose should have directed Roxy to the proper customer support channels rather than trying to do it herself. Could be benign, but it could also be malicious. Maybe Roxy is Rose's daughter and Rose doesn't want her having an account. She might go in and mess around with Roxy's account to prevent her from having one. Maybe they're in cahoots. Rose might be granting Roxy benefits that Roxy hasn't paid for. Clicky. How about this one? What do you see here that looks sketchy? Targets. I'll give you an extra hint, because this one's not obvious. The bug number is not me being lazy when I made up data for this slide. Yeah. So here we have an actor looking at the accounts of current and former presidents. He's searched for accounts at whitehouse.government.gov email addresses. The tool that he's using, it's message viewer admin. So he probably went in and looked at the messages in our president's accounts. But the bug number he provided is almost certainly bogus. Sometimes actors with malicious intent, when they have to enter a business justification, will try and hide their activity by using keyboard strings, by providing fake justifications with keyboard strings. Things like one, two, three, four, ASDF, whatever the right hand version of that is that I can't remember right now. I've seen that one too. Those are all giant red flags for investigators. One more. You get three dels this time. And time stamps in a readable format because they're important here. So what do you guys see here? What's sketchy about these? Same action on different dates. Anything else? Account deep dive. The combination of repeated accesses over a long period of time is pretty suspicious. We've also got the automatic customer support justification which doesn't provide a lot of information and they're using this account deep dive tool. I talked earlier about setting automatic justifications for some job roles. This is why it's not a real great idea. You can't really tell here if Romeo is working on a particularly long standing customer support ticket or if he's actively stalking Juliet. So cases like this are where your investigation teams expertise and knowledge will come into play. For example, an investigator might be able to dig up a customer support ticket for each of those events which would indicate a business justification. Alternatively, they might know that Romeo's coworkers almost never use the account deep dive tool and they might check Romeo's history and they see that he only uses it to access Juliet. It's a big red flag. So what's this about an investigation team? Where did this come from? So what's the point of logging all of this data if no one's looking at it? Now the one slide clicks over, there it goes. Now that you have your user data access logs, you need a team dedicated to investigating the events generated by these logs. This could be its own team adjacent to your existing sock if you have the resources or you could include it in your sock's regular duties. There's quite a bit of overlap between a typical security event investigator and a data access event investigator. It's the log sources are different but otherwise it's much the same skillset and tools. You also need to make sure that the investigation team has legal support. Security events are typically caused by people outside your organization. Maybe in a few really high profile cases there might be legal action taken but for the most part it's gonna be handled internally. There's no external legal ramifications. User data access events however come from your own employees. Depending on the consequences you lay out in your user data access policy you may find yourself firing people for abuse or taking other employment related actions. You need to have a legal support team to make sure that you're doing everything by the book. Just like with security logs and security events you'll wanna set up an automatic logs parsing system or logs analysis system to help your investigation team sort out the sketchy from the benign. This isn't a complete list. Exactly what you look for is gonna depend on your organization, on the type of user data you collect, on what resources you have to investigate and not all accesses that match one or more of these are going to necessarily be malicious. But they're a good start and your investigation team will be able to develop new rules, more precise rules over time. So that's a lot. That was a lot of information. TLDR. Basically if you have user data in your systems and you almost certainly do you need to make sure that it is protected but typical security logs don't capture nearly enough information to investigate potential access abuse events. You need data access logs, DELs which captures six key pieces of information about every access made by your employees to use your data. The who? Who made the access? Whom? Whose data was accessed? What data was accessed? Where? Which is what tool or system was used? When the access occurred and why? Which is the business justification for the access. Without all six pieces of information it can be difficult or impossible to determine if a particular access was benign or abusive. Once you have all of these DELs you need a team dedicated to investigating them. They'll use many of the same tools as your existing SOC but they'll need legal support to back them up. They'll create a set of rules to monitor for suspicious behavior and they'll investigate events using the information provided by the DELs. Data access logging sounds complicated, sounds like hard work, it is hard work. But we've never let a little hard work stand in the way of securing our users' data. So why would we let it stand in the way of making sure our users' data is protected? By protecting your users' data you're keeping your headlines positive, you're earning your users' trust and above all, you're protecting your users. Questions? Do you have any experience and if so what are your opinions of use DLP systems? The automatic classification? I don't have any experience with DLP systems so it would probably depend on exactly what you're doing, what data you are collecting and how much risk you're willing to accept. I'll say for example... Okay. Potentially. You need to make sure that you aren't either breaching HIPAA yourself in the way that you are implementing the logging or also you're not abusing your employees right to privacy when you're doing this. Any others? Good change management. A large enough team that not one person is responsible for everything. It's a lot harder to slip something by if you have to have your code reviewed, for example, or if there's multiple people working on a system or even if you just have multiple people watching the logs is somebody's going to notice. It's basically who watches the watchers situation and you have to just make sure that you have enough people that no single person is doing all of one job. Cause machine learning is still relatively in its infancy here. You can use it. Again, you want to be careful that you're not generating a lot of noise and that's the hard thing. Especially when you're just implementing the user data access logging there's going to be a lot of noise because you're still figuring out what data you have, how people use it, what are typically used patterns. And so in my experience it hasn't been that helpful yet cause we're still figuring out like where to start the machine learning off. It probably as we develop it more it'll be a really useful tool because then that way no one single like log watcher, event analyst has to try and keep all of this in their head. Like the machine can say, hey, you know, the last 30 accesses by this one person were made using the customer support billing tool and they made two with user admin pro deep dive. You know, that's harder for a human to spot but easy for a machine to spot. So just as we develop, as we get a better understanding of what the rules we know what security logs should be, you know, things to log to watch for in those logs we're still learning what that is in privacy logs. Anybody else? So they're asking what templates and what kinds of strings to search for. So that was, so this is where I would start with the strings and what the string exactly is going to work out to be is going to depend on how your logging tool works. But for example, you can search for like well-known people so maybe put, you know, whoever our current president is search for that string or like the CEO of your company or if somebody's having their 15 minutes of fame, you know, you wanna be watching out for them because somebody might say, oh hey, you know, who's this whoever person? I'm gonna go look up and see if they have an account because I just heard about him in the news. Looking for unusual job role and tool pairs. So for like, and that's where I was saying, you know, last 30 accesses they made were using this one tool. Everybody else in their job role only uses this one tool and now you've got this one person with this job role using an unusual tool. And then the format exactly is going to depend on your system and exactly what you can do. If you have the ability to write your own custom logs, then you can use, you know, protobufs or XML or whatever makes sense for your system and then you can just format them however you want. If you're working with cut software and maybe you're working off of Syslogs or like AWS logs or something, it's gonna be kind of restricted by what those logs give you. Anybody else? Going once, going twice. Thank you very much. Thank you.