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.  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 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?  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.  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.  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.


and NCAAs that year, Bang to Taylor smashed everybody else. Kyle Dakin, Bang to Taylor were two people, Pete just couldn't beat, but he's our general manager and our head coach. He was an animal on top, okay? I get a lot of these small details from him. So we're gonna get to our crab right position right here, but we're gonna be in a claw, okay? When we get to this claw position, now we get to our butt, okay? I'm gonna shift his head away from the side. I have my claw. Everybody see that?  Everybody see that? Shift his head away, my forearm goes on his neck, and I grab my own forearm. Now again, bottom toes trapping, my hand side's kicking. Right here, I'm just holding it to his back. Now I can kinda squeeze it, right? And make it a choke. Again, I'm not trying to be mean. This is perfectly legal. I don't have my arms wrapped around his head, okay? I got a claw, and I got my own forearm, okay? So I shift the head, freehand grabs my forearm, and then I snatch him back to make him to your base. So if I get there in my crab ride, I'm going claw, okay? So I'm double thigh pride, I'm going deep. Again, I don't want my knee on the mat because that means my knee's on the mat, weight's not on him. So I'm jamming, dip, wrap, okay? I float, float, float, float, float, float. Jump in my lap, I got eight points of control. Shift the head, grab my own forearm. Bottom toes trapping, high hand side kicking. I'm just pulling everything nice and tight right here, okay? If he's fighting me a little bit, maybe I pinch my forearms together, okay? Just to say, hey man, just sit down a little bit and give him my three points, okay? And again, when he starts to belly down, I'm back top handed, okay? I can't trap the risk, both my arms are on this side, but I'm back top hand, okay? And tomorrow, when we letting belly down, when we letting belly down, oh, these jokers start coming in. Long day, long day for bottom man tomorrow, long day. Everybody's going to be walking home like this tomorrow, okay? Except for me, all right? I'll walk that way anyways. Anybody need to see it again, can you see it? You sure?


And we have a situation where an unprecedented five candidates are vying for the presidency of the St. Vincent and the Grenadines Football Federation incumbent Carl Dixon will be challenged by former president Marvin Fraser, current vice president Otashi Spring and Wayne Grant along with former national player and senior men's team manager, Renson Haynes. The elections were rescheduled from last November to early this year after FIFA recommended constitutional changes be adopted before a new executive council is in place. Now following a visit to the Islands Federation, FIFA's chief member association's officer Kenny Jean-Marie insisted that the recommended guidelines for new statutes and a revised electoral code be completed by the end of 2023. Now with that process seemingly complete, the elections are set for this Saturday in the capital, Kingstown, searchlight writer, Rohan Thomas has been tracking this story and he now joins us via Zoom to discuss this issue. Well, let me start here, Rohan, great to have you on the Sportsmax zone and I see where the processes outlined by FIFA or script says are seemingly complete. Can you say categorically that it's not seemingly complete but that it is complete? Thank you very much for having me. It's not my first time I've been on Sportsmax a few times before and a few years ago and it's one of my favorite shows, I'm in fact a big Annette Gan fan, I'm a journalist.  Yes. Anyway, to the meat of the matter, basically yes and no because there's not been a definitive vote from the secretary as to Saturday's meeting but if you follow the trends that has in fact the roadmap has laid down by the SVGFF and the secretary, we were supposed to have the final notification of the Congress last on the 11th that has not been, the affiliates have not been notified and the declaration of the candidates was supposed to be on the 12th that was, well that's the nomination of the candidates was on the 12th that was released but the integrity check was supposed to be on the 16th with the 19th being the date for the dissemination of those candidates who are eligible. As the story develops we see that on the 19th just three days after the integrity check was supposed to be the accolation so there is a 20 second and we have not heard a word from the secretariat as to what has happened to the integrity checks and if you notice that there are three days span between the integrity check as well as the informing affiliates of the candidates so which means we can hazard a guess that that has not been done affiliates have not been notified of the who constitute the electoral commission plus the candidates after the integrity checks they have a three day period to appeal those have not been in place so I'm just based on conjecture and the way the trends are taken place and falling that the elections may not take place this afternoon. May not. Can you backtrack briefly though Ruan on the integrity check because I had seen it a few weeks ago that for the first time integrity checks will precede the process of these elections what what are these integrity checks about overall and why was this approach used. Well it's as you said before that FIFA they are on a path of we do in some of the MAs constitutions which and the statutes which have been some a cake to some extent so I think the integrity checks for basically persons who may have when a fall of maybe FIFA maybe even personal civil matters and so on. So that is has been one of the burden issues in terms of going forward in terms of the this present electoral process. You're suggesting Ruan that nothing has been heard about these integrity checks. Does that well what what happened the candidates nominations will fail. Yes. The 12th was the set date for nominations. The release was made of the candidates 33 candidates but these the integrity checks were to be done on the 16th. Nothing has been done. Nothing has been done. Nothing has been done. Nothing has been revealed as to who candidates who have passed or have failed and so on. So but to go back to your question the that has been it has been a new phenomenon in terms of having background checks on candidates. It's new. Yeah. I recognize that and the overall question to we ask. I've never seen in any Caribbean football union territory where as many as five candidates are going going in a presidential election. How is the football fraternity in St. Vincent and the Grenadines embracing such such a number vying for one spot. It's almost unheard of isn't it. Well as you said quite rightly said it's unprecedented. It's not normal for five persons to to be there. But what is interesting is that there are two current VPs. The first vice president and Mr. Tashi spring as well as Mr. Wayne Grant the second VP. He is both are going against the current or the sitting president Mr. Caldickson and we have a former president who served as for 15 months after the ban of Mr. Coombs. He is in the in the race as well as Wrenson Haines as some posts of him from the Vincy Heat fame and so on. He was also a former national player. Yeah. And even the youth level as well. So it's unprecedented. But I think it's that's the way the democracy works. And it is it makes for interesting reading. Right. Rohan you know in Jamaica I could speak for Jamaica because I've lived here now for approximately five years. And well I can speak about Trinidad and Tobago because it's where I was born and raised when there is an election and of course a football election there's a lot of heat on the ground of course you know a lot of controversy a lot of articles a lot of information coming to hand. And the thing about it is even if the information is not present or available people ask they want to know because this involves of course the sport of the country that a lot of people look forward to and they enjoy it also involves a lot of money. What's the atmosphere. I know Lance mentioned it but I want to get a bit more from you. What's the atmosphere like one seeing that the elections didn't happen in December. Now we're in January and we're not sure if it will happen come Saturday. I think the majority of the population wants it over and done with because we have not been able to play football at the national level for some time since last but basically the premiership finished sometime in April of last year and we've not been able to have that premiership played. There's other issues but I think affiliates as well as the business people everybody wants it done with. And as you quite rightly said it's it's really the game of the people. It's it's the only election in the country apart from national elections that the masses get involved get involved because they want to know who will be the next president because football is the most popular sport here. I think the deal they we may just cause a bit more agitation as to what will eventually happen whenever it is called but you to say that we are not into it will be be wrong because the radio programs are flooded with cars. The sports programs are flooded with cars and everybody is dealing with the matter of football. Right. And the last election was in November 2019. Right. Yes. Right. And you know if you had to rate the current administration to where we are now we're in you know it's years later of course you know we're looking forward to more football and to seeing St. Vincent and Grenadines football on the highest level. How would you rate the years gone by from 2019 to now. Well you also take into account a couple factors. One we COVID situation. We had a double bluff double blow I should say not a double bluff but a double blow in terms of the the volcano in 21 but set aside that there have been some infrastructure development and promises of infrastructure development. But I think what Vincentians are really looking at is the our senior team mainly our Vincent team and its progress and its the way it matches up against others in the Caribbean. That has not been to the best in the past four years I must say. But we are seeing some signs of improvement. We're seeing some we are a new technical director being in place from 2021 or 2022 sorry. But that doesn't mean I think people look at the game or the assess the game based on what is on the field. Not necessarily the infrastructure and what goes on administratively that is what people assess the game as. Yeah. From that standpoint. Yeah. Rohan in terms of the unprecedented number of candidates for the presidency of the St. Vincent and the Grenadines Football Federation I suspect the reason we are in this position is because the body voting not to have slates. And so therefore you end up with a situation where independent individuals and as far as the presidency post goes five of those have thrown their hats in the ring but I suspect for other executive positions it will be the same as well. And as far as I understand it this goes against the recommendation from FIFA and this recommendation from FIFA is the recommendation that they would give to all their member federations. Can you give us some insight as to why the St. Vincent and the Grenadines Football Association would have voted not to go slates and the fallout from that essentially. Can you talk us through that. Well that's a issue that has been ventilated in meetings. However what we have are teams. It does not translate. You may say it but it have teams that they are basically running teams or candidates which in a particular behind a particular president and they have it. But the thing about slates you know slates can be good. They can be bad. They can be indifferent depends on what because I think people are looking at getting the best persons in. Maybe some persons from a team may have the best set of persons. But to say a slip or say I don't think that personally that's me. I don't think we're ready because I guess the slates you win one you win all. Yeah. Isn't it potentially though. Isn't it potentially harmful chaotic to the St. Vincent and the Grenadines Football Federation. If you have a number of different individuals from different teams ending up on the executive body and you potentially run into a situation where these different individuals have different goals different philosophies different ideas about how the football is to go forward in St. Vincent and the Grenadines isn't that potentially more harmful more chaotic for the Federation and for football in the country. Well to me if you look at the history of football it has always been that case because we have we have never we had a just in recent times we start having teams of persons having nominated candidates for each position. It will work if you if if you have the persons of the same team been elected. But we can show you that persons who are there would once elected will work. There's only a case of personality. That's my my candid view. It's a case of personality. They may have difference of opinion. But at the end of the day it would be affiliates who will vote for them based on their what they put forward in their manifestos what they put forward individually and one on one meetings with their affiliates. It can work in once we have like mine once persons have the interest of football at heart. It can work because it's not a click or to say well OK an entire state may win. It may happen. It may not happen. But we have to work because we are all in the development of football for St. Vincent and Grenadines. Yeah quickly in 20 seconds. Do you have an understanding of why FIFA would want it this way and would be making the recommendation to their member federations. Go Slate. Because I that's what I'm looking at. They think that they want the best in terms of cohesion. The persons who you you can work with for the same interpersonal reasons where that may have played other MAs before. So I think it's along that line FIFA may be thinking that OK you elect and you elected your Slate so that you can work with the persons who who you could you feel comfortable working with and who have the skillsets and acumen to work with. Yeah. We've got to leave it there. But I just want to get from you very quickly. Is there a favorite for the presidential race. You say there are a lot of radio talk shows going on and so on. Do you get a sense of from the public who they think would be the best person to win. Well there's not a clear cut because they are 53 affiliates. If you look at their shifts they may be shifts maybe once it's time they shift in and who do you think will win. Who do you think will win. I can't answer that because it's a bit too close to call between who. I think everybody goes in with a clear choice. All right. We're going to leave it there. But we'll be in touch throughout the week because as you said at the top we're not 100 percent sure this election will go off. So we'll be in touch and talk about that. Thanks Ron Thomas. Thank you. Search like newspaper in St. Vincent and the Grenadines back with more on the zone after this.