Welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, and together we'll work with business leaders and industry experts to dive into the misunderstood business of cybersecurity and compliance to learn how to start making money from being secure and compliant. Welcome to Cash in the Cyber Sheets.
Hey everybody, welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, Chief Security and Compliance Architect here at Input Output. Very happy to have you back with us this week as we continue our discussion of the Dirty 13, the top audit issues we see when we're doing audits of CPA firms. And quite honestly, it's audits of everybody, uh, shares these top issues.
This week, I want to go into the issues we see around audits and more specifically, logging and monitoring. Pretty serious things there that with the way regulations and insurance are making steps and changes could create some, some pretty nasty, uh, situations for your company. So interesting stuff to get in there, but before we do, please click that subscribe, click that follow wherever you're listening to us, Spotify, Apple podcasts, YouTube, click that follow, uh, send us some comments.
We'd love to hear from you and let's go ahead and jump in to the logging issues. So practically every regulation now, FTC safeguards rule, HIPAA's had it, uh, PCI, ISO 27,001, SOC 2, go down the list. They all require that you have, uh, logging practices.
So you're collecting system logs and that you're monitoring and reviewing those in some, some manner. This is also an area that practically every company we audit has a significant issue. And the reason for that is it's kind of a tricky situation that even when looking right at it, it seems like it's fine until somebody comes and shifts it a little bit.
And you can see, Oh my God, that's, that's an absolute mess. So to get into that, we'll talk about a few things. One of the big ones with logging is the policies and procedures.
There's no real requirements around it. And you may be sitting there thinking, well, no, I can show you right in our policy where it says that, that we need to retain logs and that's absolutely right. Practically every policy says we need to retain logs.
It doesn't specify, however, is what logs do we need to retain? Is that everything? Are we retaining every single log from our system? Are we retaining every Adobe log, every, every software log, everything that's happening and to what level are we doing debugging logs, are we doing just alerts? The problem with the lack of, the problem where I say that the logs aren't specified in policy, how we're going to retain those is that there's no specificity. We need to be more specific with what logs we're going to retain and how we're going to retain those. This goes into the next one of not specifying how we're going to retain our logs and more specifically goes into, we're not retaining the logs as we need to.
So by secting that a few ways, most systems, if it's a windows or a Mac system, will keep the logs, some will keep them until the log folder, the log cache completely fills up, cache, until that completely fills up and it just starts overriding older logs. That may be in some cases, years, the entire life of the product. In some cases that may only be a few days and it creates an issue to where one, if our policy says that we need to retain all of our logs, well, we're not doing that because they keep falling off.
If we're under something like HIPAA, where we have to retain them six years since last use, if we're only retaining a few days or in a lot of systems, an average of 30 to 90 days, that's a far cry from six, six years from last use. If we're doing FTC safeguards, it also goes to our, our policy standards, our retention standards. So if we've got in our policy, this very high level, we're retaining logs, which now, according to our policy, we've got to retain every type of log possible.
We say that we retain our data for seven years. Now we've got to retain every log possible for seven years. This becomes a logistical nightmare.
It's also a situation to where it's not helpful. To be honest, a lot of logs are not any good after 30 or 60 days. If you're going back in time, because it's taken you six months to notice that you had an incident, then that can be helpful in seeing what happened.
Logs that are, that go farther back, but that's an issue. If you're only retaining 30 or 90 days, you're not going to be able to do that. So this creates an issue with regulations.
If we're not maintaining, if we're not backing up those logs appropriately, we're not meeting regulatory requirements. We're also not meeting our policy requirements, which may put us in a situation of being, violating contracts with our suppliers or with our clients. Or in cases, taking it a step further with regulations, if we're violating, say something like HIPAA, and we're also in our practice taking Medicaid, Medicare.
Well, now we're taking money from the federal government and we've made a claim that we're following all of the security requirements, but technically we're not. That puts us at exposure for False Claims Act to where we can get some pretty serious fines for basically making false claims to the government. And it sucks that they're actually using that to give almost a private right of action to HIPAA.
That is a completely different subject that we will get into. But my point here is that the simple little issue of log retention can turn into a major, major risk for the business. Where this also creates an issue is if our policies state that we're retaining all of our logs for say seven years, we go and get insurance.
Our insurance looks at all of our policy, our information security program, and says, this is good. We'll agree to insure you based on this. Well, if we have a data incident and now we can only show 30 or 90 days worth of logs, sometimes less, well, we weren't following our policy.
We weren't following the agreement that the insurance company made with us to insure us. What this can do is create situations to where our claims can even get denied. So this little issue here is not so much of a little issue.
And it's because of how it's structured, because it seems like a little pebble. It's overlooked by practically every organization, but it puts them at such considerable risk. The other issue here, this goes into the not collecting the appropriate logs, but I do want to throw it out because it's kind of important is just not considering all the places that you should be getting logs, your switch, your firewall, any other type of devices.
Maybe you have some Synologies, local NAS systems. You need to make sure that whatever systems you have, you're aggregating those logs appropriately, also your gateway. And this steps into a thing of, well, my firewall only retains logs for 30 days or my gateway only retains them for 15 days, how are we supposed to, to make considerations there? Well, one that comes into how you structure your policy.
You can avoid a lot of issues here by just getting more specific with your policy and stating here are the logs that we're going to maintain, here's how long we're going to maintain those logs. And if there are systems that, that you just, there's no way that we can retain logs any longer. Put risk exceptions in place or compensating controls.
Listen, I can't retain all the logs on my router, but we're doing it with our firewall. And we're doing it with all of our other systems. So we'll be able to see if there's an intrusion where the hops took place.
And especially in the case, if we're retaining all of our firewall logs, it, it's a small jump from the router to the firewall, it doesn't really matter. So it's important with your policies to make sure you're just getting very specific with the type of logs that you retain, how long you're going to retain those logs and how you're going to retain the logs. Another big issue is even in cases where the logs are being appropriately identified, they're being appropriately retained, which is practically never.
But even in cases there, another big issues, issues, another big issue that we see is a lack of monitoring and review. There's no real point for logs. If they're never reviewed, they're never, if they're not monitored in practically every regulation has stipulations in there that you're collecting the logs and you're monitoring and reviewing them so that you can see if there's any type of abnormal behavior so that you can identify an incident quicker so that you can take action against unauthorized access sooner rather than later.
It's a very difficult thing to review logs. I don't know if you've ever pulled an actual, actual set of logs and looked at them, it's, it's not fun. There's millions and millions of lines of these, you can't go through it all.
And even in cases where you can parse the data, that turns into a situation where, well, are we going to look at every single system? How do we do that? A good way to manage that comes into our, our primary recommendation, which is getting a good SILM. Now I want to, I want to hit pause here real quick and talk about SILM or SIEM. Which one is it? And this kind of comes into a potato, potato situation, but not so much.
And here's why you have SILMs out there, S I M, which are security information management systems. You also have SILMs out there, S E M security event management systems. And a SILM is basically a SILM and a SILM together.
Does that make sense? It should, it's real simple. So S I E M security information and event management systems. It's just the, the, a SILM, an information management system and event management system coming together.
God, that's even difficult to get. So in some cases, you'll hear some people state it as a SIEM. Technically it, it really is a SILM and for what it's worth, that's a little painful to say, just like saying a JIF, but whatever it's actually should, should be SILM, we'll call it SILM.
That's what we mean. Now back to our regular, regularly scheduled program, get yourself a good SILM. What this will do is aggregate all of your logs into one central location.
You can parse out or scrub out all the ones that aren't relevant at all. Just make sure that's in your policy and that it meets with regulatory requirements and practically every SILM also provides alerts. So if the SILM sees something that's out of line in any of those logs, it's going to send you an alert.
And what's really easy is you can have that come right to your email or right to your IT ticketing system. So anything abnormal is coming right to you and you're monitoring it. This way you're meeting your monitoring requirements.
You're not having to go out there and look at every single system, every single month. It makes things considerably easier to manage. What the SILM also does is now that all of your logs are aggregated in one location, some of them will continue to back those up for you for as long as you need them, seven years or more.
A lot of them will also allow you to export those. So maybe they'll only retain them six months or a year. You can export them, store them in your own backup, and then in that way, if you ever need them, they're there, but you're not having to pay that huge expense to back them up at the SILM provider because sometimes that can be pretty costly.
A lot of information we could give about SILMs, but biggest thing is that they can help tidy up all of your information security logging, retention, aggregation, monitoring, and review requirements all in one nice little package, very worth all the money that you spend on them. And a lot of them aren't even really that much money at all. Some other quick things just to go through is I would, I would feel remiss if I didn't bring it up just because it's in a lot of documents and we hear it all the time in security talks, but making sure that you're using a single authoritative time source, that all of your systems are on the same, basically on the same time.
And that's extremely important. You definitely want to make sure that's in place. I don't ever really see that as an issue with practically every system.
Now they're all pointing to some authoritative time source and there's multiple ones, there's multiple failovers. What we do see sometimes more is time zones not being set the same. So it would probably be useful to set all of your time zones the same and just, just validate that the same authoritative time source or that an authoritative time source is used.
So that way, when you ever have to review the logs, all the times match up, it becomes an absolute nightmare. If you try to review logs and the timestamps are off for a few minutes or seconds or whatever it just makes it that much more difficult in the great scheme of things that used to be an issue. Like I said, it's not really, I don't, I can't even remember the last time that, that a company got dinged for that.
They always seem to have it together. But the biggest thing that we do see just, and I can't stress this enough, is companies being too broad in the logs that they say they retain and not actually retaining them. Also just tying that in, a lot of people, even IT companies assume that their online provider, Microsoft 365, Google is retaining all of the appropriate logs, a lot of those only retained for 30 days, unless you pay for an enhanced license and it's a very big and here, you actually set it up.
If you don't set this up properly in your online environments, this could be another situation where you're not actually collecting the logs that you need to, and that all ties into your audit issues because if you're auditing your security controls and validating that you're following everything, this is something that you should be able to notice, but again, it is one of the most common issues that we see. I say that with every dirty 13, but this is really one of the most common issues that we see and one that takes a good deal of very specific explanation and sometimes visuals to show that they're not actually following requirements because it's so easy to, based on what you have in policy, based on your practices, to assume that you do have everything under control and you definitely do not want to be in a point to believe that you do have it under control and then find yourself having to pay regulatory fines or not get an insurance payout because you actually did it. That is all we have today for our audit logging and monitoring issues of the dirty 13.
Thank you very much for listening. Please click that subscribe, click that follow, and I can't wait to see you all next week.
Thanks for joining us today. Don't forget, click that subscribe button, leave us a review, and share it with your network. Remember, security and compliance aren't just about avoiding risk. They're about unlocking your business's full potential. So stay secure, stay compliant, and we'll catch you next week on Cash in the Cyber Sheets. Goodbye for now.
